PEP: 8001 Title: Python Governance Voting Process 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 Abstract ======== This PEP outlines the process for how the new model of Python governance is selected, in the wake of `Guido's retirement `_. 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). To ensure the vote is legitimate, the aforementioned PEPs must not be modified during the voting period. 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 a full preferential `instant run-off ranked ballot `_. Every voter orders all 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. Is omitting any candidate PEPs in the ranking allowed? ------------------------------------------------------ A vote which omits candidates in the ranking is invalid. This is because such votes are incompatible with the desired properties listed above, namely: * making voters consider alternatives, as well as * guaranteeing a conclusion in a single election. 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; see below). Are there any deficiencies of instant run-off ranked voting? ------------------------------------------------------------ There is no perfect voting method. It has been shown by the `Gibbard-Satterthwaite theorem `_ that any single-winner ranked voting method which is not dictatorial must be susceptible to so-called "tactical voting". Tactical voting occurs when a voter supports a candidate against their *sincere preference* in order to prevent an outcome they find most undesirable. There are `four major tactical voting strategies `_ (compromising, burying, push-over, and bullet voting). Instant run-off ranked voting is resistant to burying and bullet voting, while being somewhat vulnerable to compromising (less than the plurality method) and vulnerable to push-over voting. Let's summarize those two: * compromising - the voter ranks a less desirable alternative higher because they believe it has a higher chance of being elected; this is sometimes called "casting a useful vote"); * push-over - if the voter is relatively sure their preferred candidate will survive the first counting round, they may rank "the weakest" alternative higher in the hope of that weak alternative being easily beatable in a subsequent round. Copyright ========= 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: