University Policies and Regulations
As a service provided by the university, all official university policies and regulations apply to the NC State GitHub service. In particular please note the following:
Access and Usage
Use of the NC State GitHub service is free to use for all currently enrolled students, student facing faculty, and non-faculty staff employees of NC State University for the duration of their time at the university.
No-Pay and Workshop accounts are permitted access to GitHub for anyone performing academic, not-for-profit research on behalf of or in collaboration with the university for as long as their account remains active.
Service accounts are available to faculty and staff for purposes of automation. Contact us for more information.
All usage of the NC State GitHub API is subject to Rate Limiting, and requests that break the limit will be denied.
Access to the NC State GitHub instance outside the aforementioned usage is not permitted.
Accounts for qualified users are created upon their first successful authentication to the service. Users accounts will not be created before this time, and will be unavailable for the purposes of assigning permissions, transferring ownership of repositories, etc.
Once a user has been separated* from the university for a period of one month, their GitHub account will be scheduled for decommission. All content owned by the user on GitHub will be archived and sent to the user via Google Drive, and the user’s GitHub account will be deleted one week later.
Note that only content directly owned by the user will be included in the archive. Forks owned by other users, repositories owned by organizations, etc, will not be archived nor deleted, and will remain as they are. Because of how GitHub handles private forks, forks of a private repository owned by the decommissioned user will also be deleted. These forks are not included in the archive sent to the user, since the forks are not owned by the user.
Organizations that are owned by the decommissioned user where they are the only owner of the organization will be reowned to a service account controlled by the GitHub service team. A member of the organization may contact us to request ownership be transferred to them. See “Orphaned Organizations” for more details.
Workshop accounts are decommissioned regularly the day before the start of Spring, Summer, and Fall semester. This removes all repositories and permissions for the account. Archives are NOT created when Workshop accounts are decommissioned. We highly recommend Workshop account users backup and remove their data from GitHub before they lose access to the account. This prevents data from being lost when the account is wiped, and prevents other people from accessing data if the account changes hands before the scheduled wipe.
*Separated: A user is classified as “separated” if and only if they do not have an active employee record, are not currently registered for classes, and do not have an active academic plan. Students taking a semester off are not classified as “separated”.
All user accounts should be named after their Unity ID. Service accounts should match their name in Active Directory.
Any user accounts that renamed themselves will be corrected to their proper username according to their account type.
General Use and Naming Conventions
Any user may create a new organization at any time. A user may create any number of organizations.
Organizations should be named after the purpose they serve, and it is highly recommended to avoid common names such as “homework”, or “project”. If an official unit on campus wishes to create an organization and the logical name for the organization has been taken, the existing organization will be renamed and the owners will be notified of the change.
Organizations share a namespace with user account, and so organizations that have a naming conflict with a UnityID will be renamed and the owners will be notified of the change. We highly recommend choosing an organization name with a minimum of 12 characters in order to ensure the organization name will not conflict with a UnityID.
Organization names that are deemed offensive will be renamed and the owners will be notified of the change.
In the event an organization has a single owner, and that owner’s account has been decommissioned, the organization is considered “orphaned”. Ownership of the organization is transferred to a service account controlled by the GitHub service team. Repositories and membership of the organization are left as they are at the time of transfer.
A member of an orphaned organization may contact the service team and request ownership of the organization. Ownership will be transferred to that user, and the organization will no longer be considered “orphaned”. If multiple members request ownership, all will be granted ownership.
Orphaned organizations with no additional members will be decommissioned after one year.
Ownership and Permissions
User repositories are owned by their creator, and the owner has sole discretion for assigning other users permissions to access the repository.
Organization repositories are owned by the organization, and permissions are assigned as configured by the organization settings.
Any additional access requests should go though the repository owner, or a user with delegated permissions.
The contents of a repository are pursuant to University Policy 10.00.01 and generally, content in repositories owned by a student is property of the student, while content in repositories owned by an employee is property of the university.
In cases where the owner is unable or unwilling to grant access, and the contents of the repository are university property, users may reach out to the GitHub Service Team, and ownership of the repository will be transferred to an appropriate party.
General Use and Naming Conventions
Any user may create a new repository at any time. A user may create any number of repositories.
Repositories may be named anything. Repositories are always scoped to a user account or organization, so there is no risk of naming conflicts with other users.
Repositories with names that are deemed offensive will be renamed and the owner will be notified of the change.
Size and File Type Limits
There are no restrictions on what types of files may be included in a git repository. It is recommended to keep binary files out of repositories because they are not handled well by git, but it is allowed if desired.
There is a hard file size limit of 100MB. Commits containing files larger than 100MB in size will be rejected when pushing the commits to GitHub. You will need to drop the commits containing the large files before you will be able to push.
There is no hard limit on overall repository size; however, we do enforce soft limits. Users that use an abnormally large amount of disk space will be given a warning and asked to reduce their repository size if possible. In the event a repository size causes performance issues for the service, the repository will be removed and the owner will be notified.
The GitHub Enterprise server is a VM in the OIT VMware infrastructure running in the data center. The GitHub Enterprise server is backed up nightly to another server which is then backed up into the standard OIT backup environment with backups retained for 30 days for the purposes of Disaster Recovery. Implementing the Disaster Recovery plan consists of building a new VM from the image provided by GitHub and restoring the backup. The same process has been used multiple times for server migrations successfully.
For recovering individual repositories, the GitHub Enterprise server soft deletes the content for 90 days, allowing the GitHub service team to recover it without having to go to backup.