Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add Github Access Structure Overview section #5503
base: master
Are you sure you want to change the base?
add Github Access Structure Overview section #5503
Changes from 2 commits
a2d842f
97f8406
8846507
f5b6eaa
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels redundant, maybe just delete the second sentence?
Is that true? I thought we could manage that with a team where the team was added as admin on the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I missed this comment.
For
I feel like Im spliting hairs here, but you are correct that we can do that. I see benefits to the approach, however, I also see it as creating extra teams to manage and becoming confusing/hard to parse.
Let's say we have 8 different repo captains in a given org and together they captain 12 repos (assuming that of the 60ish repos across all orgs, most repos will not have a captain, but that some people are captains to multiple repos).
That makes 12 unique Github teams. One for each repo, as I understand the suggestion. That's a lot of teams, and will grow as we add more captains. Benefits I see are it's simple enough to onboard someone to the permissions, create the team if it doesn't exist and add admin rights on the given repo to the teama, invite the captain. Offboarding means removing them from the team. The above can be accomplished via individually applied permissions as well, without creating 12 teams of 1. That's basically my whole argument, fewer teams to manage, and if we expect mostly 1 captain per repo the team approach is no less adhoc than individually applied permissions to a user account.
We could also have a situation where a captain steps down without one stepping up. We either delete the team outright, or let it coast as something which can be @ mentioned but has 0 members to see the ping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to bikeshed on this. I will be happy with whatever approach is picked. I brought my own opinions after thinking through the above. I'd prefer to do everything via teams, but I don't think teams map well to the repo captain concept when it comes to applying permissions due to noise/overhead created by teams of 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what this means. All of this will be manually managed 🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Manually here means going into settings in github, selecting a given member from the org and setting their bespoke permissions (write on expressjs/body-parser, expressjs/multer, for example). Removing their perms requires the same manual work.
Contrast that to permission management with teams. TC/owners get admin on everything in the org. You can give those specific perms to a team, and then just add the user to the team. To revoke perms, remove them from the team.
That works well for TC and Triage, who have a homogenous set of perms, but not well for folks w/ ad hoc write access like Committer or Project captain. Which forces you to manually manage perms for individual accounts in the Github UI. It's extra work but I don't think there's a better way.
Here's github docs about these two different approaches which they call "Individually managing access" and "Managing Team Access". These are both very light docs that link to the same place, but they are two distinct access management strategies.