204 lines
7.5 KiB
ReStructuredText
204 lines
7.5 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). This PEP also summarizes a
|
||
`subsequent thread <https://discuss.python.org/t/python-governance-electoral-system/290>`_
|
||
that took place on discuss.python.org .
|
||
|
||
The governance situation should be resolved in a timely fashion.
|
||
Ideally that should happen by the end of the 2018 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 US 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 all PEPs numbered in the 801X range.
|
||
|
||
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 made read-only and public on December 1st.
|
||
|
||
Voting mechanics
|
||
----------------
|
||
|
||
The vote will be by ranked ballot. Every voter
|
||
orders all candidate PEPs from the most preferred to the least
|
||
preferred. The vote will be tallied and a winner chosen using the
|
||
`Condorcet method <https://en.wikipedia.org/wiki/Condorcet_method>`_.
|
||
|
||
In the unlikely case of a tie (or cycle as is possible under the
|
||
Condorcet method), voting will be re-opened for another week to allow
|
||
voters to change their ballots. This re-opening and allowing of vote
|
||
changing for a week will continue until a winner is determined.
|
||
|
||
An example ballot is::
|
||
|
||
Please rank **every** choice -- starting at 1 and ending at 6 by entering your rankings
|
||
between the square brackets (e.g. `[1]`, with 1 being your most preferred choice and
|
||
6 being your least preferred).
|
||
|
||
If you are currently an inactive core developer *who intends to remain inactive*,
|
||
please abstain from voting.
|
||
|
||
**DO NOT LEAVE ANY BRACKETS BLANK!**
|
||
**DO NOT REPEAT A RANKING/NUMBER!**
|
||
|
||
[] PEP 8010: The BDFL Governance Model (Warsaw)
|
||
[] PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw)
|
||
[] PEP 8012: The Community Governance Model (Langa)
|
||
[] PEP 8013: The External Council Governance Model (Dower)
|
||
[] PEP 8014: The Commons Governance Model (Jansen)
|
||
[] PEP 8015: Organization of the Python community (Stinner)
|
||
[] Further discussion
|
||
|
||
|
||
Questions and Answers
|
||
=====================
|
||
|
||
Why the Condorcet method?
|
||
----------------------------------
|
||
|
||
1. It allows voters to express preference by ranking PEPs
|
||
2. It is `consensus decision-making <https://en.wikipedia.org/wiki/Consensus_decision-making#Condorcet_consensus>`_
|
||
3. In a `poll <https://discuss.python.org/t/python-governance-electoral-system/290/26>`_
|
||
open to only core developers and run using Approval voting, it was
|
||
the clear preference
|
||
|
||
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
|
||
* Doing everything possible to reach 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 in the Condorcet method?
|
||
------------------------------------------------------------
|
||
|
||
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". This can lead to
|
||
people not voting as they truly believe in order to influence the
|
||
outcome.
|
||
|
||
The Condorcet method also has the possibility of having cycles (known as
|
||
the `Condorcet paradox <https://en.wikipedia.org/wiki/Condorcet_paradox>`_).
|
||
Due to the fact that the Condorcet method chooses a winner based on whether
|
||
they would win against the other options in a 1-on-1 race, there is a
|
||
possibility that PEP A > PEP B > PEP C > PEP A (or in terms of the game
|
||
rock-paper-scissors, imagine a three-player game where someone played rock,
|
||
another played paper, and the last person played scissors; no one wins that
|
||
game as everyone is defeated by someone). The chances of this occurring when
|
||
there are 21 or more voters, though, is
|
||
`less than 1.5% <https://www.accuratedemocracy.com/l_cycles.htm>`_.
|
||
|
||
|
||
|
||
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:
|