PEP 8016 proposes a council with authority to establish Python's processes

Python needs a way to decide language proposals after Guido van Rossum's withdrawal from the BDFL role. One possible answer is to elect a group with enough authority to establish decision procedures, while expecting it to avoid ruling personally on every issue. That is the central choice in PEP 8016, the steering council proposal by Nathaniel J. Smith and Donald Stufft.

Smith has posted the full draft on November 6. That dated text gives a concrete version to examine while discussion continues. It proposes an elected council of five core developers and leaves several details open, including the initial election's returns officer. The proposal remains a proposal, so its mechanisms describe a possible governing arrangement rather than offices already occupied.

I depend on Python's ecosystem while remaining reluctant about parts of the language and its tooling. For that reason, the governance question matters independently of whether I favour a particular language change. The libraries around Python need a project capable of making decisions without requiring one person to carry every contested argument.

Broad authority supports delegated procedures

The draft gives the council authority to accept or reject PEPs, enforce the code of conduct and work with the Python Software Foundation on project assets. It can also delegate authority to other committees or processes. Those powers let it establish rules for routine decisions instead of becoming the compulsory destination for every question.

The rationale explicitly favours established governance practices and borrows detail from Django's governance. Its scope concentrates on the council, the core team and the procedure for changing the governing document. Other processes can then be established through that authority. The authors are trying to make a small governing arrangement sufficient to permit further decisions without specifying every future procedure in advance.

This creates a distinction between having power and exercising it directly. A council able to reject a PEP can instead establish a process through which proposals normally reach decisions. Delegation does not require the governing document to predict the right specialist arrangement for every category of change.

The tradeoff is that the authority remains broad. Expectations of restraint are meaningful guidance, but they do not mechanically prevent intervention. The draft therefore also needs rules describing how the council acts and how the core team can respond when confidence in it fails.

Formal council decisions require a vote. Each member must vote or explicitly abstain, and a member with a conflict of interest must abstain. A strict majority of non-abstaining members is required. Deliberations and votes should be public whenever possible. These provisions make a decision identifiable as an action by the council instead of an informal opinion from one member.

The electorate retains control over the rules

The council cannot amend the governing PEP simply by exercising its general authority. Changes require a core-team vote with at least a two-thirds majority of votes cast. That limitation prevents the council's broad operational powers from automatically extending to rewriting the rules that define those powers.

Core-team membership also has an explicit admission procedure. The draft requires at least two-thirds positive votes in a core-team vote and no council veto. Membership is therefore neither solely a council appointment nor solely an unrestricted outcome of the team's vote. Both parts participate in the admission decision.

The draft describes contributions broadly. Code review and patches count, but so do work on infrastructure, support and other activities contributing to the project's goals. This matters because the electorate maintains more than the interpreter implementation. Its composition should account for sustained project work that does not necessarily appear as a stream of source-code commits.

It also introduces an emeritus category for people no longer contributing. The posted draft discusses moving people after two years without a non-trivial contribution if they do not respond to a request. That status removes privileges such as voting and commit access. These are substantive membership rules, so their interpretation deserves attention alongside the more visible council election.

My preference is for rules that identify who can change the electorate and who can change the constitution. The proposed separation makes those questions explicit. It gives contributors something concrete to assess instead of relying on expectations attached to the individuals who happen to be available.

Elections establish terms and employer limits

The posted draft restricts council candidates to core-team members. Its election has a candidacy phase followed by an anonymous vote in which each core-team member can select zero to five candidates. Candidates rank by votes received. This version breaks ties by the date a candidate joined the core team.

A new council follows each feature release, with the existing term continuing until the next election result is finalized. There are no term limits. Vacancies can be filled by council appointment for the remainder of the term. Those rules distinguish the normal renewal of authority from replacing someone between elections.

At most two council members may share an employer. The draft explains this in terms of avoiding the appearance of one company dominating development. The rule can disqualify a lower-ranked candidate when the election would otherwise produce three members from the same employer. It also requires correction if employment changes break the limit during a term.

This is a constraint on council composition, not a claim that an employer directs every decision of its employees. It gives the project a rule that applies even when participants act in good faith. Its effect is observable in eligibility for the five seats.

Exceptional removal has separate thresholds

The core team can initiate a no-confidence vote against one council member or the entire council. A public call and a second core developer's support trigger a two-week vote. At least two-thirds of voters must express no confidence for removal to succeed.

The council's power to eject a core developer has its own higher threshold, and it cannot be delegated or used during a no-confidence vote. With all five members voting, a three-to-two majority is insufficient. These provisions place explicit limits around exceptional actions affecting membership, while leaving ordinary delegated decisions to the processes the council would establish.