This article describes configuration settings for GitHub Cloud organizations, which are recommended as a baseline for general usage.
The ncstate-demo organization will be used as an example to demonstrate the proposed configuration.
Generally speaking, it is recommended to treat membership of the organization as a pool of users who may or may not be involved in the management or daily usage of repositories within the organization, and utilize Team memberships to grant specific permissions where appropriate. The permissions a user has simply by being a member of the organization should likely be close to zero. This allows organization owners to delegate access control decisions to the Maintainers of each Team, and the Administrators of each repository, rather than needing to take a greater direct role in access management.
When creating a Team, a user may be designated as a Maintainer, which grants the user additional permissions to manage the Team.
When creating or importing repositories, it is highly recommended to grant access control based on Teams, rather than individual users.
Even in cases where there may be a single user for a given role, setting the access control to use a Team with one user can make access control easier down the road.
At this time, please do not utilize the "Identity Provider Group" feature. The GitHub Service Team is actively investigating ways to utilize this feature in a manner which preserves student privacy and meets compliance requirements.
This article will cover the General Settings and Access Control settings, with recommendations for setting each value. The rest of the organization settings are recommended to leave as defaults unless you plan to use a specific feature and would like to configure the corresponding settings. Please consult the official GitHub documentation for more information on these settings.
These settings control metadata about the organization, which are visible to any NC State user.
Set this to a human readable name for your organization. E.g. "NC State Example Organization"
This should be an email address where anyone who wishes to contact the organization can get a response. Usually this should be your primary helpdesk email, or help@ncsu.edu.
This should be a long-form description of the organization, and/or how the organization is used on GitHub.
This could be your main organization website, the NC State Service Portal, or any other site related to your GitHub operations.
Generally these are not relevant for most on-campus organizations, but can be set if desired
Country of Origin, fine to leave blank.
To use the Gravatar service to populate your profile picture, the email address associated with your Gravatar account can be set here. This email address will not be displayed anywhere, and is only used to pull the profile picture. Alternatively, a relevant profile picture can be uploaded directly.
NC State organizations are not eligible for sponsorship, so this can be left blank.
Repository rulesets can be defined to exert fine-grained control over who is allowed to create repositories within the organization, including restricting the creation of repositories to specific Teams, enforcing naming conventions, and more. The specifics of configuration here will vary between organizations based on your own requirements and workflows, but if you need a more granular approach to policy for repository creation, this is the tool for you.
Custom organization roles can be used for fine-grained control over the permissions a Team has within the organization. These roles can be used to grant a particular Team a certain level of permissions across ALL repositories within the organization. You may wish to grant your IT staff as CI/CD Admin across all repositories to configure CI/CD integrations, for example.
Custom repository roles are used to augment the default roles available when granting access to an individual repository. The base roles are usually sufficient for most usage, but specific workflows may benefit from the creation of a custom role.
This value is enforced at the Enterprise level to grant No Permissions to members of the organization by default. This forces the use of Teams assignments or explicit user permissions for repository access, and helps to enforce the Principle of Least Access and improve our overall security posture.
By default, members of the organization are not allowed to create new repositories, and only owners are able to create repositories. To enable repository creation by organization members, enable the appropriate setting here. Keep in mind that ALL members of the organization will be able to create repositories when these settings are enabled. The repository rulesets mentioned earlier can be used for fine-grained control over repository creation, including limiting repository creation to specific teams or requiring specific naming conventions.
By default the ability to fork repositories is disabled. When enabled, users with read access to a repository will be able to fork the repository to the selected destinations. It is recommended to use "User accounts and organizations within this enterprise" in most cases when enabling forking.
Repository administrators are always allowed to add users from outside the organization by Enterprise level policy. Please contact the GitHub Service Team if you have a reason to disable this feature.
This setting controls whether or not a user's name is displayed next to their username in Issues and Pull Requests. Recommended to enable.
Whether or not to enable Discussions for users with Read access to a repository. Recommended when using Discussions in an open collaborative setting, while for more structured usage should be disabled.
This setting controls the default permission level when creating new projects. Recommended to use "No Access" here, and define an appropriate setting for each project.
If you'd like your members to be able to publish GitHub Pages in repositories where they have write access, keep this enabled, otherwise disable.
This setting allows external collaborators to submit requests for GitHub Apps or OAuth Apps to be approved by an organization owner. It is recommended to disable this setting, and only allow members of the organization to request integrations. Be VERY careful when accepting integration requests, as they will act on behalf of the organization, often with broad permissions.
These settings control whether or not repository administrators may perform certain administrative actions on the reposi they control. Recommended to enable in most cases, but disable for tighter control of when repositories are moved or deleted.
Whether or not issues may be permanently deleted. Generally recommended to keep this disabled and archive issues instead.
Whether or not to allow members to create teams. Generally recommended to disable and require organization owners to manage team creation.
Generally recommended to keep enabled to allow members to see dependency graphs for repositories where they have read access.