Mailman 3 November 2018 - python-committers

PEP 8015: Organization of the Python community
by Victor Stinner 15 Nov '18

15 Nov '18

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: * 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(a)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(a)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.

3 9

IMPORTANT: Missing Email Addresses for Governance Election Voter Roll
by Donald Stufft 14 Nov '18

14 Nov '18

We need a list of core developers email addresses to send ballot emails to. Since PEP 8001 states that we’re using inclusion in the ``python-core`` team on GitHub as the list of “registered voters”, I wrote up a quick script that compiled a list of GitHub usernames in that team *today* and any public email address on their GitHub profile if there is one. That is located at https://github.com/python/voters <https://github.com/python/voters> (specifically the 2018-11-16-governance-election.csv file), which is a private repository. Please everyone take a moment to find your GitHub username in that file (it’s in alphabetical order) and ensure that the email address there is a good email for you to send your ballot to. If it’s wrong or missing, update the CSV file (there is a .voters.csv file that will taken into effect for any future voter rolls we may generate from this script). If you’re not a member of the python-core team on Github and you want to participate in the vote, please ask to be added to that team, then add yourself to the 2018-11-16-governance-election.csv file. We particularly need the following people (GitHub usernames) to go fill in their email addresses, as we do not currently have an email address for them, and without an email address, we cannot send you a ballot. - [ ] @abalkin - [ ] @akuchling - [ ] @aleaxit - [ ] @amauryfa - [ ] @applio - [ ] @avassalotti - [ ] @brettcannon - [ ] @doerwalter - [ ] @doko42 - [ ] @eliben - [ ] @ericsnowcurrently - [ ] @ericvsmith - [ ] @ezio-melotti - [ ] @facundobatista - [ ] @ilevkivskyi - [ ] @jcea - [ ] @jeremyhylton - [ ] @larryhastings - [ ] @lisroach - [ ] @malemburg - [ ] @Mariatta - [ ] @markshannon - [ ] @methane - [ ] @mhammond - [ ] @nascheme - [ ] @ncoghlan - [ ] @ned-deily - [ ] @pfmoore - [ ] @pitrou - [ ] @pjenvey - [ ] @rbtcollins - [ ] @rhettinger - [ ] @sandrotosi - [ ] @serhiy-storchaka - [ ] @sjoerdmullender - [ ] @skrah - [ ] @stevendaprano - [ ] @taleinat - [ ] @vadmium - [ ] @willingc This list of people is also available on Github at https://github.com/python/voters/issues/1 <https://github.com/python/voters/issues/1> (primarily so people would get a GitHub notification as well). Thanks!

4 4

Comparison of the 7 governance PEPs
by Victor Stinner 05 Nov '18

05 Nov '18

Hi Paul, Le sam. 3 nov. 2018 à 11:55, Paul Moore <p.f.moore(a)gmail.com> a écrit : > Currently, I feel like my only option is to abstain and hope - I don't > have the time (or knowledge) to review, understand and assess the > proposals well enough to make an informed vote, but I have no way of > assessing the "expert opinions" of those who do, to allow me to make a > broad judgement. Frankly, I feel pretty disenfranchised by the process > at the moment. I wrote a comparison and summary of the 7 governance PEPs for you :-) https://discuss.python.org/t/comparison-of-the-7-governance-peps/392 WARNING: It is not always easy to extract the information and summarize it, so it’s likely that I made mistakes. Two weeks ago (October 24), Jake Edge wrote "Picking a governance model for Python" on LWN: https://lwn.net/Articles/769178/ I didn't publish the link earlier, since previously you required to have a LWN account to read it (I do!). Victor

1 0

If you care about the voting method, please vote ; -)
by Tim Peters 05 Nov '18

05 Nov '18

There's a poll about the voting method to use to decide on the winning governance PEP. We'd like to see more people weigh in: https://discuss.python.org/t/python-governance-electoral-system/290/26 PEP 8001 specifies that IRV will be used. There's pushback against that. Since a poll is a form of approval voting, there's also pushback against using a poll to vote on the voting method. But we really don't have the time to pursue infinite regress to its end ;-) I'm not in charge of anything, so take this for what it's worth: pick the option(s) that are closest to what you can live with, but add a comment to the poll if there's some aspect of what you vote for that you really can't abide (e.g., at least one person said they would vote for Approval, _except_ that they object to getting the PSF Board involved in case there's a tie). The high-order bit of this poll is about the basic approaches people can live with, not details of how problem cases are handled.

6 11

Suggestion: A PSF grant for running a "Core Dev Mentorship Program"
by Tal Einat 03 Nov '18

03 Nov '18

*tl;dr:* I’d like to apply for a PSF grant to mentor several developers towards becoming active contributors and hopefully core-devs. 1. What do you think? Any +1/-1 would be very helpful. 2. I'm looking for info on how successful mentoring has been in getting more contributors. Any such info or references would be a great help! ------------------------------------------------------------------------------- Recently there has been a recent "wave" of requests for mentoring on this list. This was triggered by Victor Stinner’s post "Looking for people from underrepresented groups to mentor" <https://mail.python.org/mm3/archives/list/core-mentorship@python.org/messag…>, who later wrote that he received 20-30 requests for mentoring <https://mail.python.org/mm3/archives/list/core-mentorship@python.org/messag…> (!). My understanding is that many of us would like to have more active contributors and core developers. Additionally, many would like these to be a more diverse group. Guido and Victor have lately taken up mentoring several developers with the explicit intent of achieving these goals. I would also like to work towards these goals. I have recently invested more time on the core-mentorship mailing list and Zulip stream, as well as doing my best to mentor two promising developers. However, my free time is becoming increasingly limited again, and I am learning that effectively mentoring a developer requires being able to spend a good amount of time nearly daily on such mentoring. My life circumstances are such that I would be able to commit to a medium-term part-time paid project. Therefore, I’ve come up with an idea for a concerted effort to mentor a group of developers for a significant length of time, which I’ve called a “Core Dev Mentorship Program”. My current suggestion is to remotely mentor five developers for 10 weeks, selecting the participants to be as diverse a group as possible among appropriate applicants. I wrote a proposal and submitted it to the PSF. They rightly asked that I first bring this before the core devs, so here I am. I can think of reasons to oppose such a project, with the foremost being that most (all?) such mentorship has thus far been done on a volunteer basis, and we wouldn’t want to negatively impact future volunteer mentorship efforts. In my eyes this project would be a complementary effort, and I propose it only because it appears that we are currently unable to mentor as many as we would like, nor as many as would like to be mentored. I am purposefully not including the details of my proposal, as I would like to first focus on whether the idea is supported in general. Any and all comments, suggestions and criticism are most welcome. ------------------------------------------------------------------------------- Note: I also posted this in the "commiters" category on <https://discuss.python.org/t/suggestion-a-psf-grant-for-running-a-core-dev-…> discuss.python.org; see additional discussion there.

4 9