196 lines
6.8 KiB
ReStructuredText
196 lines
6.8 KiB
ReStructuredText
PEP: 8001
|
||
Title: Python Governance Voting Process
|
||
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@python.org>,
|
||
Pablo Galindo Salgado <pablogsal@gmail.com>,
|
||
Raymond Hettinger <python@rcn.com>,
|
||
Zachary Ware <zachary.ware@gmail.com>
|
||
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
|
||
<https://mail.python.org/pipermail/python-committers/2018-July/005664.html>`_.
|
||
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
|
||
<https://en.wikipedia.org/wiki/Instant-runoff_voting>`_. 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
|
||
<https://en.wikipedia.org/wiki/Gibbard%E2%80%93Satterthwaite_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
|
||
<https://en.wikipedia.org/wiki/Tactical_voting>`_
|
||
(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:
|