With The father of Python Guido van Rossum stepping down from BDFL, the future of Python (specifically CPython) is on the minds of many developers. So far, the Python community has proposed seven governance solutions, and the winner will determine the direction and approach of Python’s future development. This topic is so important that any Python developer should be aware of it. Victor Stinner, one of Python’s core developers and author of PEP-8015, provides a comprehensive comparison of these seven governance proposals, which I translate as follows:

Original text: tc n/EyhQd3b

By Victor Stinner

The cat under the Pea flower

Note: The original was published on November 6, the translation is based on the November 27 version

I did a comparison of several important differences in governance PEPs. I chose to ignore some of the less important aspects, such as dedicated voting organizations (see each PEP for details). It’s not easy to extract information and summarize it, so I can make mistakes.

I suggest voting on governance proposals not by their completeness, but by focusing on the part of the decision-making process, namely who gets to make decisions and how? In my opinion, pePs that are not complete enough can absorb the best ideas of other PEPs and gradually improve themselves.

PEPs

From PEP 8000:

  • PEP 8010 – The Technical Leader Governance Model

    Continue Status Quo (ish)

    Sponsor: Barry Warsaw

  • PEP 8011 – Python Governance Model Lead by Trio of Pythonistas

    Similar status quo, but three people making decisions

    Sponsors: Mariatta Wijaya, Barry Warsaw

  • PEP 8012 – The Community Governance Model

    There is no central decision maker

    Proposer: ł ukasz Langa

  • PEP 8013 – The External Governance Model

    Non-core Oversight

    Sponsor: Steve Dower

  • PEP 8014 – The Commons Governance Model

    Core Oversight

    Sponsor: Jack Jansen

  • PEP 8015 – Organization of the Python Community

    Push most decisions -making to teams

    Sponsor: Victor Stinner

  • PEP 8016 – Steering Council Model

    Bootstrap iterating on governance

    Sponsors: Nathaniel J. Smith, Donald Stufft

Addition,

Most PEPs have a “top of the Hierarchy” (steering committee, board of Directors, Big Three, GUIDO, etc.), except peP-8012 and PEP-8014.

PEP 8011, 8012, and 8015 define “working groups” (or “experts” or “Python teams”) that explicitly participate in the decision process, which can be considered the second level of decision making.

PEP 8014 allows anyone (any Python user) to vote. PEP 8013 excludes core developers from decision-making committees. With the exception of these two exceptions, the decision process in all pePs is strongly dependent around core developers (candidates must be core developers, only core developers can vote, etc.).

PEP 8010, 8012, 8013, 8014, and 8016 propose No Confidence votes. I’m not sure other PEPs are deliberate if they don’t include this. I like this proposal so will add it to my pep-8015 🙂

PEP 8015 and 8016 strictly limit the number of members on a committee to less than 50% being businesses (maximum of two on a five-member committee). Other PEPs have no restrictions.

Some PEPs (8010, 8011, and 8014) focus almost exclusively on defining the top decision level, while others (8015 and 8016) also focus on electing/ejecting core developers, how to update governance proposals, and so on. I don’t know if the former was intentional, or if there wasn’t enough time to perfect it.

PEP 8011, 8014, and 8015 mention diversity, but do not mention detailed rules on how to “enforce” diversity. Pep-8011 says: “Take every effort into including members from underrepresented group into consideration.”

Top level of decision making

  • Pep-8012 explicitly avoids it

  • Pep-8014 has a Council of Elders that decides how and when to approve pePs, based on a vote open to all (see the section on PEP processes below)

Other PEPs refer to them as Technical leaders, Trio, Council, Steering committees, and so on.

membership

  • PEP 8010:4 = 1 (Leader) + 3 (Council)
  • PEP 8011:3 (” TRIO “) + working group
  • PEP 8012: N/A (Leaderless, autonomous expert team)
  • PEP 8013:2-4 (including 1 “Chairman”)
  • PEP 8014:5-10 (Council)
  • PEP 8015:5 (Committee) + Python team
  • PEP 8016:5 (committee) (+ other teams/multiple committees/representatives, etc. Subject to demand)

The candidate

Qualifications of candidates:

  • PEP 8010: Core Developer
  • PEP 8011: Core developers, voting members of THE PSF, the Big Three, doing their best to embrace the disadvantaged
  • PEP 8012: N/A
  • PEP 8013: Never be a core developer
  • PEP 8014: Not core developers, “Preferably diverse committee”, “Members should know Python and the Python community”
  • PEP 8015: Core developer, up to 2 enterprise members
  • PEP 8016: Up to 2 enterprise members nominated by core developers

The election

Who votes and how?

  • PEP 8010: Core Developer

  • PEP 8011 :(active) core developer

  • PEP 8012: N/A

  • PEP 8013: Core Developer; In the event of a tie, the chairman may cast another vote

  • PEP 8014: Voting open to all (core developers don’t have to be)

  • PEP 8015: Core Developer; If there is a tie, there will be a second vote. If there is a tie, then the PSF Board (used to create the committee, as well as the steering committee) will make the choice

  • PEP 8016: Core Developer; “In the event of a tie, it can be settled by the candidates, otherwise it will be chosen at random.”

## Term length and limits

  • PEP 8010:4.5 years (leader, 3 Python versions); Three-year term (Committee)
  • PEP 8011:5 years
  • PEP 8012: N/A
  • PEP 8013:1 Python version with no term limits
  • PEP 8014: “Because the powers of the council are purely procedural, it is better to have members serve longer. But it would be nice if the reinstate board could be updated regularly.”
  • PEP 8015:3 years, rotating election (1/3 replaced each year), no term limits
  • PEP 8016:1 Python version with no term limits

Vote of no confidence

  • PEP 8010: Can be used to evict (EVICT) leaders, initiated by unanimous decision of the Board, with majority decision by all core developers (no threshold for majority decision is specified)
  • PEP 8011: N/A
  • PEP 8012: N/A
  • PEP 8013: More than 2/3 votes are required for individual board members
  • PEP 8014: One elder, or group of 10 core developers, or VOTING members of the PSF, can apply for a vote with immediate effect for the entire Council
  • PEP 8015: N/A
  • PEP 8016: A 2/3 vote is required for a single member or for the entire committee

Team/Expert

  • PEP 8010: For individual PEPs, “GUIDO consults with The CoP to determine The expert”
  • PEP 8011: Working group (3-5 people) to advise the Big Three, not necessarily core developers
  • PEP 8012: Experts self-organize into sub-teams in specific areas of interest. This avoids majority voting and “design by committee”. To disband a team of experts, more than two-thirds of the vote is required.
  • PEP 8013: N/A
  • PEP 8014: N/A
  • PEP 8015: Self-organizing Python teams that the committee allows to approve their own PEPs (Packaging Teams), core developers, and contributors
  • PEP 8016: N/A

The PEP process

The worst generalization. , review each PEP

  • PEP 8010: PEP stands for, GUIDO is the final authority on PEP decisions
  • PEP 8011: The Big Three and/or the Working Group?
  • PEP 8012: Follow the existing PEP process. The proposer sets the topic direction for the PEP. The proposer is responsible for collecting and integrating feedback (from the entire community). Experts in the field then put together all the discussions and begin a 14-day final review, which does not require a community vote. If a PEP is controversial, any expert member can move a motion to reject it (2/3 vote required)
  • PEP 8013: If the Board does not veto, the PEP is automatically approved
  • PEP 8014: Voting is open to all Python users (not just core developers). The council announces whether the vote is sufficient for a decision. It came up with a decision. If the Board of Governors adopts an appeal, the party to whom the majority vote is obtained must demonstrate the conditions of admission
  • PEP 8015: The committee chooses between PEP representatives (usually from the Python team) or gives the core developers a vote of more than two-thirds
  • PEP 8016: The Board can directly approve/reject the PEP if necessary, but it is best to set up a process to avoid making such decisions (for example, delegating decision authority to the team or a BDFL representative)

Core Developer

promotion

  • PEP 8010: N/A
  • PEP 8011: N/A
  • PEP 8012: Core developer votes, each -1 counts as a veto
  • PEP 8013: Core developer votes, each -1 counts as a veto
  • PEP 8014: N/A
  • PEP 8015: Core Developer vote, two-thirds required
  • PEP 8016: Core Developer vote, two-thirds vote, board veto

eliminate

  • PEP 8010: N/A
  • PEP 8011: N/A
  • PEP 8012: Vote of no confidence, more than 2/3 votes required
  • PEP 8013: N/A
  • PEP 8014: N/A
  • PEP 8015: Enforce working group temporary ban => Remove core Developer status
  • PEP 8016: Steering Committee vote, more than 4/5 votes required; Members who are inactive do not have voting rights

Update governance mode

  • PEP 8010: N/A
  • PEP 8011: N/A
  • PEP 8012: N/A
  • PEP 8013: N/A
  • PEP 8014: N/A
  • PEP 8015: Delegate to core developers, 4/5 votes required
  • PEP 8016: Commission to core developer, 2/3 vote required

Code of Conduct

  • PEP 8010: Code of Conduct governs all interactions and discussions
  • PEP 8011: The Big Three are required to follow the PSF’s Code of conduct
  • PEP 8012: Rely on existing PSF Behavior workgroups (named “Moderators” in PEP)
  • PEP 8013: N/A
  • PEP 8014: N/A
  • PEP 8015: Rely on the existing PSF behavior working group
  • PEP 8016: The steering committee is encouraged to set up the CoC process, and the details can be worked out flexibly

(Translator added)

Noun explanation:

PEP (Python Enhancement Proposals). There are nearly 500 of them, covering Python functionality implementations, specifications, and peripheral information. The seven proposals presented in this article are all for the new governance model, with additional proposals likely to follow. To better understand PEP and find out which proposals are required reading, read my book learning Python without Knowing A Little PEP. .

PSF: The Python Software Foundation (Python Software Foundation) is a non-profit organization whose mission is to promote the Python community by organizing various community events. Such as developing core Python distributions, managing intellectual property, hosting developer conferences (such as PyCon), promoting diversity and internationalization, and raising development funds.

BDFL: Benevolent Dictator For Life, formerly given to Guido Van Rossum, with absolute and final authority. On July 12, 2018, he announced that he would no longer serve in this capacity. The entire PEP in this article is about how to select the new BDFL and the accompanying governance scheme; the term no longer refers to anyone in particular.

Postscript:

This is my first attempt at translation work, and it is hard to be a know-it-all. However, when the translation is finished, I get the sweet joy is really the knowledge of the self-knowledge! As most of the content of the original text is extremely general short sentences, there are many proprietary expressions, so, I take the translation strategy is to try to convey the meaning, therefore, inevitably there are translation mistakes and deviations from the original text, welcome readers and I (public number: Python cat) exchange correction. Translation of this article is personal behavior, purely for the purpose of exchange and learning, welcome to reprint, but please ensure that the source, do not use for commercial or other bad purposes.

—————–

This article was originally published on the wechat public account [Python Cat]. The background replies “Love learning”, and you can get 20+ selected e-books for free.