Hi,
I wrote a comparison of some points which I consider important in
governance PEPs. I chose to ignore some aspects which I consider less important
like exact organization of votes (see each PEP for that). It is not always easy
to extract the information and summarize it, so it’s likely that I made mistakes.
My advice to vote on governance PEP would to not judge PEPs in their completeness, but focus on the decision process. Who can take decisions and how? IMHO it’s fine to complete PEPs which are less complete later, by copying best ideas from other PEPs.
PEPs
From PEP 8000:
-
PEP 8010 - The Technical Leader Governance Model
- continue status quo (ish)
- Author: Barry Warsaw
-
PEP 8011 - Python Governance Model Lead by Trio of Pythonistas
- like status quo but with 3 co-leaders
- Author: Mariatta Wijaya, Barry Warsaw
-
PEP 8012 - The Community Governance Model
- no central authority
- Author: Łukasz Langa
-
PEP 8013 - The External Governance Model
- non-core oversight
- Author: Steve Dower
-
PEP 8014 - The Commons Governance Model
- core oversight
- Author: Jack Jansen
-
PEP 8015 - Organization of the Python community
- push most decision-making to teams
- Author: Victor Stinner
-
PEP 8016 - The Steering Council Model
- bootstrap iterating on governance
- Author: Nathaniel J. Smith, Donald Stufft
Differences
Most PEPs have a “top of the hierarchy” (Steering Committee, Council, Trio, GUIDO, etc.), but PEP 8012 and 8014 don’t.
The PEP 8011, 8012 and 8015 define “working groups” (or “experts” or “Python Teams”) which are explicitly involved in the decision process, and may be seen as the second level of the hierarchy.
The PEP 8014 includes everybody (any Python user) in votes, like for vote on a PEP. The PEP 8013 excludes core devs from its council. Except of these exceptions, the decision process is strongly around core devs in all governance PEPs (candidates must be core devs, only core devs can vote, etc.).
PEP 8010, 8012, 8013, 8014 and 8016 define a No Confidence Vote. I’m not sure
if it’s a deliberate choice that other PEPs don’t have such vote. For example,
I like the idea and should add it to my PEP 8015 
PEP 8015 and 8016 restrict companies to have strictly less than 50% members of the
council (2 members max of a council of 5 members). Other PEPs have no restriction.
Some PEPs (PEP 8010, 8011 and 8014) are strongly focused on defining the top of
the hierarchy, whereas others (PEP 8015 and 8016) try to also formalize how
core developers are elected/ejected, how the governance PEP will be updated,
etc. I’m not sure if it’s only a deliberate choice, or a lack of time to
“complete” the PEP.
PEP 8011, 8014, 8015 mention diversity but have no strict rules to “enforce”
diversity. PEP 8011 says “take every effort into including members from underrepresented group into consideration”.
Top of the hierarchy
- PEP 8012 explicitly avoids it.
- PEP 8014 has a Council of Elders who decides how and when a PEP is approved, decision based on a vote open to everybody (see the PEP process section below for detail).
Other call it Technical Leader, Trio, Council, Steering Committee, etc.
Number of people
- PEP 8010: 4 = 1 (leader) + 3 (council)
- PEP 8011: 3 (“trio”) + working groups
- PEP 8012: N/A (no leader, but self-organized teams of experts)
- PEP 8013: 2 to 4 (including 1 “president”)
- PEP 8014: 5 to 10 (council)
- PEP 8015: 5 (committee) + Python Teams
- PEP 8016: 5 (committee) (+ further teams/committees/delegates etc. to be defined as desired)
Candidates
Requirements to be a candidate:
- PEP 8010: core dev
- PEP 8011: core dev, voting PSF member, slate of 3 core devs, take every
effort into including members from underrepresented group into consideration - PEP 8012: N/A
- PEP 8013: must not be core devs
- PEP 8014: no need to be a core dev, “it would be good if the council is diverse”. “Members should be knowledgeable about Python and the Python community”.
- PEP 8015: core dev, max 2 members/company
- PEP 8016: nomination by a core dev, max 2 members/company
Election
Who votes, how?
- PEP 8010: core devs
- PEP 8011: (active) core devs
- PEP 8012: N/A
- PEP 8013: core devs, release manager may get 1 extra vote to avoid tie
- PEP 8014: vote is open to everyone (no need to be a core dev)
- PEP 8015: core devs, second vote in case of tie, the PSF Board (for the creation of the committee, then the Steering Commitee) chooses in case of a new tie in the 2nd vote
- PEP 8016: core devs, “If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.”
Term length and limit
- PEP 8010: 4. 5 years (leader, three Python releases); 3 years with rotating elections (council)
- PEP 8011: 5 years
- PEP 8012: N/A
- PEP 8013: 1 Python release, no term limit
- PEP 8014: “Because the powers of the council are purely procedural it is probably good if members serve for a fairly long time. However, it would still be good if the council was reinstated regularly.”
- PEP 8015: 3 years, rotating elections (1/3 replaced every year), no term limits
- PEP 8016: one Python release, no term limits
No confidence vote
- PEP 8010: can be used to evict the leader; vote triggered by unanimous decision by council, followed by a supermajority vote by all devs (exact supermajority threshold not specified)
- PEP 8011: N/A
- PEP 8012: N/A
- PEP 8013: vote need > 2/3 majority, against one council member
- PEP 8014: A single Elder, or a group of 10 core developers, or PSF voting members can ask for an immediate reinstating vote of the council as a whole.
- PEP 8015: N/A
- PEP 8016: vote needs 2/3 majority, target a single member or the whole council
Teams / Experts
- PEP 8010: for a PEP, “GUIDO, in consultation with the CoP, identifies experts”
- PEP 8011: Working Groups (3-5 people), advice the Trio, no need to be core devs
- PEP 8012: Experts self-organized into sub-teams for a given area of interest. This avoids most voting and “design by committee”. Disbanding a given experts team requires a vote with > 2/3 majority.
- PEP 8013: N/A
- PEP 8014: N/A
- PEP 8015: self-organized Python Teams, Committee might allow them to approve
their own PEP (Packaging Team), core devs and contributors. - PEP 8016: N/A
PEP process
XXX worst summarized section, double check each PEP XXX
- PEP 8010: PEP delegate, GUIDO is the ultimate authority for decisions on PEPs
- PEP 8011: trio and/or working groups?
- PEP 8012: Formalized existing PEP process. PEP author identifies which area of interest the PEP belongs to. PEP author is responsible for gathering and integrating feedback (from the entire community). Afterwards, experts in the relevant area of interest summarize the PEP discussion and open a 14-day-long final comment period, after which the experts decide without a committer-wide vote. If a PEP is controversial enough, any committer may raise a motion to reject it by vote (2/3 majority needed).
- PEP 8013: PEPs approved when the council does not veto
- PEP 8014: Vote open to all Python users (not only core dev). The council declares whether the outcome of the vote is sufficient to carry the decision. It proposes a decision. If the council is swayed by an appeal, goes back to the state where more support has to be demonstrated.
- PEP 8015: committee chooses between PEP delegate (usually from a Python Team), or vote reserved to core
devs which requires >= 2/3 majority - PEP 8016: council can approve/reject PEPs directly if necessary, but is encouraged to set up processes to avoid this (e.g., delegating to teams or BDFL-delegates)
Core developers
Promote
- PEP 8010: N/A
- PEP 8011: N/A
- PEP 8012: core devs vote, each -1 counts as a veto
- PEP 8013: core devs vote, each -1 counts as a veto
- PEP 8014: N/A
- PEP 8015: core devs vote, need >= 2/3 majority
- PEP 8016: core devs vote, need >= 2/3 majority, council has a veto vote
Eject
- PEP 8010: N/A
- PEP 8011: N/A
- PEP 8012: vote of no confidence, need > 2/3 majority
- PEP 8013: N/A
- PEP 8014: N/A
- PEP 8015: conduct workgroup temporary ban => remove core dev status
- PEP 8016: steering council vote, >= 4/5 majority; also members who are in “inactive” status lose privileges until they become “active” again
Update the governance
- PEP 8010: N/A
- PEP 8011: N/A
- PEP 8012: N/A
- PEP 8013: N/A
- PEP 8014: N/A
- PEP 8015: vote reserved to core devs, need >= 4/5 majority
- PEP 8016: vote reserved to core devs, need >= 2/3 majority
Code of Conduct
- PEP 8010: the Code of Conduct governs all interactions and discussions
- PEP 8011: the trio (…) adhere to The PSF’s Code of Conduct
- PEP 8012: Rely on existing PSF Conduct Workgroup (named “Moderators” in the PEP)
- PEP 8013: N/A
- PEP 8014: N/A
- PEP 8015: Rely on existing PSF Conduct Workgroup
- PEP 8016: steering council encouraged to set up a CoC process but details are left flexible
Especially the PEP 8016. And the comparison focus on differences, like the Vote of no confidence. I didn’t notice this vote (I didn’t understand its important on the whole governance) when I first read other PEPs.