Skip to content

Instantly share code, notes, and snippets.

@melekes

melekes/notes.md

Forked from calebamiles/notes.md
Created February 15, 2020 08:43
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save melekes/86ccb21dd1b88b66299508ba8866f43a to your computer and use it in GitHub Desktop.
Save melekes/86ccb21dd1b88b66299508ba8866f43a to your computer and use it in GitHub Desktop.
Download ZIP
Notes on Open Source Governance Models
Raw
notes.md

Node.js Foundation

  • Healthy Open Source
    • explicit goal to be a lightweight process
    • concrete ability to scale to hundreds of contributors
    • good fundamental goals
      • transparency
      • participation
      • efficacy
    • ecosystem projects encouraged but not required to adopt foundation governance templates
    • creation of projects under TSC explicity delegates authority from TSC to project TC
    • repository splits focused on keeping traffic to manageable levels
    • any committer can merge any approved change
    • TTL on PRs
    • doesn't blame GitHub for scaling issues ;-)
    • lazy consensus seeking process for non trivial PRs
      • default is to accept when no committer has an objection
      • onus is on reviewers to note what adjustments are needed to a PR

        For new contributors it’s a big leap just to get that initial code up and sent. Viewing the code review process as a series of small adjustments and education, rather than a quality control hierarchy, does a lot to encourage and retain these new contributors.

      • all committers have write access on the repository
      • focus on scaling the number of committers
  • Project Lifecycle
    • TSC charters working groups and top level projects which can further charter their own working groups
    • top level projects represented on TSC
    • employer quotas when establishing TC
    • time zone distribution requirement for TCs
    • uses DCO!
  • Technical Steering Committee (TSC) Charter
    • changes to charter made by simple majority of full TSC with ultimate approval made by Foundation Node.js Foundation Board of Directors
    • clear relationship between TSC and umbrella organization (Node.js Foundation)
  • Community Committee
    • directly accountable to Foundation Board of Directors alongside the TSC
    • gives explict voice to broad community around Node.js (e.g. NodeSchool)
    • oversees explicit working group focused on inclusivity (because it's 2017 and we really all should be focused on this stuff...)

OpenStack Foundation

  • OpenStack Technical Committee
    • project meetings held in IRC
    • design summits held regularly to gather requirements and draft specifications
    • public roadmaps
    • election of technical leads and members of technical committee
    • clearly defined guiding priciples
      • OpenStack Primarily Produces Software
      • OpenStack is Built for our Users
      • Contribution Is Our Currency
      • One Contributor, One Vote
      • Representative Democracy
      • OpenStack Leaders Exist to Serve Their Community
      • Changes in Leadership are Good
      • We value clear, friendly, and open communication
      • OpenStack First, Project Team Second, Company Third
      • Empowering Businesses, on a Level Playing Field
      • We all should Always Follow the OpenStack Way
      • Participation is Voluntary
    • Explicit project team lead role focused on day to day operations of project and on resolving technical disputes
    • Weekly meetings of Technical Committee on IRC
    • Meetings require quorum in order to be held
    • Separation of formalized project team and informal working groups which anyone can create
    • Ability to set OpenStack wide goals
    • Historical archive of resolutions adopted by the technical committee
  • OpenStack User Committee
    • tracks OpenStack usage and installation
    • aggregates themes/requirements into multi release roadmap
    • creation of a repeatable, transparent process for prioritization of Development Proposals for cross project changes
    • projects have explicit technical lead "Maintainer"
  • Node.js Top-Level Working Groups
    • basically a pointer to working groups chartered under the Core Technical Committee (CTC) which manages node.js/node
  • Node.js Core Working Groups
    • states the purpose and responsibilities of each working group
    • links to each working group's landing page with public membership lists!
    • each working group seems to have at least one repository under its management
    • links to meeting notes exist in SCM!

Apache Foundation

  • How the Apache Foundation works
    • projects within the foundation serve as central decision making body
      • projects determine own technical charter
      • projects determine own governance
    • establishment of Project Management Committees through resolution of Apache Foundation board of directors
      • chair of a PMC appointed to the Apache Foundation board of directors
      • PMC chair is not about coding but about the further health of the community
    • roles within Apache Foundation follow individual rather than employer
    • any member of the Apache Foundation can propose a project for incubation
    • philosophical goals of project stated
    • Apache Foundation composed of individuals without respect to affiliation
    • quarterly reporting of PMC to Apache Foundation board
    • whether to release is a voting activity
      • requires manual testing by voters
    • preference for "robust, reviewable decision making" over efficient decision making
    • PMC required to submit quarterly report to board of directors with specified format
  • Policy on software releases
    • release manager is the shepherd of the release process rather than being responsible for approving the release contents which is the purvey of the PMC
  • Incubation process
    • established body for handling incubation project management
    • requirement to create project scope, mission, and charter as a precondition for graduation
    • extensive guide on how to create a proposal
  • Formal mentoring guide
    • project is selected by potential mentee
    • mentorship can start whenever
    • mentees help improve mentorship program

Mozilla

  • module ownership governance system
    • module owners have ultimate control for a module but are instructed not to be tyrants
    • creation of a team to manage module ownership in extraordinary cases
    • module owners and peers responsible for module ownership changes
    • separation between module owner and default owner of bugs

Rust

  • Rust Governance RFC
    • technical decisions made by consensus driven RFC process
    • clearly stated goals of governance changes
    • creation of subteams under core team to scale focus and handle increased number of RFCs
    • subteams own policy for subteam
      • must determine what changes require RFC or simple pull request
    • subteam responsible for delegating reviewer rights for subteam area
    • requirement that each subteam must contain at least one member of the core team
    • subteam responsible for alerting core team on RFCs which are cross cutting or have entered "final comment period"
    • subteam responsible for RFCs and PRs progressing at a reasonable rate
    • subteam responsible for publishing status of RFCs, PRs and news related to area
    • core team sets project priorities and release schedule
    • core team can create or remove subteams
    • core team ungates features
    • features are either "nightly" or "stable" rather than alpha/beta/stable
    • clearly defines what consensus means to project
    • creation of team focused on handling Code of Conduct violations

Debian

  • Debian Constitution
    • focus on decision making bodies and process
    • ability to override decisions made by Project Leader and their Delegate(s)
    • ability for general body of developers to make position statements through general resolution
    • ability to change constitution through general resolution
    • ability for Project Leader to define new areas of ongoing responsibility
    • creation of a small technical committee
    • catch all for decision making vested in Project Leader
    • creation of Technical Committee to decide issues of technical policy
    • arbitration of areas of overlapping technical responsibility
    • formal advisory role for Technical Committee
    • term limits for service to Technical Committee
    • creation of a Technical Committee chair to avoid decision lock
    • no detailed design work by Technical Committee
    • Technical Committee makes decisions only as last resort after consensus fails
    • mechanism for devolving powers from Project Leader

GNOME

  • GNOME Foundation membership guidelines
    • prefer inclusive rather than exclusive policies (e.g not having bandwidth to process applications is not an excuse to make applying for membership harder)
    • lifetime membership with opt in renewal process to remain "active"
  • GNOME Foundation Charter
    • clearly stated principles of the project
    • focus on openness
    • all contributors must have direct ability to influence decisions which are made
    • democratic process
    • creation of a body to separate corporate interests from direct influence on project
    • role of foundation of coordinating releases, deciding what projects are part of GNOME, producing educational material
    • admission that no real powers of enforcement exist
    • independence of foundation
    • clearly defined tasks
      • release
      • public image and communication
      • corporate and organizational point of contact
      • standards definition
      • direction and vision
      • $$$ handling
    • clearly defined structure
      • elected board of directors
      • broader membership (with access gated on contribution to GNOME project)
      • advisory board
      • mechanism for broader membership to overturn decision of board of directors through referendum
      • limits on corporate/organizational control of board of directors regardless of election results
      • creation of non voting advisory board to collect corporate concerns; advisory board is fee based
      • ability for any member of foundation to issue referendum with consensus building requirements
      • limits on ability for corporate interests to vote as a block
      • ability to recall board members via referendum
    • historical section on bootstrapping
    • explicit decision to build on the existing structure
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment