Google manages quite a few organizations on GitHub (go/github/orgs), and with the amount of open source code that we release, we regularly get requests for new ones. But adding new orgs comes with both management and monetary costs.
When a new organization is warranted, we're happy to help set that up and assist you in using it effectively. But a project may be better suited for one of our existing GitHub orgs, or perhaps a different source control system altogether.
IMPORTANT: To request a new organization, file an issue using the organization request template (go/new-org-request).
Why is a new organization needed?
Describe your intended use of the organization in detail. Explain why your goals cannot be achieved with new repositories in an existing org (go/github/orgs).
Keep in mind that projects can always be moved out into a separate organization down the road. This is in fact exactly what happened with kubernetes, bazelbuild and others, all of which started out in one of our shared organizations. Repository moves between organizations are relatively seamless – GitHub will automatically redirect web and git traffic, and everything on the repo itself (stars, forks, issues, pull requests) remain intact. We strongly prefer incubating projects in an existing org first, and then move them out to a standalone org only when that is really needed.
Who is going to be responsible for this organization?
Identify two full-time Googlers who will be responsible for this organization. These two persons, and generally only these two (not including "Google GitHub Owner"), should be added as owners of the organization (see go/github-org-owners#owners). They will be responsible for setting up the organization profile, inviting the rest of the team to join the organization, making sure the entire team understands the rules of engagement for GitHub, etc. Make sure that these two people understand these responsibilities and have the time and resources to dedicate to it.
If and when we receive new go/releasing requests that ask for a repo in this organization, we will delegate the "GitHub Owner" approval bit to these owners. If you prefer, you can also set up a group which we will assign that bit to.
Succession planning
If and when organization owners leave Google, you must have a plan in place to replace them with someone new. If an org becomes truly abandoned and we're unable to find someone to maintain it, we will likely look at turning it down and moving the repos elsewhere.
How large do you anticipate this org being?
- How many people will you be adding to the org at launch? Within six months?
- How many repos will you be adding at launch? Within six months?
- How heavily is this org going to be promoted? Is this something big like TensorFlow or a more low-key release?
Is your leadership committed to staffing the organization?
Maintaining a GitHub organization takes some time. Organization owners will be responsible for approving requests for new repositories in the org, day-to-day tasks such as inviting Googlers to join the org, and tasks related to security and compliance.
As part of the approval for a new organization, we ask for a formal commitment from your leadership (director or above) to appropriately staff the org to handle these tasks for the foreseeable future. This should be included in the org request bug. We understand that plans change and sometimes projects get cancelled, but we are looking for a good faith commitment.
If the project is still experimental, or it's not clear that it will be a long-term effort, then using an existing organization is more appropriate. If and when things change, we can talk about moving out into a standalone org.
Follow go/github-org-owners
Confirm that you've read and will comply with go/github-org-owners, and let us know if you have any questions about those policies.
Once you have included all the information in the issue (filed using go/new-org-request) and included the username of your director, who will need to confirm their commitment to staffing and supporting this organization, we will process your request.
Once the org is created
New orgs are created in the free tier by default. If you would like to take advantage of paid features, you have a few options. In general, most orgs do not require paid-for features as most features are available for free on public repos.
Add a billing method
You can attach your corporate card to your org and pay as you go for overages. This is usually the easiest way to be unblocked if you are finding that you require extra resources.