> On 25. Mar 2020, at 17:34, Radek Antoniuk <
radek.a...@gmail.com> wrote:
>
> Tim Jacomb mentioned that the reason for this is that the teams were often re-created in the past, but I think that:
> - if we assume that each plugin "automatically" has a long-lived team that is called "<pluginId>-admins" or "-maintainers" and that this one is not deleted, but only members are changing
>
> then I would propose to re-enable GH Team Discussions and let the plugin maintainers decide if they would like to use it or not.
Tim is mostly correct -- While it's not a regular occurrence, we delete teams whenever we feel like it (or at least I do). For example, if a plugin repo gets renamed, the names no longer match: 'old-name Developers' grants permissions to 'new-name'. If we've granted permissions in the mean time, there might even be multiple teams related to the repo: old-name Developers, and new-name Developers. Nuking and adding permissions again, if needed, is easier than manually trying to merge them.
I've also had some fun conversations with GitHub support who cannot believe our per-repo team model. It seems the way we're using teams is _very_ unusual. I've wanted to get rid of them for quite some time, replacing them with external collaborators and some automation around it for org membership, but it looks like this never seems to make the cut.
So when GitHub introduced team conversations and the option to disable them, I did just that -- to not unnecessarily complicate administrative actions, eliminate the potential for accidental data loss by deleting teams with conversations, and allow for an easier migration away from teams.
Personally I would rather see discussions in issues or pull requests in the open, than in private in teams. Since there's a 1:1 relationship between repos and most teams, most notably the ones you're discussing here, what's the benefit of team conversations over GH issues or PRs?