We want to expand the Core Committer program from its current membership of 9 engineers for the following reasons:
Innovation: stronger innovative collaboration with the Open edX community
Accelerate: increased developer velocity that accelerates platform advancement
Capacity: increased developer capacity to own and maintain the platform
We’d love to expand this membership to 81 core committers - encompassing engineers, PMs, UXers, Doc writers, and more - this calendar year. This document focuses on where we might go in Q4, which involves adding more engineering core committers; initially, these will likely be drawn from partner organizations. In tandem, we will work on defining what a non-engineering core committer looks like, and work to identify community members that meet that definition. Longer term, we will develop strategies to expand the core committer program to 81 members and beyond, and seek to find CCs from outside our partner orgs.
In May 2021, a survey of CC Champions was conducted. As a reminder, CC champions were edX employees who served as an interface between CCs and edX. Each CC in the pilot was assigned to 2 edX employees as their 2 internal champions. The champions supported 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.
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.
This survey sought to understand how the pilot program went and how much effort was required of champions. We discovered that:
The majority of champions spent less than an hour a week, and no more than 2, working with their assigned CC
Most engaged with their CC in myriad ways: Open edX Slack, shared Slack channels, email, and PR comments
The majority rarely reviewed PRs coming from CCs, trusting them to have the knowledge to review and approve them
There was a decided mix of who let CCs merge their own PRs - 1 always did, 1 never did, and the remaining 6 were split between letting their CC merge rarely, sometimes, or often.
Overall the sentiment was that CCs know their stuff, and champions assisted primarily in connecting CCs with other experts. Most champions expressed that their CCs were fairly autonomous.
The overall feeling is that the CC program is going well.
CCs are serving as additional code reviewers for teams
Pluggability will help things out a lot
CCs need to be better informed about decisions made about the future of code and code repos
This first round involved CCs very familiar with edX code; will we be able to grant such autonomy and spend as little time on the program when we expand to those with more varied experience?
We propose that each CC has a singular point of contact, aligned with a team that owns the area(s) that the CC is working in. We initially debated an “embedded in the team” model, but felt that this would be problematic as it’s easy for requests to fall through the cracks as team members can assume “others will handle this [email/PR/Slack message]”. Via team-based review and communication described below, the CC is effectively embedded in a team, but there is still direct ownership over the relationship. I am using the term “point-of-contact” or POC here rather than “Champion”, which I believe has more implications that only one person, rather than a team, is responsible for the CC.
This singular point-of-contact would take the form of one person on a team, with another as backup. We recommend the backup be the engineering manager for the team, to facilitate routing requests when the first POC is unavailable.
Team-based review and communication: We strongly recommend each team make a shared external-openedx-[teamname] Slack channel with team’s CCs and all team members. The CC’s POC on the team may delegate any needed reviews and merging to others on the team. We also encourage teams to reach out to their CCs for reviews on their own PRs.
We recognize that CCs may work in various areas of the codebase. Therefore, a CC may have multiple POCs depending on area. For example, someone working on LTI as well as maintenance upgrades may have POCs within CE as well as Arch-BOM.
Open edX theme (CE, Arch-BOM) should be first teams to pilot new approach
Identify a handful of new CC’s that would match these two teams' domains
Run for a month, then assess how things are going - did communication work alright? Were benefits accrued (ie, the team received code reviews from CC’s; new additions to the platform were beneficial)? Evaluate how much time and effort was spent to support the CCs.
If things are going well, expand to another 2-3 teams in early Q1; I suggest teams with engineering managers who volunteer and/or teams with ongoing Blended projects (TNL/TNL-PAK for example)
If things aren’t going well, we’ll huddle to pivot direction and run another month