notes-group-projectGovernanceSystems see also commentary in "Story 2: Digging Through the Sedimentary Layers of Enspiral’s Agreements" in older versions: some that seem particularly important:


hyperrail 1 day ago [–]

Bruce Momjian doesn't mention it in the OP blog post, but the PostgreSQL? core team consists of just 5 people including himself:


justinclift 1 day ago [–]

The core team is kept that way on purpose.

They're a decision making group (eg project direction), and the size doesn't reflect the number of active developers on the project in any way.

eg there are a lot more active developers than there are "core team"

craigkerstiens 1 day ago [–]

There are a couple big things that are probably useful context here.

The first is the different between core team and committers. The core team is much more like a steering committee than anything else. The core team is responsible for various policy issues, coordinating broader release activities, and handling disciplinary issues.

In contrast, committers are the ones that determine what code goes in and does not. The list of committers is about 30 people. And there are many people that work to contribute large pieces of code but not responsible for the final leg of committing.

Edit: I've written a bit more before on all of the non-code bits of Postgres -


" The people

Within the Postgres community there are 2 major sets of people. The core team

The core team is a smaller team within the Postgres community. The core team is effectively a steering committee for Postgres. They’re responsible for coordinating releases, handling confidential issues (read: security issues), managing permissions around PostgreSQL? code and infrastructure, defining policy.

The core team is a very small list of people, at the moment 5 individuals. Contributors

Yes, anyone can contribute to Postgres, and with each release there are a laundry of people that write some code that goes into Postgres. If fact Postgres 10 had 325 people that contributed in some form. That said there is a hierarchy that exists. The two biggest ones are committers and major contributors.

Committers gain access after years of contributing to Postgres showing sustained commitment to the project. New committers are voted on each year at PgCon? which happens in March/April in Ottawa. If you’re ever curious for a conference of what’s coming and being deep in the internals of Postgres it’s one to check out. Once you do gain your commit bit you’re expected to contribute every couple of years to the project. And of course there are a number of qualifications such as contributing high quality code and perhaps most key is helping review others contributions.

Major contributors are another notable group. Major contributors don’t have full sole commit access, but are held in a higher regard from consistently contributing major features as well as providing review for others.

Contributors in general are another area worth calling out. While they may not have a flagship feature to their name like the major contributors, Postgres is what it is because of the contributions of everyone.

" --



"The Pedantic Code Construction Contract (PC3) is an evolution of the GitHub? Fork + Pull Model, and the ZeroMQ? C4 process, aimed at providing an optimal collaboration model for commercial software projects. PC3 helps an organization build consistently good software, cheaply, and rapidly." (about stable releases in C4) ten rules for open source success long article on the motivations for his governance system, and on how it is designed to the the opposite of a cult



how does Linux do dev?

[1] [2]


how does git do dev?

[3] [4] [5] [6] [7]



" The Rust Foundation will hold its first board meeting tomorrow, February 9th, at 4pm CT. The board of directors is composed of 5 directors from our Founding member companies, AWS, Huawei, Google, Microsoft, and Mozilla, as well as 5 directors from project leadership, 2 representing the Core Team, as well as 3 project areas: Reliability, Quality, and Collaboration. " [8]

sho_hn 2 hours ago [–]

> The decision making power within the Rust project is uniquely delegated and distributed; with the core team holding little more privilege than other more specialized teams. [...] And the potential of such a system has bore fruit: It is not a mistake that such a promising technology has emerged from such a progressive conception of collaboration.

These are values and thoughts describing an approach that the KDE community (and its foundation; hello from another board!) holds equally dearly and has inscribed in its Manifesto (, cf. Common Ownership).

While maybe not unique, I'm excited to see another organization adopt this idea set (a support body not interfering with technical agenda, low barriers to participation, not entrenching maintainers, working succession mechanisms, etc.) as a core message. We've seen it work very well to sustain a productive community for 25 years and I think this bodes well for Rust!


crazypython 2 hours ago [–]

The board's vote seems to be heavily biased in favor of large corporations, with half the seats for them, 2 for the community, and 3 for "project areas." Contrast this with the governance of GCC, which has all of them as community members or project areas.


ChrisSD? 2 hours ago [–]

The goal of the foundation is to work as a bridge between the Rust teams and the corporate world (e.g. sponsorship, licensing, etc). As the blog post notes, the actual development of the language is fully open and is comprised of RFCs and the like which allow anyone to contribute. It's the core team who oversee this process, not the foundation.

In short the foundation works for Rust, not the other way around.


hobofan 2 hours ago [–]

> Contrast this with the governance of GCC

The equivalent of that would be the Rust teams[0] as far as I can tell, which will still be the governing body of all development, and won't be replaced by the Rust foundation.



--- rails

one or two ppl on seem to think that the governance process really needs to be made more explicit.


the two main 'open' IRC networks:


clarry on April 14, 2020 [–]

Open up WG14 mailing list for non-members?

It's hard to appreciate what's going on at WG14 (or take part) when you can see the results only from afar, with none of the surrounding discussion.

I recently read Jens Gustedt's blog on C2x where he casually recommended this as a way to get involved: "The best is to get involved in the standard’s process by adhering to your national standards body, come to the WG14 meetings and/or subscribing to the committee’s mailing list."

Afaict (from browsing the wg14 site), the mailing list and its archives are not open to access.

EDIT: In general, how is one supposed to approach wg14 with ideas or need for clarification on the standard's wording / interpretation?

AaronBallman? on April 14, 2020 [–]

> In general, how is one supposed to approach wg14 with ideas or need for clarification on the standard's wording / interpretation?

I'm currently working on an update to the committee website to clarify exactly this sort of thing! Unfortunately, the update is not live yet, but it should hopefully be up Soon™.

Currently, the approach for clarifications and ideas both require you to find someone on the committee to ask the question or champion your proposal for you. We hope to improve this process as part of this website update to make it easier for community collaboration.

DougGwyn? on April 14, 2020 [–]

In general, the committee accepts what we used to call "defect reports" (now something like "requests for improvement"), assigns them "WG14 series" sequence numbers, and upon requests for "floor time" schedules meeting discussions. Occasional votes are taken, which might trigger modifications to the draft standard. At some point, the committee decides that the updated draft standard is ready for public review, and the various national representatives deal with review comments. All this starts with proposal documents in "WG14 series" form.









Debian's which hunt


Rust had some sort of constitutional crisis that caused the mod team to resign in protest:

The pull request was written by the mod team that resigned.

Apparently there was a moderation process involving member(s) of the core team, but the mod team did not have the power to moderate the core team members (that is, to enforce the Rust Code of Conduct on the Core Team), so they resigned.

The followup letter, which does not conclude the issue but describes how it is being worked on and provides reassurance that the work of Rust will go on, on schedule, in the meantime, is signed by the Library team lead (the Rust core team has no lead; furthermore, the core team "does not make decisions that fall under the scope of one of the other teams") but says it is "on behalf of the top-level team leads, the new mods, the project directors to the Foundations, and the core team". The follow letter is posted to the Inside Rust Blog jointly by someone on the core team, and the person who signed the followup letter.

I call it a constitutional crisis because 25 days passed in between the mod team resigning and the followup letter, and because the followup letter describes difficulty in determining who should be part of the process for dealing with this issue -- suggesting that significant consensus-building had to take place before the mod team resignation could even be dealt with (despite two new mods, who are still there as of 25 days later, joining the empty mod team within a day of the resignation).


founder leaves: discussion:


" doug-moen 11 hours ago

link flag

I recall that in the early days, the Scheme standard was controlled by a large group of notable researchers, and a unanimous vote was required to add a new feature. That process collapsed when R7RS-large was proposed. Now it looks like the work is being continued by John Cowan and 3 other people (looking at the codeberg link from @Drakonis), using the SRFI process to generate and test proposals (each SRFI is implemented by multiple Scheme implementations before it gets added to the standard). " -- [9]

--- PEP 13 – Python Language Governance

" Creation of this document

The Python project was started by Guido van Rossum, who served as its Benevolent Dictator for Life (BDFL) from inception until July 2018, when he stepped down.

After discussion, a number of proposals were put forward for a new governance model, and the core devs voted to choose between them. The overall process is described in PEP 8000 and PEP 8001, a review of other projects was performed in PEP 8002, and the proposals themselves were written up as the 801x series of PEPs. Eventually the proposal in PEP 8016 was selected as the new governance model, and was used to create the initial version of this PEP. The 8000-series PEPs are preserved for historical reference (and in particular, PEP 8016 contains additional rationale and links to contemporary discussions), but this PEP is now the official reference, and will evolve following the rules described herein. " -- " Why the Condorcet method?

    It allows voters to express preference by ranking PEPs
    It is consensus decision-making
    In a [ poll] open to only core developers and run using Approval voting, it was the clear preference

" poll: 84%Pure Condorcet, with ties or “pathological cycles” thrown to the PSF board to resolve

    68%Schulze, with ties thrown to the PSF board to resolve
    60%Approval voting, with ties thrown to the PSF board to resolve
    48%1-2-3, with ties thrown to the PSF board to resolve
    32%IRV, with ties thrown to the PSF board to resolve

25voters 73total votes

"Nathaniel J. Smith njsCPython core developer Oct '18

    Honestly, the “Pure Condorcet” and “Schulze” choices are the same thing: if “problem cases” are punted to the PSF Board, then the only part of Schulze that remains is seeing whether there is a Condorcet winner (which, if it exists, is necessarily unique). Which is presumably exactly the same as what “Pure Condorcet” does. Schulze without punting problem cases to the PSF Board would be a different choice.

Please read the poll options as:

    “Pure condorcet”: If there’s a condorcet winner, pick that. If there isn’t – which means either a classic tie, or that we have a “Condorcet cycle” – then ask the PSF Board to resolve things. (Presumably by picking from the Smith set , if you want to get technical.)
    “Schulze”: If there’s a Schulze winner, pick that. If there isn’t – which means a classic tie – then ask the PSF board to resolve things. (Presumably by picking one of the tied options.)"

" Electing the council

A council election consists of two phases:

    Phase 1: Candidates advertise their interest in serving. Candidates must be nominated by a core team member. Self-nominations are allowed.
    Phase 2: Each core team member can vote for zero or more of the candidates. Voting is performed anonymously. Candidates are ranked by the total number of votes they receive. If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random." --

TOREAD PEP 8002 – Open Source Governance Survey "This PEP surveys existing and similar open source and free software projects for their governance models, providing summaries that will serve as useful references for Python’s own selection of a new governance model in the wake of Guido’s retirement."

voters/citizens = 'core team'

the contenders were 8010 thru 8016: PEP 8010 – The Technical Leader Governance Model (6th choice in the final vote) PEP 8011 – Python Governance Model Lead by Trio of Pythonistas (3rd choice in the final vote) PEP 8012 – The Community Governance Model (2th choice in the final vote) adhocracy -- voters join various teams at will. Decisions made via proposals submitted to those teams. Proposals pass by 100% consensus of the teammembers on a team, unless vetoed by >1/3 of all voters. New voters admitted by 100% consensus of existing voters. Voters ejected by 2/3s vote of voters. (my comment: this imo has voting thresholds that are too high. Any single voter can block any proposal by joining the relevant team and vetoing it) PEP 8013 – The External Council Governance Model (7th choice in the final vote) PEP 8014 – The Commons Governance Model (5th choice in the final vote) PEP 8015 – Organization of the Python community (4th choice in the final vote) PEP 8016 – The Steering Council Model (1st choice in the final vote) (8016 won) 5-person "steering council" elected by voters via majoritarian (not proportional) multiseat approval voting councilmember can be ejected by a 2/3 vote of the other councilmembers (so, all of the other 4), or by a 2/3s vote of the voters the whole council can be ejected at once by a 2/3s vote of the voters new voters given membership via a 2/3 vote of the voters with no veto by the steering council amend via 2/3 vote of the voters. Steering council cannot amend this document

the vote that chose 8016:


    PEP 8016: The Steering Council Model (Smith, Stufft)
    (Condorcet winner: wins contests with all other choices)
    PEP 8012: The Community Governance Model (Langa)
    loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 40–22
    PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw)
    loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 37–20
    loses to PEP 8012: The Community Governance Model (Langa) by 34–28
    PEP 8015: Organization of the Python community (Stinner)
    loses to PEP 8016: The Steering Council Model (Smith, Stufft)by 41–18
    loses to PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) by 33–24
    PEP 8014: The Commons Governance Model (Jansen)
    loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 50–9
    loses to PEP 8015: Organization of the Python community (Stinner) by 38–18
    PEP 8010: The Technical Leader Governance Model (Warsaw)
    loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 44–15
    loses to PEP 8014: The Commons Governance Model (Jansen) by 30–28
    PEP 8013: The External Council Governance Model (Dower)
    loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 55–6
    loses to PEP 8010: The Technical Leader Governance Model (Warsaw) by 38–17
    Further discussion
    loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 57–4
    loses to PEP 8013: The External Council Governance Model (Dower) by 32–29" --