diff --git a/pep-8000.rst b/pep-8000.rst index 7def5d6d7..5d81187a6 100644 --- a/pep-8000.rst +++ b/pep-8000.rst @@ -91,6 +91,18 @@ PEPs. (Guido van Rossum) with a new "Python board" of 3 members which has limited roles, mostly decide how a PEP is approved (or rejected). +* PEP 8016 - The Steering Council Model + + This PEP proposes a model of Python governance based around a + steering council. The council has broad authority, which they seek + to exercise as rarely as possible; instead, they use this power to + establish standard processes, like those proposed in the other + 801x-series PEPs. This follows the general philosophy that it's + better to split up large changes into a series of small changes that + can be reviewed independently: instead of trying to do everything in + one PEP, we focus on providing a minimal-but-solid foundation for + further governance decisions. + Additional governance models may be added before the final selection. diff --git a/pep-8016.rst b/pep-8016.rst new file mode 100644 index 000000000..466ade3c4 --- /dev/null +++ b/pep-8016.rst @@ -0,0 +1,345 @@ +PEP: 8016 +Title: The Steering Council Model +Author: Nathaniel J. Smith, Donald Stufft +Status: Draft +Type: Informational +Content-Type: text/x-rst +Created: 2018-11-01 + +Abstract +======== + +This PEP proposes a model of Python governance based around a steering +council. The council has broad authority, which they seek to exercise +as rarely as possible; instead, they use this power to establish +standard processes, like those proposed in the other 801x-series PEPs. +This follows the general philosophy that it's better to split up large +changes into a series of small changes that can be reviewed +independently: instead of trying to do everything in one PEP, we focus +on providing a minimal-but-solid foundation for further governance +decisions. + + +Rationale +========= + +The main goals of this proposal are: + +* Be **boring**: We're not experts in governance, and we don't think + Python is a good place to experiment with new and untried governance + models. So this proposal sticks to mature, well-known, previously + tested processes as much as possible. The high-level approach of a + mostly-hands-off council is arguably the most common across large + successful F/OSS projects, and low-level details are derived + directly from Django's governance. +* Be **simple**: We've attempted to pare things down to the minimum + needed to make this workable: the council, the core team (who elect + the council), and the process for changing the document. The goal is + Minimum Viable Governance. +* Be **comprehensive**: But for the things we need to define, we've + tried to make sure to cover all the bases, because we don't want to + go through this kind of crisis again. Having a clear and unambiguous + set of rules also helps minimize confusion and resentment. +* Be **flexible and light-weight**: We know that it will take time and + experimentation to find the best processes for working together. By + keeping this document as minimal as possible, we keep maximal + flexibility for adjusting things later, while minimizing the need + for heavy-weight and anxiety-provoking processes like whole-project + votes. + +A number of details were discussed in `this Discourse thread +`__, +which may be useful to anyone trying to understand the rationale for +various minor decisions. + + +Specification +============= + +The steering council +-------------------- + +Composition +~~~~~~~~~~~ + +The steering council is an elected committee of 5 core team members. + + +Mandate +~~~~~~~ + +The steering council's 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 the Python code of conduct +* Work with the PSF to manage any project assets +* Delegate 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. Only core + team members may be candidates. + +* 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. In case of a tie, the + candidate who joined the core team earlier wins. + +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 [TBD]. + +The council should ideally reflect the diversity of core Python +contributors, 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 any willing core team member 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. + + +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 "emeritus members". 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. Emeritus team members lose their privileges such as voting +rights and commit access. + + +Changing this document +---------------------- + +Changes to this document require at least a two-thirds majority of +votes cast in a core team vote. + + +TODO +==== + +- Maybe add compare-and-contrast with other 801x proposals? + +- Ask Ian or Ernest if they're willing to be the initial returns officer. + +- Lots of people contributed helpful suggestions and feedback; we + should check if they're comfortable being added as co-authors + +- It looks like Aymeric Augustin wrote the whole Django doc, so + presumably holds copyright; maybe we should ask him if he's willing + to release it into the public domain so our copyright statement + below can be simpler. + + +Acknowledgements +================ + +Substantial text was copied shamelessly from `The Django project's +governance document +`__. + + +Copyright +========= + +Text copied from Django used under `their license +`__. The rest of +this document has been placed in the public domain. + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End: