- 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
Just a quick note on VOTING in apache.
They may seem like an overly bureaucratic process, but they are actually legal implications.
For example the act of VOTING on a release, removes the liability of the release manager and puts it on the foundation. The VOTE is officially recorded in mailing list to show that we followed the foundation process.
If there was ever a lawsuit against an ASF software that was properly released (with a VOTE), than they lawsuit would be against the foundation and not against the Release Manager or even individual contributor.