Movatterモバイル変換


[0]ホーム

URL:


Following system colour schemeSelected dark colour schemeSelected light colour scheme

Python Enhancement Proposals

PEP 13 – Python Language Governance

Author:
The Python core team and community
Status:
Active
Type:
Process
Topic:
Governance
Created:
16-Dec-2018

Table of Contents

Abstract

This PEP defines the formal governance process for Python, and recordshow this has changed over time. Currently, governance is based arounda steering council. The council has broad authority, which they seekto exercise as rarely as possible.

Current steering council

The 2025 term steering council consists of:

  • Barry Warsaw
  • Donghee Na
  • Emily Morehouse
  • Gregory P. Smith
  • Pablo Galindo Salgado

Per the results of the vote tracked inPEP 8106.

The core team consists of those listed in the privatehttps://github.com/python/voters/ repository which is publiclyshared viahttps://devguide.python.org/developers/.

Specification

The steering council

Composition

The steering council is a 5-person committee.

Mandate

The steering council shall work to:

  • Maintain the quality and stability of the Python language andCPython interpreter,
  • Make contributing as accessible, inclusive, and sustainable aspossible,
  • Formalize and maintain the relationship between the core team andthe PSF,
  • Establish appropriate decision-making processes for PEPs,
  • Seek consensus among contributors and the core team before acting ina formal capacity,
  • Act as a “court of final appeal” for decisions where all othermethods have failed.

Powers

The council has broad authority to make decisions about the project.For example, they can:

  • Accept or reject PEPs
  • Enforce or update the project’s code of conduct
  • Work with the PSF to manage any project assets
  • Delegate parts of their authority to other subcommittees orprocesses

However, they cannot modify this PEP, or affect the membership of thecore team, except via the mechanisms specified in this PEP.

The council should look for ways to use these powers as little aspossible. Instead of voting, it’s better to seek consensus. Instead ofruling on individual PEPs, it’s better to define a standard processfor PEP decision making (for example, by accepting one of the other801x series of PEPs). It’s better to establish a Code of Conductcommittee than to rule on individual cases. And so on.

To use its powers, the council votes. Every council member must eithervote or explicitly abstain. Members with conflicts of interest on aparticular vote must abstain. Passing requires a strict majority ofnon-abstaining council members.

Whenever possible, the council’s deliberations and votes shall be heldin public.

Electing the council

A council election consists of two phases:

  • Phase 1: Candidates advertise their interest in serving. Candidatesmust be nominated by a core team member. Self-nominations areallowed.
  • Phase 2: Each core team member can assign zero to five stars to eachcandidate. Voting is performed anonymously. The outcome of the voteis determined using theSTAR voting system,modified to use theMulti-winner Bloc STARapproach. If a tie that is not automatically resolved by the election software occurs, it maybe resolved by mutual agreement among the candidates, or else thewinner will be chosen at random.

Each phase lasts one to two weeks, at the outgoing council’s discretion.For the initial election, both phases will last two weeks.

The election process is managed by a returns officer nominated by theoutgoing steering council. For the initial election, the returnsofficer will be nominated by the PSF Executive Director.

The council should ideally reflect the diversity of Pythoncontributors and users, and core team members are encouraged to voteaccordingly.

Term

A new council is elected after each feature release. Each council’sterm runs from when their election results are finalized until thenext council’s term starts. There are no term limits.

Vacancies

Council members may resign their position at any time.

Whenever there is a vacancy during the regular council term, thecouncil may vote to appoint a replacement to serve out the rest of theterm.

If a council member drops out of touch and cannot be contacted for amonth or longer, then the rest of the council may vote to replacethem.

Conflicts of interest

While we trust council members to act in the best interests of Pythonrather than themselves or their employers, the mere appearance of anyone company dominating Python development could itself be harmful anderode trust. In order to avoid any appearance of conflict of interest,at most 2 members of the council can work for any single employer.

In a council election, if 3 of the top 5 vote-getters work for thesame employer, then whichever of them ranked lowest is disqualifiedand the 6th-ranking candidate moves up into 5th place; this isrepeated until a valid council is formed.

During a council term, if changing circumstances cause this rule to bebroken (for instance, due to a council member changing employment),then one or more council members must resign to remedy the issue, andthe resulting vacancies can then be filled as normal.

Ejecting core team members

In exceptional circumstances, it may be necessary to remove someonefrom the core team against their will. (For example: egregious andongoing code of conduct violations.) This can be accomplished by asteering council vote, but unlike other steering council votes, thisrequires at least a two-thirds majority. With 5 members voting, thismeans that a 3:2 vote is insufficient; 4:1 in favor is the minimumrequired for such a vote to succeed. In addition, this is the onepower of the steering council which cannot be delegated, and thispower cannot be used while a vote of no confidence is in process.

If the ejected core team member is also on the steering council, thenthey are removed from the steering council as well.

Vote of no confidence

In exceptional circumstances, the core team may remove a sittingcouncil member, or the entire council, via a vote of no confidence.

A no-confidence vote is triggered when a core team member calls forone publicly on an appropriate project communication channel, andanother core team member seconds the proposal within one week.

The vote lasts for two weeks. Core team members vote for or against.If at least two thirds of voters express a lack of confidence, thenthe vote succeeds.

There are two forms of no-confidence votes: those targeting a singlemember, and those targeting the council as a whole. The initial callfor a no-confidence vote must specify which type is intended. If asingle-member vote succeeds, then that member is removed from thecouncil and the resulting vacancy can be handled in the usual way. Ifa whole-council vote succeeds, the council is dissolved and a newcouncil election is triggered immediately.

The core team

Role

The core team is the group of trusted volunteers who manage Python.They assume many roles required to achieve the project’s goals,especially those that require a high level of trust. They make thedecisions that shape the future of the project.

Core team members are expected to act as role models for the communityand custodians of the project, on behalf of the community and allthose who rely on Python.

They will intervene, where necessary, in online discussions or atofficial Python events on the rare occasions that a situation arisesthat requires intervention.

They have authority over the Python Project infrastructure, includingthe Python Project website itself, the Python GitHub organization andrepositories, the bug tracker, the mailing lists, IRC channels, etc.

Prerogatives

Core team members may participate in formal votes, typically to nominate newteam members and to elect the steering council.

Membership

Python core team members demonstrate:

  • a good grasp of the philosophy of the Python Project
  • a solid track record of being constructive and helpful
  • significant contributions to the project’s goals, in any form
  • willingness to dedicate some time to improving Python

As the project matures, contributions go beyond code. Here’s anincomplete list of areas where contributions may be considered forjoining the core team, in no particular order:

  • Working on community management and outreach
  • Providing support on the mailing lists and on IRC
  • Triaging tickets
  • Writing patches (code, docs, or tests)
  • Reviewing patches (code, docs, or tests)
  • Participating in design decisions
  • Providing expertise in a particular domain (security, i18n, etc.)
  • Managing the continuous integration infrastructure
  • Managing the servers (website, tracker, documentation, etc.)
  • Maintaining related projects (alternative interpreters, coreinfrastructure like packaging, etc.)
  • Creating visual designs

Core team membership acknowledges sustained and valuable efforts thatalign well with the philosophy and the goals of the Python project.

It is granted by receiving at least two-thirds positive votes in acore team vote that is open for one week and is not vetoed by thesteering council.

Note

The devguide has asuggested templateto use for such votes.

Core team members are always looking for promising contributors,teaching them how the project is managed, and submitting their namesto the core team’s vote when they’re ready.

There’s no time limit on core team membership. However, in order toprovide the general public with a reasonable idea of how many peoplemaintain Python, core team members who have stopped contributing areencouraged to declare themselves as “inactive”. Those who haven’t madeany non-trivial contribution in two years may be asked to movethemselves to this category, and moved there if they don’t respond. Torecord and honor their contributions, inactive team members willcontinue to be listed alongside active core team members; and, if theylater resume contributing, they can switch back to active status atwill. While someone is in inactive status, though, they lose theiractive privileges like voting or nominating for the steering council,and commit access.

The initial active core team members will consist of everyonecurrently listed in the“Python core” team on GitHub (accessgranted for core members only), and theinitial inactive members will consist of everyone else who has been acommitter in the past.

Changing this document

Changes to this document require at least a two-thirds majority ofvotes cast in a core team vote which should be open for two weeks.

No vote is required to update note blocks and the “Current steeringcouncil” and “History of council elections” sections with currentinformation.

History

Creation of this document

The Python project was started by Guido van Rossum, who served as itsBenevolent Dictator for Life (BDFL) from inception until July 2018,when hestepped down.

After discussion, a number of proposals were put forward for a newgovernance model, and the core devs voted to choose between them. Theoverall process is described inPEP 8000 andPEP 8001, a review ofother projects was performed inPEP 8002, and the proposals themselveswere written up as the 801x series of PEPs. Eventually the proposal inPEP 8016 wasselectedas the new governance model, and was used to create the initialversion of this PEP. The 8000-series PEPs are preserved for historicalreference (and in particular,PEP 8016 contains additional rationaleand links to contemporary discussions), but this PEP is now theofficial reference, and will evolve following the rules describedherein.

History of council elections

History of amendments

  • 2019-04-17: Added the vote length for core devs and changes to this document.
  • 2024-12-10:Adopted Multi-winner Bloc STAR voting for council elections.
  • 2024-12-10:Added a one-week deadline for seconding a vote of no confidence.
  • 2025-11-12:Clarified that the software used for elections may resolve tiesautomatically if possible.

Acknowledgements

This PEP began asPEP 8016, which was written by Nathaniel J. Smithand Donald Stufft, based on a Django governance document written byAymeric Augustin, and incorporated feedback and assistance fromnumerous others.

Copyright

This document has been placed in the public domain.


Source:https://github.com/python/peps/blob/main/peps/pep-0013.rst

Last modified:2025-11-12 11:59:17 GMT


[8]ページ先頭

©2009-2025 Movatter.jp