Comparison of the 7 governance PEPs


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.


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


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 :slight_smile:

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)


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


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


  • 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


  • 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

I converted my post to a wiki. I’m not sure if all core devs can edit it.

As a general rule, most of the "N/A"s probably mean “doesn’t need to be defined by this PEP” as opposed to “doesn’t need to exist”. I didn’t go through to make that edit everywhere, but it’s safe to assume that the CoC will apply whether a PEP explicitly mentions it or not :slight_smile:

1 Like

Right, as it’s safe to assume that we will still promote contributors even where I wrote N/A :slight_smile:

Thanks a lot! I’ve updated various bits about 8014. I also need to do a new version of 8014 (mainly clarifying and a few minor changes) and this helps immensely because it shows the areas I need to concentrate my effort.

You’re welcome. It’s also useful for my own PEP. The other PEPs evolved after I wrote mine :slight_smile: 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.

For the PEP process of the PEP 8013, I wrote “PEP 8013: vote requires >= 2/3 majority”, but Steve replaced it with: “PEPs approved when the council does not veto”. It seems like my summary was plain wrong, it looks like a copy/paste mistake… But Steve’s sentence is unclear to me, approved… by who? I suggest to replaced it with: “the council pronounces on PEPs (accept/reject); the council can nominate a core developer to assess the proposal and provide the council a recommendation”. cc @steve.dower

He said “the council” approves which is the Council of Auditors as specified by his PEP.

Brett is correct. PEPs are approved when a core developer submits them for pronouncement and the council indicates they do not intend to refuse it (there’s a few more details about dealing with absent council members, but certainly no requirement that anyone do any voting, unless the council requests it for a particular PEP by indicating that they’ll veto it without a successful vote).

1 Like

I disagree with that. For me, the most critical part of the decision process is to approve PEPs. In the PEP 8014, the Council of Elders indirectly decides how and when a PEP is approved. It’s similar to the power of the Steering Council in my PEP 8015. It’s a weak power, but it’s still more power than regular Python users. I will update the PEP 8014 in this section to try to better describe it.

@jackjansen: I tried to update my summary for your PEP 8014 update. Would you mind to review it? You can edit directly, it’s a wiki :slight_smile:

Reviewed and updated.

1 Like

PEP 8010 specifies the term limit of council members at 3 years, with a rotating election cycle.

Oh, thanks for fixing my summary :slight_smile:

1 Like

I updated the comparison for the version 7 of my PEP 8015.

@njs: Would you mind to check if this comparison is still up to date according to the latest changes of your PEP 8016? I removed the restriction of being a core dev to a candidate of the council.

I looked it over and made some edits. I noticed a few other issues that I fixed, like noting that PEP 8010’s no-confidence requires a vote by all core devs. I also got the impression that it hasn’t been updated for @jackjansen’s changes to 8014, but I’m not familiar enough with the details there to fix it myself.

I think it’s fine (but thanks for the heads-up).