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
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.
PRs merged by a core contributor will go to edx.org production systems in a matter of hours or less. Coordination between CCs and edx.org engineers is sometimes necessary when merging changes that require migrations or are highly impactful - even a very small change may be highly impactful to a production system. Therefore CCs should use these chat rooms to do merge coordination with 2U/edX engineers and ask pointed questions around the PRs. These chat rooms are not for questions along the lines of “help me design/code/review my feature”.
Each room is monitored by a 2U/edX engineering manager. Each room maps to one or more repositories as described in this spreadsheet. Core contributors should join the room(s) applicable to them. Others are welcome to sit in, but please be sure to keep the channel’s usage to what is described above.
Merge guidelines for coding CCs are expanded upon 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.
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.