diff --git a/pep-8000.rst b/pep-8000.rst index efc8aba60..fc0fd0fe8 100644 --- a/pep-8000.rst +++ b/pep-8000.rst @@ -86,6 +86,14 @@ PEPs. rights and what a majority vote consists of. In stead this is determined by the council of elders on a case by case basis. +* PEP 8015 - Organization of the Python community + + This PEP formalizes the current organization of the Python community + and 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). + Additional governance models may be added before the final selection. diff --git a/pep-8015.rst b/pep-8015.rst new file mode 100644 index 000000000..23c1a9d50 --- /dev/null +++ b/pep-8015.rst @@ -0,0 +1,425 @@ +PEP: 8015 +Title: Organization of the Python community +Author: Victor Stinner +Status: Active +Type: Informational +Content-Type: text/x-rst +Created: 2018-10-04 + +Abstract +======== + +This PEP formalizes the current organization of the Python community and +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). + +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. + +The number of changes is mininized 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. + +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 +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 +is only approved if the majority of core developer vote "+1" (see the +`PEP process`_ section below for the vote details). + + +Common Guidelines +================= + +* The Python community is open to everyone. +* Members must respect the `Python Community Code of Conduct + `_ which ensures that + discussions remain constructive and that everybody feels welcomed. +* Python is and will remain an autonomous project. It cannot be owned by + a company. +* People with decisions power should reflect the diversity of its users + and contributors. + + +Community Organization +====================== + +Right now, there are different group of people involved in the Python +project. The more involved you are, the most decisions power you get. It +is important that the people acceding to the deepest group are the most +trusted ones. + +This PEP formalizes the following groups: + +* Python Users +* Python Contributors +* Python Teams Members +* Python Core Developers +* Python Board Members +* PSF Code of Conduct Workgroup + + +Python Users +============ + +This is the largest group: anyone who uses Python. + + +Python Contributors +=================== + +Once a Python user sends an email to a Python mailing list, comments the +Python bug tracker, proposes or reviews a Python change, they becomes a +Python contributor. + + +Python Teams +============ + +Python became too big to work as an unique team anymore, people +naturally have grouped themself as teams to work more closely on +specific topics, sometimes called "Special Interest Group" (SIG). + +Team members are Python contributors and Python core developers. The +team is responsible to select who can join the team and how. + +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 +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. + +See `Annex: Examples of Python Teams`_. + + +Python Core Developers +====================== + +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 +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. + +Becoming a core developer means more responbilities. For example, if a +developer approves a change, they become indirectly responsible for +regressions and for the maintenance of that modified code. + +Core developers are also expected to be exemplary when it comes to the +Code of Conduct. They are encouraged to mentor contributors. + +Promote a contributor as core developer +--------------------------------------- + +Once an existing core developer considers that a contributor is ready to +join the core group, to become a core developer, that core developer +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. + +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 +promoted, a new vote can be organized later, when the candidate gets the +missing skills, for example 6 months later. + + +Python 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 +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 +------------------------- + +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 +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. + +Board members must be Python core developers. It is important that the +members of the board 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). + +To bootstrap the process, 3 members will be elected at the board +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). + +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 +another board members), they have to resign. + +Board roles +----------- + +Board roles: + +* Decide how a PEP is approved (or rejected or deferred). +* Grant or revoke permissions to a Python team. For example, allow + a team to give the bug triage permission (on the team component) to a + contributor. + +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"): + 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. + +The board 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 +------------------------------------ + +A board member cannot be a PEP delegate. + +A board 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 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, 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 +============================= + +The workgroup's purpose is to foster a diverse and inclusive Python +community by enforcing the PSF code of conduct, along with providing +guidance and recommendations to the Python community on codes of +conduct, that supports the PSF mission of “ongoing development of +Python-related technology and educational resources”. + +We work toward this common goal in three ways: + +* Review, revise, and advise on policies relating to the PSF code of + conducts and other communities that the PSF supports. This includes + any #python chat community & python.org email list under PSF + jurisdiction. +* Create a standard set of codes of conduct and supporting documents for + multiple channels of interaction such as, but not limited to, + conferences, mailing lists, slack/IRC, code repositories, and more. +* Develop training materials and other processes to support Python + community organizers in implementing and enforcing the code of + conduct. + +The organization of this workgroup is defined by the +`ConductWG Charter `_. + + +Annex: Examples of Python Teams +=============================== + +Below are examples of some Python teams (the list will not be kept up to +date in this PEP). + +Packaging team +-------------- + +The packaging team runs its own PEP category and can approve (or reject) +their own PEPs. + +* Website: `packaging.python.org `_ +* Mailing list: `distutils-sig + `_ +* Bug tracker component: ``Distutils`` +* Example of members: Paul Moore, Nick Coghlan, Donald Stuff +* Stdlib module: ``distutils`` +* Current PEP delegate: Paul Moore + +IDLE team +--------- + +IDLE is a special case in the Python standard library: it's a whole +application, not just a module. For this reason, it has been decided +that the code will be the same in all Python stable branches (whereas +the stdlib diverges in newer stable branches). + +* Bug tracker component: ``IDLE`` +* Example of members: Terry Reedy, Cheryl Sabella, Serhiy Storchaka +* Stdlib module: ``idlelib`` + +Mentorship team +--------------- + +Becoming a core developer is long and slow process. Mentorship an an +efficient way to train contributors as future core developers and build +a trust relationship. + +* Websites: + + * https://www.python.org/dev/core-mentorship/ + * https://devguide.python.org/ + +* Repository: https://github.com/python/devguide +* Mailing list: `core-mentorship + `_ (private archives) +* Example of members: Guido van Rossum, Carol Willing, Victor Stinner + +Note: The group is not responsible to promote core developers. + +Documentation team +------------------ + +* Mailing list: `doc-sig + `_ +* Bug tracker component: ``Documentation`` +* GitHub tag: ``type-doc`` + +The team also manages documentation translations. + +See also the Mentorship team which maintains the "Devguide". + +Security team +------------- + +* Website: https://www.python.org/news/security/ +* Mailing lists: + + * ``security@python.org`` (to report vulnerabilities) + * `security-sig + `_ + (public list) + +* Stdlib modules: ``hashlib``, ``secrets`` and ``ssl`` +* Example of members: Christian Heimes, Benjamin Peterson + +The ``security@python.org`` mailing list is invite-only: only members of +the "Python Security Response Team" (PSRT) can read emails and reply; +whereas security-sig is public. + +Note: This team rarely proposed PEPs. + +Performance team +---------------- + +* Website: https://speed.python.org/ +* Mailing list: `speed + `_ +* Repositories: + + * https://github.com/python/performance + * https://github.com/tobami/codespeed + +* Bug tracker type: ``Performance`` +* GitHub label: ``type-performance`` +* Stdlib module: ``cProfile``, ``profile``, ``pstats`` and ``timeit`` +* Example of members: Victor Stinner, INADA Naoki, Serhiy Storchaka + +Usually PEPs involving performance impact everybody and so are discussed +on the python-dev mailing list, rather than the speed mailing list. + +Asynchronous programming team +----------------------------- + +* Website: https://docs.python.org/dev/library/asyncio.html +* Mailing list: `async-sig + `_ +* Bug tracker component: ``asyncio`` +* GitHub label: ``expert-asyncio`` +* Stdlib modules: ``asyncio`` and ``contextvars`` +* Example of members: Andrew Sveltov, Yury Selivanov + +PEP only modifying ``asyncio`` and ``contextvars`` can be discussed on +the async-sig mailing list, whereas changes impacting the Python +language must be discussed on python-dev.