Summary

This RFC proposes a policy for managing permissions to the Rust-Lang GitHub Organization and repositories within this organization.

This RFC was written in consultation with the Governance Working Group and the Infrastructure team. Most discussion took place on this issue and this pull request.

Motivation

Access control for the Rust-Lang GitHub Organization and repositories within that organization is currently managed either through the rust-lang team database, or ad-hoc via the GitHub UI by the org owners. We need a policy that defines how these accesses are granted and managed. This will allow us to have greater security in permissions to our GitHub org, and provide transparency and clarity on how access is managed.

Guide-level explanation

Rust-Lang GitHub Permissions Policy

This policy applies to both the Rust-Lang GitHub Organization and all repositories within that organization.

Rust-Lang Organization

Access to the Rust-Lang GitHub organization is managed with the rust-lang team database. The team database is managed by the team-repo-admins, whose policies are specified in the Team Maintenance documentation.

Selected members of the Infrastructure Team can also be organization owners if their work requires it.

All GitHub accounts used to interact with the Rust-Lang GitHub organization (owner or non-owner) must have 2FA enabled.

Rust-Lang Repositories

Access to and permissions for repositories within the Rust-Lang organization must be administered through the rust-lang team database. Permissions should not be given to individuals, only to teams or groups.

GitHub provides several permission levels for access to a repository. Please refer to GitHub's documentation for details on permission levels and what each level can do.

Repositories in the Rust-Lang organization should follow these permission guidelines:

Admin --- No users or teams except for org owners should have this permission level.
Maintain --- Teams may have this permission level at their discretion for repositories the team is responsible for. Repositories using the bors bot may want to consider using the write permission level instead in order to deactivate the "Merge" button on PRs to enforce that merges go through bors.
Write --- Teams that are responsible for a repository should have at least this permission level.
Triage --- This role is available if teams want to give these permissions to other teams, such as for triage support. Unfortunately this role does not allow contributors to edit issue descriptions or titles, so its utility for that purpose is limited.
Read --- This role is unnecessary, and should not be used (it is generally only relevant to private repositories, and we do not have a use case for it).

Teams who are responsible for a repository may give access to other teams at their discretion.

Teams or groups may ask for repositories to be created to fulfill their needs by opening a PR to the Team Repository. It is up to the team-repo-admins to approve creating the repositories. Existing repositories that need to be transferred from outside the rust-lang organization should consult with the Infrastructure Team to fulfill that request.

By default, repositories should be public and allow read access to all. When needed, some repositories can have limited read access (i.e. repositories related to security).

Some teams - such as the moderation team - need broad access to public Rust-Lang repositories. The first way to manage this is through creating a GitHub team managed through the Team Repository and granting that team appropriate permissions to the appropriate repos. Another way is to create tooling that will allow a member of the moderation team to selectively and temporarily gain the access that they need when it is needed (such as deleting a comment or issue). For now, we are proceeding with managing access to repos for moderation through a GitHub team, however, should it be needed, we can develop tooling to apply more fine grained and time limited access.

Bot accounts controlled by the Infrastructure Team (such as the triagebot) can be granted any level of access required for them to work at the discretion of the Infrastructure Team.

Implementation

It is the responsibility of the Leadership Council, the Infrastructure Team, and the team-repo-admins to finish the migration to implement this policy. New teams may need to be created, which is outside the scope of this RFC to define.

Drawbacks

There can be exceptional cases where a team wants to give repository access to an individual to assist with their work. Requiring them to join or create a team in order to perform that work can be a significant hassle. Teams who find they need this frequently should consider creating a "contributors" subteam for that purpose, or to investigate other tooling to assist with what they need.

Unresolved questions

Should these rules applied to Rust-Lang affiliated repositories and organizations that are outside of the Rust-Lang GitHub Org, such as rust-embedded?

Future possibilities

Custom GitHub Roles could be created for use cases where the existing roles do not suffice.
Extend tooling, such as triagebot, to provide extended permissions that are not normally available (for example, it currently offers labeling).

6.6 KiB Raw Permalink Blame History