[pep-8001] Python Governance Voting Process

pep-8001.rst

@@ -1,7 +1,15 @@
 PEP: 8001
 Title: Python Governance Voting Process
-Author: Barry Warsaw <barry@python.org>
+Author: Brett Cannon <brett@python.org>,
-Status: Active
+        Christian Heimes <christian@python.org>,
+        Eric Snow <ericsnowcurrently@gmail.com>,
+        Gregory P. Smith <greg@krypto.org>,
+        Łukasz Langa <lukasz@python.org>
+        Mariatta Wijaya <mariatta.wijaya@gmail.com>,
+        Pablo Galindo Salgado <pablogsal@gmail.com>,
+        Raymond Hettinger <raymond.hettinger@gmail.com>,
+        Zachary Ware <zachary.ware@gmail.com>
+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
+<https://en.wikipedia.org/wiki/Instant-runoff_voting>`_.  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
 =========