Notes On Github Organizations

GitHub also offers the following documentation to get started and learn more about using it.

• https://docs.github.com/en/enterprise-cloud@latest/get-started

• https://docs.github.com/en/enterprise-cloud@latest/get-started/quickstart  

Background

The Tufts enterprise license for Github does accommodate the ability to create additional Github organizations, but there are many caveats associated with this and it is usually not recommended to do so. To quote Github best practices:

In general, GitHub recommends minimizing the number of organizations you create. Having fewer organizations encourages greater collaboration and innersourcing, which increases efficiency. In fact, many businesses are best served by a single organization, for the following reasons.

The reasons they cite are (also quoted from Github):

• It's easier to find resources within a single organization, as there's only one place to search.

• It's easier to communicate within a single organization, as @-mentions only work between members of the same organization.

• Being part of a single, large organization where anyone and anything is accessible fosters collaboration and loyalty, whereas being separated into smaller organizations can make teams more isolated.

Responsibilities

The creation of a new Github organization underneath the Tufts enterprise also carries an additional management burden regarding the care and maintenance of that organization, which will be the responsibility of the requesting party, and includes things such as:

• setup of authentication, such as Shibboleth or Active Directory

  • see: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on

  • note: if Shibboleth is used, any user with valid Tufts credentials has the potential for read access to internal repositories and additional care must be used to scope repository visibility and permissions to a suitable level

• maintenance of related AD groups

• specifically managing access for any cross-group collaborators

• troubleshooting situations where a user isn’t able to see

• contacting Github support in the event of issues

Alternatives

It is still possible to control the visibility (and permissions) of repositories in one of the existing Github organizations, so it may not make sense to take on the additional responsibilities if this is the main use case for a new, separate organization. Please see: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility and https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams

Example Use Cases

Note that in some specific cases, a separate organization might make sense, such as:

• requirement for multiple 3rd party vendor integrations other than CI/CD

Next Steps

If you’d like to discuss your use case further, please submit a Service Now support ticket to Tufts IT. If you’re like to request a separate organization after reading the above, please have someone at a senior management/leadership level (director, assistant director, etc) submit a ticket that states approval of the new organization, the requested organization name, and the names and email addresses of people who should be considered admins for the new organization.