...
Right | Responsibility | |
Legal | Be an individual CC regardless of organization affiliation | Sign individual (and, if needed, entity) contributor agreements, per edX legal requirements |
Renew annual continued interest in being an individual CC | 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 |
(for Pilot) 2 designated edx-internal champions to support CC with on-call issues | Retain strong communication with the champions, including visibility into expected merges and time availabilities | |
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 CCs | Train new/young developers2 to help hone their own judgment and skills, while following our code of conduct |
Co-establish the selection process for CCs | Lead by example |
Footnotes
1 Sharing insights into product goals and roadmap will enable us to be successful in establishing technical direction.
2 Each CC 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 | Required Technical Ownership |
Maintenance updates & bug fixes | 1 core committer | N/A |
Technical enhancements | 1 core committer | Acknowledgement from owning team4 |
End-user facing changes | 1 edX product | Acknowledgement from owning team |
3 In the event of any disagreement between CCs, it is expected that the CCs will demonstrate appropriate judgment and work it out amongst themselves. If moderation is required, they can reach out to Nimisha, as head of architecture.
4 The process for “acknowledgment” from the owning team is left to the discretion of the Champion and CC 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.