333 lines
14 KiB
ReStructuredText
333 lines
14 KiB
ReStructuredText
PEP: 8001
|
|
Title: Python Governance Voting Process
|
|
Author: Brett Cannon <brett@python.org>,
|
|
Christian Heimes <christian@python.org>,
|
|
Donald Stufft <donald@stufft.io>,
|
|
Eric Snow <ericsnowcurrently@gmail.com>,
|
|
Gregory P. Smith <greg@krypto.org>,
|
|
Łukasz Langa <lukasz@python.org>,
|
|
Mariatta <mariatta@python.org>,
|
|
Nathaniel J. Smith <njs@pobox.com>,
|
|
Pablo Galindo Salgado <pablogsal@python.org>,
|
|
Raymond Hettinger <python@rcn.com>,
|
|
Tal Einat <tal@python.org>,
|
|
Tim Peters <tim.peters@gmail.com>,
|
|
Zachary Ware <zach@python.org>
|
|
Status: Final
|
|
Type: Process
|
|
Topic: Governance
|
|
Content-Type: text/x-rst
|
|
Created: 24-Aug-2018
|
|
|
|
|
|
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?
|
|
-----------------
|
|
|
|
November 16th, 2018 to November 30th, 2018 is the official governance
|
|
PEP review period. We discourage the PEP authors from making major
|
|
substantive changes during this period, although it is expected that
|
|
minor tweaks may occur, as the result of this discussion period.
|
|
|
|
The vote will happen in a 2-week-long window from December 1st, 2018
|
|
to December 16th, 2018
|
|
(`Anywhere on Earth <https://en.wikipedia.org/wiki/Anywhere_on_Earth>`_).
|
|
|
|
Where is the vote?
|
|
------------------
|
|
|
|
The vote will happen using a "private" poll on the
|
|
`Condorcet Internet Voting Service <https://civs.cs.cornell.edu/>`_. Every committer
|
|
will receive an email with a link allowing them to rank the PEPs in their order of
|
|
preference.
|
|
|
|
The election will be supervised by Ee Durbin, The PSF Director of Infrastructure.
|
|
|
|
The results of the election, including anonymized ballots, will be made public on
|
|
December 17th, after the election has closed.
|
|
|
|
The following settings will be used for the vote in the CIVS system:
|
|
|
|
Name of the poll: ``Python governance vote (December 2018)``
|
|
|
|
Description of the poll::
|
|
|
|
This is the vote to choose how the CPython project will govern
|
|
itself, now that Guido has announced his retirement as BDFL. For
|
|
full details, see <a
|
|
href="https://peps.python.org/pep-8001/">PEP
|
|
8001</a>. Many discussions have occurred under <a
|
|
href="https://discuss.python.org/tags/governance">the "governance"
|
|
tag</a> on discuss.python.org.
|
|
<p>
|
|
All votes must be received <b>by the end of December 16th, 2018, <a
|
|
href="https://en.wikipedia.org/wiki/Anywhere_on_Earth">Anywhere on
|
|
Earth</a></b>. All CPython core developers are <a
|
|
href="https://github.com/python/voters">eligible to vote</a>.
|
|
It is asked that inactive core developers <i>who intend to remain
|
|
inactive</i> abstain from voting.
|
|
<p>
|
|
<b>Note: You can only vote once, and all votes are final.</b> Once
|
|
you click "Submit ranking", it's too late to change your mind.
|
|
<p>
|
|
All ballots will be published at the end of voting, but <b>without
|
|
any names attached</b>. No-one associated with the Python project or
|
|
the PSF will know how you voted, or even whether you voted.
|
|
<p>
|
|
If you have any questions, you can post in <a
|
|
href="https://discuss.python.org/c/committers">the Committers
|
|
topic</a>, on <a href="mailto:python-committers@python.org">the
|
|
python-committers list</a>, or <a
|
|
href="mailto:ee@python.org">contact the vote administrator
|
|
directly</a>.
|
|
<p>
|
|
<h1>Options</h1>
|
|
<p>
|
|
We're selecting between seven PEPs, each proposing a different
|
|
governance model.
|
|
<p>
|
|
The options below include links to the text of each PEP, as well
|
|
as their complete change history. The text of these PEPs was
|
|
frozen on December 1, when the vote started. But if you looked at
|
|
the PEPs before that, they might have changed. Please take the
|
|
time to check the current text of the PEPs if you read an older
|
|
draft.
|
|
<p>
|
|
A "Further discussion" option is also included. It represents the
|
|
option of not making a choice at all at this time, and continuing
|
|
the discussion instead. Including this option lets us demonstrate
|
|
the core team's readiness to move forward.
|
|
<p>
|
|
If you think a proposal is a particularly bad idea, you can
|
|
express that by ranking it below "Further discussion". If you
|
|
think all of the proposals are better than further discussion,
|
|
then you should rank "Further discussion" last.
|
|
|
|
Candidates (note: linebreaks are significant here)::
|
|
|
|
<a href="https://peps.python.org/pep-8010/">PEP 8010: The Technical Leader Governance Model</a> (Warsaw) (<a href="https://github.com/python/peps/commits/main/pep-8010.rst">changelog</a>)
|
|
<a href="https://peps.python.org/pep-8011/">PEP 8011: Python Governance Model Lead by Trio of Pythonistas</a> (Mariatta, Warsaw) (<a href="https://github.com/python/peps/commits/main/pep-8011.rst">changelog</a>)
|
|
<a href="https://peps.python.org/pep-8012/">PEP 8012: The Community Governance Model</a> (Langa) (<a href="https://github.com/python/peps/commits/main/pep-8012.rst">changelog</a>)
|
|
<a href="https://peps.python.org/pep-8013/">PEP 8013: The External Council Governance Model</a> (Dower) (<a href="https://github.com/python/peps/commits/main/pep-8013.rst">changelog</a>)
|
|
<a href="https://peps.python.org/pep-8014/">PEP 8014: The Commons Governance Model</a> (Jansen) (<a href="https://github.com/python/peps/commits/main/pep-8014.rst">changelog</a>)
|
|
<a href="https://peps.python.org/pep-8015/">PEP 8015: Organization of the Python community</a> (Stinner) (<a href="https://github.com/python/peps/commits/main/pep-8015.rst">changelog</a>)
|
|
<a href="https://peps.python.org/pep-8016/">PEP 8016: The Steering Council Model</a> (Smith, Stufft) (<a href="https://github.com/python/peps/commits/main/pep-8016.rst">changelog</a>)
|
|
Further discussion
|
|
|
|
Options::
|
|
|
|
[x] Private
|
|
[ ] Make this a test poll: read all votes from a file.
|
|
[ ] Do not release results to all voters.
|
|
[x] Enable detailed ballot reporting.
|
|
[ ] In detailed ballot report, also reveal the identity of the voter with each ballot.
|
|
[ ] Allow voters to write in new choices.
|
|
[ ] Present choices on voting page in exactly the given order.
|
|
[ ] Allow voters to select “no opinion” for some choices.
|
|
[ ] Enforce proportional representation
|
|
|
|
These options will have the effect of:
|
|
|
|
* Making the election "private", or in other words, invite only.
|
|
* The results of the election will be released to all voters.
|
|
* The contents of every ballot will be released to the public, along
|
|
with a detailed report going over how the winner was elected.
|
|
* The detailed ballots will *not* include any identifying information
|
|
and the email addresses of the voters will be thrown away by the CIVS
|
|
system as soon as the email with their voting link has been sent.
|
|
* Voters will *not* be able to write in new choices, meaning they will
|
|
be limited only to the options specified in the election.
|
|
* Voters will *not* have the ability to change their vote after casting
|
|
a ballot. [no-changes]_
|
|
* The default ordering for each ballot will be randomized to remove
|
|
any influence that the order of the ballot may have on the election.
|
|
* Voters will have to rank all choices somehow, but may rank multiple
|
|
choices as equal.
|
|
|
|
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>`_.
|
|
|
|
Note: each voter can only cast a single vote with no ability to
|
|
revise their vote later. [no-changes]_ If you are not absolutely
|
|
sure of your choices, hold off casting your ballot until later in
|
|
the voting period. Votes cast on the last day of the election are
|
|
just as valid as the ones cast on the first day.
|
|
|
|
While the CIVS system does not provide an option for a "Pure"
|
|
Condorcet election, any Condorcet method will select the "Pure"
|
|
Condorcet winner if one exists and otherwise only vary if one
|
|
doesn't exist. The CIVS system differentiates between a Condorcet
|
|
winner and a non Condorcet winner by stating if the winner was a
|
|
Condorcet winner, or if it merely wasn't defeated versus any other
|
|
option. So a winner in the CIVS system will only be accepted if
|
|
it states it was a Condorcet winner.
|
|
|
|
In the unlikely case of a tie (or cycle as is possible under the
|
|
Condorcet method), a new election will be opened, limited to the
|
|
options involved in the tie or cycle, to select a new winner from
|
|
amongst the tied options. This new election will be open for a
|
|
week, and will be repeated until a single winner is determined.
|
|
|
|
|
|
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 private?
|
|
-------------------------------
|
|
|
|
When discussing the election system, a number of core developers expressed
|
|
concerns with the idea of having public ballots, with at least one core
|
|
developer stating that they were planning on abstaining from voting
|
|
altogether due to the use of a public ballot. A poll ran on Discourse
|
|
identified the overwhelming majority of voters prefer private ballots.
|
|
[private-vote]_
|
|
|
|
A secret ballot is considered by many to be a requirement for a free and
|
|
fair election, allowing members to vote their true preferences without
|
|
worry about social pressure or possible fallout for how they may have
|
|
voted.
|
|
|
|
Why the use of CIVS?
|
|
--------------------
|
|
|
|
In the resulting discussion of this PEP, it was determined that core
|
|
developers wished to have a secret ballot. [private-vote]_ Unfortunately
|
|
a secret ballot requires either novel cryptography or a trusted party to
|
|
anonymize the ballots. Since there is not known to be any existing novel
|
|
cryptographic systems for Condorcet ballots, the CIVS system was chosen to
|
|
act as a trusted party.
|
|
|
|
More information about the security and privacy afforded by CIVS, including
|
|
how a malicious voter, election supervisor, or CIVS administrator can
|
|
influence the election can be found
|
|
`here <https://civs.cs.cornell.edu/sec_priv.html>`_.
|
|
|
|
Why cannot voters change their vote?
|
|
------------------------------------
|
|
|
|
CIVS does not allow voters to update their vote and as part of its goal
|
|
to prevent the election supervisor from being able to influence the
|
|
votes.
|
|
|
|
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). For one analyzed set of real-world
|
|
elections with 21 voters or more, a cycle occurred
|
|
`less than 1.5% of the time. <https://www.accuratedemocracy.com/l_cycles.htm>`_.
|
|
|
|
|
|
References
|
|
==========
|
|
|
|
.. [no-changes] https://discuss.python.org/t/pep-8001-public-or-private-ballots/374/20
|
|
|
|
.. [private-vote] https://discuss.python.org/t/pep-8001-public-or-private-ballots/374/4
|
|
|
|
|
|
Copyright
|
|
=========
|
|
|
|
This document has been placed in the public domain.
|