529 lines
19 KiB
ReStructuredText
529 lines
19 KiB
ReStructuredText
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 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".
|
|
|
|
|
|
Rationale
|
|
=========
|
|
|
|
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.
|
|
|
|
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
|
|
any individual down.
|
|
|
|
To keep most of the decision power within the hands of the community,
|
|
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.
|
|
|
|
The most sensitives PEPs are decided by democracy: a vote reserved to
|
|
core developers, a PEP is only approved if the number of "+1" exceed the
|
|
number of "-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
|
|
<https://www.python.org/psf/codeofconduct/>`_ 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 Steering Committee 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 on
|
|
the Python bug tracker, proposes or reviews a Python change, they become
|
|
a Python contributor.
|
|
|
|
|
|
Python Teams
|
|
============
|
|
|
|
Python became too big to work as an unique team anymore, people
|
|
naturally have grouped themselves as teams to work more closely on
|
|
specific topics, sometimes called "Special Interest Group" (SIG).
|
|
|
|
When enough developers are interested by a specific topic, they can
|
|
create a new team. Usually, the main action is to ask the Python
|
|
postmaster to create a new "SIG" mailing list, but the team can choose
|
|
to use a different communication channel.
|
|
|
|
Team members are Python contributors and Python core developers. The
|
|
team is self-organized and 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
|
|
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.
|
|
|
|
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 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 or longer.
|
|
|
|
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.
|
|
|
|
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 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
|
|
promoted, a new vote can be organized later, when the candidate gets the
|
|
missing skills, for example 6 months later.
|
|
|
|
|
|
Python Steering Committee
|
|
=========================
|
|
|
|
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.
|
|
|
|
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
|
|
committee composition will be updated frequently.
|
|
|
|
Election of Python Steering Committee Members
|
|
---------------------------------------------
|
|
|
|
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.
|
|
|
|
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 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 committee
|
|
creation. The first members will stay for 1, 2 or 3 years (3 years for
|
|
the candidate ranked at the first position, 1 year for the candidate
|
|
ranked at the third position).
|
|
|
|
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 Steering Committee 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
|
|
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 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 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 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: Steering Committee Members And PEPs
|
|
-------------------------------------------------
|
|
|
|
A committee member cannot be a PEP delegate.
|
|
|
|
A committee member can offer a PEP, but cannot decide how their own PEP
|
|
is approved. In this case, the two other board members are responsible
|
|
to decide how the PEP is approved.
|
|
|
|
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
|
|
=============================
|
|
|
|
Charter
|
|
-------
|
|
|
|
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 <https://wiki.python.org/psf/ConductWG/Charter>`_.
|
|
|
|
Special Case: Ban a core developer
|
|
----------------------------------
|
|
|
|
As any other member of the Python community, the PSF Code of Conduct
|
|
Workgroup can ban a core developer for a limited amount of time. In this
|
|
case, the core developer immediately loses their core developer status.
|
|
|
|
In general, a ban is only the last resort action when all other options
|
|
have been exhausted.
|
|
|
|
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
|
|
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
|
|
======================
|
|
|
|
The first version of this PEP has been written after Guido van Rossum
|
|
decided to resign from his role of BDFL in July 2018. Before this PEP,
|
|
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.
|
|
|
|
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
|
|
===============================
|
|
|
|
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 <https://packaging.python.org/>`_
|
|
* Mailing list: `distutils-sig
|
|
<https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/>`_
|
|
* 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
|
|
<https://www.python.org/dev/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
|
|
<https://mail.python.org/mailman/listinfo/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
|
|
<https://mail.python.org/mm3/mailman3/lists/security-sig.python.org/>`_
|
|
(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
|
|
<https://mail.python.org/mm3/mailman3/lists/speed.python.org/>`_
|
|
* 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
|
|
<https://mail.python.org/mailman/listinfo/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.
|
|
|
|
Type Hints team
|
|
---------------
|
|
|
|
* Website: http://mypy-lang.org/
|
|
* Repository: https://github.com/python/typing
|
|
* GitHub label for mypy project: `topic-pep-484
|
|
<https://github.com/python/mypy/labels/topic-pep-484>`_
|
|
* Stdlib modules: ``typing``
|
|
* Example of members: Guido van Rossum, Ivan Levkivskyi,
|
|
Jukka Lehtosalo, Łukasz Langa
|
|
|
|
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.
|