[Python-Dev] Python Language Governance Proposals

Victor Stinner vstinner at redhat.com
Tue Oct 23 05:55:56 EDT 2018


Last July, Guido van Rossum decided to resign from his role of BDFL.
Python core developers decided to design a new governance/organization
for Python. 6 governance PEPs have been proposed. It has been decided
that discussions are reserved to core developers (everyone can read,
but only core devs can write), since the governance will mostly impact
the life of core developers. I'm writing this email to python-dev to
keep you aware that something is happening :-)

Core developers (of the GitHub team) will vote to decide the new
Python governance in 3 weeks:
"The vote will happen in a 2-week-long window from November 16 2018 to
November 30 (Anywhere-on-Earth)."

See PEP 8001: Python Governance Voting Process

Below are links to the governance PEPs, their abstract, and link to
the Discourse discussions.

Note: a Discourse instance is experimented at discuss.python.org to
maybe replace python-{ideas,dev,committers} mailing lists. See the
"Discourse Feedback" category at https://discuss.python.org/  :-)

(1) PEP 8010: The BDFL Governance Model

This PEP proposes a continuation of the singular project leader model,
euphemistically called the Benevolent Dictator For Life (BDFL) model
of Python governance, to be henceforth called in this PEP the Gracious
Umpire Influencing Decisions Officer (GUIDO). This change in name
reflects both the expanded view of the GUIDO as final arbiter for the
Python language decision making process in consultation with the wider
development community, and the recognition that "for life" while
perhaps aspirational, is not necessarily in the best interest of the
well-being of either the language or the GUIDO themselves.

This PEP describes:

* The rationale for maintaining the singular leader model
* The process for how the GUIDO will be selected, elected, retained,
recalled, and succeeded;
* The roles of the GUIDO in the Python language evolution process;
* The term length of service;
* The relationship of the GUIDO with a Council of Pythonistas (CoP)
that advise the GUIDO on technical matters;
* The size, election, and roles of the CoP;
* The decision delegation process;
* Any changes to the PEP process to fit the new governance model;

This PEP does not name a new BDFL. Should this model be adopted, it
will be codified in PEP 13 along with the names of all officeholders
described in this PEP, as voted on per the guidelines in PEP 8001.


(2) PEP 8011: Python Governance Model Lead by Trio of Pythonistas

This PEP proposes a governance model for the Core Python development
community, led by a trio of equally authoritative leaders. The Trio of
Pythonistas (ToP, or simply Trio) is tasked with making final
decisions for the language. It differs from PEP 8010 by specifically
not proposing a central singular leader, but instead a group of three
people as the leaders.

This PEP also proposes a formation of specialized workgroups to assist
the leadership trio in making decisions.

This PEP does not name the members of the Trio. Should this model be
adopted, it will be codified in PEP 13 along with the names of all
officeholders described in this PEP.

This PEP describes:

* The role and responsibilities of the Trio
* Guidelines of how trio members should be formed
* Reasoning of the group of three, instead of a singular leader
* Role and responsibilities of Python core developers to the trio
* Sustainability considerations
* Diversity and inclusivity considerations


(3) PEP 8012: The Community Governance Model

This PEP proposes a new model of Python governance based on consensus
and voting by the Python community. This model relies on workgroups to
carry out the governance of the Python language. This governance model
works without the role of a centralized singular leader or a governing

It describes how, when, and why votes are conducted for decisions
affecting the Python language. It also describes the criteria for
voting eligibility.

Should this model be adopted, it will be codified in PEP 13.

This model can be affectionately called "The Least Worst Governance
Model" by its property that while far from ideal, it's still the most
robust one compared to the others. Since avoiding issues inherent to
the other models is a paramount feature of the Community Governance
Model, we start the discussion a bit unusually: by rejecting the other


(4) PEP 8013: The External Council Governance Model

This PEP proposes a new model of Python governance based on a Group of
Unbiased Independent Directors of Order (GUIDO) tasked with making
final decisions for the language. It differs from PEP 8010 by
specifically not proposing a central singular leader, and from PEP
8011 by disallowing core committers from being council members. It
describes the size and role of the council, how the initial group of
council members will be chosen, any term limits of the council
members, and how successors will be elected.

It also spends significant time discussing the intended behaviour of
this model. By design, many processes are not specified here but are
left to the people involved. In order to select people who will make
the best decisions, it is important for those involved to understand
the expectations of GUIDO but it is equally important to allow GUIDO
the freedom to adjust process requirements for varying circumstances.
This only works when process is unspecified, but all participants have
similar expectations.

This PEP does not name the members of GUIDO. Should this model be
adopted, it will be codified in PEP 13 along with the names of all
officeholders described in this PEP.


(5) PEP 8014 -- The Commons Governance Model

This PEP proposes a governnance model with as few procedures, defined
terms and percentages as possible. It may also be called The Anarchist
Governance Model but uses Commons for now because of possible negative
connotations of the term Anarchist to some audiences.

The basic idea is that all decisions are voted on by a subset of the
community. A subset, because although the whole community is in
principle entitled to vote in practice it will always be only a small
subset that vote on a specific decision. The vote is overseen by an
impartial council that judges whether the decision has passed or not.
The intention is that this council bases its decision not only on the
ratio of yes and no votes but also on the total number of votes, on
the gravity of the proposal being voted on and possibly the individual
voters and how they voted. Thereby this council becomes responsible
for ensuring that each individual decision is carried by a sufficient


(6) PEP 8015: Organization of the Python community

This PEP formalizes the current organization of the Python community
and proposes 3 main changes:

Formalize the existing concept of "Python teams";
Give more autonomy to Python teams;
Replace the BDFL (Guido van Rossum) with a new "Python Core Board" of
3 members which have limited roles. Their key role is mostly to decide
how a PEP is approved (or rejected or deferred).

Note: the "BDFL-delegate" role is renamed to "PEP delegate".



See also:

PEP 8000: Python Language Governance Proposal Overview

PEP 8002: Open Source Governance Survey


More information about the Python-Dev mailing list