Python's governance vote selects the steering council model

Python's core developers have selected a governing model without selecting the people who will hold its offices. The December 17 result names PEP 8016, the steering council model by Nathaniel J. Smith and Donald Stufft, as the winner. The distinction matters because this vote resolves the rules for future authority. Choosing the five council members is a separate operation under those rules.

The result reports 62 ballots from 94 authorized voters. PEP 8016 is a Condorcet winner, preferred to every other option in a head-to-head comparison of the ranked ballots. Against the next-ranked proposal, PEP 8012, it wins by 40 votes to 22. Those figures describe the election that occurred. They do not imply that all developers preferred the winning model or agreed with every provision it contains.

I depend on Python's ecosystem while retaining reservations about the language and its tooling. An identifiable decision process matters to that dependence. It gives maintainers a way to settle future language changes without assuming that the founder must personally resolve each difficult argument.

The election answers a question about rules

PEP 8001 defines this vote as the choice of a governance PEP to implement. It invites CPython core developers to vote, while asking inactive developers who intend to remain inactive to consider abstaining. That request is advisory and relies on their own judgement.

The ballot contains seven governance proposals and a further-discussion option. That final choice allows a voter to express the view that adopting a proposal is worse than continuing the debate. The published result prefers PEP 8016 over further discussion by 57 to 4. This comparison supports moving forward with the selected model, while the full ranking preserves information about preferences among the alternatives.

The procedure uses ranked ballots through the Condorcet Internet Voting Service. Voters rank all choices and may assign equal ranks. PEP 8001 explains that a winner must be a Condorcet winner, with another election needed if the outcome instead produces a tie or cycle. The result meets that criterion, so the transition does not depend on interpreting a fallback outcome as equivalent to a direct winner.

This mechanism differs from counting first preferences alone. The pairwise comparisons ask which option voters prefer when considering each pair. A proposal's position in the result therefore reflects relationships across the ranking, not merely the number of people placing it first. The published matrix makes those comparisons available for inspection.

The vote chooses a model with a council. It does not elect a council by ranking the proposal authors, nor does it appoint those authors to seats. Keeping those operations distinct prevents the institutional result from becoming an unsupported claim about who now holds decision-making authority.

PEP 8001 also separates review from voting. It sets aside November 16 through November 30 for review and prohibits modifying the candidate PEPs during the vote. That gives the ranked choices a stable meaning while ballots are being submitted. A developer who read an earlier draft still needs to examine the version on the ballot, since the review period permitted minor revisions. The procedure makes the selected document, rather than a recollection of its first announcement, the object of the decision.

Ballot privacy coexists with published evidence

The result includes anonymized ballots in randomized order. PEP 8001 describes a private, invitation-only poll with detailed ballot reporting that omits identifying information. The procedure therefore separates eligibility from the public record of preferences.

This choice addresses a practical concern in a small community. The voting-process PEP records objections to public named ballots and explains the aim of reducing social pressure on voters. It also acknowledges reliance on the voting service as a trusted party for anonymization. Privacy here has an implementation and a trust assumption, rather than being an unqualified property of any electronic vote.

Voters cannot revise a submitted ballot. The procedure consequently advises them to wait if uncertain, since a vote on the last day has the same validity as one on the first. This is a property of the chosen process, not a general requirement of ranked voting.

Publishing the ballots and result details allows readers to examine the tally without attaching a choice to a named contributor. That matters for the legitimacy of this particular transition. The project needs a result that can be checked while allowing developers to express preferences without publicly affiliating themselves with one governance camp.

The council can establish ordinary decision processes

PEP 8016 defines a five-person council with broad project authority. It can accept or reject PEPs, delegate authority and work with the Python Software Foundation on project assets. Its mandate also includes establishing appropriate PEP decision processes and seeking consensus before formal action.

The model expects the council to exercise direct power sparingly. Delegating decisions and establishing procedures can reduce the need to vote on every individual case. Broad authority makes it possible to establish those arrangements without requiring the governing document to enumerate every specialist process in advance.

That design leaves a real responsibility with the people elected. The existence of power to intervene does not determine when intervention is appropriate. Council members must apply the model's preference for consensus and ordinary processes to particular circumstances. The constitutional document supplies authority and limits, while the office holders still exercise judgement.

Formal action requires a council vote. Members must vote or explicitly abstain, with abstention required for a conflict of interest. A majority of non-abstaining members must support the decision. The model also calls for public deliberations and votes whenever possible. These provisions identify how the council turns its judgement into an authorized action.

My preference is for this separation between a process and the individuals currently applying it. A contributor should be able to determine what role can settle a proposal and what procedure that role must follow. Electing people remains important, but their authority now has a written basis that can be examined independently of their personal standing.

Membership and constitutional changes have their own rules

The council's general authority does not let it rewrite the governing document at will. Changes require at least a two-thirds majority of votes cast in a core-team vote. This reserves constitutional amendment to the electorate that gives the council its mandate.

Admission to the core team also combines a team vote with a council role. A candidate needs at least two-thirds positive votes and no council veto. The model recognizes contributions beyond implementation patches, including infrastructure, review and community work. That definition matters because the core team is both a group maintaining Python and the electorate participating in formal governance.

At most two council members may work for the same employer. The rule applies during elections and during a term if employment changes. Its stated concern includes the appearance of one company dominating development. It therefore constrains composition without requiring a finding that any individual has acted improperly.

Terms follow feature releases, with one council continuing until the next election result is final. Vacancies during a term can be filled under the model's replacement provisions. This gives the office an explicit continuity rule instead of leaving an unavailable member's seat undefined.

The council election itself uses votes for candidates, with core-team members able to select zero to five. That is different from the ranked comparison just used to select the governance model. The project has chosen rules for more than one kind of election, and those rules answer different questions.

Removal procedures limit exceptional authority

Core developers can call a no-confidence vote against an individual council member or the council as a whole. Another core developer must second the call, and the two-week vote succeeds if at least two-thirds of voters express no confidence. A successful whole-council vote triggers a new election.

Removing a core developer against their will requires a separate council threshold. With all five members voting, a three-to-two majority is insufficient and at least four must favour removal. The council cannot delegate this power or use it while a no-confidence vote is in progress.

Those provisions address the possibility that ordinary trust fails. They leave the core team a defined way to remove elected leadership and constrain the council's ability to change membership during a challenge to its own authority. The December result adopts a governing arrangement containing these limits. The next institutional step is to use its separate election procedure to choose the people who will serve on the council.