iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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 2018-11-01 16:50:11 +01:00 committed by GitHub
parent fb854added
commit 878f0e9ce7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 150 additions and 106 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

256
pep-8015.rst
View File

@ -14,9 +14,10 @@ proposes 3 main changes:
* Formalize the existing concept of "Python teams"; * Formalize the existing concept of "Python teams";
* Give more autonomy to Python teams; * Give more autonomy to Python teams;
* Replace the BDFL (Guido van Rossum) with a new "Python Core Board" of 3 * Replace the BDFL (Guido van Rossum) with a new "Python Steering
members which have limited roles. Their key role is mostly to decide how a Committee" of 3 members which have limited roles. Their key role is
PEP is approved (or rejected or deferred). 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". 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 Rationale
========= =========
This PEP describes the organization of the whole Python development community, This PEP describes the organization of the whole Python development
from Python users to the Python Core Board. Describing all groups and all roles community, from Python users to the Python Steering Committee.
in the same document helps to make the organization more consistent. 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 number of governance changes is minimized to get a smooth transition from
the old to the new organization. the old to the new organization.
@ -43,7 +45,7 @@ decisions and responsibilities to reduce the pressure and avoid wearing
any individual down. any individual down.
To keep most of the decision power within the hands of the community, 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 that a group of people or companies "takes over" the Python project
through just a couple individuals. The project must remain autonomous through just a couple individuals. The project must remain autonomous
and open to everybody. and open to everybody.
@ -81,7 +83,7 @@ This PEP formalizes the following groups:
* Python Contributors * Python Contributors
* Python Teams Members * Python Teams Members
* Python Core Developers * Python Core Developers
* Python Core Board Members * Python Steering Committee Members
* PSF Code of Conduct Workgroup * 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 component. Working in a team is a nice way to learn more to maybe later
become a core developer. become a core developer.
A team might become allowed to decide on their own PEPs, but only the Core A team might become allowed to decide on their own PEPs, but only the
board can allow that (and the board has the power to revoke it as well). 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: Such a case is exceptional, currently a single team has such permission:
the Packaging team. 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 the contributor is interested in such new responsibilities, a vote is
organized. organized.
The vote is public and organized on the python-committers mailing list The vote is reserved to core developers, is public, and is open for 1
for 1 month. Usually the core developer who proposes the promotion has week. Usually the core developer who proposes the promotion has to
to describe the work and skills of the candidate in the email opening describe the work and skills of the candidate in the description of the
the vote. vote. A contributor is only promoted if the number of "+1" exceed the
number of "-1"; other votes (null, "+0" and "-0") are ignored.
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 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 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. 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 The Python Steering Committee is made of the most trusted core
most decision power. The roles of this group are strictly limited to developers since it has the most decision power. The roles of this group
ensure that Python keeps its autonomy and remains open. 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 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 The Python Steering Committee is composed of 3 people. They are elected
year terms, and each year a member is replaced. A board member can be for three year terms, and each year a member is replaced. A committee
a candidate for the seat they are leaving. Candidates have 2 weeks to member can be a candidate for the seat they are leaving.
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.
Board members must be Python core developers. It is important that the Committee members must be Python core developers. The vote is announced
members of the board reflect the diversity of Python' users and 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 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). cannot work for the same company (or subsidiaries of the same company).
In addition, to encourage more people to get involved, a core developer 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 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 the candidate ranked at the first position, 1 year for the candidate
votes). ranked at the third position).
If a board member steps down, a new vote is organized to replaced them. If a committee 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 If the situation of a committee member changes in a way that no longer
satisfies the board constraint (eg: they move to the same company as satisfies the committee constraint (eg: they move to the same company as
another board members), they have to resign. 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). * Decide how a PEP is approved (or rejected or deferred).
* Grant or revoke permissions to a Python team. For example, allow * 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 To decide how a PEP is approved (or rejected or deferred), there are two
options: 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 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. PEP. The Python team of the PEP or the committee select the PEP delegate.
* If the board decides that the PEP is too risky (like language * If the committee decides that the PEP is too risky (like language
changes), a vote is organized (see `PEP process`_ for details on the changes), a vote is organized (see `PEP process`_ for the
vote). The board decides when the vote is opened. 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 sure that important features reach completion. Their ability to pick PEP
delegates is meant to help them to achieve that goal. 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. is approved.
When the committee decides that a PEP must be voted, committee members
PEP process can vote as they are also core developers, but they don't have more
=========== power than any other core developer.
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.
PSF Code of Conduct Workgroup 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. regular contributor.
If the developer changes their behavior, another core developer can 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 developer. The vote follows the same process than for any other Python
contributor. 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 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 difficult to design a perfect organization at the first attempt. This
PEP can be updated in the future to adjust the organization. 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 Any change to this PEP must be validated by a vote. The vote is
change must be validated by a vote. The vote is reserved to core announced 3 weeks in advance, is reserved to core developers, happens in
developers, happens in public on the python-committers mailing list, and public on the python-committers mailing list, and is open for 1 week.
will be open for 1 month. The change is only approved if the number of The proposed PEP change can still be updated during the 3 weeks notice,
"+1" exceed the number of "-1". Other votes (null, "+0" and "-0") are but must not be modified during the vote. The change is only approved if
ignored. the number of "+1" exceed the number of "-1"; other votes (null, "+0"
and "-0") are ignored.
Annex: Examples of Python Teams Annex: Examples of Python Teams
@ -475,3 +491,31 @@ Type Hints team
Note: There is a backport for Python 3.6 and older, see Note: There is a backport for Python 3.6 and older, see
`typing on PyPI <https://pypi.org/project/typing/>`_. `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.