Github way to address @committers/@project-leads/@pmc

Can we have a way for github hosted projects to have @commiters, @project-lead, @pmc groups to ease including all/PLs/PMC in certain discussion looking for their guidance? There is https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads but it's private so people are not aware of it and also can't/don't use it when they need PLs attention.

This would be great also to have an overview in

https://github.com/orgs/eclipse-equinox/teams and https://github.com/orgs/eclipse-equinox/people

just open these in a private browser tab and you will e.g. see that only two people are "public" (why? can I change this??).

At least PMC + Project lead should be required to be "public visible", given that on the project page everyone is showed "public" I don't see why we should hide those at Github.

Funny enough it seems I'm allowed to just create a new team:

I'm pretty sure that you shouldn't be able to create a new team. @webmaster can you confirm/lock this down, please?

Also... there is no "project management council". The Eclipse TLP has a "Project Management Committee" (PMC). Eclipse Equinox does not have a PMC.

I've walked all the organizations Webmaster is an owner on and have removed the 'create teams' permission.

I changed mine to public. I have not idea what/when/why set it to public

Yep I also changed this, when you make it "public" it seems that in your profile one now can see that you are part of the "organization".

added IT-severitylow ~16280 labels

For the PMCs using the Mailing lists(*-pmc at eclipse dot org) is still probably the best option if you need their attention.

Groups for committers/pls already exist(and have a specific format), so you should be able to @ them. I suppose the only real question is: should they be publicly visible? In this day and age I would lean towards keeping them 'private' , but I don't have a strong opinion on it. @wbeaton what do you think?

If we're talking about making the group names known, I have to problem with that. If we can use that information to @ folks by role, then that's great (and something that we should document in the handbook). If the intention is to @ by role, then it should be unnecessary to display the identity of the people in that role.

Having said that, wee make PL and CM status public in the PMI pages; calling the Eclipse API will give you a committer's GitHub Id; and committer email addresses are already accessible via Git commit records. So I'm not too fussed by making the identity of PLs and CMs visible via GitHub.

I think that I've answered the question. Let me know if otherwise.

I've filed a ticked with the webdev team to see about getting this fixed.

For me it seams that teams are always only visible to organization members see: https://docs.github.com/en/organizations/organizing-members-into-teams/changing-team-visibility

So "public" teams are visible for everyone that is signed in and is member of the eclipse/equinox/... org:

• Visible teams can be viewed and @mentioned by every organization member.
• Secret teams are only visible to the people on the team and people with owner permissions. They're great for hiding teams with sensitive names or members, such as those used for working with external partners or clients. Secret teams cannot be nested under parent teams or have child teams.

mentioned in issue eclipsefdn/it/webdev/eclipsefdn-vc-tools#212 (closed)

I am not sure of the utility of adding @ mention groups for committer/etc on GitHub. Most committers are already subscribed to the GH repo and already get all the emails. So @ mentioning committer will not put an email in the inbox of a committer that they were not already going to get.

My goal with @ mentioning groups is to be able to say - Please advice as a @ PLs/PMC or similar and people from respective groups get explicit mentions without requester having to first check who are they. I agree that 'committers' probbaly makes no sense, I added it initially for completeness.

Everyone can actually choose to only get notified by GH if explicitly mentioned!

So something like @committers could be useful for explicitly requesting additional feedback from others as well.

Everyone can actually choose to only get notified by GH if explicitly mentioned!

Sure, and committers can also unsubscribe from the -dev mail list but then they are not really good committers. And if they are choosing to not be good committers, then trying to rope them back in with @committer will not please them either.

And there is a difference between not being notified at all or notified under certain circumstance, e.g you can select to not be notified about new PR bust for new issues, still if someone is mentioned you gets a mail for that particular PR comment then... nerveless the discussion getting a bit offtopic as even if some won't use it or it might not be useful in all cases it could still improve the way we are currently working

By default there are now several groups for Eclipse projects hosted on separate GitHub organizations:

• <project-short-name>-committers
• <project-short-name>-project-leads
• <project-short-name>-contributors

example: automotive-velocitas-committers for the github organization eclipse-velocitas.

The created teams are made secret till now as there is a technical glitch with GitHub that members of the organization could create teams on their own with one of the existing teams as parent. These created teams would inherit all the permissions of the parent team.

This possibility can be prevented by a setting on organization level, but this has to be done via the Web UI only and it was considered to be too dangerous to purely rely on this flag to be set correctly.

In the meantime we have worked on a tool called otterdog to make sure that settings for GitHub organizations are more consistent and match a certain policy. When this tool is enabled for your project, we would be able to make these existing teams public so that you can mention them or reference them in things like branch protection rules or the like.