PEP 8015: Organization of the Python community
Hi,
I just finished to write the PEP 8015: "Organization of the Python community". I had limited time to write it, so sorry if some parts still look "raw". Full content below. HTML version:
https://www.python.org/dev/peps/pep-8015/
Right now, the HTML page still returns me a 404 error. In the meanwhile, you can read it at:
https://github.com/python/peps/blob/master/pep-8015.rst
Summary with few quotes:
""" 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). """
"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."
Thanks to all friends who helped me to late reviews ;-)
Victor
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 <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 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 <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 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 <https://wiki.python.org/psf/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 <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:
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
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,secretsandsslExample 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:
Bug tracker type:
PerformanceGitHub label:
type-performanceStdlib module:
cProfile,profile,pstatsandtimeitExample 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:
asyncioandcontextvars - 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.
On Mon, 8 Oct 2018 at 13:08, Victor Stinner vstinner@redhat.com wrote:
Hi,
I just finished to write the PEP 8015: "Organization of the Python community". I had limited time to write it, so sorry if some parts still look "raw". Full content below. HTML version:
https://www.python.org/dev/peps/pep-8015/
Right now, the HTML page still returns me a 404 error. In the meanwhile, you can read it at:
https://github.com/python/peps/blob/master/pep-8015.rst
Summary with few quotes:
""" 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). """
"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."
Thanks to all friends who helped me to late reviews ;-)
Victor
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 <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 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
"themself" -> "themselves"
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.
How is this bootstrapped? Do I get to declare myself the "import team" and then I get to choose who joins after that?
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
" responbilities" -> "responsibilities"
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 <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 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).
Is the two-term limit forever, or just consecutively?
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.
So do the two other board members then make the decision? Or is there some third person who will step in to make up the loss of a vote (e.g. the release manager if they happen to not already be a board member)?
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 <https://wiki.python.org/psf/ConductWG/Charter>_.
Is this here to mean the expectation that the conduct WG will manage CoC issues for the core development team?
-Brett
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:
idlelibMentorship 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:
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-docThe team also manages documentation translations.
See also the Mentorship team which maintains the "Devguide".
Security team
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,secretsandssl- Example of members: Christian Heimes, Benjamin Peterson
The
security@python.orgmailing 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:
Bug tracker type:
PerformanceGitHub label:
type-performanceStdlib module:
cProfile,profile,pstatsandtimeitExample 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:
asyncioandcontextvars- Example of members: Andrew Sveltov, Yury Selivanov
PEP only modifying
asyncioandcontextvarscan be discussed on the async-sig mailing list, whereas changes impacting the Python language must be discussed on python-dev.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Le ven. 12 oct. 2018 à 20:33, Brett Cannon brett@python.org a écrit :
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.
How is this bootstrapped? Do I get to declare myself the "import team" and then I get to choose who joins after that?
I don't want to formalize the Python community too much. I don't think that it's needed to have a process to create a group. It seems like in the past, some people started to talk about a topic a litlte bit off-topic for a list, then someone proposed to create a SIG. A mailing list have been created. That's it. Sometimes, the list dies after a few messages. Sometimes, the list becomes very popular.
Contributors are free to organize and group themselves, but the need the board to make concrete changes in Python: merge changes, accept PEPs, etc.
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).
Is the two-term limit forever, or just consecutively?
I propose forever. In your life, you can be a board member for 6 years. It's designed to rotate frequently. So it's very different of the previous organization using a single BDFL for life :-)
To boot 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.
So do the two other board members then make the decision? Or is there some third person who will step in to make up the loss of a vote (e.g. the release manager if they happen to not already be a board member)?
Yes, the two other members have to decide how a PEP is decided. These two people are free to ask the opinion or support of anyone help :-) Again, I don't think that it's neeed to formalize too much here.
The organization of this workgroup is defined by the
ConductWG Charter <https://wiki.python.org/psf/ConductWG/Charter>_.Is this here to mean the expectation that the conduct WG will manage CoC issues for the core development team?
I don't want to put this responsibility on the board. So yes, conflicts between core developers will be handled by the conduct WG. By the way, technically, I think that it's fine if a board member is also part of the conduct WG. But they would have to behave and communicate differently when having the "board hat" or the "conduct WG hat".
But I'm open to other propositions how to handle such conflict :-)
Victor
Le 15/10/2018 à 10:30, Victor Stinner a écrit :
The organization of this workgroup is defined by the
ConductWG Charter <https://wiki.python.org/psf/ConductWG/Charter>_.Is this here to mean the expectation that the conduct WG will manage CoC issues for the core development team?
I don't want to put this responsibility on the board. So yes, conflicts between core developers will be handled by the conduct WG.
How does that work? The conduct WG doesn't even seem to have published procedures. Also we cannot expect them to follow the history of interpersonal interactions in Python core development.
But I'm open to other propositions how to handle such conflict :-)
If something is required, I would suggest some kind of ethical committee that would be comprised of core developers. I would also suggest their mission to focus on appeasement rather than punishment.
Regards
Antoine.
Le lun. 15 oct. 2018 à 11:35, Antoine Pitrou antoine@python.org a écrit :
I don't want to put this responsibility on the board. So yes, conflicts between core developers will be handled by the conduct WG.
How does that work? The conduct WG doesn't even seem to have published procedures. Also we cannot expect them to follow the history of interpersonal interactions in Python core development.
https://wiki.python.org/psf/ConductWG/Charter contains many information.
But I'm open to other propositions how to handle such conflict :-)
If something is required, I would suggest some kind of ethical committee that would be comprised of core developers. I would also suggest their mission to focus on appeasement rather than punishment.
"punishment" Oh, you seem to have a very bad opinion about the conduct WG :-( Why do you have a so bad opinion? I don't think that the goal of the conduct WG is to punish.
I don't know if they already published transparency reports, but I'm quite sure that removing messages or ban someone is the least common option and only taken for the worst incidents. I'm quite sure that many issues are handled in private with people involved in the incident and that no punishment action has been taken.
... That's just guesses, I don't know much about this conduct group :-) It seems to be one of your concern, the lack of transparency?
I'm not sure how creating a *new* group would be way better: more fair and more transparent?
I like the idea of having a group which is external to the core developer group, since I expect them to be more "fair". For example, if an "important"/"popular" core dev misbehaves, it may be more difficult for other core developers to take any action. If the group handling CoC incidents is external, I expect them to handle incidents the same way for everyone.
For example, when Guido was the BDFL, if you imagine that BDFL misbehaved, who would stand up against Guido? Maybe this example is too hypothetical. Better examples can be found in the Linux community, their BDFL Linus Torvalds is known to have strong words on the mailing list: https://www.newyorker.com/science/elements/after-years-of-abusive-e-mails-th...
I'm not interested here to discuss if Linus behaviour was appropriate or not. I'm just asking about the process: who is supposed to discuss with Linus about his behaviour? Replace "Linus" with any other famous/popular Linux developer. And why no action has been taken to reduce the toxicity of the Linux mailing list when Sage Sharp wrote a blog post explaining clearly that the Linux community has issues? https://sage.thesharps.us/2015/10/05/closing-a-door/
I'm using the example of Linux because multiple events are well documented, the situation is getting better, and in the past, there were many blocker issues to handle "Code of Conflict" incidents. Moreover, it's easier to criticize a community different than ours community :-) Our community is perfect, right? :-)
Victor
Le 15/10/2018 à 12:00, Victor Stinner a écrit :
Le lun. 15 oct. 2018 à 11:35, Antoine Pitrou antoine@python.org a écrit :
I don't want to put this responsibility on the board. So yes, conflicts between core developers will be handled by the conduct WG.
How does that work? The conduct WG doesn't even seem to have published procedures. Also we cannot expect them to follow the history of interpersonal interactions in Python core development.
https://wiki.python.org/psf/ConductWG/Charter contains many information.
That information doesn't seem to include resolving conflicts. It advises on policies, creates a set of standard documents, and develops training materials.
My understanding is that the WG is not meant to handle conflicts by itself. Rather, it gives guidance to other bodies on how to handle conflicts. So we would have to have our own body for handling conflicts, such as an ethical committee.
... That's just guesses, I don't know much about this conduct group :-) It seems to be one of your concern, the lack of transparency?
That, and the fact they're outside the loop of core development, and don't know anything about the usual social / power dynamics here. They also don't have the time to devote that a professional magistrate would have.
Replace "Linus" with any other famous/popular Linux developer. And why no action has been taken to reduce the toxicity of the Linux mailing list when Sage Sharp wrote a blog post explaining clearly that the Linux community has issues?
But do you think an external WG would have had the authority to deal with the problem? People did criticize Linus' behaviour, even amongst kernel developers. But there wasn't any solution exercisable from the outside. You couldn't just displace Linus and put someone else in power, because that wouldn't have been accepted by the broader community.
Only a recognized body formed by the community itself could be legitimate enough to take action. Which suggests to me that the CoC WG can be a source of advice and suggestions, not take decisions by itself.
Regards
Antoine.
Hi Brett,
I just updated my PEP to take in account your comments.
Le ven. 12 oct. 2018 à 20:33, Brett Cannon brett@python.org a écrit :
Team members are Python contributors and Python core developers. The team is responsible to select who can join the team and how.
How is this bootstrapped? Do I get to declare myself the "import team" and then I get to choose who joins after that?
I added the first paragraph and added "self-organized" in the second:
""" 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. """
https://www.python.org/dev/peps/pep-8015/#python-teams
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).
Is the two-term limit forever, or just consecutively?
I clarified the limit of 2 mandates:
""" 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. """
https://www.python.org/dev/peps/pep-8015/#election-of-python-steering-commit...
Does it look better to you? If not, would you mind to propose something?
Victor
Brett:
Is this here to mean the expectation that the conduct WG will manage CoC issues for the core development team?
Core developers and Steering Committee members are at the same level than any other Python contributor when they misbehave. I expect the "autonomous" conduct workgroup to handle CoC issues from all Python contributors.
I added a "Special Case: Ban a core developer" section which has a direct relationship between the Code of Conduct and the core developer status. Extract:
"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."
https://www.python.org/dev/peps/pep-8015/#special-case-ban-a-core-developer
It is also a consequence of this notice:
"Core developers are also expected to be exemplary when it comes to the Code of Conduct."
https://www.python.org/dev/peps/pep-8015/#python-core-developers
Victor
Hi,
To take in account all discussions around my PEP 8015, I updated it: it’s now the version 4. I added a Version History at the bottom of the PEP to help reviewers. In short: votes are now announced in advance (0, 1 or 3 weeks depending on the vote) and only open for 1 week instead of 1 month, the “Python (Core) Board” has been renamed to “Python Steering Committee” to clarify its role.
https://www.python.org/dev/peps/pep-8015/
Discussion on Discourse: https://discuss.python.org/t/pep-8015-organization-of-the-python-community/1...
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.
Victor
Hi,
Since October 8, we had many productive discussions on governance PEPs and I made multiple changes to my PEP 8015. See the "Version History" at the end. The latest (I hope the *last*) change is that the Steering Committee is now made of 5 people instead of 3, there are no term limits (instead of a limit of 2 mandates: 6 years in total), and a committee member can now be a PEP delegate. Full text below.
HTML version: https://www.python.org/dev/peps/pep-8015/
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 5 members which has limited roles: basically decide how decisions are taken, but don't take decisions.
PEPs are approved by a PEP delegate or by a vote (reserved to core
developers, need >= 2/3 majority).
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 BDFL organization to the new Steering Committee 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, most decisions have been taken by the Benevolent Dictator For Life (BDFL), Guido van Rossum. 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, see the PEP process_ section below for the voting
method.
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.
- 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 more 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. The more involved in a team you are, the more decisions power and responsibilities you get.
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, but also (and this is more important) what changes should not be made. 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 merges a change, they become responsible for regressions and for the maintenance of that modified code.
Core developers are 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 two thirds (>= 2/3) of
votes approve ("+1") the promotion. Only "+1" and "-1" votes are
accounted; other votes (ex: null, "-0", "+0.5") 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.
The Python Steering Committee is composed of 5 members. They are elected for 3 years and 1/3 is replaced every year (first year: 1, second year: 2, third year: 2). This way, a member will stay for one full Python release and the committee composition will be updated frequently. A committee member can be a candidate for the seat they are leaving. There are no term limits.
Committee members must be Python core developers. 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 only 2 members (strictly less than 50% of the 5 members) can work for the same employer (same company or subsidiaries of the same company).
The size of 5 members has been chosen for the members diversity and to ensure that the committee can continue to work even if a member becomes unavailable for an unknown duration.
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 committee select the PEP delegate who can be proposed by the Python team where the PEP is discussed.
- The committee can organize a vote on on the PEP, see
PEP process_ for the vote organization. The committee decides when the vote is organized. A vote is preferred for changes affecting all Python users, like language changes.
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.
Election of Python Steering Committee Members
The vote is organized by the Steering Committee. It 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 Schulze/Beatpath/CSSD variant <https://en.wikipedia.org/wiki/Schulze_method>_ of the Condorcet method <https://en.wikipedia.org/wiki/Condorcet_method>_ using an
online service like Condorcet Internet Voting Service (CIVS) <https://civs.cs.cornell.edu/>_. This voting method reduces the risk of
tie. It also produces a ranking of all candidates, needed for the
creation of the committee.
In case of tie, a new vote is organized immediately between candidates involved in the tie using the same voting method and also during 1 week. If the second vote leads to a tie again, the current Steering Committee is responsible to select the elected member(s).
If a committee member steps down, a new vote is organized to replace them.
If the situation of a committee member changes in a way that no longer satisfies the committee constraint (ex: they move to the same company as two other committee members), they have to resign. If the employer of a member is acquired by the employer of two other members, the member with the mandate ending earlier has to resign once the acquisition completes.
Election Creating the Python Steering Committee Members
To bootstrap the process, 5 members are elected at the committee creation. The vote follows the same rules than regular committee votes, except that the election needs 5 members, and the vote is organized by the PSF Board.
In a council election, if 3 of the top 5 vote-getters work for the same employer, then whichever of them ranked lowest is disqualified and the 6th-ranking candidate moves up into 5th place; this is repeated until a valid council is formed.
In case of tie, a second vote is organized immediately between candidates involved in the tie and following candidates to fill the remaining seats. The vote follows the same rules as the regular committee vote. If the second vote still result in a tie, the PSF Board is responsible to elect members and decide their position in the vote result.
The order in the vote result must be unique for elected members: #1 and #2 are elected for 3 years, #2 and #3 for 2 years, and #5 for 1 year.
Example of vote result with a tie:
- A
- B
- C
- D
- E, F
- G
- ...
The first 4 candidates (A, B, C and D) are elected immediately. If E works for the same employer than two other elected member, F is also elected. Otherwise, a second vote is organized for the 5th seat between E and F.
Special Case: Steering Committee Members And PEPs
A committee member can be a PEP delegate.
A committee member can propose a PEP, but cannot be the PEP delegate of their own PEP.
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 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. Core developers are expected to be exemplary when it comes to the Code of Conduct.
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 motivate 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 public, 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 two thirds (>= 2/3) of votes approve
("+1") the PEP. Only "+1" and "-1" votes are accounted; other votes
(ex: null, "-0", "+0.5") are ignored.
A PEP can only be approved or rejected by a vote, not be deferred.
Lack of Decision
If a discussion fails to reach a consensus, if the Python Steering Committee fail to choose a PEP delegate, 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.
Change 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, specify how to handle corner cases and fix mistakes.
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 four fifths (>= 4/5) of votes approve
("+1") the change. Only "+1" and "-1" votes are accounted; other votes
(ex: null, "-0", "+0.5") are ignored.
Annex: Summary on votes
====================== ======= ====== =======
Vote Notice Open Ballot Method ====================== ======= ====== =======
Promote contributor none 1 week public >= 2/3 majority
PEP 1 week 1 week public >= 2/3 majority
Change this PEP 3 weeks 1 week public >= 4/5 majority
Steering Committee 3 weeks 1 week private Condorcet
(Schulze/Beatpath/CSSD)
====================== ======= ====== =======
All these votes are reserved to core developers.
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 is an efficient way to train contributors as future core developers and build a trust relationship.
Websites:
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 - Example of members: Julien Palard, INADA Naoki, Raymond Hettinger.
The team also manages documentation translations.
See also the Mentorship team which maintains the "Devguide".
Security Team
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,secretsandsslExample 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:
Bug tracker type:
PerformanceGitHub label:
type-performanceStdlib module:
cProfile,profile,pstatsandtimeitExample 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:
asyncioandcontextvars - 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, Mark Shannon.
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 7: Adjust the Steering Committee
- The Steering Committee is now made of 5 people instead of 3.
- There are no term limits (instead of a limit of 2 mandates: 6 years in total).
- A committee member can now be a PEP delegate.
Version 6: Adjust votes
- Specify the Condorcet method: use Schulze/Beatpath/CSSD variant to elect Python Steering Committee members. Specify how to deal with tie and the constraint on the employers.
- Vote on promoting a contributor and on PEPs now requires
>= 2/3rather than50%+1. - Vote on changing this PEP now requires
>= 4/5rather than50%+1. - Explain how to deal with a company acquisition.
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.
participants (3)
-
Antoine Pitrou -
Brett Cannon -
Victor Stinner