Update PEP 8015 (version 4) (#824)
* Rename Core Board to Steering Committee * Steering Committee doesn't approve PEPs * Move PSF Code of Conduct Workgroup section * Limit committee mandates * Add Version History and Copyright sections * Adjust votes
This commit is contained in:
Victor Stinner
GitHub
parent
fb854added
commit
878f0e9ce7
256
pep-8015.rst
256
pep-8015.rst
|
|
@ -14,9 +14,10 @@ proposes 3 main changes:
|
|||
|
||||
* Formalize the existing concept of "Python teams";
|
||||
* Give more autonomy to Python teams;
|
||||
* Replace the BDFL (Guido van Rossum) with a new "Python Core Board" of 3
|
||||
members which have limited roles. Their key role is mostly to decide how a
|
||||
PEP is approved (or rejected or deferred).
|
||||
* Replace the BDFL (Guido van Rossum) with a new "Python Steering
|
||||
Committee" of 3 members which have limited roles. Their key role is
|
||||
mostly to decide how a PEP is approved (or rejected or deferred),
|
||||
but not to approve PEPs.
|
||||
|
||||
Note: the "BDFL-delegate" role is renamed to "PEP delegate".
|
||||
|
||||
|
|
@ -24,9 +25,10 @@ Note: the "BDFL-delegate" role is renamed to "PEP delegate".
|
|||
Rationale
|
||||
=========
|
||||
|
||||
This PEP describes the organization of the whole Python development community,
|
||||
from Python users to the Python Core Board. Describing all groups and all roles
|
||||
in the same document helps to make the organization more consistent.
|
||||
This PEP describes the organization of the whole Python development
|
||||
community, from Python users to the Python Steering Committee.
|
||||
Describing all groups and all roles in the same document helps to make
|
||||
the organization more consistent.
|
||||
|
||||
The number of governance changes is minimized to get a smooth transition from
|
||||
the old to the new organization.
|
||||
|
|
@ -43,7 +45,7 @@ decisions and responsibilities to reduce the pressure and avoid wearing
|
|||
any individual down.
|
||||
|
||||
To keep most of the decision power within the hands of the community,
|
||||
the Python Core Board has very limited roles. The idea is to reduce the risk
|
||||
the Python Steering Committee has very limited roles. The idea is to reduce the risk
|
||||
that a group of people or companies "takes over" the Python project
|
||||
through just a couple individuals. The project must remain autonomous
|
||||
and open to everybody.
|
||||
|
|
@ -81,7 +83,7 @@ This PEP formalizes the following groups:
|
|||
* Python Contributors
|
||||
* Python Teams Members
|
||||
* Python Core Developers
|
||||
* Python Core Board Members
|
||||
* Python Steering Committee Members
|
||||
* PSF Code of Conduct Workgroup
|
||||
|
||||
|
||||
|
|
@ -113,8 +115,9 @@ Team members can get the bug triage permission on the team bug tracker
|
|||
component. Working in a team is a nice way to learn more to maybe later
|
||||
become a core developer.
|
||||
|
||||
A team might become allowed to decide on their own PEPs, but only the Core
|
||||
board can allow that (and the board has the power to revoke it as well).
|
||||
A team might become allowed to decide on their own PEPs, but only the
|
||||
Python Steering Committee can allow that (and it has the power to revoke
|
||||
it as well).
|
||||
Such a case is exceptional, currently a single team has such permission:
|
||||
the Packaging team.
|
||||
|
||||
|
|
@ -150,13 +153,11 @@ asks the contributor if they would like to become a core developer. If
|
|||
the contributor is interested in such new responsibilities, a vote is
|
||||
organized.
|
||||
|
||||
The vote is public and organized on the python-committers mailing list
|
||||
for 1 month. Usually the core developer who proposes the promotion has
|
||||
to describe the work and skills of the candidate in the email opening
|
||||
the vote.
|
||||
|
||||
A contributor is only promoted if the number of "+1" exceed the number of
|
||||
"-1". Other votes (null, "+0" and "-0") are ignored.
|
||||
The vote is reserved to core developers, is public, and is open for 1
|
||||
week. Usually the core developer who proposes the promotion has to
|
||||
describe the work and skills of the candidate in the description of the
|
||||
vote. A contributor is only promoted if the number of "+1" exceed the
|
||||
number of "-1"; other votes (null, "+0" and "-0") are ignored.
|
||||
|
||||
If the candidate is promoted, usually they get a mentor for 1 month to
|
||||
help them to handle new responsibilities. If the candidate is not
|
||||
|
|
@ -164,48 +165,54 @@ promoted, a new vote can be organized later, when the candidate gets the
|
|||
missing skills, for example 6 months later.
|
||||
|
||||
|
||||
Python Core Board
|
||||
=================
|
||||
Python Steering Committee
|
||||
=========================
|
||||
|
||||
The Python Core Board is made of the most trusted developers since it has the
|
||||
most decision power. The roles of this group are strictly limited to
|
||||
ensure that Python keeps its autonomy and remains open.
|
||||
The Python Steering Committee is made of the most trusted core
|
||||
developers since it has the most decision power. The roles of this group
|
||||
are strictly limited to ensure that Python keeps its autonomy and
|
||||
remains open.
|
||||
|
||||
Board members are elected for 3 years, a third of it is refreshed every
|
||||
Steering Committee members are elected for 3 years, a third of it is refreshed every
|
||||
year. This way, a member will stay for one full Python release but the
|
||||
board composition will be updated frequently.
|
||||
committee composition will be updated frequently.
|
||||
|
||||
Election of Python Core Board members
|
||||
-------------------------------------
|
||||
Election of Python Steering Committee Members
|
||||
---------------------------------------------
|
||||
|
||||
The Python Core Board is composed of 3 people. They are elected for three
|
||||
year terms, and each year a member is replaced. A board member can be
|
||||
a candidate for the seat they are leaving. Candidates have 2 weeks to
|
||||
apply, and a vote is open for 1 month. The vote uses the `Condorcet
|
||||
method <https://en.wikipedia.org/wiki/Condorcet_method>`_. Votes are
|
||||
private during the vote, but become public when the vote completes.
|
||||
The Python Steering Committee is composed of 3 people. They are elected
|
||||
for three year terms, and each year a member is replaced. A committee
|
||||
member can be a candidate for the seat they are leaving.
|
||||
|
||||
Board members must be Python core developers. It is important that the
|
||||
members of the board reflect the diversity of Python' users and
|
||||
Committee members must be Python core developers. The vote is announced
|
||||
3 weeks in advance: candidates have to apply during this period. The
|
||||
vote is reserved to core developers and is open for 1 week. Votes are
|
||||
private during the vote, but become public when the vote ends. The
|
||||
vote uses the `Condorcet method
|
||||
<https://en.wikipedia.org/wiki/Condorcet_method>`_ to rank candidates.
|
||||
|
||||
It is important that the
|
||||
members of the committee reflect the diversity of Python' users and
|
||||
contributors. A small step to ensure that is to enforce that two members
|
||||
cannot work for the same company (or subsidiaries of the same company).
|
||||
In addition, to encourage more people to get involved, a core developer
|
||||
can only be a board member twice (up to 6 years total).
|
||||
can only be a committee member twice in their whole life (up to 6 years
|
||||
total), it can be two mandates in a row.
|
||||
|
||||
To bootstrap the process, 3 members will be elected at the board
|
||||
To bootstrap the process, 3 members will be elected at the committee
|
||||
creation. The first members will stay for 1, 2 or 3 years (3 years for
|
||||
the candidate with most votes, 1 year for the candidate with least
|
||||
votes).
|
||||
the candidate ranked at the first position, 1 year for the candidate
|
||||
ranked at the third position).
|
||||
|
||||
If a board member steps down, a new vote is organized to replaced them.
|
||||
If the situation of a board member changes in a way that no longer
|
||||
satisfies the board constraint (eg: they move to the same company as
|
||||
another board members), they have to resign.
|
||||
If a committee member steps down, a new vote is organized to replaced them.
|
||||
If the situation of a committee member changes in a way that no longer
|
||||
satisfies the committee constraint (eg: they move to the same company as
|
||||
another committee members), they have to resign.
|
||||
|
||||
Python Core Board roles
|
||||
-----------------------
|
||||
Python Steering Committee Roles
|
||||
-------------------------------
|
||||
|
||||
Board roles:
|
||||
Python Steering Committee roles:
|
||||
|
||||
* Decide how a PEP is approved (or rejected or deferred).
|
||||
* Grant or revoke permissions to a Python team. For example, allow
|
||||
|
|
@ -215,70 +222,29 @@ Board roles:
|
|||
To decide how a PEP is approved (or rejected or deferred), there are two
|
||||
options:
|
||||
|
||||
* The board elects a PEP delegate (previously known as "BDFL-delegate"):
|
||||
* The committee elects a PEP delegate (previously known as "BDFL-delegate"):
|
||||
a core developer who will take the final decision for the specific
|
||||
PEP. The Python team of the PEP or the board select the PEP delegate.
|
||||
* If the board decides that the PEP is too risky (like language
|
||||
changes), a vote is organized (see `PEP process`_ for details on the
|
||||
vote). The board decides when the vote is opened.
|
||||
PEP. The Python team of the PEP or the committee select the PEP delegate.
|
||||
* If the committee decides that the PEP is too risky (like language
|
||||
changes), a vote is organized (see `PEP process`_ for the
|
||||
vote organization). The committee decides when the vote is organized.
|
||||
|
||||
The board keeps the "vision" and consistency of Python. It also makes
|
||||
The committee keeps the "vision" and consistency of Python. It also makes
|
||||
sure that important features reach completion. Their ability to pick PEP
|
||||
delegates is meant to help them to achieve that goal.
|
||||
|
||||
|
||||
Special Case: Board Members And PEPs
|
||||
------------------------------------
|
||||
Special Case: Steering Committee Members And PEPs
|
||||
-------------------------------------------------
|
||||
|
||||
A Python Core board member cannot be a PEP delegate.
|
||||
A committee member cannot be a PEP delegate.
|
||||
|
||||
A Python Core board member can offer a PEP, but cannot decide how their own PEP
|
||||
A committee member can offer a PEP, but cannot decide how their own PEP
|
||||
is approved.
|
||||
|
||||
|
||||
PEP process
|
||||
===========
|
||||
|
||||
There are 2 main roles on PEPs:
|
||||
|
||||
* PEP Authors
|
||||
* PEP Delegate
|
||||
|
||||
PEP Authors do their best to write high quality PEP.
|
||||
|
||||
The PEP delegate is responsible to help the authors to enhance their PEP
|
||||
and is the one taking the final decision (accept, reject or defer the
|
||||
PEP). They can also help to guide the discussion.
|
||||
|
||||
If no decision is taken, the authors can propose again the PEP later
|
||||
(ex: one year later), if possible with new data to motive the change. A
|
||||
PEP Delegate can also choose to mark a PEP as "Deferred" to not reject
|
||||
the PEP and encourage to reopen the discussion later.
|
||||
|
||||
PEPs specific to a Python team are discussed on the team mailing list.
|
||||
PEPs impacting all Python developers (like language changes) must be
|
||||
discussed on the python-dev mailing list.
|
||||
|
||||
Vote on a PEP
|
||||
-------------
|
||||
|
||||
When the Python Core board decides that a PEP needs a wider approval, a vote
|
||||
will be open for 1 month to all core developers. Such vote will happen on the
|
||||
mailing list where the PEP has been discussed. The PEP must have been
|
||||
discussed for a reasonable amount of time before it is put to vote.
|
||||
|
||||
A PEP is only approved if the number of "+1" exceed the number of "-1".
|
||||
Other votes (null, "+0" and "-0") are ignored.
|
||||
|
||||
|
||||
Lack of decision
|
||||
================
|
||||
|
||||
If a discussion fails to reach a consensus, if the board fail to choose
|
||||
a PEP delegate for a PEP, or if a PEP delegate fails to take a decision,
|
||||
the obvious risk is that Python fails to evolve.
|
||||
|
||||
That's fine. Sometimes, doing nothing is the wisest choice.
|
||||
When the committee decides that a PEP must be voted, committee members
|
||||
can vote as they are also core developers, but they don't have more
|
||||
power than any other core developer.
|
||||
|
||||
|
||||
PSF Code of Conduct Workgroup
|
||||
|
|
@ -323,11 +289,60 @@ At the end of the ban, the developer is allowed to contribute again as a
|
|||
regular contributor.
|
||||
|
||||
If the developer changes their behavior, another core developer can
|
||||
open a new vote to propose the developer for promotion to core
|
||||
organize a new vote to propose the developer for promotion to core
|
||||
developer. The vote follows the same process than for any other Python
|
||||
contributor.
|
||||
|
||||
|
||||
PEP process
|
||||
===========
|
||||
|
||||
There are 2 main roles on PEPs:
|
||||
|
||||
* PEP Authors
|
||||
* PEP Delegate
|
||||
|
||||
PEP Authors do their best to write high quality PEP.
|
||||
|
||||
The PEP delegate is responsible to help the authors to enhance their PEP
|
||||
and is the one taking the final decision (accept, reject or defer the
|
||||
PEP). They can also help to guide the discussion.
|
||||
|
||||
If no decision is taken, the authors can propose again the PEP later
|
||||
(ex: one year later), if possible with new data to motive the change. A
|
||||
PEP Delegate can also choose to mark a PEP as "Deferred" to not reject
|
||||
the PEP and encourage to reopen the discussion later.
|
||||
|
||||
PEPs specific to a Python team are discussed on the team mailing list.
|
||||
PEPs impacting all Python developers (like language changes) must be
|
||||
discussed on the python-dev mailing list.
|
||||
|
||||
Vote on a PEP
|
||||
-------------
|
||||
|
||||
When the Python Steering Committee decides that a PEP needs a wider
|
||||
approval, a vote is organized.
|
||||
|
||||
The vote is reserved to core developers, is announced 1 week in advance,
|
||||
and is open for 1 week. The PEP can still be updated during the 1 week
|
||||
notice, but must not be modified during the vote. Such vote happens on
|
||||
the mailing list where the PEP has been discussed. The committee decides
|
||||
when the vote is organized. The PEP must have been discussed for a
|
||||
reasonable amount of time before it is put to vote. A PEP is only
|
||||
approved if the number of "+1" exceed the number of "-1"; other votes
|
||||
(null, "+0" and "-0") are ignored.
|
||||
|
||||
|
||||
Lack of Decision
|
||||
================
|
||||
|
||||
If a discussion fails to reach a consensus, if the Python Steering Committee fail to choose
|
||||
a PEP delegate for a PEP, or if a PEP delegate fails to take a decision,
|
||||
the obvious risk is that Python fails to evolve.
|
||||
|
||||
That's fine. Sometimes, doing nothing is the wisest choice.
|
||||
|
||||
|
||||
How to update this PEP
|
||||
======================
|
||||
|
||||
|
|
@ -337,12 +352,13 @@ the roles of Python community members have never been formalized. It is
|
|||
difficult to design a perfect organization at the first attempt. This
|
||||
PEP can be updated in the future to adjust the organization.
|
||||
|
||||
The process to update this PEP is that someone proposes a change and the
|
||||
change must be validated by a vote. The vote is reserved to core
|
||||
developers, happens in public on the python-committers mailing list, and
|
||||
will be open for 1 month. The change is only approved if the number of
|
||||
"+1" exceed the number of "-1". Other votes (null, "+0" and "-0") are
|
||||
ignored.
|
||||
Any change to this PEP must be validated by a vote. The vote is
|
||||
announced 3 weeks in advance, is reserved to core developers, happens in
|
||||
public on the python-committers mailing list, and is open for 1 week.
|
||||
The proposed PEP change can still be updated during the 3 weeks notice,
|
||||
but must not be modified during the vote. The change is only approved if
|
||||
the number of "+1" exceed the number of "-1"; other votes (null, "+0"
|
||||
and "-0") are ignored.
|
||||
|
||||
|
||||
Annex: Examples of Python Teams
|
||||
|
|
@ -475,3 +491,31 @@ Type Hints team
|
|||
|
||||
Note: There is a backport for Python 3.6 and older, see
|
||||
`typing on PyPI <https://pypi.org/project/typing/>`_.
|
||||
|
||||
|
||||
Version History
|
||||
===============
|
||||
|
||||
History of this PEP:
|
||||
|
||||
* Version 4:
|
||||
|
||||
* Adjust votes: open for 1 week instead of 1 month, and announced
|
||||
in advance.
|
||||
* Rename the "Python Core Board" to the "Python Steering Committee";
|
||||
* Clarify that this committee doesn't approve PEPs and that committee
|
||||
members cannot cumulate more than 2 mandates;
|
||||
* Add the "Type Hints" team to the annex.
|
||||
|
||||
* Version 3: Add "Special Case: Ban a core developer" and "How to update
|
||||
this PEP" sections.
|
||||
* Version 2: Rename the "Python board" to the "Python Core Board",
|
||||
to avoid confusion with the PSF Board.
|
||||
* Version 1: First version posted to python-committers and
|
||||
discuss.python.org.
|
||||
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
This document has been placed in the public domain.
|
||||
|
|
|
|||
Loading…
Reference in New Issue