Phases of Phase 3

Initial

• [Nim] early meeting with Legal - Ned, Nim, Sarina

  • [Sarina] find time for 3 of us to meet & create a narrative

• [Open edX team ticket] learn from edX Champions what they actually did

Real Soon

• Dogfood within Open edX theme

  • [Ned/Sarina] BTR

  • EduNext ?

• [Sarina] Pilot with T&L team

• [Sarina] Pilot with a team w/ enthusiastic eng mgrs

Soon

• [Sarina] Update edX career skills pathway to include “community” efforts

• [Sarina/Nim] Eng Manager Roadshow

  • bring forth ideas of mapping experienced CCs with teams' existing tech debt/backlog

  • Quantify the skillsets of our potential CCs

• [Open edX team ticket] GitHub Bot to allow CCs to have limited access

Later

• Consumer Review

• Frontend Core Committers

Prior Art: Core Committer Program

• Open edX Core Committers  

• Core Committers Phase 2 (note Retro Summary at the bottom) 

• https://github.com/orgs/edx/projects/1

• 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

  • FY21 Architecture User Story Roadmap

Brainstorm: How are we going to move Phase 3 forward? ✨

A. Growing # of CCs

• Team-based Champions

  • Intended Outcomes

    1. Cuts down on bus-factor (team support

    2. Helps form relationships and communications

    3. Helps align on tech roadmap

    4. 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.

• •