GitHub Organization Owners
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, check with emailremoved@.
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 repository 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.
Billing: See go/github-billing for details on how billing is now handled. Additionally, please add the Google GitHub Owner account as a billing manager. This lets us see billing alerts should there be a problem with your payment method.
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 ask emailremoved@.
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.
Webhooks: Organizations must be configured to enforce CLAs for all pull requests by following the instructions at go/cla/github.
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 accounts: All Google organizations must include the Google GitHub Owner account as an owner, as well as the googlebot account which is used to manage CLAs. Both of these accounts are managed by OSPO, accessible only to a small number of engineers in the open source office, and have two-factor authentication enabled.
Additional accounts: In addition to the accounts listed above, most organizations will also include representatives from the relevant product or DevRel team in the GitHub Owners. While it is common in google3 to have your entire product team in your OWNERS files, this is not the case for GitHub. GitHub organizations should contain at most 2-3 owners from the product team: one primary point of contact, and one or two backups.
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.
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/github-kitten).
Migrating existing open source projects to your org is generally fine, and some teams at Google have specific exemptions, but if you are at all unsure as to whether this applies to you, contact emailremoved@ before setting up new repos.
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.
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.
Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.