Governance Breakout

Owned by John Mark Walker (Deactivated)
Jun 04, 2018
2 min read

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.