Granting write access to repos in the openedx org
Axim’s policy on granting write access to repos in the openedx GitHub organization follows the model outlined in OEP-54 Core Contributors: anyone wishing to have write access to a repository must be nominated for inclusion in the Core Contributor program with specified repo access in the Discourse forums. Prior to this nomination, potential CCs must contribute to the repo(s) they’re requesting access for to show their submissions are of high quality and meet maintainer standards.
This includes 2U engineers who used to get access to the code base a different way before Feb 2025. Since then all new 2U engineers must also go through the standard Core Contributor Program.
Authors of new repos will need to be added to specific teams that grant write access to the repos. Write access to a repo is granted in one of the following ways:
Original author(s) of the repo being created or moved in are given write access to the repo.
If an author is not yet a Core Contributor, they will need to be nominated as a Core Contributor.
Authors will be part of a team and the team will be granted write access. It could be a new team or an existing team: work with Axim to determine what team is appropriate.
Non-original authors - 2U engineers included - who wish to have write access to repos need to follow the core contributor “expansion of responsibilities” process:
Commit to the repo(s) they want access to, using pull requests from a personal fork.
Be nominated (or self-nominate) for write access to the additional repos using the expansion of responsibilities process outlined in OEP-54.
Anyone can contribute to any repo by using a personal fork to create a pull request, then having it reviewed and merged by someone with write permissions.
Is there a parallel policy document to this one for administrative access to repos? E.g. 2U’s OCM Site Reliability Engineering team has administrative access to a number of repositories which used to be edX Inc.'s. We use this administrative access to do things like: manage self-hosted runners for github actions, make sure repo-level quality standards are automatically applied appropriately, and jump in to help resolve production issues more quickly.
I wanted to surface that this administrative access moving forward is still an open question, and that we might do well to mention that if those questions are meant to be out-of-scope of this document we may need to add language to that effect (since it’s impossible to refuse write permissions to folks with admin permissions, for example).