### Node.js Foundation
- [Healthy Open Source](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
  - 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](https://github.com/nodejs/TSC/blob/master/Project-Lifecycle.md)
   - 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](https://github.com/nodejs/TSC/blob/master/TSC-Charter.md)
   - 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](https://github.com/nodejs/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](https://governance.openstack.org/tc/)
  - 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](https://governance.openstack.org/tc/reference/principles.html)
    - 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](https://governance.openstack.org/tc/goals/index.html)
  - Historical archive of [resolutions adopted by the technical committee](https://governance.openstack.org/tc/resolutions/index.html)
- [OpenStack User Committee](https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee)
  - tracks OpenStack usage and installation
  - aggregates themes/requirements into multi release roadmap
  - creation of a repeatable, transparent process for prioritization of [Development Proposals](https://wiki.openstack.org/wiki/ProductTeam/Development_Proposals) for cross project changes
  - projects have explicit technical lead "Maintainer"
- [Node.js Top-Level Working Groups](https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md)
  - basically a pointer to working groups chartered under the Core Technical Committee (CTC) which manages `node.js/node`
- [Node.js Core Working Groups](https://github.com/nodejs/ctc/blob/master/WORKING_GROUPS.md)
  - 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](https://www.apache.org/foundation/how-it-works.html)
  - 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](http://www.apache.org/foundation/board/reporting)
- [Policy on software releases](http://www.apache.org/legal/release-policy.html)
  - 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](http://incubator.apache.org/incubation/Process_Description.html)
  - established body for handling incubation project management
  - requirement to create project scope, mission, and charter as a precondition for graduation
  - [extensive guide](http://incubator.apache.org/guides/proposal.html#template-issue-tracking) on how to create a proposal
- [Formal mentoring guide](http://community.apache.org/mentoringprogramme.html)
  - project is selected by potential mentee
  - mentorship can start whenever
  - mentees help improve mentorship program

### Mozilla

- [module ownership governance system](https://www.mozilla.org/en-US/about/governance/policies/module-ownership/)
  - 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](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
  - 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](https://www.debian.org/devel/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](https://mail.gnome.org/archives/foundation-announce/2002-October/msg00003.html)
  - 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](https://wiki.gnome.org/action/show/FoundationBoard/Resources/Charter?action=show&redirect=Foundation%2FCharter)
   - 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