python-peps/pep-8015.rst

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. To avoid
self-censorship, the vote uses secret ballots: avoid the risk of
hostility from someone who may get more power (if they get elected).
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 5: Election of Python Steering Committee Members uses secret
  ballots
* 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.