250 lines
9.4 KiB
ReStructuredText
250 lines
9.4 KiB
ReStructuredText
|
PEP: 8013
|
|||
|
|
Title: The External Council Governance Model
|
|||
|
|
Author: Steve Dower <steve.dower@python.org>
|
|||
|
|
Status: Draft
|
|||
|
|
Type: Informational
|
|||
|
|
Content-Type: text/x-rst
|
|||
|
|
Created: 2018-09-14
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
========
|
|||
|
|
|
|||
|
|
This PEP proposes a new model of Python governance based on a Group
|
|||
|
|
of Unbiased Independent Directors of Order (GUIDO) tasked with making
|
|||
|
|
final decisions for the language. It differs from PEP 8010 by
|
|||
|
|
specifically not proposing a central singular leader, and from PEP
|
|||
|
|
8011 by disallowing core committers from being council members. It
|
|||
|
|
describes the size and role of the council, how the initial group of
|
|||
|
|
council members will be chosen, any term limits of the council
|
|||
|
|
members, and how successors will be elected.
|
|||
|
|
|
|||
|
|
It also spends significant time discussing the intended behaviour of
|
|||
|
|
this model. By design, many processes are not specified here but are
|
|||
|
|
left to the people involved. In order to select people who will make
|
|||
|
|
the best decisions, it is important for those involved to understand
|
|||
|
|
the expectations of GUIDO but it is equally important to allow GUIDO
|
|||
|
|
the freedom to adjust process requirements for varying circumstances.
|
|||
|
|
This only works when process is unspecified, but all participants have
|
|||
|
|
similar expectations.
|
|||
|
|
|
|||
|
|
This PEP does *not* name the members of GUIDO. Should this model be
|
|||
|
|
adopted, it will be codified in PEP 13 along with the names of all
|
|||
|
|
officeholders described in this PEP.
|
|||
|
|
|
|||
|
|
Open Discussion Points
|
|||
|
|
======================
|
|||
|
|
|
|||
|
|
Some suggestions in this document are currently weak suggestions, and
|
|||
|
|
are open to change during the discussion period. These include:
|
|||
|
|
|
|||
|
|
* We can change the name of the group. "Council of Auditors" is the
|
|||
|
|
suggested alternative.
|
|||
|
|
|
|||
|
|
* We can change voting procedures, timelines, and tie-breakage rules
|
|||
|
|
|
|||
|
|
|
|||
|
|
The Importance of the Grey Area
|
|||
|
|
===============================
|
|||
|
|
|
|||
|
|
In any actual decision-making process, there is going to be grey area.
|
|||
|
|
This includes unexpected scenarios, and cases where there is no
|
|||
|
|
"correct" answer.
|
|||
|
|
|
|||
|
|
Many process plans attempt to minimise grey area by defining processes
|
|||
|
|
clearly enough that no flexibility is required.
|
|||
|
|
|
|||
|
|
This proposal deliberately goes the other way. The aim is to provide a
|
|||
|
|
robust framework for choosing the best people to handle unexpected
|
|||
|
|
situations, without defining how those people should handle those
|
|||
|
|
situations.
|
|||
|
|
|
|||
|
|
Examples are provided of "good" responses to some situations as an
|
|||
|
|
illustration. The hope is that the "best" people are the best because
|
|||
|
|
they would live up to those examples. The process that is proposed has
|
|||
|
|
been designed to minimise the damage that may be caused when those
|
|||
|
|
people turn out not to be the best.
|
|||
|
|
|
|||
|
|
Grey area is guaranteed to exist. This proposal deliberately embraces
|
|||
|
|
and works within that, rather than attempting to prevent it.
|
|||
|
|
|
|||
|
|
Model Overview
|
|||
|
|
==============
|
|||
|
|
|
|||
|
|
Key people and their functions
|
|||
|
|
------------------------------
|
|||
|
|
|
|||
|
|
The Group of Unbiased Independent Directors of Order (GUIDO) is a
|
|||
|
|
council of varying size, typically two to four people, who are elected
|
|||
|
|
for the duration of a Python release. GUIDO has responsibility for
|
|||
|
|
reviewing controversial decisions in the form of PEPs written by
|
|||
|
|
members of the core development team.
|
|||
|
|
|
|||
|
|
GUIDO may choose to accept a PEP exactly as presented, or may request
|
|||
|
|
clarification or changes. These changes may be of any form and for any
|
|||
|
|
reason. This flexibility is intentional, and allows the process to
|
|||
|
|
change over time as different members are elected to GUIDO. See the
|
|||
|
|
later sections of this document for examples of the kinds of requests
|
|||
|
|
that are expected.
|
|||
|
|
|
|||
|
|
GUIDO only pronounces on PEPs submitted to python-committers. There is
|
|||
|
|
no expectation that GUIDO follows or participates on any other mailing
|
|||
|
|
lists.
|
|||
|
|
|
|||
|
|
The Release Manager (RM) is also permitted the same ability to accept
|
|||
|
|
or request changes on any PEPs that specify the release they are
|
|||
|
|
responsible for. After feature freeze, the RM retains this
|
|||
|
|
responsibility for their release, while GUIDO rotates and begins to
|
|||
|
|
focus on the subsequent release. This is no different from the current
|
|||
|
|
process. The process for selection of a RM is not changed in this
|
|||
|
|
proposal.
|
|||
|
|
|
|||
|
|
Core developers are responsible for electing members of GUIDO, and
|
|||
|
|
have the ability to call a "vote of no confidence" in members of
|
|||
|
|
GUIDO. The details of these votes are discussed below.
|
|||
|
|
|
|||
|
|
Members of GUIDO may choose to resign at any point. If at least two
|
|||
|
|
members of GUIDO remain, they may request a new election to refill the
|
|||
|
|
group. If only one member remains, the election is triggered
|
|||
|
|
automatically.
|
|||
|
|
|
|||
|
|
The intended balance of power is that the core developers elect
|
|||
|
|
members of GUIDO who reflect the direction and have the trust of the
|
|||
|
|
development team, and also have the ability to remove members who do
|
|||
|
|
not honour commitments made prior to election.
|
|||
|
|
|
|||
|
|
Regular decision process
|
|||
|
|
------------------------
|
|||
|
|
|
|||
|
|
Regular decisions continue to be made as at present.
|
|||
|
|
|
|||
|
|
For the sake of clarity, decisions requiring a PEP are always treated
|
|||
|
|
as controversial.
|
|||
|
|
|
|||
|
|
GUIDO may be asked to advise on whether a decision would be better
|
|||
|
|
made using the controversial decision process, but the core
|
|||
|
|
development team is not bound by such advice.
|
|||
|
|
|
|||
|
|
Controversial decision process
|
|||
|
|
------------------------------
|
|||
|
|
|
|||
|
|
Controversial decisions are always written up as PEPs, following the
|
|||
|
|
existing process. The approver (formerly "BDFL-Delegate") is always
|
|||
|
|
GUIDO.
|
|||
|
|
|
|||
|
|
GUIDO will pronounce on PEPs submitted to python-committers with a
|
|||
|
|
request for pronouncement. Any member of GUIDO may request changes to
|
|||
|
|
a PEP for any reason, provided they include some indication of what
|
|||
|
|
additional work is required to meet their expectations. See later
|
|||
|
|
sections for examples of expected reasons.
|
|||
|
|
|
|||
|
|
When all members of GUIDO indicate that they have no concerns with a
|
|||
|
|
PEP, it is formally accepted. When one or more members of GUIDO fail
|
|||
|
|
to respond in a reasonable time, the President of GUIDO may choose to
|
|||
|
|
interpret that as implied approval. Failure of the President to
|
|||
|
|
respond should be handled using a vote of no confidence.
|
|||
|
|
|
|||
|
|
Election terms
|
|||
|
|
--------------
|
|||
|
|
|
|||
|
|
Members of GUIDO are elected for the duration of a release. The
|
|||
|
|
members are elected prior to feature freeze for the previous release,
|
|||
|
|
and hold their position until feature freeze for their release.
|
|||
|
|
|
|||
|
|
Members may seek re-election as many times as they like. There are no
|
|||
|
|
term limits. It is up to the core developers to prevent re-election of
|
|||
|
|
GUIDO members where there is consensus that the individual should not
|
|||
|
|
serve again.
|
|||
|
|
|
|||
|
|
Election voting process
|
|||
|
|
------------------------
|
|||
|
|
|
|||
|
|
The election process for each member of GUIDO proceeds as follows:
|
|||
|
|
|
|||
|
|
* a nomination email is sent to python-committers
|
|||
|
|
* a seconding email is sent
|
|||
|
|
* the nominee is temporarily added to python-committers for the
|
|||
|
|
purpose of introducing themselves and presenting their position
|
|||
|
|
* voting opens two weeks prior to the scheduled feature freeze of the
|
|||
|
|
previous release
|
|||
|
|
* votes are contributed by modifying a document in a private github
|
|||
|
|
repository
|
|||
|
|
* each core developer may add +1 votes for as many candidates as they
|
|||
|
|
like
|
|||
|
|
* after seven days, voting closes
|
|||
|
|
* the nominee with the most votes is elected as President of GUIDO
|
|||
|
|
* the next three nominees with the most votes and also at least 50%
|
|||
|
|
the number of votes received by the President are elected as the
|
|||
|
|
other members of GUIDO
|
|||
|
|
* where ties need to be resolved, the RM may apply one extra vote for
|
|||
|
|
their preferred candidates
|
|||
|
|
* accepted nominees remain on python-committers; others are removed
|
|||
|
|
|
|||
|
|
No-confidence voting process
|
|||
|
|
----------------------------
|
|||
|
|
|
|||
|
|
A vote of no confidence proceeds as follows:
|
|||
|
|
|
|||
|
|
* a vote of no confidence email is sent to python-committers, naming
|
|||
|
|
the affected member of GUIDO, justifying the nomination, and
|
|||
|
|
optionally listing accepted PEPs that the nominator believes should
|
|||
|
|
be reverted
|
|||
|
|
* a seconding email is sent within seven days
|
|||
|
|
* the nominated member of GUIDO is allowed seven days to respond,
|
|||
|
|
after which the nominator or the seconder may withdraw
|
|||
|
|
* if no nominator or seconder is available, no further action is
|
|||
|
|
taken
|
|||
|
|
* voting opens immediately
|
|||
|
|
* each core developer may add a +1 vote (remove the GUIDO member) or
|
|||
|
|
a -1 vote (keep the GUIDO member) by modifying a document in a
|
|||
|
|
private github repository
|
|||
|
|
* after seven days, voting closes
|
|||
|
|
* if +1 votes exceed -1 votes, the GUIDO member is removed from
|
|||
|
|
python-committers and any nominated PEPs are reverted
|
|||
|
|
* if requested by the remaining members of GUIDO, or if only one
|
|||
|
|
member of GUIDO remains, a new election to replace the removed
|
|||
|
|
member may be held following the usual process.
|
|||
|
|
* in the case of removing the President of GUIDO, the candidate
|
|||
|
|
who originally received the second-most votes becomes President
|
|||
|
|
|
|||
|
|
Examples of intended behaviour
|
|||
|
|
==============================
|
|||
|
|
|
|||
|
|
This section describes some examples of the kind of interactions that
|
|||
|
|
we hope to see between GUIDO and the core developers. None of these
|
|||
|
|
are binding descriptions, but are intended to achieve some consensus
|
|||
|
|
on the types of processes we expect. GUIDO candidates may campaign
|
|||
|
|
on the basis of whatever process they prefer, and core developers
|
|||
|
|
should allocate votes on this basis.
|
|||
|
|
|
|||
|
|
Scenario 1 - The Case of the Vague PEP
|
|||
|
|
--------------------------------------
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
Scenario 2 - The Case of the Endless Discussion
|
|||
|
|
-----------------------------------------------
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
Scenario 3 - The Case of the Unconsidered Users
|
|||
|
|
-----------------------------------------------
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
|
|||
|
|
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:
|