From d4a5364baf4e814c522079262df1535808da113a Mon Sep 17 00:00:00 2001 From: "Nathaniel J. Smith" Date: Wed, 26 Dec 2018 22:40:25 -0800 Subject: [PATCH] PEP 13: make it real (#857) --- pep-0013.rst | 326 +++++++++++++++++++++++++++++++++++++++++++++++++-- pep-8016.rst | 7 ++ 2 files changed, 324 insertions(+), 9 deletions(-) diff --git a/pep-0013.rst b/pep-0013.rst index 87b771525..41fe6e2af 100644 --- a/pep-0013.rst +++ b/pep-0013.rst @@ -1,23 +1,331 @@ PEP: 13 Title: Python Language Governance -Author: Barry Warsaw +Author: The Python core team and community Status: Active Type: Informational Content-Type: text/x-rst -Created: 2018-08-24 +Created: 2018-12-16 Abstract ======== -This PEP is a placeholder for the Python language governance model voted on -and selected by representatives from the Python community. The process for -selecting a new governance model in the wake of `Guido's retirement -`_ -is outlined in PEP 8000. +This PEP defines the formal governance process for Python, and records +how this has changed over time. Currently, governance is based around +a steering council. The council has broad authority, which they seek +to exercise as rarely as possible. -This PEP both describes the new model and names duly elected officeholders. -It maintains the history of those officeholders. + +Current steering council +======================== + +The current steering council consists of: + +* to be determined + +The core team consists of: + +[TODO: we need a canonical list somewhere, in order to hold votes and +things. Right now we have multiple non-canonical lists that need to be +consolidated. Where should we keep it? Dropping it straight into this +PEP doesn't feel like the best idea...] + + +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 and + CPython interpreter, +* Make contributing as accessible, inclusive, and sustainable as + possible, +* Formalize and maintain the relationship between the core team and + the PSF, +* Establish appropriate decision-making processes for PEPs, +* Seek consensus among contributors and the core team before acting in + a formal capacity, +* Act as a "court of final appeal" for decisions where all other + methods 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 or + processes + +However, they cannot modify this PEP, or affect the membership of the +core team, except via the mechanisms specified in this PEP. + +The council should look for ways to use these powers as little as +possible. Instead of voting, it's better to seek consensus. Instead of +ruling on individual PEPs, it's better to define a standard process +for PEP decision making (for example, by accepting one of the other +801x series of PEPs). It's better to establish a Code of Conduct +committee than to rule on individual cases. And so on. + +To use its powers, the council votes. Every council member must either +vote or explicitly abstain. Members with conflicts of interest on a +particular vote must abstain. Passing requires a strict majority of +non-abstaining council members. + +Whenever possible, the council's deliberations and votes shall be held +in public. + + +Electing the council +~~~~~~~~~~~~~~~~~~~~ + +A council election consists of two phases: + +* Phase 1: Candidates advertise their interest in serving. Candidates + must be nominated by a core team member. Self-nominations are + allowed. + +* Phase 2: Each core team member can vote for zero to five of the + candidates. Voting is performed anonymously. Candidates are ranked + by the total number of votes they receive. If a tie occurs, it may + be resolved by mutual agreement among the candidates, or else the + winner 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 the +outgoing steering council. For the initial election, the returns +officer will be nominated by the PSF Executive Director. + +The council should ideally reflect the diversity of Python +contributors and users, and core team members are encouraged to vote +accordingly. + + +Term +~~~~ + +A new council is elected after each feature release. Each council's +term runs from when their election results are finalized until the +next 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, the +council may vote to appoint a replacement to serve out the rest of the +term. + +If a council member drops out of touch and cannot be contacted for a +month or longer, then the rest of the council may vote to replace +them. + + +Conflicts of interest +~~~~~~~~~~~~~~~~~~~~~ + +While we trust council members to act in the best interests of Python +rather than themselves or their employers, the mere appearance of any +one company dominating Python development could itself be harmful and +erode 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 the +same employer, then whichever of them ranked lowest is disqualified +and the 6th-ranking candidate moves up into 5th place; this is +repeated until a valid council is formed. + +During a council term, if changing circumstances cause this rule to be +broken (for instance, due to a council member changing employment), +then one or more council members must resign to remedy the issue, and +the resulting vacancies can then be filled as normal. + + +Ejecting core team members +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In exceptional circumstances, it may be necessary to remove someone +from the core team against their will. (For example: egregious and +ongoing code of conduct violations.) This can be accomplished by a +steering council vote, but unlike other steering council votes, this +requires at least a two-thirds majority. With 5 members voting, this +means that a 3:2 vote is insufficient; 4:1 in favor is the minimum +required for such a vote to succeed. In addition, this is the one +power of the steering council which cannot be delegated, and this +power cannot be used while a vote of no confidence is in process. + +If the ejected core team member is also on the steering council, then +they are removed from the steering council as well. + + +Vote of no confidence +~~~~~~~~~~~~~~~~~~~~~ + +In exceptional circumstances, the core team may remove a sitting +council member, or the entire council, via a vote of no confidence. + +A no-confidence vote is triggered when a core team member calls for +one publically on an appropriate project communication channel, and +another core team member seconds the proposal. + +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, then +the vote succeeds. + +There are two forms of no-confidence votes: those targeting a single +member, and those targeting the council as a whole. The initial call +for a no-confidence vote must specify which type is intended. If a +single-member vote succeeds, then that member is removed from the +council and the resulting vacancy can be handled in the usual way. If +a whole-council vote succeeds, the council is dissolved and a new +council 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 the +decisions that shape the future of the project. + +Core team members are expected to act as role models for the community +and custodians of the project, on behalf of the community and all +those who rely on Python. + +They will intervene, where necessary, in online discussions or at +official Python events on the rare occasions that a situation arises +that requires intervention. + +They have authority over the Python Project infrastructure, including +the Python Project website itself, the Python GitHub organization and +repositories, the bug tracker, the mailing lists, IRC channels, etc. + + +Prerogatives +~~~~~~~~~~~~ + +Core team members may participate in formal votes, typically to nominate new +team 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 an +incomplete list of areas where contributions may be considered for +joining 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, core + infrastructure like packaging, etc.) +- Creating visual designs + +Core team membership acknowledges sustained and valuable efforts that +align well with the philosophy and the goals of the Python project. + +It is granted by receiving at least two-thirds positive votes in a +core team vote and no veto by the steering council. + +Core team members are always looking for promising contributors, +teaching them how the project is managed, and submitting their names +to the core team's vote when they're ready. + +There's no time limit on core team membership. However, in order to +provide the general public with a reasonable idea of how many people +maintain Python, core team members who have stopped contributing are +encouraged to declare themselves as "inactive". Those who haven't made +any non-trivial contribution in two years may be asked to move +themselves to this category, and moved there if they don't respond. To +record and honor their contributions, inactive team members will +continue to be listed alongside active core team members; and, if they +later resume contributing, they can switch back to active status at +will. While someone is in inactive status, though, they lose their +active privileges like voting or nominating for the steering council, +and commit access. + +The initial active core team members will consist of everyone +currently listed in the `"Python core" team on Github +`__, and the +initial inactive members will consist of everyone else who has been a +committer in the past. + + +Changing this document +---------------------- + +Changes to this document require at least a two-thirds majority of +votes cast in a core team vote. + + +History +======= + +The Python project was started by Guido van Rossum, who served as its +Benevolent Dictator for Life (BDFL) from inception until July 2018, +when he `stepped down +`__. + +After discussion, a number of proposals were put forward for a new +governance model, and the core devs voted to choose between them. The +overall process is described in PEP 8000 and PEP 8001, a review of +other projects was performed in PEP 8002, and the proposals themselves +were written up as the 801x series of PEPs. Eventually the proposal in +PEP 8016 was `selected +`__ +as the new governance model, and was used to create the initial +version of this PEP. The 8000-series PEPs are preserved for historical +reference (and in particular, PEP 8016 contains additional rationale +and links to contemporary discussions), but this PEP is now the +official reference, and will evolve following the rules described +herein. + + +Acknowledgements +================ + +This PEP began as PEP 8016, which was written by Nathaniel J. Smith +and Donald Stufft, based on a Django governance document written by +Aymeric Augustin, and incorporated feedback and assistance from +numerous others. Copyright diff --git a/pep-8016.rst b/pep-8016.rst index 3cdb2af48..929aa7be0 100644 --- a/pep-8016.rst +++ b/pep-8016.rst @@ -6,6 +6,13 @@ Type: Informational Content-Type: text/x-rst Created: 2018-11-01 +Note +==== + +This PEP is retained for historical purposes, but the official +governance document is now PEP 13. + + Abstract ========