GitHub Access & Team Structure
All openedx GitHub repository access is managed through GitHub Teams. Do not grant any repoistory access directly to users. This system helps us audit and understand the access that we grant, both to contributors and to our own tools.
We also use GitHub Teams for other purposes: granting access to GitHub Projects (aka boards), mentioning groups of people, assigning maintainers in Backstage, and assigning watchers in GitHub Code Owners.
Axim needs to keep the team and access structure consistent for the safety of the project, for fairness to contributors, and for our own sanity.
Who can access what
Entity - Role | Axim Coding CCs | Community Coding CCs | All Non-Coding CCs | Other Contributors |
|---|---|---|---|---|
Org - Owner | Grant as long as their CC nomination thread includes this access level. | Deny. Only Axim engineers can be org owners. | ||
Org - Member | Grant | Grant | Grant | Grant upon request to those who want to participate in issues/projects because they’re actively contributing to some part of Open edX. We have unlimited seats in the organization. We do an annual audit to remove inactive contributors from the organization.
|
Repo - Read | Grant upon request. For public repos, read access is redundant (everyone can read them), except for the fact that it allows the teams to additionally be @-mentioned and assigned as reviewers on those repos' PRs and issues without having participated yet. So, read access can be granted to any team for any public repo, especially for repos which the team is likely to work in. | |||
Repo - Triage | Grant via the openedx-triage team to unblock project & issue participation. This team should grant triage access to every public repo to everyone in the organization. | |||
Repo with Only Issues - Write
| Grant via the committers team so that they can (a) edit issues other than their own and (b) manage repository milestones. | Grant upon request as needed so that non-coding CCS can edit issues and milestones. Tod o so, create or find a team by the name
and add them to it, and add the appropriate repositories to it with write access. The non-coding CCs should not use this access to merge code changes! (This is OK because, as of late 2024, as all CCs sign the same agreement and must sign an individual CLA, so we are covered legally.) | Deny. Non-CC contributors must do their work on repository forks. They can submit PRs to openedx repositories for CCs to consider and merge if acceptable. Note: Non-CC contributors must sign a CLA in order to contribute code. If they do not, a PR check will fail and prevent any PR of theirs from merging. | |
Repo with Code - Write | Following a positive CC onboarding or CC rights expansion vote for the particular repo in question, these can be granted to Coding CCs only via:
The sum of a CC’s write access grants should match this page: Core Contributors to the Open edX Project . If this page doesn’t match reality, then the source of truth is to be found in the result of the votes on the forums--you might have to do some digging. | |||
Repo - Maintain | Deny. This grants the ability to modify branch protection rules, which we can only allow Axim engineers to do. We do not use this role at this time. | |||
Repo - Admin | Deny. This grants the ability to modify branch protection rules and access roles, which we can only allow Axim engineers to do. Axim engineers may be granted org-level admin rights (see “Owner” above) but we do not use the repo-level admin role at this time. | |||
Project - Write (Note: A “Project” in GH is collection of boards. Example.) | Grant as needed. Not formally managed. Can be granted by Project admins at their discretion. | Grant as needed. Not formally managed. Can be granted by project admins at their discretion. As a prereq, this requires being a member of the organization (see above). | ||
Project - Admin | Grant upon request, with discretion. Not formally managed. | Deny. We cannot think of a scenario where a non-CC would be administering a project. Raise to Axim eng team if this scenario does come up, though. | ||
Team names and types
Use only lowercase letters, numbers, and hyphens to name teams. No uppercase, no spaces, no special chars.
Choose team names that get more specific as you read them from left to right. For example: 2u-enterprise-quokkas follows the pattern COMPANY-TEAM-SUBTEAM.
Avoid nested teams. They are very confusing to work with (we’ve tried in the past!).
Teams are organized by prefix:
Prefix | Who | Access | Examples (these don’t all exist…. yet) |
|---|---|---|---|
openedx- | Teams related to managing the Open edX project itself. | Varies depending on need. Sometimes write, sometimes maintain, sometime admin. Follows the principle of least privilege. The openedx-triage team is special team that grants triage on everything, so no other team should ever need to grant triage or read. | openedx-triage openedx-release-managers (Grants maintain access to all community release repos.) openedx-product |
bot- | Bot accounts that need access to repositories. Generally one bot per team, although bots could be grouped together if it makes sense. | Ideally, the lowest level of access (write/maintain/admin) that the bot needs in order to function, granted on the smallest number of repositories possible. | bot-requirements bot-semantic-release cla-checker (needs renaming) |
committers- | A subset of Coding Core Contributors, organized around an area of expertise or contribution topic. | Grants write access to a single repo or a set of related repos. Note: Some repos will have multiple `committers-` teams representing different contexts. For example, committers-edx-platform-2u-tnl includes all 2U T&L team members with write access to edx-platform. | committers (All Coding CCs. Grants write to open-edx-proposals + all issues-only repos.) Broad group examples:
More-specific examples:
Single repo examples:
|
fc-XXXX | Teams implementing Axim funded contributions in new repositories. | Grants write access to specific repositories as needed for funded contribution work. These groups are not common and are typically used for new repositories. These groups are not for granting write access to established repos like edx-platform – those sorts of contributions would still need to be reviewed and merged by a core contributor. Access through an fc- group is explicitly temporary, and these teams are removed when the funded contribution contract ends. A goal of FCs is to help ramp folks up who could then go on to be nominated as Core Contributors. | Make sure to use the full four digits of the FC:
|
axim- | Teams or sub-teams at Axim or direct contractors thereof. | Ideally just read access, but in some special cases we may need to grant write access. | axim-engineering axim-oncall axim-aximprovements |
COMPANY- | Firms/companies/orgs or teams within them. | None, other than read if requested in order to make it easier to mention the team on certain repos. (Previously, | 2u-tnl 2u-cosmonauts 2u-enterprise 2u-enterprise-quokkas opencraft opencraft-bebop |
wg-NAME- | Teams related to the working group <GROUPNAME>. | None other than read | wg-build-test-release wg-build-test-release-chair |
wg-maintenance-NAME | Teams responsible for maintaining a repo (or set of repos) | None other than read | wg-maintenance-paragon |
interest- | Teams in the community that are centered around a shared project, interest, activity, background, etc. | None other than read | interest-performance |
< anything that doesn’t fit the pattern above > | This is a legacy team that will be deleted or renamed by Axim in the near future. | Varies |
|