From 16732235de5582051aea5ed0b368553dfd409bdb Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Tue, 9 Oct 2018 13:55:05 +0530 Subject: [PATCH] Clarify Python Core Board from PSF Board (#803) * Clarify Python Core Board from PSF Board Signed-off-by: Carol Willing * Fix typo Signed-off-by: Carol Willing --- pep-8015.rst | 69 ++++++++++++++++++++++++++-------------------------- 1 file changed, 34 insertions(+), 35 deletions(-) diff --git a/pep-8015.rst b/pep-8015.rst index 23c1a9d50..549e5c5fc 100644 --- a/pep-8015.rst +++ b/pep-8015.rst @@ -14,9 +14,9 @@ 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 board" of 3 - members which has limited roles, mostly decide how a PEP is approved - (or rejected or deferred). +* 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). Note: the "BDFL-delegate" role is renamed to "PEP delegate". @@ -24,32 +24,31 @@ Note: the "BDFL-delegate" role is renamed to "PEP delegate". Rationale ========= -This PEP describes the organization of the whole Python community, from -Python users to the Python 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 Core Board. Describing all groups and all roles +in the same document helps to make the organization more consistent. -The number of changes is mininized to get a smooth transition from the -old to the new organization. +The number of governance changes is minimized to get a smooth transition from +the old to the new organization. One key design of the organization is to avoid decision bottlenecks. Discussions and decisions are distributed into Python teams where experts in each topic can be found. The expectation is smoother discussions on PEPs: fewer people with better knowledge of the topic. - Previously, almost all decisions have been taken by the Benevolent Dictator For Life (BDFL). The growing popularity of Python increased the pressure on a single person. The proposed organization distributes decisions and responsibilities to reduce the pressure and avoid wearing -them down. +any individual down. To keep most of the decision power within the hands of the community, -the Python board has very limited roles. The idea is to reduce the risk +the Python Core Board 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. -The most sensitives PEPs are decided by democracy: in that case, a PEP +The most sensitive PEPs are decided by democracy: in that case, a PEP is only approved if the majority of core developer vote "+1" (see the `PEP process`_ section below for the vote details). @@ -81,7 +80,7 @@ This PEP formalizes the following groups: * Python Contributors * Python Teams Members * Python Core Developers -* Python Board Members +* Python Core Board Members * PSF Code of Conduct Workgroup @@ -113,7 +112,7 @@ 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 +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). Such case is exceptional, currently a single team has such permission: the Packaging team. @@ -128,13 +127,13 @@ One restricted definition of a core developer is the ability to merge a change (anywhere in the code) and have the bug triage permission (on all bug tracker components). -Core developers are developers who proved to have the required skills to +Core developers are developers who are proven to have the required skills to decide if a change can be approved or must be rejected. Python has a long history, big constraints on backward compatibility, high quality standards (ex: changes require new tests). For these reasons, becoming -a core can take several months. +a core can take several months or longer. -Becoming a core developer means more responbilities. For example, if a +Becoming a core developer means more responsibilities. For example, if a developer approves a change, they become indirectly responsible for regressions and for the maintenance of that modified code. @@ -164,23 +163,23 @@ promoted, a new vote can be organized later, when the candidate gets the missing skills, for example 6 months later. -Python Board -============ +Python Core Board +================= -The Python board is made of the most trusted developers since it has the -most decisions power. The roles of this group are strictly limited to +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. Board 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. -Election of board members -------------------------- +Election of Python Core Board members +------------------------------------- -The Python board is composed of 3 people. They are elected for three -years, and each year a member is replaced. A board member can be -candidate for the seat they is leaving. Candidates have 2 weeks to +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 +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 `_. Votes are private during the vote, but become public when the vote completes. @@ -199,11 +198,11 @@ votes). 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 -satify the board constraint (eg: they move to the same company as +satisfies the board constraint (eg: they move to the same company as another board members), they have to resign. -Board roles ------------ +Python Core Board roles +----------------------- Board roles: @@ -230,10 +229,10 @@ delegates is meant to help them to achieve that goal. Special Case: Board Members And PEPs ------------------------------------ -A board member cannot be a PEP delegate. +A Python Core board member cannot be a PEP delegate. -A board member can offer a PEP, but cannot decide how their own PEP is -approved. +A Python Core board member can offer a PEP, but cannot decide how their own PEP +is approved. PEP process @@ -262,8 +261,8 @@ discussed on the python-dev mailing list. Vote on a PEP ------------- -When the 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 +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. @@ -275,7 +274,7 @@ Lack of decision ================ If a discussion fails to reach a consensus, if the board fail to choose -a PEP delegate for a PEP, if a PEP delegate fails to take a decision, +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.