Governance Breakout

Here are notes I took from the governance breakout session at the Developer Summit.

Everyone wants big magic button for commit access
Veto power by community
Want to be able to raise flags and get issues reviewed if a merge will impact downstream community
- Want influence over architectural direction of the platform
- “Soft” veto power - the ability to prevent merges that will have negative impact
Xav- not just asking for stuff but seen as a positive resource
Feature proposal - “community source” it -
- Everyone can submit OEPs to kick off review
- edX can review and determine validity or which direction to push activity

Ideal Governance Model

Open up committer status - decision-making power
Nate: if there’s concern about opening up, can we open up specific project
- Start with xblock?
- Edx isn’t using, why not open up process around xblock
Giulio - Drupal not wholly owned by Acquia - core committers come from outside
- Drupal community can push things into core
- Ed: plugin community is massive and moves at its own pace
Xavier - what is the community prepared to contribute
- What are core committer responsibilities - what are they willing to contribute?
- What criteria do we use for selection process
What about money? How much could organizations contribute?
Drupal foundation has corporate sponsors
Plone has foundation, copyright ownership, “framework team”
Nate - let’s decide as a community right way to govern open edx project
Omar - face the risk of breakage because edx makes a decision that filters downstream
- Gap between edx and everyone else forces companies to expend significatn energy closing that gap
- “Opportunity cost” - energy expended on cleanup could be spent on creating “additive” code
- Matej “refactoring” code, pushing into product - outside of open edx
Xavier - community waits too long to push new things
- Define process, what would be the application process, how to do reviews, PRs

Ed: do questions about changing the core, BE/FE breakup concern community members

Giulio - concerned, but understands why it’s needed
We have to have understanding of how to kill stuff
Arch wants to kill things some people are still using
Review the deprecation OEP!
Omar: half the things I have to push upstream should be plugins
- Excited by FE/BE split, API utilization
Nate: how can we talk about RBAC with edX, but also how can we have arch meetings more than once per year - 1 / quarter?

To summarize: we’ve done this before, “show me the money”