Challenge: There is no other Guido

There is no other single person with the unique skillset of Guido van Rossum. Such a person would need to have the technical, communication, and organizational experience to lead the project successfully. Specifically, the person would need to:

• set and articulate a cohesive long-term vision for the project;
• possess deep technical understanding of the runtime, the standard library, and the wider third-party library context;
• negotiate and resolve contentious issues in ways acceptable to all parties involved;
• have free time and possess the energy to sustain continuous involvement over periods of years.

Risk: Malevolent Dictator For Life

What if we got somebody who is not as well suited for the position as our first Dictator? There are possible scenarios in which this could lead to severe consequences.

The Dictator could gather insufficient trust due to missing technical depth, a “close” election, inconsistent vision, poor ability to deal with conflict or burnout, and so on. Given a controversial decision decided by the Dictator in a specific way, a Dictator with insufficient trust may cause a split within the project.

The Dictator setup invites lobbying concentrated on a single person. Unless that person is immune to leverage due to wealth, health, and a stable life situation, this poses risk of malicious actors steering the project from behind the curtain.

Finally, the Dictator coming from a particular part of the community may put more weight on the needs and interests of that particular part of the user base, alienating others.

Observation: We don’t actually need a Dictator

The irony of the Dictator model is that it requires an election. Better yet, we need an election to even decide on which governance model to use.

If we are already able solve two problems of this gravity via the community process, why not keep using it for all subsequent decisions?

Risk: The warm and fuzzy feeling of a vague proposal

One last thing worth mentioning is that when a BDFL model is suggested, it’s easy to bypass the criticism above by not mentioning who the BDFL should be. That way the hopeful reader can project their best expectations and wants onto the abstract BDFL, making the idea appear more attractive. This is a mistake.

Without naming the BDFL in the model proposal we are not talking about a concrete model. We can avoid asking and answering the hard questions. We can imagine our best-case scenario, a candidate we’d like to serve the role.

Omitting a name for the BDFL also puts the Community Model at an unfair disadvantage. We already know the good, the bad, and the ugly of our core developer group. It’s no platonic ideal, no perfect sphere with no friction. In fact, we expect there to be a fair amount of friction and imperfections.

Thus, to fairly assess the BDFL model proposal, dear reader, you should imagine the worst possible person within our team as that BDFL. A concrete human being. Imagine it’s me.

Conclusion While this has been our history, without Guido, this model does not serve the best interests of the language into the future.

Risk: Dilution and confusion

This model favors a small group, between three and five people. That way it shares most of the criticism with the Dictator model, amplified. Having not one but, say, three people in position of power dilutes responsibility while still providing high risk of lobbying, insufficient trust, or alienating parts of the community.

Risk: Internal Conflict

Additionally, having multiple people share the responsibility of governance creates ample opportunity for internal conflict, inconsistent long-term vision of the project, and multiplies the required continuous time involvement by its members (it’s no Quorum if they can’t “reach quorum” due to other time commitments).

Just like with a frictionless spherical BDFL, reject ideas of Councils without considering how would it work for you if that Council consisted of three people you find inadequate for the role. Imagine if I had two friends.

Most importantly, just like with a Dictator, we don’t need a Council. By the time we had one, we would have already had two successful elections. Why not keep voting?

Conclusion This model has similar risks like a Dictator, only worse.

The core team

The Python project is developed by a team of core developers. While membership is determined by presence in the “Python core” team in the “python” organization on GitHub, contribution takes many forms:

• committing changes to the repository;
• reviewing pull requests by others;
• triaging bug reports on the issue tracker;
• discussing topics on official Python communication channels.

Some contributors are may be considered dormant, in other words they did not contribute to the last two releases of CPython. Any dormant contributor can at any time resume contribution.

Experts

The Python Developer’s Guide lists a number of interest areas along with names of core developers who are recognized as experts in the given area. An expert or a sub-team of experts has the following responsibilities:

• responding to issues on the bug tracker triaged to the given interest area on a timely basis;
• reviewing pull requests identified as belonging to the given interest area on a timely basis;
• overviewing cohesive design in the evolution of the given interest area.

A core developer can assign and unassign themselves at will to a given interest area. Existing experts listed for the given interest area must be made aware of this change and have to unanimously agree to it.

If a given interest area lists multiple experts, they form a sub-team within the core team. They are responsible for the given interest area together.

A core developer should avoid membership as an expert in too many interest areas at the same time. This document deliberately doesn’t specify a maximum number, it simply signals that overexertion leads to burnout and is a risk to the project’s ability to function without a given contributor.

Moderators

There is a group of people, some of which are not core developers, responsible for ensuring that discussions on official communication channels adhere to the Code of Conduct. They take action in view of violations.

PEP, Enhanced

The PEP process is augmented with the following changes and clarifications over information already present in PEP 1:

• PEPs are not merged until the final decision is made on them; they are open pull requests on GitHub until that moment;
  • to make review easier, all changes to the PEP under review should be made as separate commits, allowing for granular comparison;
• a submitted PEP needs to identify the area of interest and relevant experts as the body that makes the final decision on it;
• if the PEP author is one of the experts of the relevant area of interest, they must name another person from outside of that interest area to contribute to the final decision in their place;
• the PEP author is responsible for gathering and integrating feedback on the PEP using the official communication channels, with the goal of building consensus;
• all community members must be enabled to give feedback;
• at some point, one of the named experts posts a “summary comment” that lays out the current state of discussion, especially major points of disagreement and tradeoffs; at the same time the expert proposes a “motion for final comment period” (FCP), along with a proposed disposition to either:
  • accept;
  • accept provisionally;
  • reject; or
  • defer the PEP.
• to enter the FCP, the PEP must be signed off by all experts of the relevant area of interest;
• the FCP lasts for fourteen calendar days to allow stakeholders to file any final objections before a decision is reached.

Very controversial PEPs

If a core contributor feels strongly against a particular PEP, during its FCP they may raise a motion to reject it by vote. Voting details are described below in “Voting Mechanics”.

This should be a last resort and thus a rare occurrence. It splits the core team and is a stressful event for all involved. However, the experts filing for a FCP for a PEP should have a good sense whether a motion to reject it by vote is likely. In such a case, care should be taken to avoid prematurely filing for a FCP.

There is no recourse for the opposite situation, i.e. when the experts want to reject a PEP but others would like it accepted. This ensures that the relevant experts have the last say on what goes in. If you really want that change, find a way to convince them.

Moderators on official communication channels enforce the Code of Conduct first and foremost, to ensure healthy interaction between all interested parties. Enforcement can result in a given participant being excluded from further discussion and thus the decision process.

Revisiting deferred and rejected PEPs

If a PEP is deferred or rejected, the relevant experts should be contacted first before another attempt at the same idea is made. If the experts agree there is substantial evidence to justify revisiting the idea, a pull request editing the deferred or rejected PEP can be opened.

Failure to get proper expert buy-in beforehand will likely result in immediate rejection of a pull request on a deferred or rejected PEP.

Nominating a new core developer

A champion nominates a person to become a new core developer by posting on official communication channels. A vote is opened.

If any existing core developer does not feel comfortable with the nominee receiving the commit bit, they should preferably address this concern in the nomination thread. If there is no satisfactory resolution, they can cast a negative vote.

In practice, nominating a person for a core developer should often meet with surprise by others that this person is not a core developer yet. In other words, it should be done when the candidate is already known and trusted well enough by others. We should avoid nominations based on potential.

Votes of no confidence

• Removing a core developer from the core team;
• Disbanding the experts team for a given area of interest.

Those describe a situation where a core developer is forcefully removed from the core team or an experts team is forcefully disbanded. Hopefully those will never have to be exercised but they are explicitly mentioned to demonstrate how a dysfunctional area of interest can be healed.

If a core developer is removed by vote from the core team, they lose the ability to interact with the project. It’s up to the Moderators’ discretion to remove their ability to post on the bug tracker and GitHub or just moderate their future behavior on a case-by-case basis.

If the experts team for an area of interest is disbanded, other core developers can step up to fill the void at will. Members of the disbanded experts team cannot self-nominate to return.