...
Proposal
Lines of Communication
...
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, it’s easy for requests to fall through the cracks as team members can assume “others will handle this”. Effectively, the CC is embedded in a team, but there is direct ownership over the relationship.
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 on 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 depending on area
...
. For example someone working on LTI as well as platform core may have POCs within CE as well as TNL.
Rollout Plan
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; I suggest teams with welcoming eng mgrs 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