Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

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.

WHat does this do and why

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: we need a way for project leads to add people to the github organization. as of now, only org admins have the permissions to do this. David and I discussed 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

<project name> Lead

<project name> Contributors

<project name> Maintainers

<project name> Reviewers

The project lead should have admin privileges on all the teams, 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.

Code Reviews and Branch Protection

  • No labels