Committers, under the Core Contributor Program, are individuals with merge and ownership rights to (parts of) the Open edX codebase. They are essential contributors to the Open edX ecosystem with demonstrated influence on the technical upkeep and direction of the platform.
This document describes a phased program for expanding these rights to other members of the Open edX community.
We believe having a more inclusive Committers group will lead to a more vibrant platform ecosystem that fosters:
stronger innovative collaboration with the Open edX community
increased developer velocity that accelerates platform advancement
increased developer capacity to own and maintain the platform
Initiation and rollout of the Core Committer program will need to ensure that we:
Continue to remain in compliance with edX’s security (PCI, etc), privacy (GDPR, etc), and a11y commitments.
Co-establish technical direction of designated repositories1
Documenting and reviewing decisions in ADRs (and OEPs) and maintaining READMEs, HowTos, etc
Co-maintain prioritized backlog of needed technical improvements of designated repositories.
Negotiate and allocate a regular percentage of time toward technical upkeep, including refactorings and other items listed in this column.
(in Future) Co-own designated repositories
Ongoing upgrade and feature maintenance and other ownership costs of designated repositories
Vote in the selection process for future Committers
Train new/young developers2 to help hone their own judgment and skills, while following our code of conduct
Co-establish the selection process for Committers
Lead by example
1 Sharing insights into product goals and roadmap will enable us to be successful in establishing technical direction. 2 Each Committer uses their own experience and judgment to determine how best to train new folks. For example, investing time in scaffolded constructive reviews on both code PRs and design/decision PRs can have a multiplicative effect.
Reviews and Ownership
The requirements for when edX Product must review a PR varies based on the type of change as summarized in the table below. Similarly, non-trivial changes need to be accepted by the team that owns the repository in order to ensure the owning team has the context for the change and acknowledges its future ongoing maintenance.
Type of change
Required review3 (not counting the author)
Required Technical Ownership
Maintenance updates & bug fixes
1 CC Committer
1 CC Committer
Acknowledgement from owning team4
End-user facing changes
1 edX product 1 CC Committer
Acknowledgement from owning team
3 In the event of any disagreement between Committers, it is expected that the Committers will demonstrate appropriate judgment and work it out amongst themselves. If moderation is required, they can reach out to the #core-contributors Slack channel for additional guidance. 4 The process for “acknowledgment” from the owning team is left to the discretion of the owning team and Committer so they may find a working model for the relevant changes. For certain types of contributions, a one-time acknowledgment at the beginning of a project is sufficient to avoid blockers on every PR.