| Table of Contents |
|---|
Who are Code Committers?
Committers, under the Core Contributor Program, are individuals with merge rights and a sense of ownership 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.
Why?
We believe having See https://openedx.atlassian.net/wiki/spaces/COMM/pages/2759460357/Core+Contributor+Role+Definitions#Code-contributors---Sarina
Why?
Having a more inclusive Committers group will lead leads 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
Principles
...
Uphold the principles and standards defined in OEP-54 Core Contributors and OEP-55 Maintainers.
Continue to remain in compliance with edX’s security (PCI, etc)the platform’s security, privacy (GDPR, etc), i18n, and a11y commitments.
Since edX.org currently (as of March 2024) deploys continuously off of master, please work with the relevant groups (https://docs.google.com/spreadsheets/d/1ryqbaxMp4x-8Apwss2Br2IOU2UA7zXEI-VDo8dJPb9U/edit#gid=0) to determine when appropriate merge windows are; guidelines will vary repo-to-repo. Guidelines, as they come online, are maintained here: Merge Guidelines for Coding Core Contributors
Do not regress in the forward movement we are concurrently making on technical ownership. For each Committer contribution, we will need to ensure:
edX Product accepts future maintenance costs of new/enhanced features in the platform.
edX Engineering owning team acknowledges acceptance of ownership of changes.Support Committers who are at varying levels of technical expertise, though they must demonstrate excellent judgment and accountability.
Be transparent and open about the existence and eligibility of the Committer program.Constrain Committer’s relationship to the Open edX (public) codebase, without exposing edX-confidential business or data.
Hold an equal bar for both edX engineers and community engineers, in the long-term. In the future, for instance, edX engineers might earn merge rights just as other contributors to the platform.
Respect edX’s right to modify and terminate the Committer program.
Committer Rights and Responsibilities
...
Right
...
Responsibility
...
Legal
...
Be an individual Committer regardless of organization affiliation
...
Sign individual (and, if needed, entity) contributor agreements, per edX legal requirements
...
Renew annual continued interest in being an individual Committer
...
Complete annual training for security, privacy, a11y, and architecture
...
Merge
...
Merge to master, using defensive CI/CD techniques such as feature toggles
...
Ensure approved review process is upheld and be on-call to address issues with recently merged PRs. Follow Merge Guidelines for Coding Core Contributors
...
Own
...
Review PRs and suggest technical changes in designated repositories
...
Learn and advocate for clean code, quality, and architecture principles and practices (per repository’s definition of done)
...
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
...
Process
...
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
...
N/A
...
Technical enhancements
...
1 CC Committer
...
Acknowledgement from owning team4
...
End-user facing changes
...
1 edX product
1 CC Committer
...
Acknowledgement from owning team
...
all engineers.
High Level Contributing Guidelines
Technical changes must be reviewed by other contributors and should align with the maintainers goals for the component.
Before making large technical or architectural changes, be sure to communicate your ideas with the other engineers that work in that area and make sure everyone is aligned on the impementation. These discussions should take place on issues in the relevant repo or in the discussion forums if they span multiple repositories.
Any user-facing change should go through Open edX Product Review prior to starting on coding. This process is described: How to submit an open source contribution for Product Review
Once a change has passed through product review, implementation may begin. If, during implementation, it is discovered that the approved design cannot be coded for one reason or another, the product review discussion thread should be re-opened and alternatives discussed until agreement is reached.
Code reviewers of a user-facing change should read through the product review discussion to ensure they are reviewing and approving only a design that the product team has approved.