Who are Code Committers?
Why?
Having a more inclusive Committers group 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 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
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.
Hold an equal bar for 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.