diff --git a/pep-8001.rst b/pep-8001.rst index 0f5f5c803..3ced94284 100644 --- a/pep-8001.rst +++ b/pep-8001.rst @@ -1,7 +1,15 @@ PEP: 8001 Title: Python Governance Voting Process -Author: Barry Warsaw -Status: Active +Author: Brett Cannon , + Christian Heimes , + Eric Snow , + Gregory P. Smith , + Łukasz Langa + Mariatta Wijaya , + Pablo Galindo Salgado , + Raymond Hettinger , + Zachary Ware +Status: Draft Type: Process Content-Type: text/x-rst Created: 2018-08-24 @@ -17,6 +25,116 @@ Once the model is chosen by the procedures outlined here, it will be codified in PEP 13. +Motivation and Rationale +======================== + +Guido's stepping down from the BDFL role left us with a meta-problem of +having to choose *how we will choose* how the Python project should be +governed from now on. + +This document presents a concrete proposal how this choice can be made. +It summarizes discussion and conclusions of the proceedings of a working +group at the core sprint in Redmond in September 2018. Names of all +attendees are listed as authors. + +The governance situation should be resolved in a timely fashion. +Ideally that should happen by the end of the year which unblocks +substantial improvements to be merged in time for Python 3.8. At the +latest, the governance situation needs to be resolved by PyCon 2019 to +avoid a PR crisis. + + +Implementation +============== + +What are we voting for? +----------------------- + +We are voting to choose which governance PEP should be implemented by +the Python project. The list of candidate PEPs is listed in PEP 8000 +and consists of six PEPs (PEP 8010, PEP 8011, PEP 8012, PEP 8013, +PEP 8014, and PEP 8015). + +Who gets to vote? +----------------- + +Every CPython core developer is invited to vote. In the interest of +transparency and fairness, we are asking core developers to self-select +based on whether the governance situation will affect them directly. +In other words, we are recommending for inactive core developers *who +intend to remain inactive* to abstain from voting. + +When is the vote? +----------------- + +The vote will happen in a 2-week-long window from November 16 2018 +to November 30 (Anywhere-on-Earth). + +Where is the vote? +------------------ + +The vote will happen through a private GitHub repository named +"vote-governance" within the Python organization. Every committer +will push a single file named after their GitHub username. Inside the +file, preferences should be stated one PEP per line. + +Committers are allowed to change their vote while voting is open. + +The repository will be archived and made public on December 1st. + +Voting mechanics +---------------- + +The vote will be an `instant run-off ranked ballot +`_. Every voter +orders candidate PEPs from the most preferred to the least preferred. +When the voting period ends, counting commences: + +* First Choices are summed up; +* if the most popular candidate PEP receives a majority of votes, + it wins; +* otherwise, the least popular candidate is eliminated and counting + is restarted. + +In the unlikely case of a tie, the Board of Directors of the Python +Software Foundation decide. + + +Questions and Answers +===================== + +Why instant run-off ranked voting? +---------------------------------- + +1. It is the cheapest election method: only one election needs to be + held to arrive at a conclusion. This is crucial as a failed vote + creates a risk of a governance crisis in 2019. +2. It provides consensus by forcing voters to consider alternatives. +3. It provides a good overview of what voters actually want. While not + all voters get their first-choice, they will at least have a vote in + the final outcome. + +Why recommend for dormant core developers to not vote? +------------------------------------------------------ + +The choice of the governance model will have far reaching and long-term +consequences for Python and its community. We are inviting core +developers to assess their skin in the game. + +Note: this is not an edict and will not be policed. We trust all +members of the core team to act in the best interest of Python. + +Why should the vote be public? +------------------------------ + +The population of Python core developers is very small. With an +important decision like governance, we owe it to ourselves and the wider +Python community to be transparent about how the choice was made. +This removes ambiguity around *who* voted and *how*, as well as allows +people to confirm whether any "tactical voting" occurred (which instant +run-off ranked voting is criticized for). + + Copyright =========