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.

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 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).


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: