Phases of Phase 3 - Rollout Plan - Milestones
Initial
early meeting with Legal
learn from edX Champions what they actually did
Soon
Update edX career skills pathway to include “community” efforts.
Quantify the skillsets of our potential CCs
Eng Manager Roadshow
bring forth ideas of mapping experienced CCs with teams' existing tech debt/backlog
Later
Consumer Review
Prior Art: Core Committer Program
Core Committers Phase 2 (note Retro Summary at the bottom)
https://docs.google.com/document/d/1vNzw7oLdiuz2ofWlPNLuWyjDM19o-gqVmOWzSb8ef8U/edit
Why
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
Goal
Expand from 9 to 9x9 (?) by end of this year (Dec).
Expand to include any type of contributor, not just developers.
Scaling impediments
Need to scale “edX Champions” that were assigned to Core Committers
Scaling Community-driven Development (ideation)
What did edX Champions do?
Operational - deploying to and monitoring production.
Merged for Core Committer in repos that have Continuous Deployment
(Continuous Deployment of http://edx.org prevents us from trusting the community to merge)
Liaisons to edX employees when needed.
Alignment on platform needs and direction
Brainstorm: How are we going to move Phase 3 forward? ✨
A. Growing # of CCs
Team-based Champions
Intended Outcomes
Cuts down on bus-factor (team support
Helps form relationships and communications
Helps align on tech roadmap
Sharing work from our tech backlogs (eg reviewing PRs, proposing ADRs, train new developers, write docs, refactor, etc)
Question around how to get team buy-in; what if some teams end up with disproportionate CCs? (ex CE team owns most XBlocks)
If a team is getting “too many” contributions (aka “producing work”), just give them more resources ;)
As we scale to Phase 3 (beyond the first 8 champions), I imagine we’ll need team buy-in.
⇨✨ Non-Devs as CCs: Explore what this could look like and the criteria, etc.
Need better definition of “non-code” contributors
⇨✨ BTR could use core committers to particular branches.
Question: Meaning BTR would have CCs for only certain branches in repos?
Yes: “open-release/lilac.master in these 36 repos”
B. Reducing Friction (easier to be a Core Committer or a Champion)
Externalizing edX Organization
Specialty Champions
Direct access to edX experts: a11y, performance, database migrations
Ownership Transparency
GitHub Intentional Management
Github team names
Namespacing things
C. Reducing Risk
Limiting CC Access
Continuous Deployment: Limit CCs to satellite repos
Or at least, actively make more CCs on smaller repos rather than edx-platform
Directory/module-specific core committers? Is this possible? (You can only merge code to X sub-directory of edx-platform, for instance)
CI Checks
Scale & Performance
Best Practices Education
How to write good Open edX migrations, APIs, react components, tests, etc.
GitHub Intentional Management
Repo access
Build a bot to allow/enforce fine-grained merge/cherry-pick access
Rearchitect Core: On removing the CD issues:
Shrink the “core”, version it, and deploy versions of the core to http://edx.org without CD. Punt extensions out of the core and use CD on those instead, where the majority of development and experimentation are taking place.
I’m thinking about how open source companies that provide hosted services probably run (“probably” because this is not evidence-based) - in that if you’re running hosted elasticsearch and you are Elastic, you’re presumably not running that from the main branch, but from versioned releases of the product so that your customers know what to expect.
If we do merge freezes
Regarding merge freezes - Can we deploy off a branch that we update from main? Then we can choose when CD happens based on when we merge to that branch, and main can continue along its merry way? If you name them develop and release then it maybe makes more sense.
Omg you’re giving me nightmares/flashbacks to our old release cycles :) but perhaps we could make this work with appropriate automation
Could we programmatically enforce merge freezes somehow in GH to eliminate the concern about CCs merging at inopportune times? I think Jinder mentioned something.
D. Maximize Aligned Contributions
What: Aligned Roadmap: Creation of shared roadmap (already a backlog item)
⇨✨ Pick a place where we want to put our roadmap
How: Definition of Done: i18n, a11y, test-coverage, etc.
CCs should demonstrate good understanding of best practices for the code they can commit.