GitHub Team Discussions in jenkinsci GH Org

[Radek Antoniuk]

I'm sure than other people co-maintaining the plugins over the world also have the problem that we have multiple ideas and discussions regarding project maintenance.

Those obviously could be maintained in GitHub Issues, but since we have dedicated GitHub Teams per plugin maintainers, I'd like to use this feature to discuss new ideas on a "threaded" basis directly in GitHub.

However, when I went to our maintainers team of jira-plugin and tried to start a discussion, I saw:

Team discussions are disabled for this organization.

Learn more or contact an administrator to enable this feature.

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.

WDYT?

[Gavin Mogan]

I'm super conflicted about this.

On one hand, I totally support freedom of choice, and it would be limited to plugin teams only, not the general public right?

On the other hand, I think the project suffers from a fragmentation problem

* "Who" - I wouldn't want another set of teams, as is the team member list is poorly maintained, there's a list in pom.xml, the github team, the repo's collaborators, and https://github.com/jenkins-infra/repository-permissions-updater

* Mailing list

* Jira

* Github issues (maybe)

* Gitter

* Irc

* Slack

* Zoom Meetings

* Special Sigs rooms

I'd be curious to see how many want it. Personally I think more discussions should happen on the dev mailing list, so info is shared, and more eyes on, etc.

Gavin

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a0c85aae-a1f5-4ca7-89be-12b7b66d1534%40googlegroups.com.

[Daniel Beck]

> 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?

[Slide]

I concur with Daniel. The conversations should be in the open.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B2A2C585-DD52-4221-A644-D0D858F0C7F9%40beckweb.net.

--

Website: http://earl-of-code.com

[Oleg Nenashev]

I agree about the public vs. private notion. Team conversations are hard to access for GitHub org members, and they are basically inaccessible to external contributors and visitors. My recommendation would be to use public channels where it is possible, and I am -1 for GitHub Team Discussion as a general communication channel. Alternatives I would recommend:

• GitHub Issues: Actually they work pretty well as a public forum. Ideas/proposals/questions can be labeled accordingly, and it is possible to configure automation around them
• Chats: There are many Gitter channels for plugins, and this approach seems to be okay. Not everyone likes Gitter (me neither), but at the moment it looks to be the most convenient way

For me the only use-case for GitHub Team Discussions is private communications: coordinating security fixes, resolving escalations and disputes, etc. I hope plugin maintainers have too much traffic of such kind.

Would be great to get more feedback from plugin maintainers

Best regards,

Oleg

 

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B2A2C585-DD52-4221-A644-D0D858F0C7F9%40beckweb.net.

--

Website: http://earl-of-code.com

[Daniel Beck]

> On 26. Mar 2020, at 08:30, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> For me the only use-case for GitHub Team Discussions is private communications: coordinating security fixes

Not a good choice in that case either.

We'll soon update the docs on that, but even if maintainers discover issues in their own plugins, and can fix them themselves (which is already a notable hurdle -- fixes are incomplete or ineffective more often than one would expect), they should file issues in the SECURITY project or email the security team. That way we can properly inform users about the issue once a fix is released via the usual and expected channels, not to mention auxiliary benefits like being able to see trends, or to investigate other components for similar issues.

[Radosław Antoniuk]

On Thu, Mar 26, 2020 at 8:30 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:

I agree about the public vs. private notion. Team conversations are hard to access for GitHub org members, and they are basically inaccessible to external contributors and visitors. My recommendation would be to use public channels where it is possible, and I am -1 for GitHub Team Discussion as a general communication channel. Alternatives I would recommend:

• GitHub Issues: Actually they work pretty well as a public forum. Ideas/proposals/questions can be labeled accordingly, and it is possible to configure automation around them
• Chats: There are many Gitter channels for plugins, and this approach seems to be okay. Not everyone likes Gitter (me neither), but at the moment it looks to be the most convenient way

For me the only use-case for GitHub Team Discussions is private communications: coordinating security fixes, resolving escalations and disputes, etc. I hope plugin maintainers have too much traffic of such kind.

I agree with Oleg's approach. GH Issues are fine for me too. My usecases for the team discussions where e.g.:

-  "when shall we release X" - coordination

- project type work, like discussion about migrating from JIRA to GH Issues

but indeed both of those could be tracked in Issues - it just feels that's not really the exact place for them to be but transparency sounds like a good argument.

 

I am against chats as they neither have visibility or transparency. The work in the plugins is often happening on the "when i have time level" and then tracking multiple discussions/subjects, their goals and what was agreed or not - in chat is impossible.

Thanks a lot for all input, that was really worth it learning about the decision path!