...
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 |
Phased Rollout
Here is a proposal for a phased rollout of a CC program, beginning with an initial low-effort learnable pilot, later expanding to a more scalable solution.
Phase 1: Pilot with champion support
This pilot is an initial increment of the CC program, with an opportunity to test assumptions and gather initial learnings before moving forward. In this phase, we focus on discovering unanticipated technicalities and legalities in the program by enlisting a few carefully selected long-time contributors to the platform (external CCs and internal champions) to help us co-create this program and collectively identify issues.
Legal agreements
Contributor agreement(s)
Each CC signs an individual contributor agreement that allows the CC to contribute to the platform without any affiliation with an organization. This is a required legal agreement that clarifies legal ownership and potential liability of the individual’s contributions.
If the CC works at an organization that is an Open edX provider, an additional entity contributor agreement is required to eliminate any risk of confusion between work done in an individual capacity versus in an employee capacity.
NDA
Each CC signs an NDA with edX in order to protect edX from any confidential/security/legal exceptional cases that occur from inadvertent code merges and when the CC is included to troubleshoot the issue. Additionally, edX is obligated to protect member, customer, and learner info, when there is an unintended disclosure.
Internal Champions
Each CC in the pilot is assigned to 2 edX employees as their 2 internal champions. The champions support the CCs through the pilot to:
Ensure a reliable and timely communication channel exists with the CC, for example, in case of emergencies or questions on upcoming PRs.
Wherever possible, avoid private discussions and default to public channels.
Inform the CC of escaped production issues through the deployment pipeline’s auto-notification.
The CC can undo their changes by merging (and deploying via CD) a revert of their PR.
Escalate urgent issues to edX engineering management that are impediments for the CC.
Help the CC connect with relevant technical owners, as required by the review process below.
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 core committer
...
N/A
...
Technical enhancements
...
1 core committer
...
Acknowledgement from owning team4
...
End-user facing changes
...
1 edX product
1 core committer
...
Acknowledgement from owning team
People
We believe the following shortlist of long-time contributors are ideal candidates for this initial pilot experiment and for providing feedback to iterate and improve the program in its future.
...
CC
...
Current Org
...
Repos
...
2 edX Champions
...
Zia Fazalziafazal
...
Edly by Arbisoft
...
edx-platform
...
Jeremy Bowman (Deactivated) & Feanil Patel
...
Braden MacDonaldbradenmacdonald
...
OpenCraft
...
blockstore, xblock, xblock-sdk, xblock-utils, opaque-keys, edx-platform
...
...
Usman Khalidsymbolist
...
OpenCraft
...
blockstore, xblock, xblock-sdk, xblock-utils
...
...
Jill Vogelpomegranited
...
OpenCraft
...
configuration, edx-ora2
...
Ned Batchelder (Deactivated) & Feanil Patel
...
Felipe Montoya,felipemontoya
...
EduNext
...
xblock, xblock-sdk, xblock-utils, opaque-keys, edx-platform,
...
Jeremy Bowman (Deactivated) & Feanil Patel
...
Omar Al-IthawiomarIthawi
...
Appsembler
...
edx-ace
...
Ned Batchelder (Deactivated) & Nimisha Asthagiri (Deactivated)
...
Peter Pinchpdpinch
...
MIT Open Learning
...
ccx-keys, opaque-keys, xblock, xblock-sdk, xblock-utils, edx-platform
...
Dave Ormsbee & sburch (Deactivated)
...
Regis Behmoregisb
...
...
devstack, edx-toggles, django-config-models, edx-django-utils, code-annotations
...
Jeremy Bowman (Deactivated) & Kyle McCormick
...
Igor Degtiarovidegtiarov
...
Raccoon Gang
...
xblock-lti-consumer, edx-organizations, auth-backends, edx-search, edx-rest-api-client, edx-rbac, edx-proctoring
...
Ned Batchelder (Deactivated) & Nimisha Asthagiri (Deactivated) & Simon Chen
Phase 2: Co-establish and publish CC program
Building upon learnings from the pilot, in this phase we focus on officially establishing and publishing the CC program in collaboration with the participants in the pilot.
Retro. Collect feedback and input in the form of a retrospective of the pilot program.
Adjust. Based on learnings from the retro, make any adjustments to the proposed program.
Selection. With the group, form a concrete proposal for the selection criteria of who can join as a CC.
Publish. Document and publish the establishment of the CC program, along with its updated rights, responsibilities, and selection process. When published, communicate that the program is still in its infancy and yet to be fully developed (to be scalable in phase 3).
Phase 3: Scale program without the need for champions
At this point, we pivot from small-scale hand-holding of CCs to a more scalable solution. Based on learnings from the previous phases, we can introduce measures to reduce involvement from the internal edX champions. Otherwise, the limited availability of edX champions will remain a bottleneck and prevent the expansion of this program.
During this phase, we can also revisit the need for CCs to sign an NDA, depending on learnings from earlier and how we choose to scale the program.
Expansion Ideas
Here are some preliminary ideas for scaling the program (pending learnings from earlier phases):
Self-serve testing capability to predict scalability and production issues (ref: DrupalCI Testing)
Further advancements in decoupling code changes from production usage
Toggle agility and scalability
Configuration simplicity and decoupling
Extract CC-ownable extensions from the core and distribute shared ownership of extensions with CCs
Rejected Ideas
Here are some alternative ideas that were considered, but rejected after initial deliberation with edX Legal and Enterprise representatives:
Give CCs access to edX production debugging and monitoring tools so they can be self-sufficient with addressing issues in their own code changes and repositories.
Give CCs access to edX deployment pipeline and other operational infrastructure so they can rollback and manage deployment of their own changes.
These approaches take us down the path of having CCs be closer in relation to edX contractors, with them gaining potential access to edX PII and production data in order to troubleshoot issues. While this may be a viable path to production-aware self-sufficiency, it complicates the CC relationship and introduces legal and security barriers. So we reject this path in favor of keeping CCs focused on code, rather than data and deployment and confidential business.
Target Milestones
June 2020: Phase 1 begins
Sep 2020: Phase 2 begins
Jan 2021: Phase 3 begins
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.
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.