Voting opens for Python's first Steering Council

Python's new governance model gives five people broad authority while asking them to avoid exercising it unnecessarily. That tension is deliberate. The council can settle decisions, but the preferred outcome is a process through which contributors can settle them without repeated intervention. Today's election begins choosing the people who will put that arrangement into practice.

The election specification in PEP 8100 opens voting on January 21, 2019 at 12:00 UTC. Voting closes on February 4 at 12:00 UTC, following the nomination period of January 7 through January 20. Active core team members elect the first council. This is a decision about who has responsibility for the project, with consequences for people who depend on Python but have no ballot.

I tend to judge Python through the usefulness of its libraries and the complexity of maintaining the surrounding environment. Governance matters to that assessment because a useful ecosystem still needs a way to resolve disagreements about the language it depends on. A process with identifiable authority makes it possible to distinguish an unresolved discussion from a decision that contributors can implement.

A council with discretion to delegate

Nathaniel J. Smith and Donald Stufft's PEP 8016 supplies the rationale behind the arrangement. The proposal deliberately draws on established governance practices, including Django's governance document. Core developers accepted it on December 17, 2018. Its authors wanted a small set of foundational rules that could support further decisions without requiring the community to settle every procedural question at once.

The proposal defines a five-person steering council and a core team that elects it. The council's responsibilities include maintaining the quality and stability of Python and CPython, establishing processes for deciding PEPs, and sustaining participation. Its authority includes accepting or rejecting proposals and delegating responsibilities to other groups or processes. Those powers give it enough scope to resolve uncertainty about where a decision belongs.

Delegation is central to the design. A council that personally adjudicates every proposal would concentrate work as well as authority. PEP 8016 instead recommends establishing procedures for proposal decisions and delegating appropriate responsibilities. Contributors can then work within an understood process, while the council remains available when other methods fail. The distinction affects how much coordination every technical change requires.

This is also why broad powers do not imply that every discussion becomes a council vote. The proposal asks the council to seek consensus and use formal authority sparingly. That leaves room for technical work to proceed among the people doing it. The council supplies a final decision mechanism when agreement cannot be reached through those ordinary interactions.

What the ballot actually selects

PEP 8100 specifies Helios as the voting service. Eligible voters receive ballots by email, candidate order is randomized, and the election uses voter aliases. Participation is restricted to the voter roll. The published configuration allows each voter to select between zero and five candidates, with the candidates ranked by their totals under the original council model.

That mechanism selects a group from the candidate list. It does not ask voters to assign a separate office to each successful candidate. The number of selections also does not require a voter to fill every available choice. A ballot can express support for fewer than five people, which is relevant when interpreting what the voting configuration permits.

The returns officer manages the election. Normally, an outgoing council appoints that officer. The first election needs a different starting procedure because no outgoing council exists. Under the founding rules, the Python Software Foundation's executive director makes the appointment. PEP 8100 records Ewa Jodlowska's appointment of Ee Durbin. This closes a procedural dependency that would otherwise prevent the first council from being constituted.

Candidates need nomination by a core team member, and core team members can nominate themselves. The electorate is therefore narrower than the population of Python users, while candidacy is defined through nomination. For an application developer, the relevant fact is that this is contributor governance. Adoption of Python does not itself create a vote in the election.

Authority has explicit limits

The founding model constrains employer representation. At most two council members can work for a single employer. If the five highest-ranked candidates would violate that limit, the lowest-ranked candidate from the overrepresented employer is displaced and the next candidate moves up. The process repeats until the council satisfies the rule.

This rule addresses the appearance of concentrated corporate influence as well as an actual conflict. It means that counting the five largest totals is only part of determining the valid council. Eligibility of the resulting group matters too. The model also requires a remedy if an employment change creates an invalid composition during a term.

Individual decisions have a separate conflict rule. Council members must vote or explicitly abstain, and a member with a conflict of interest must abstain. Decisions require a majority among the non-abstaining members. The proposal calls for public deliberations and votes whenever possible, which gives contributors a stated expectation about how authority should be exercised.

The council cannot simply rewrite its own governing document. Changes require a core team vote with at least a two-thirds majority of votes cast. Removing a core team member also has a special threshold and restrictions. These provisions make the governing rules distinct from ordinary council decisions. Authority over proposals does not include unrestricted authority over the electorate that chooses the council.

Accountability between elections

A council term runs until the next council's term starts, with a new election following each feature release. Members can serve additional terms. The proposal also provides for vacancies, including appointment of a replacement by the remaining council and replacement of a member who cannot be contacted for a month or longer.

Core team members retain a no-confidence procedure. A public call, seconded by another core team member, triggers a two-week vote. A two-thirds majority of voters can remove an individual council member or the whole council, depending on the motion. Removing the entire council triggers a new election. Accountability therefore includes a remedy between regular elections.

I prefer this explicit treatment of exceptional cases. A governance document becomes useful when disagreement is difficult enough that informal expectations stop being reliable. Specifying who can act, who can object, and how authority can be withdrawn gives contributors a procedure without requiring agreement about personalities.

For Python users, the immediate event is the opening of a vote, with its result still ahead. Its practical significance is that the project is beginning to assign responsibility under rules that separate routine technical work from final arbitration. The founding proposal leaves the council room to establish more detailed processes, while reserving constitutional changes and electoral accountability to the core team.