...
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. The reasons for this are that if there’s not one POC, 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”. Effectivelythis [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 point of contact 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 points of contact POCs depending on area. For example, someone working on LTI as well as platform core maintenance upgrades may have POCs within CE as well as TNLArch-BOM.
Rollout Plan (Remainder of Q4)
...