Overview
...
See Processes for details on how we administer GitHub.
...
See Philosophy to understand why these processes are the way they are.
Table of Contents
| Table of Contents | ||||
|---|---|---|---|---|
|
Processes
We take requests via issues to the openedx/tcril-engineering repository. Your requests will be triaged and initially responded to within one business day by the engineer(s) in the @openedx/tcril-oncall GitHub team during their own working hours. They may be delegated to other engineers. tCRIL does not generally provide support during US-Eastern evenings or weekends.
...
Onboarding Core Contributors
So, you just became a core contributor? Congrats! 🎉 Your sponsor should file a GitHub Request - Generic issue on your behalf, with a link to the approving Discourse thread, your GH username, and the repos approved access for. If your sponsor is not responding to pings, you may file it yourself.
Please first read the “For Those Joining” section here: This page has been deleted in favor of:
...
...
...
...
...
A Core Contributor Program Administrator will be reaching out to send you the appropriate documents and ensure correct access.
...
...
...
...
Onboarding 2U OCM Employees
So, you just started at 2U OCM? Congrats! 🎉 Either 2U IT or your manager should file a GitHub Request - Onboarding issue on your behalf. (Please don’t file file the request yourself--we need someone who is already in the openedx organization to vouch that you are indeed a new 2U OCM employee).
2U IT and managers: For new hires, file a GitHub Request - Onboarding issue with us. We often do not get to requests the day they are filed, so please file the request as far in advance of the employee’s start date as possible. Please provide a helpful title, but make sure it remains prefixed with [GH Request] so that our automation picks it up. Thanks!
Offboarding, access changes, and other requests
Do you need us to:
add or remove GitHub permissions from a user?
change the configuration of a GitHub application?
remove someone from the
openedxGitHub organization?help you out with anything else?
File an issue using the tCRIL Engineering board above, selecting the most appropriate template. Please provide reasoning for your change and as much supplemental detail as possible. Please provide a helpful title, but make sure it remains prefixed with [GH Request] so that our automation picks it up.
Transferring repositories into the openedx organization
If you have read “What code should be in the openedx organization?" and believe that a repository of yours should be moved into the openedx organization, then submit a GitHub Request - Generic issue on the board linked above, detailing what repository should be transferred in and why.
Transferring repositories out of the openedx organization
If you have read “What code should be in the openedx organization?" and believe that a repository in the openedx organization doesn’t belong there, then submit a GitHub Request - Generic on the board linked above, detailing what repository should be transferred out and why.
Please note: If, instead of a transferring a repository, you want to archive it because it is unused, please see OEP-14: Archiving GitHub Repositories.
Philosophy
| Note |
|---|
This whole section will end up being shaped into an Open edX Proposal (OEP) so that the community can give feedback before we formalize it. In the meantime, we’re posting it in a wiki page for transparency. |
The Center for Reimagining Learning (tCRIL) stewards the Open edX codebase. As such, we (tCRIL) maintain administrative control over the upstream Open edX repositories, but aim to do so in accordance with guidelines agreed upon by the greater community of Open edX contributors.
Since the transition of project stewardship from edX to tCRIL in November 2021, we have been working hard to establish fair and clear community guidelines for the granting of core contributorship, merge access rights, project maintainership, and other privileges. However, there is more to do and we are still hard at work, so please be understanding and don’t hesitate to ask questions 
So you use GitHub issues now?
Yes. We decided as a team that we would track all of our work using GitHub Issues and GitHub Projects, as they:
integrate nicely with pull requests and other GitHub workflows,
let us locate issues closer to the code that they pertain to,
are automatable via GitHub Actions,
use the same GitHub accounts that all Open edX engineers already have,
have a simpler access control scheme that is tied to repository access (which we already manage and intentionally default to “publicly-visible”),
are included in our non-profit GitHub Teams plan,
work across different GitHub organizations, with some limitations,
have a fast UI, and
have already been adopted by others in the Open edX community, such as the Build-Test-Release Working Group.
What code is in “Open edX”?
We consider the “Open edX codebase” to be equivalent to the code within the openedx GitHub organization.
What should be in the openedx GitHub organization?
Firstly, any repositories that are strictly necessary in order to run an Open edX instance should be part of the openedx GitHub organization, except for third-party software such as Django. Note that the code for Open edX distributions (notably: Tutor) may exist external to the openedx organization, provided that the code within openedx does not directly depend on the external code.
Beyond that, any repository can exist in the openedx GitHub organization, granted that:
it is likely to be of interest and use to the Open edX community,
its maintainers strive to review community contributions and participate in community discussions related to the repository, and
its maintainers strive to keep the repository compliant with the accepted Open edX Proposals (OEPs).
This criteria is obviously a little fuzzy, and should be nailed down in the aforementioned OEP. In the meantime, tCRIL has been using its best judgement.
What about other GitHub organizations?
Many extensions and utilities for Open edX exist in other GitHub organizations such as edx and open-craft, which are administered by other individuals and companies in the community. We consider this code to be part of the greater “Open edX ecosystem”. Although vital to the health of the project community, these extensions and utilities should not be strictly necessary for running an out-of-the-box Open edX instance. If they are necessary, we will aim to either make them optional or transfer the upstream repository in the openedx organization.
Why can’t I just create new repositories in the openedx GitHub organization?
Keeping repositories working, secure, documented, and otherwise up-to-date with the various OEPs is extremely time consuming. When each repository has a team attending to it, the task is easier; when there are repositories that nobody is paying attention to, it is nearly impossible.
The openedx GitHub organization has nearly 200 repositories: some have active maintainers, others do not. We would like to get to a point where every repository in the openedx organization is actively maintained. Obviously, this is easier when there are fewer repositories.
So, we are being judicious about the creation of new repositories in the organization. Before adding to the stack of ~200, we are looking for indication that the repository will be actively maintained and useful to the community.
What if I disagree with this philosophy or processes?
Please let us know! You can comment in this doc, file a issue with openedx/tcril-engineering, or post on Slack in #openedx-transition.
Also, keep an eye out for an upcoming OEP in which we’ll solicit discussion on all of these decisions and codify them more formally. We’ll link the OEP PR here, so you can stay up-to-date by watching this page.
Thanks!
...