NOTE: This information applies to owners of existing GitHub organizations. If you think you need a new org, stop and follow go/new-github-org. Do not create a new org without talking to emailremoved@.
If you just administer a particular repository or two, you can stop reading now, though go/github-docs may be of interest. Organization owners have some pretty serious access and we trust you to handle it responsibly.
Some organizations have exceptions to some of these rules (they generally know who they are). If you're unsure, file a bug and we'll check.
Point of Contact
All organizations must have a primary point of contact, who will be listed at go/github/orgs. This individual will ultimately be responsible for ensuring the org is configured properly, reviewing go/releasing requests for new repos in the organization and flipping the "GitHub Owners" approval bit on Ariane launches, and handling other requests as they arise.
If the primary contact changes teams or is planning to leave Google, please email file a request to set a new primary contact.
Settings
Go to the settings page for the organization, and make sure it is set up as specified below.
Profile: Add a profile picture if you have one. If you don't have one, try to come up with one and fill out the rest of the profile as much as possible; it helps make a good first impression when people find your repos.
Member privileges: The option to allow members of the organization to create repositories must be disabled. The default repository permission is up to you, but you should generally err on the side of caution by giving members less access by default. You can always set up teams to grant more access to the folks that really need it.
Third-party access: Third-party application access restrictions must be enabled. If anyone in your organization requests to approve an app, you must ensure that it complies with the policies at go/github-docs#services. If in doubt, don't hesistate to file a bug.
Two-factor authentication: The option to require members of the organization to use two-factor authentication must be enabled. This affects both organization members and outside collaborators. See go/github-org-2fa for information on enabling two-factor authentication on your organization and how we enforce this setting.
Installed GitHub Apps: Organizations must be configured to enforce CLAs for all pull requests by following the instructions at go/cla/github.
Repo settings:
- Repository creation should be disabled for all members.
- Repository visibility changes will only be handled at the org-owner level.
- Repository deletion/transfer should be disabled. This will be handled by org admins or tooling.
Owners
Organization owners have full access to the organization, including the ability to modify billing information and even delete the entire organization. Therefore, we are very cautious about giving more people this access than really need it. Fortunately, there are very few things that most Googlers would ever need owners access for.
Required: All Google organizations must have the following owners:
- Google GitHub Owner (for administration)
- googlebot (for CLA management)
Both of these accounts are managed by OSPO and are accessible only to a small number of engineers.
Additional: GitHub organizations should contain at most 2-3 human owners from the product team: one primary point of contact, and one or two backups. While it is common in google3 to have your entire team in your OWNERS files, this is not the case for GitHub.
If you need to give your team access to a large number of repositories, do not use owners access for this. Create a GitHub team and give that team access (admin if needed) to the necessary repositories.
Creating repositories
Being the owner of a GitHub organization is not free license to create new repositories whenever you want. With only a few exceptions, all new open source projects must go through the go/releasing process before code is published on GitHub. This is the policy of both the open source office and the Google Security team (go/sourcecodeguidelines).
Granting access
GitHub allows repository access to be granted in two ways, either by adding the individual as a collaborator on the individual repository, or by adding them to a team in the organization which may have access to one or more repositories. See the various repository permissions that an individual or team can be granted on a repo.
NOTE: Before adding a user to an organization, team, or repo, please consider if it's actually needed. If the user just wishes to make a small number of changes, forking a repo and sending a pull request is the right approach.
Organizations are generally free to choose how to manage access, within the following limitations:
Googlers can be granted any level of permission on a repository that is needed.
Non-Googlers should not be granted admin access to any Google repositories (see go/github-docs#contributors).
Automated systems (either google-authored or third-party) have special rules at go/github-docs#services.
For most GitHub orgs, only Googlers should be added as members of the organization, and outside contributors should be added as GitHub collaborators.
NOTE: Googlers must register their account at go/github before being added as a member of any Google GitHub org. It is the organization owners' responsibility to ensure Googlers are registered by looking them up at go/github before inviting them to join the org.