Governance: better define github permission setup#28840
Conversation
| * Invitations to contributor events | ||
| * Eligible to become a Reviewer | ||
| * For repositories hosted on Github, Contributors receive Read privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. | ||
| * For repositories hosted on Github, Contributors receive no special privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. |
There was a problem hiding this comment.
to be clear because all repos are public all userd have read permissions, we have no real process to assign read permissions as because doing so is not useful I rather just say they receive no privileges then dealing with updating user permissions.
| * Has permissions to change labels on Github to aid in triage | ||
| * For repositories hosted on Github, Reviewers receive Triage privileges | ||
| * For repositories hosted on Github, Reviewers receive Triage privileges by being added to the `<repo-name>-reviewers` team. | ||
| They also will be invited to the `podman-container-tools` Github organization as member. |
There was a problem hiding this comment.
adding them to the team automatically invites the as member to the org, the user has to accept that invitation
| * Have a vote in Core Maintainer decision-making meetings | ||
| * For all repositories hosted on Github, Core Maintainers receive Admin privileges. | ||
| * For all repositories hosted on Github, Core Maintainers receive Admin privileges by being added as `podman-container-tools` | ||
| Github organization Owner. They keep being a member of the `<repo-name>-maintainers` team to also receive pings for normal maintainers. |
There was a problem hiding this comment.
The second sentence is a bit unclear. Are core maintainers required to be on every repo's -maintainers team? This should probably be rewritten as optional - "Core Maintainers may also choose to be a member of any repo's -maintainers team in order to receive pings to maintainers and assist in code review and maintenance. This is not mandatory but it is strongly encouraged to subscribe to at least one repository in this way"
There was a problem hiding this comment.
We can argue abut this but I rather have this non optional.
I like to have a script which can actually check all permission against the maintainers files, any special case needs extra work there and in the end you may end up missing many important pings?
Who do you ping on maintainers votes otherwise if not all maintainers are ion this group?
I think it depends on how do you expect pings to be used, if everyone pings this group on any repo for any review sure that likely will be to much. My personal experience is that most team pings like that get ignored already and it is much more effective to ping by name directly and just the ones you really want a review from.
Ideally asking for a basic review doers not need a ping to everyone all the time, maybe some day we get there where all people review without being prompted explicitly
There was a problem hiding this comment.
And if being a core maintainer gives you rights to all repos than there should be a implied requirement that you can (to some extend) review and work on all repos.
There was a problem hiding this comment.
Alright. If this is mandatory, it should be a new bullet point, separate from Admin privileges.. Recommended wording:
* For all repositories hosted on Github, Core Maintainers will be added to the <repo-name>-maintainers team. Separate from the permissions granted above, this ensures that Core Maintainers receive pings meant for repository maintainers, as part of their responsibility to assist in code review and decision making in all repositories
| * Represent the project in interactions with the CNCF | ||
| * Have a voice, but not a vote, in Core Maintainer decision-making meetings | ||
| * For repositories hosted on Github, Maintainers receive Maintain privileges by default. If they have a legitimate reason to require Admin privileges (e.g. working on project CI systems), a Maintainer can petition a Core Maintainer to be granted these additional privileges in Github. | ||
| * For repositories hosted on Github, Maintainers receive Maintain privileges by default by being added to the `<repo-name>-maintainers` team and removed from the `<repo-name>-reviewers` teams. |
There was a problem hiding this comment.
Is removing from -reviewers right? I’m thinking “who should PR submitters ping” — that should ideally be ≤1 group. But then again, maybe we should aim for “ideally no-one because it will be unnecessary” :).
There was a problem hiding this comment.
we can all have them in reviewers if this is what people prefer
|
LGTM |
1 similar comment
|
LGTM |
| * Invitations to contributor events | ||
| * Eligible to become a Reviewer | ||
| * For repositories hosted on Github, Contributors receive Read privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. | ||
| * For repositories hosted on Github, Contributors receive no special privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. |
There was a problem hiding this comment.
| * For repositories hosted on Github, Contributors receive no special privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. | |
| * For repositories hosted on GitHub, Contributors receive no special privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. |
There was a problem hiding this comment.
this exists all over the doc though, so if it should be changed it must be done consitently
There was a problem hiding this comment.
pushed a new commit to replace it
|
The intent and direction looks good to me, just a few scattered nits and changing the last bit per Matt's suggestion. I too found those two lines to be confusing. |
Define the team rules we already used before, this makes it explicitly how the users should be given their access. In short we should add users to the github teams and not add them individually to the repos. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As suggested by Tom, by rename Github to the more common spelling GitHub. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
6 participants
Define the team rules we already used before, this makes it explicitly how the users should be given their access.
In short we should add users to the github teams and not add them individually to the repos.
Does this PR introduce a user-facing change?