[pep-8001] Python Governance Voting Process
This commit is contained in:
Łukasz Langa
parent
f6036613e5
commit
411114422a
122
pep-8001.rst
122
pep-8001.rst
|
|
@ -1,7 +1,15 @@
|
|||
PEP: 8001
|
||||
Title: Python Governance Voting Process
|
||||
Author: Barry Warsaw <barry@python.org>
|
||||
Status: Active
|
||||
Author: Brett Cannon <brett@python.org>,
|
||||
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
|
||||
=========
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue