- 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 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
- basically a pointer to working groups chartered under the Core Technical Committee (CTC) which manages
- 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!
- 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
- projects within the foundation serve as central decision making body
- 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
- 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 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 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 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
Added notes on Node.js governance. I agree, @bgrant0607 that the Node.js Foundation has a pretty attractive model especially relative to where we are now.