[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
Dogfood within Open edX theme
[Ned/Sarina] BTR
EduNext ?
[Sarina] Pilot with T&L team
[Sarina] Pilot with a team w/ enthusiastic eng mgrs
[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
Consumer Review
Frontend Core Committers
Core Committers Phase 2 (note Retro Summary at the bottom)
https://docs.google.com/document/d/1vNzw7oLdiuz2ofWlPNLuWyjDM19o-gqVmOWzSb8ef8U/edit
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
Expand from 9 to 9x9 (?) by end of this year (Dec).
Expand to include any type of contributor, not just developers.
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
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”
Externalizing edX Organization
Specialty Champions
Direct access to edX experts: a11y, performance, database migrations
Ownership Transparency
GitHub Intentional Management
Github team names
Namespacing things
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.
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.