python-peps/pep-8001.rst

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: