February 4, 2019·6 min read·engineeringpythongovernancecommunity

Python elects its first Steering Council

The first council election assigns Python's new governing authority to five members. The founding rules explain how that authority is shared, delegated and constrained.

Python's first Steering Council now has members. The important change is that authority defined in a governance proposal has become the responsibility of an identifiable group. Contributors have a council to approach when a decision needs final resolution, and that council has a written mandate to establish processes that let ordinary work proceed without its constant intervention.

Ee Durbin's February 4 election announcement names Barry Warsaw, Brett Cannon, Carol Willing, Guido van Rossum and Nick Coghlan as the five successful candidates. Voting closed at 12:00 UTC. Of 96 eligible voters, 69 cast ballots. The announcement reports no conflict under the governance rules that would alter the resulting council.

The election specification, PEP 8100, defines this as the first council election under Python's new system. Nominations ran for two weeks, followed by two weeks of voting. Today's result completes that initial selection process. It does not settle every procedure the council will need, because the founding model deliberately leaves many of those decisions to the people now taking office.

I care about this as someone who finds Python's ecosystem useful while remaining impatient with the complexity around it. A language can have excellent libraries and still make decisions difficult for the people maintaining them. Clear responsibility helps distinguish a technical disagreement that needs more work from one that has reached the point of requiring a binding decision.

Election and governing model answer different questions

The election implements the model set out by Nathaniel J. Smith and Donald Stufft in PEP 8016. That proposal was accepted by a core developer vote on December 17, 2018. Its rationale favors established governance practices and draws details from Django's governance document. The aim is a small, workable set of rules that can support further procedural decisions.

The distinction between choosing a model and choosing its members matters. The December decision established a council, an electorate and limits on council authority. This election selects the people who will exercise the powers already defined there. Support for a candidate is therefore not a separate vote on the whole constitution, and the new council cannot treat its election as permission to rewrite that constitution by itself.

Under the founding election rules, each active core team member could select zero to five candidates. Candidates were ranked by votes, subject to the employer limit. The ballot did not elect a president or assign different powers to individual seats. Authority belongs to the committee under its voting rules, which makes collective decision-making part of the arrangement.

PEP 8100 specifies Helios as the voting service. It restricts participation to the voter roll, uses voter aliases and randomizes candidate order. Durbin's announcement says eligible voters received result notifications and could return to Helios to audit or verify the result. These are concrete parts of how the selection took place, distinct from judgments about the people elected.

Broad powers need a process for ordinary work

The council can accept or reject PEPs, delegate responsibilities and work with the Python Software Foundation on project assets. The founding proposal also gives it responsibilities for the language and CPython's quality and stability. It includes the accessibility and sustainability of contribution within that mandate. Governance consequently covers the conditions under which technical work happens as well as the eventual decision on a particular proposal.

Those powers make the council a possible final authority for a disputed change. They also let it establish procedures that assign decisions elsewhere. PEP 8016 specifically encourages the council to use its powers sparingly, prefer consensus where possible, and define processes for deciding proposals. Delegation is a normal exercise of its authority under this design.

That approach has a practical effect on contributors. If every decision required five elected people to study the complete technical detail, the committee would accumulate work that specialists could handle. A defined delegation can preserve expertise at the point of decision while making responsibility explicit. The council remains available when other decision methods fail.

There is a corresponding tradeoff. The founding document does not prescribe every detailed procedure in advance. Contributors gain flexibility, but some questions will still require the council to establish how work should proceed. Today's result identifies who can make those decisions. It does not provide evidence about decisions the council has not yet made.

Employer limits apply to the group

The founding rules allow no more than two council members to work for the same employer. If the highest-ranked candidates would produce an invalid council, the lowest-ranked candidate from the overrepresented employer gives way to the next candidate. The rule repeats as necessary until the composition is valid. Durbin reports that no such conflict affected this result.

This is a constraint on the composition of the committee. It does not imply that every employee has the same views or that an independent contributor lacks interests. PEP 8016 explains the rule partly in terms of avoiding the appearance that one company dominates development. That appearance can undermine confidence even when individuals act in good faith.

The model treats conflicts on individual decisions separately. A council member with a conflict must abstain from the relevant vote. Every member must either vote or explicitly abstain, and a majority of non-abstaining members is required for a decision. The employer cap therefore does not replace judgment about a particular question.

If circumstances change during a term and the employer limit is exceeded, the rules require resignations to restore a valid composition. Vacancies can then be filled through the council's appointment process. The requirement applies after election day, which matters because employment is not fixed for the duration of a governance term.

The core team retains constitutional authority

The council has broad responsibility, but its mandate has boundaries. Altering the governing document requires a core team vote with at least a two-thirds majority of votes cast. The council cannot amend those rules through the ordinary majority it uses for its own decisions. The electorate retains a direct role in changes to the governing arrangement.

Removal of a core team member is also exceptional. The founding model requires at least two-thirds support within the council, making four votes necessary when all five members vote. This power cannot be delegated, and the council cannot use it while a no-confidence vote is underway. Those restrictions are relevant because core team membership affects who can participate in governance.

Core team members can initiate a no-confidence vote against an individual council member or the entire council. A public proposal, seconded by another core team member, starts a two-week vote. At least two-thirds of voters must support removal. If the motion removes the whole council, a new election follows immediately.

These provisions make accountability available between normal elections. They also distinguish ordinary disagreement from a constitutional remedy. A losing argument over a PEP does not itself remove a council member. The core team must explicitly use the specified process and reach its higher threshold.

I prefer having those boundaries written down before an exceptional dispute arises. Contributors can disagree about a decision while still sharing an understanding of which body can make it and which body can remove that authority. That is a more useful basis for maintaining a language than relying on everyone to interpret informal expectations identically.

Terms follow the release process

A new council is elected after each feature release under the founding rules. A term starts when its result is finalized and lasts until the next council's term begins. Members can serve again without a term limit. That gives the project a recurring opportunity to change its governing group while allowing continuity if the electorate wants it.

The model also provides for an individual vacancy. Remaining members can appoint a replacement to serve the rest of the term. A member who cannot be contacted for a month or longer can be replaced. These rules let the council remain functional without requiring every departure to trigger an immediate election of the whole committee.

For library authors and application maintainers, the result establishes responsibility for decisions about the language and interpreter they depend on. It does not itself alter a runtime contract, introduce syntax or change how a package builds. Its effect is procedural, but that procedure determines how future technical proposals receive a decision and how unresolved disputes can end.

The elected council can now establish more detailed decision processes within the authority granted by the founding model. Contributors retain their role in ordinary technical work and their formal rights as an electorate. The committee's first mandate includes preserving that distribution of responsibility while providing final arbitration when the project's existing methods cannot resolve a question.