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”

• What are the attainable next steps
• Working on specific projects
• Turnover over less-used repo to community
• Short of giving commit access, if certain community members can have soft veto
• Can we get substantive proposals from the community (OEPs)
• Community to create proposal for commit access and community process
• How many lines of code? Reviews? Precise criteria?
• edX review - within the sprint?
• What comes next?
• Regular arch meetings? Please please attend. Pretty please.