Skip to content

Instantly share code, notes, and snippets.

@tobie

tobie/notes.md

Forked from calebamiles/notes.md
Created July 20, 2018 05:39
Show Gist options
  • Save tobie/8d0dd0b7d1abc3f7b0d9dda92553993f to your computer and use it in GitHub Desktop.
Save tobie/8d0dd0b7d1abc3f7b0d9dda92553993f to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @calebamiles calebamiles revised this gist Apr 24, 2017. 1 changed file with 5 additions and 1 deletion.
    6 changes: 5 additions & 1 deletion notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -27,7 +27,11 @@
    - [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
  2. @calebamiles calebamiles revised this gist Apr 24, 2017. 1 changed file with 39 additions and 0 deletions.
    39 changes: 39 additions & 0 deletions notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,33 @@
    ### 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)

    ### OpenStack Foundation
    - [OpenStack Technical Committee](https://governance.openstack.org/tc/)
    - project meetings held in IRC
    @@ -27,6 +57,15 @@
    - 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

  3. @calebamiles calebamiles revised this gist Apr 14, 2017. 1 changed file with 32 additions and 1 deletion.
    33 changes: 32 additions & 1 deletion notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,34 @@
    ### Apache
    ### 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

    ### 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
    @@ -26,6 +56,7 @@
    - 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/)
  4. @calebamiles calebamiles revised this gist Apr 13, 2017. 1 changed file with 28 additions and 0 deletions.
    28 changes: 28 additions & 0 deletions notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,31 @@
    ### Apache

    - [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/)
  5. @calebamiles calebamiles revised this gist Apr 11, 2017. 1 changed file with 9 additions and 9 deletions.
    18 changes: 9 additions & 9 deletions notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,7 @@
    ### Mozilla

    - [module ownership governance system](https://www.mozilla.org/en-US/about/governance/policies/module-ownership/)
    - module owners have ultime control for a module but are instructed not to be tyrants
    - 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
    @@ -10,13 +10,13 @@

    - [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 goverance changes
    - 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 responsibile for delegating reviewer rights for subteam area
    - subteam responsible for delegating reviewer rights for subteam area
    - requirement that each subteam must contain at least one member of the core team
    - subteam responsibile for alerting core team on RFCs which are cross cutting or have entered "final comment period"
    - 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
    @@ -42,7 +42,7 @@
    - 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 resport after consensus fails
    - Technical Committee makes decisions only as last resort after consensus fails
    - mechanism for devolving powers from Project Leader

    ### GNOME
    @@ -53,7 +53,7 @@
    - [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 contirbutors must have direct ability to influence decisions which are made
    - 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
    @@ -66,15 +66,15 @@
    - standards definition
    - direction and vision
    - $$$ handling
    - clearly definied structure
    - 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 voiting advisory board to collect corporate concerns; advisory board is fee based
    - 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
    - explcit decision to build on the existing structure
    - explicit decision to build on the existing structure
  6. @calebamiles calebamiles revised this gist Apr 10, 2017. 1 changed file with 0 additions and 5 deletions.
    5 changes: 0 additions & 5 deletions notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,6 @@
    ### Mozilla

    - [module ownership governance system](https://www.mozilla.org/en-US/about/governance/policies/module-ownership/)
    tl;dr
    - module owners have ultime 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
    @@ -10,7 +9,6 @@
    ### Rust

    - [Rust Governance RFC](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
    tl;dr
    - technical decisions made by consensus driven RFC process
    - clearly stated goals of goverance changes
    - creation of subteams under core team to scale focus and handle increased number of RFCs
    @@ -31,7 +29,6 @@
    ### Debian

    - [Debian Constitution](https://www.debian.org/devel/constitution)
    tl;dr
    - 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
    @@ -51,11 +48,9 @@
    ### GNOME

    - [GNOME Foundation membership guidelines](https://mail.gnome.org/archives/foundation-announce/2002-October/msg00003.html)
    tl;dr
    - 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)
    tl;dr
    - clearly stated principles of the project
    - focus on openness
    - all contirbutors must have direct ability to influence decisions which are made
  7. @calebamiles calebamiles created this gist Apr 10, 2017.
    85 changes: 85 additions & 0 deletions notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,85 @@
    ### Mozilla

    - [module ownership governance system](https://www.mozilla.org/en-US/about/governance/policies/module-ownership/)
    tl;dr
    - module owners have ultime 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)
    tl;dr
    - technical decisions made by consensus driven RFC process
    - clearly stated goals of goverance 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 responsibile for delegating reviewer rights for subteam area
    - requirement that each subteam must contain at least one member of the core team
    - subteam responsibile 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)
    tl;dr
    - 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 resport 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)
    tl;dr
    - 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)
    tl;dr
    - clearly stated principles of the project
    - focus on openness
    - all contirbutors 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 definied 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 voiting 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
    - explcit decision to build on the existing structure