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.

Open Discussion Points

Some suggestions in this document are currently weak suggestions, and
are open to change during the discussion period. These include:

  • We can change the name of the group. “Council of Auditors” is the
    suggested alternative, though “Python Inquisition” is very tempting
    if we believe we can be clear about the source of the name [1]_

  • We can change voting procedures, timelines, and tie-breakage rules

The Importance of the Grey Area

In any actual decision-making process, there is going to be grey area.
This includes unexpected scenarios, and cases where there is no
“correct” answer.

Many process plans attempt to minimise grey area by defining processes
clearly enough that no flexibility is required.

This proposal deliberately goes the other way. The aim is to provide a
robust framework for choosing the best people to handle unexpected
situations, without defining how those people should handle those

Examples are provided of “good” responses to some situations as an
illustration. The hope is that the “best” people are the best because
they would live up to those examples. The process that is proposed has
been designed to minimise the damage that may be caused when those
people turn out not to be the best.

Grey area is guaranteed to exist. This proposal deliberately embraces
and works within that, rather than attempting to prevent it.

Model Overview

Key people and their functions

The Group of Unbiased Independent Directors of Order (GUIDO) is a
council of varying size, typically two to four people, who are elected
for the duration of a Python release. One member of GUIDO is
considered the President, who has some minor points of authority over
the other members.

GUIDO has responsibility for reviewing controversial decisions in the
form of PEPs written by members of the core development team. GUIDO
may choose to accept a PEP exactly as presented, or may request
clarification or changes. These changes may be of any form and for any
reason. This flexibility is intentional, and allows the process to
change over time as different members are elected to GUIDO. See the
later sections of this document for examples of the kinds of requests
that are expected.

GUIDO only pronounces on PEPs submitted to python-committers. There is
no expectation that GUIDO follows or participates on any other mailing
lists. (Note that this implies that only core developers may submit
PEPs. Non-core developers may write and discuss proposals on other
mailing lists, but without a core developer willing to support the
proposal by requesting pronouncement, it cannot proceed to acceptance.
This is essentially the same as the current system, but is made
explicit here to ensure that members of GUIDO are not expected to deal
with proposals that are not supported by at least one core developer.)

GUIDO may not delegate authority to individuals who have not been
elected by the core developer team. (One relevant case here is that
this changes the implementation of the existing BDFL-Delegate system,
though without necessarily changing the spirit of that system. See the
later sections, particularly example scenario four, for more
discussion on this point.)

The Release Manager (RM) is also permitted the same ability to request
changes on any PEPs that specify the release they are responsible for.
After feature freeze, the RM retains this responsibility for their
release, while GUIDO rotates and begins to focus on the subsequent
release. This is no different from the current process. The process
for selection of a RM is not changed in this proposal.

Core developers are responsible for electing members of GUIDO, and
have the ability to call a “vote of no confidence” against a member of
GUIDO. The details of these votes are discussed in a later section.

Where discussions between core developers and members of GUIDO appear
to be ongoing but unfruitful, the President may step in to overrule
either party. Where the discussion involves the President, it should
be handled using a vote of no confidence.

Members of GUIDO may choose to resign at any point. If at least two
members of GUIDO remain, they may request a new election to refill the
group. If only one member remains, the election is triggered
automatically. (The scenario when the President resigns is described
in a later section.)

The intended balance of power is that the core developers will elect
members of GUIDO who reflect the direction and have the trust of the
development team, and also have the ability to remove members who do
not honour commitments made prior to election.

Regular decision process

Regular decisions continue to be made as at present.

For the sake of clarity, controversial decisions require a PEP, and
any decisions requiring a PEP are considered as controversial.

GUIDO may be asked to advise on whether a decision would be better
made using the controversial decision process, or individual members
of GUIDO may volunteer such a suggestion, but the core development
team is not bound by this advice.

Controversial decision process

Controversial decisions are always written up as PEPs, following the
existing process. The approver (formerly “BDFL-Delegate”) is always
GUIDO, and can no longer be delegated. Note that this does not
prevent GUIDO from deciding to nominate a core developer to assess the
proposal and provide GUIDO with a recommendation, which is essentially
the same as the current delegation process.

GUIDO will pronounce on PEPs submitted to python-committers with a
request for pronouncement. Any member of GUIDO, or the current RM, may
request changes to a PEP for any reason, provided they include some
indication of what additional work is required to meet their
expectations. See later sections for examples of expected reasons.

When all members of GUIDO and the RM indicate that they have no
concerns with a PEP, it is formally accepted. When one or more members
of GUIDO fail to respond in a reasonable time, the President of GUIDO
may choose to interpret that as implied approval. Failure of the
President to respond should be handled using a vote of no confidence.

Election terms

Members of GUIDO are elected for the duration of a release. The
members are elected prior to feature freeze for the previous release,
and hold their position until feature freeze for their release.

Members may seek re-election as many times as they like. There are no
term limits. It is up to the core developers to prevent re-election of
GUIDO members where there is consensus that the individual should not
serve again.

Election voting process

The election process for each member of GUIDO proceeds as follows:

  • a nomination email is sent to python-committers
  • a seconding email is sent
  • the nominee is temporarily added to python-committers for the
    purpose of introducing themselves and presenting their position
  • voting opens two weeks prior to the scheduled feature freeze of the
    previous release
  • votes are contributed by modifying a document in a private github
  • each core developer may add +1 votes for as many candidates as they
  • after seven days, voting closes
  • the nominee with the most votes is elected as President of GUIDO
  • the next three nominees with the most votes and also at least 50%
    the number of votes received by the President are elected as the
    other members of GUIDO
  • where ties need to be resolved, the RM may apply one extra vote for
    their preferred candidates
  • accepted nominees remain on python-committers; others are removed

No-confidence voting process

A vote of no confidence proceeds as follows:

  • a vote of no confidence email is sent to python-committers, naming
    the affected member of GUIDO, justifying the nomination, and
    optionally listing accepted PEPs that the nominator believes should
    be reverted
  • a seconding email is sent within seven days
  • the nominated member of GUIDO is allowed seven days to respond,
    after which the nominator or the seconder may withdraw
  • if no nominator or seconder is available, no further action is
  • voting opens immediately
  • each core developer may add a +1 vote (remove the GUIDO member) or
    a -1 vote (keep the GUIDO member) by modifying a document in a
    private github repository
  • after seven days, voting closes
  • if +1 votes exceed -1 votes, the GUIDO member is removed from
    python-committers and any nominated PEPs are reverted
  • if requested by the remaining members of GUIDO, or if only one
    member of GUIDO remains, a new election to replace the removed
    member may be held following the usual process.
  • in the case of removing the President of GUIDO, the candidate
    who originally received the second-most votes becomes President

Examples of intended behaviour

This section describes some examples of the kind of interactions that
we hope to see between GUIDO and the core developers. None of these
are binding descriptions, but are intended to achieve some consensus
on the types of processes we expect. GUIDO candidates may campaign
on the basis of whatever process they prefer, and core developers
should allocate votes on this basis.

Scenario 1 - The Case of the Vague PEP

Often in the past, initial proposals have lacked sufficient detail to
be implementable by anyone other than the proposer. To avoid this,
GUIDO should read proposals “fresh” when submitted, and without
inferring or using any implied context. Then, when an aspect of a PEP
is not clear, GUIDO can reject the proposal and request

Since the proposal is rejected, it must be modified and resubmitted in
order to be reviewed again. GUIDO will determine how much guidance to
provide when rejecting the PEP, as that will affect how many times it
will likely be resubmitted (and hence affect GUIDO’s own workload).
This ensures that the final PEP text stands alone with all required

Scenario 2 - The Case of the Endless Discussion

From time to time, a discussion between Python contributors may seem
to be no longer providing value. For example, when a large number of
emails are repeating points that have already been dealt with, or are
actively hostile towards others, there is no point continuing the

When such a discussion is occurring on python-committers as part of a
request for pronouncement, a member of GUIDO should simply declare the
thread over by rejecting the proposal. In most known cases, discussion
of this sort indicates that not all concerns have been sufficiently
addressed in the proposal and the author may need to enhance some

Alternatively, and in the absence of any rejection from the other
members of GUIDO, the President may declare the thread over by
accepting the proposal. Ideally this would occur after directly
confirming with the rest of GUIDO and the RM that there are no
concerns among them.

When such a discussion is occurring on another list, members of GUIDO
should be viewed as respected voices similar to other core developers
(particularly those core developers who are the named experts for the
subject area). While none have specific authority to end a thread,
preemptively stating an intent to block a proposal is a useful way to
defuse potentially useless discussions. Members of GUIDO who
voluntarily follow discussions other than on python-committers are
allowed to suggest the proposer withdraw, but can only actually
approve or reject a proposal that is formally submitted for

Scenario 3 - The Case of the Unconsidered Users

Some proposals in the past may be written up and submitted for
pronouncement without considering the impact on particular groups of
users. For example, a proposal that affects the dependencies required
to use Python on various machines may have an adverse impact on some
users, even if many are unaffected due to the dependencies being
typically available by default.

Where a proposal does not appear to consider all users, GUIDO might
choose to use their judgement and past experience to determine that
more users are affected by the change than described in the PEP, and
request that the PEP also address these users. They should identify
the group of users clearly enough that the proposer is able to also
identify these users, and either clarify how they were addressed, or
made amendments to the PEP to explicitly address them. (Note that this
does not involve evaluating the usefulness of the feature to various
user groups, but simply whether the PEP indicates that the usefulness
of the feature has been evaluated.)

Where a proposal appears to have used flawed logic or incorrect data
to come to a certain conclusion, GUIDO might choose to use other
sources of information (such as the prior discussion or a submission
from other core developers) to request reconsideration of certain
points. The proposer does not necessarily need to use the exact
information obtained by GUIDO to update their proposal, provided that
whatever amendments they make are satisfactory to GUIDO. For example,
a PEP may indicate that 30% of users would be affected, while GUIDO
may argue that 70% of users are affected. A successful amendment may
include a different but more reliable percentage, or may be rewritten
to no longer depend on the number of affected users.

Scenario 4 - The Case of the Delegated Decision

Some proposals may require review and approval from a specialist in
the area. Historically, these would have been handled by appointing a
BDFL-Delegate to make the final decision on the proposal. However, in
this model, GUIDO may not delegate the final decision making process.
When GUIDO believes that a subject matter expert should decide on a
particular proposal, GUIDO may nominate one or more individuals (or
accept their self-nomination) to a similar position to a BDFL
Delegate. The terms of these expert’s role may be set as GUIDO sees
fit, though GUIDO always retains the final approval.

As a concrete example, assume a proposal is being discussed about a
new language feature. Proponents claim that it will make the language
easier for new developers to learn. Even before an official proposal
is made, GUIDO may indicate that they will not accept the proposal
unless person X approves, since person X has a long history teaching
Python and their judgement is trusted. (Note that person X need not be
a core developer.)

Having been given this role, person X is able to drive the discussion
and quickly focus it on viable alternatives. Eventually, person X
chooses the alternative they are most satisfied with and indicates to
GUIDO that they approve. The proposal is submitted as usual, and GUIDO
reviews and accepts it, factoring in person X’s opinion.


… [1] The Spanish Inquisition, <>_


This document has been placed in the public domain.

I haven’t made any modifications from what was published a week or so ago, but there is quite a bit to like about PEP 8014 that I’d happily copy into here. The main distinction as I see it is that the council in this one cannot include core developers, while 8014 allows that and trusts council members to be impartial (which I agree will work out fine probably all of the time).

This proposal also allows the council to apply other decision making tools, which may include requesting and determining the validity of a core developer vote, but is not in any way restricted to just that.

Since I can do a poll, I’m going to do it, because as fun as the acronym “GUIDO” is, I also find it a bit immature and will happily change. Feel free to post other ideas.

  • Group of Unbiased Independent Directors of Order (GUIDO)
  • Council of Auditors (CoA)
  • Council of Elders (CoE)
  • Python Inquisition
  • The Council

0 voters

1 Like

The essential problem I’m having with this proposal is that we claim to nominate core developers people who we think apt to make reasonable decisions for the language - both minor and major decisions. But here we have an external body who are tasked with the most controversial decisions, all the while not being core developers. So we’re saying that there are people outside of the core team who are more apt than us. Clearly there’s a problem: is the core developer selection process that bad? Do we keep competent, experienced contributors out the core team on purpose, so that they might become part of the external council?

There is another, social problem: if people who didn’t get through the core developer selection may end up having “more” power over the language than people who got through it, what kind of gratification do you get in exchange for the effort of maintaining Python? Especially if you’re not a paid contributor…

I think it says that we select core developers for skills and contributions that do not necessarily imply that they are the best people to take on this role, and unlike 8014 I have chosen to avoid the risk of bias by explicitly separating those who can propose significant changes from those who decide whether they are justified.

Perhaps some people will choose to renounce their role as a core developer if elected to the council, and I think that’s fine. In my view, trying to keep a foot in every camp means that the person is not taking all of them seriously enough.

1 Like

There is indeed quite a bit of overlap between 8013 and 8014. But the 8013 GUIDO seems to be a bit more like an election commission (with the care taken to ensure its independence from the core developers).

The 8014 Council of Elders, in contrast, is expected to consist of “benevolent core developers”, most likely, who have enough knowledge of the language and the community and such to judge the weight of proposals and are benevolent enough to set aside their own preferences (while wearing the scarlet regalia).

I think I share @pitrou’s misgivings that the either/or means we’re set to lose valuable core developers or get less valuable GUIDO members.

Sorry to not elaborate, but in short, I concur with Antoine. As a core developer, I dislike getting a manager who is not a core developer…

That’s fair, though not a universally held position (the best managers are rarely the best developers). We’ll see how the voting turns out :slight_smile:

Perhaps, though there are plenty of non-core developers who many of us would trust with vision but not a merge button (or who have never requested the merge button). When discussing this at the sprints we very easily made a list of about 10 potentials, all of whom you likely know (of), none of whom have been a core committer for CPython, but certainly know the language, ecosystem and community well enough to make well-informed decisions.

“Has reviewed pull requests” seems a bit of a restrictive qualification to require when it could be “has served on the PSF board” or “has taught X thousand students” or “has keynoted X Python conferences”.

I don’t understand how teaching Python, keynoting conferences, or even serving on the PSF board, makes someone competent to make language and/or standard library decisions. Those are entirely different things.

To put it in perspective: do you think that I, as a core committer, am competent to decide on the PSF’s budget and communication activities? Why would it work in the other direction?

Can you give such names? Also, do you know they would agree to serve actively on an external board? We tried to nominate people core developers in the past based simply on their involvement in the ecosystem (Twisted developers, PyPy developers), and none of them became an active CPython developer.

Of course not :slight_smile: So why assume that only core developers are uniquely qualified to decide whether proposals are well written and supported? That’s filtering people by two different sets of criteria in series, rather than filtering different people for different positions.

No, because we didn’t speak to them and I don’t want to apply public pressure. The point was, though the immediate reactions were “nobody else besides a core developer could possibly do a good job”, it turned out to be very easy to think of people who would.

Think of any past/present conference chair you like and ask whether they might be willing to invest in Python in this way, while not wanting to review PRs all the time.

Right, because they had a job already and didn’t need another one :slight_smile:

Turns out being a CPython core developer isn’t always a lot of fun, so I’d understand people preferring to focus on a project that is moving more quickly (though I’d say Twisted is fast approaching CPython speeds…)

Because those proposals are about specific topics that core developers know best. If you look at, there doesn’t seem to be many PEPs general enough that a council of non-core developers would be best suited to judge them.

Of course non-core developers can give insight in a PEP’s topic. For example the asyncio PEP was informed by the feedback from Twisted and Tornado developers. But in the end we (core developers) made the decision on the APIs we wanted to integrate.

Hmm, I seriously disagree with you on this issue. To me “Python core developer” means that a person has a set of skills in a technical area (implementation) and possibly/probably in a language design area. But PEPs can be more far reaching, and can have consequences on usability, elegance, future direction and other areas. And for such consequences teachers/presenters/etc may be much better placed to judge them.

The point isn’t for the council to judge the PEP itself, but to judge the response to the PEP and make sure it contains everything required to justify it. Much like the other proposals, the experts in that area ought to be taken into account, assuming the PEP somehow makes it to the council without that expert weighing in (which already shouldn’t happen, but the council would probably then reject it on the basis that a relevant expert has concerns).

The biggest difference is that I’m not trying to build that into this part of the proposal, but I’d expect it to be part of the council election process, which allows us to choose people who may offer to behave differently.

If you don’t like it, don’t vote for the proposal. You seem to have run out of constructive feedback.

Just to clarify for myself and possibly @pitrou, my understanding is the Council functions essentially like an ombudsperson to make sure that a PEP was handled as specified in the rules / process. Correct?

Yes, except that the “rules/process” are deliberately not defined here. I expect people nominating for the council to provide some explanation of what they consider to be “correctly handled”, and we get to hold them to that, but I don’t want to constrain the council by specifying details or approaches up front.

1 Like

Just sharing that I’ve updated the PEP to use “Council of Auditors” in the text (basically just a find/replace to “the CoA”). No intentional changes to meaning.

1 Like

As I’m reading through PEP 8013, I’m struck by a similar experience to most of the other people who have commented thus far, that it feels supremely weird to me that core developers are left out of being able to participate as members of this Council of Auditors, but we trust them to otherwise maintain the language.

On the other hand, I do agree that just because someone isn’t a core developer, doesn’t mean they might not be able to serve well in this role. So perhaps an enhancement to this PEP would to instead of limiting this council to only be people who are not core developers, instead say that anyone is eligible to be a member of the CoA, core developer or not.

In other words, I understand what we gain by allowing non-core to participate as members of the CoA, but I don’t understand what we gain by disallowing core developers. At the very least, this PEP should probably go into more detail about why we’re preventing core developers from participating on the CoA.

Another concern I have here is the requirement that only core developers can submit PEPs. This is stated as “essentially the same as the current system”, but that’s not true at all. The current system allows anyone to submit a PEP, however if they are not a core developer then they have to go through the PEP editors to publish their PEP (although the requirement for a PEP editor is likely lessened with GitHub now). A key thing is that a PEP editor is not there to agree or disagree with the PEP, but is largely just a quality control role to make sure that PEPs are all well formed proposals that meet some minimum bar of “real”-ness.

So this proposal actively restricts who can propose a PEP, which runs counter to the claim in the PEP. The PEP should be honest about this or it should remove the new restriction.

I’m curious what the status of the Packaging PEPs are in this proposal? Currently we basically have two long standing BDFL-Delegates for any/all packaging PEPs. This is notably different than how BDFL-Delegates were used for other PEPs, where the Delegate was chosen to effectively decide on a single PEP. As I read this, this suggests that since we’re currently using the PEP system for packaging PEPs, that this is effectively revoking the standing delegation to myself and @pf_moore for those PEPs, and bringing them under the authority of the CoA instead? I should note that I expected some level of change to this sort of quasi-agreement between the packaging “interest area” and the rest of python-dev, and I have been pushing semi-recently to pull the packaging decision making process out of the PEP process and into our own process, so it’s not the end of the world in my opinion if that is the case, it would just mean that it’s all the more important IMO for the packaging decision making process to get divorced from the PEP process.

I’d note that the voting process outlined in this PEP is “Approval Voting” with some extra stipulations, although I notice that there exists a pathological case (although unlikely) that exists where the president gets far and away more votes than any other person, and thus no other person meets the 50% threshold. It is likely a good idea to explicitly define what happens in this case (my suggestion would be to set a minimum number of people who must be on the council, and allow ignoring the 50% threshold if needed to meet that threshold, although that still has the problem of what happens if fewer than the minimum threshold put themselves forward to serve… which may be an issue given we’re currently limiting this to exclude core developers, and core developers are likely the people with the most invested in helping make these kinds of choices).

I see that this proposal also includes voting via a Github repository. Similarly to PEP 8012 I’d question why we can’t just use one of the many voting systems that exist, such as Helios which the PSF already uses, discord polls, or any other online voting system. If the PEP is going to continue using GitHub, the rationale for using GitHub should probably at least be explained in the PEP.

The PEP isn’t clear about who can motion or second a motion for a vote of no confidence, is it any Python core developer? What about other members of the CoA who aren’t core developers?

Another big concern I have with this proposal is moving large parts of the PEP process to python-commiters rather than python-dev, which I cannot imagine will do anything except make some class of people feel excluded because things are being discussed/decided in a space that they cannot participate in. I suspect it will lead to “unofficial” threads popping up in random places as people try to find an outlet to discuss their opinions on said PEP when they are shut out of the discussion location that is being used.

Quoting multiple times on a phone is hard, sorry, so randomly replying to your points.

With all the voting discussion going on, I’m going to just remove the specification and replace it with “$vote” to be determined if this option is selected. I’m not wedded to the approach, provided the outcome is a variable number of winners with “pretty good” approval. For now, nobody should get hung up on the method.

Requiring non-core developers is my form of enforcing diversity, but also devaluing the trophy value of “core developer”. We ought to be far more like employees and less like superstars, and people who want to become Python-famous through the Council don’t have to pretend to be willing to maintain an old and somewhat crufty piece of software. My proposal isn’t the one triggering recent new interest in becoming a core dev :wink:

Similarly, by excluding core developers from the council, I’m preventing people running on their technical or personal histories, as well as trivially avoiding the case where a council member may be responsible for designing and implementing anything.

The python-committers requirement is only for pronouncement, not discussion. If a PEP doesn’t have at least one person who can post to python-committers in favour of it, then it’s certainly not ready for pronouncement. It also makes it clear how the council members are participating - as individuals on python-dev? Or the council on python-committers.

FWIW, I’m 100% in favour of discussions happening elsewhere, provided people don’t come back from those with a sense that nobody is allowed to argue with them any more. A good council should reject a PEP if they think big parts of our group weren’t given an opportunity to review/comment on it before pronouncement.

I would like to have distutils-sig PEPs go through the same process, because I believe they are important enough to the Python ecosystem to be treated as such. That said, a council could easily choose to win your vote by offering to auto-approve all distutils-sig PEPs that Paul approves, which I believe is status quo (plus sharing it on python-committers, because again, these PEPs are important).

(Hope that got everything. I have six lines in my text box, no scroll bar, and can’t easily get back to your post to check :slight_smile: I’ll see about updating the content at some point, but I think it’s mostly within reasonable interpretation as far as the mechanics are concerned.)