5 May 2021
3 May 2021
Prior Art: Core Committer Program
Core Committers Phase 2 (note Retro Summary at the bottom)
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? ✨
Team-based Champions
Cuts down on bus-factor
Helps form relationships
Communications
Roadmap alignment
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.
edX Organizational
Specialty Champions
Direct access to edX experts: a11y, performance, database migrations
Ownership Transparency
⇨✨ Non-Devs as CCs: Explore what this could look like and the criteria, etc.
Need better definition of “non-code” contributors
Limiting CC Access
Continuous Deployment: Limit CCs to satellite repos
Or at least, actively make more CCs on smaller repos rather than edx-platform
⇨✨ 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”
Directory/module-specific core committers? Is this possible? (You can only merge code to X sub-directory of edx-platform, for instance)
Alignment
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.
CI Checks
Scale & Performance
Best Practices Education
How to write good Open edX migrations, APIs, react components, tests, etc.
CCs should demonstrate good understanding of best practices for the code they can commit.
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.
GitHub Intentional Management
Repo access
Github team names
Namespacing things
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.