On Mon, 8 Oct 2018 at 13:08, Victor Stinner <vstin...@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: ``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: > > * ``secur...@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 ``secur...@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. > _______________________________________________ > 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/ >
_______________________________________________ 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/
