GitHub Permissions Structure
- Jason Antwi-Appah (Unlicensed)
This is adapted from a doc written by @David Launikitis that also discussed changes to GitHub permissions within the org.
Organization Permissions
Leadership
Officers and Head of Engineering should be assigned ‘admin’ permissions on the organization. Although this won’t be needed on a day-to-day basis, organization admins are able to modify anything on the
Other Members and Contributors
Other contributors should be invited to the GitHub organization with ‘read’ permissions. Alumni/inactive contributors can remain as org members as this only assigns read privileges to repos.
todo: only org admins have the permissions to add people to the GH organization and we need a way for project leads to do this. David and I discussed creating a Discord bot to do this. We could also set up a small web server to handle webhook payloads from GitHub whenever a user gets added to a team and automatically invite them to the org
Project Repository Permissions
GitHub teams are used to manage permissions for projects.
Contributors should not be directly added to project repositories. Using teams exclusively to manage permissions makes it easier for us to see what levels of access a given person has. It also makes it easier to keep the permissions up to date as people stop contributing/join teams, or as new repos are added for a specific project.
Project Teams
The project lead should have admin privileges on all the teams for their given project, allowing a lead to assign members to their teams. This needs to be explicitly set on the parent project team and the child teams since an admin of a parent team doesn't automatically become an admin on child teams.
<project name> Reviewers
This team does not add any permissions to a given user. Members of this team are automatically assigned as pull request reviewers via a repo’s CODEOWNERS file (see the Code Reviews and Branch Protection section for more details)
<project name> Contributors
Members of this team will be assigned the write role on the corresponding repositories for a given project. This is intended for frequent contributors to a project, including recruits.
<project name> Maintainers
Members of this team will be assigned the maintain role on the corresponding repositories for a given project. This is intended for trusted contributors for whom the contributor permissions do not suffice.
<project name> Lead
Members of this team will be assigned the admin role on the corresponding repositories for a given project. This is intended solely for the project lead.
For details on what permissions each repository role assigns to a user, refer to GitHub’s documentation: Repository roles for an organization - GitHub Docs
Code Reviews and Branch Protection
All projects should require changes to
developormaincome from PRsAll PRs should require one review from someone who isn’t the PR’s author before being merged