From doug at doughellmann.com Mon Oct 1 08:18:40 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 1 Oct 2018 08:18:40 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <958DA9C9-923A-46D1-AAA4-355EE400C0E5@doughellmann.com> > On Sep 28, 2018, at 5:45 PM, ?ukasz Langa wrote: > > Signed PGP part > Hello committers, > since this got pretty long, here's the tl;dr: > > - we're at the point where it is hard to make mailing lists work for us; > - we're switching to Discourse; it's better in many ways; > - go to https://discuss.python.org/ and create your account there; > - please do not post to python-committers for the remainder of the year to give Discourse a real shot. The site shows up blank for me in Safari. Which browsers are supported? Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP URL: From doug at doughellmann.com Mon Oct 1 08:26:21 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 1 Oct 2018 08:26:21 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <958DA9C9-923A-46D1-AAA4-355EE400C0E5@doughellmann.com> References: <958DA9C9-923A-46D1-AAA4-355EE400C0E5@doughellmann.com> Message-ID: <2F7CFCCC-9D5B-4CB0-84BD-D747CC7F9F8F@doughellmann.com> > On Oct 1, 2018, at 8:18 AM, Doug Hellmann wrote: > > Signed PGP part > > >> On Sep 28, 2018, at 5:45 PM, ?ukasz Langa > wrote: >> >> Signed PGP part >> Hello committers, >> since this got pretty long, here's the tl;dr: >> >> - we're at the point where it is hard to make mailing lists work for us; >> - we're switching to Discourse; it's better in many ways; >> - go to https://discuss.python.org/ and create your account there; >> - please do not post to python-committers for the remainder of the year to give Discourse a real shot. > > The site shows up blank for me in Safari. > > Which browsers are supported? Nevermind, it appears related to the javascript popup-blocking setting. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP URL: From chris.jerdonek at gmail.com Wed Oct 3 06:06:24 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Wed, 3 Oct 2018 03:06:24 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <5A2CA85B-277B-40DD-9EA5-09F5480200B6@langa.pl> References: <5A2CA85B-277B-40DD-9EA5-09F5480200B6@langa.pl> Message-ID: On Fri, Sep 28, 2018 at 4:47 PM ?ukasz Langa wrote: > On 28 Sep 2018, at 23:55, Chris Jerdonek wrote: > > I hope this thread about transitioning is exempt from this call to action! > :) > > This e-mail is specifically re-posted on Discourse so you can discuss it > there, too :-) > Hi ?ukasz, I tried signing up three days ago, but it doesn't look like I've been approved yet (e.g. I'm not listed in the members list). I notice some other people have been approved during this time based on the group count. I tried emailing you privately about this a couple days ago, too. Thanks for any help, --Chris - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From berker.peksag at gmail.com Wed Oct 3 06:44:14 2018 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Wed, 3 Oct 2018 13:44:14 +0300 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <5A2CA85B-277B-40DD-9EA5-09F5480200B6@langa.pl> Message-ID: On Wed, Oct 3, 2018 at 1:06 PM Chris Jerdonek wrote: > Hi ?ukasz, I tried signing up three days ago, but it doesn't look like I've been approved yet (e.g. I'm not listed in the members list). I notice some other people have been approved during this time based on the group count. I tried emailing you privately about this a couple days ago, too. Hi Chris, I've just added you to the group. --Berker From chris.jerdonek at gmail.com Wed Oct 3 06:48:31 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Wed, 3 Oct 2018 03:48:31 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <5A2CA85B-277B-40DD-9EA5-09F5480200B6@langa.pl> Message-ID: Great, thank you! --Chris On Wed, Oct 3, 2018 at 3:44 AM Berker Peksa? wrote: > On Wed, Oct 3, 2018 at 1:06 PM Chris Jerdonek > wrote: > > Hi ?ukasz, I tried signing up three days ago, but it doesn't look like > I've been approved yet (e.g. I'm not listed in the members list). I notice > some other people have been approved during this time based on the group > count. I tried emailing you privately about this a couple days ago, too. > > Hi Chris, > > I've just added you to the group. > > --Berker > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Thu Oct 4 09:02:58 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 4 Oct 2018 15:02:58 +0200 Subject: [python-committers] Please wait for my governance PEP Message-ID: Hi, I was waiting for other governance PEPs to decide if I would write mine or not. Since I don't see other PEPs, I decided that I will write mine. Please give me between one and three weeks to write it. Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if this mailing list should be used or not. Victor From lukasz at langa.pl Thu Oct 4 09:18:49 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Thu, 4 Oct 2018 15:18:49 +0200 Subject: [python-committers] Please wait for my governance PEP In-Reply-To: References: Message-ID: <4BC2EE69-10AF-4D82-A274-9D4CFA6B51E2@langa.pl> There are already three published PEPs: - PEP 8012: discussion on https://discuss.python.org/t/pep-8012-the-community-model/156/5 - PEP 8013: some discussion here - PEP 8014: no discussion yet I expect PEP 8010 and PEP 8011 to be done by the deadline which was extended to October 8. You are free to write your own PEP but you might save significant effort and time by looking at the existing ones and teaming up with one of them. You can reach out to Mariatta or Barry to learn how far along they are. I know I'd be very happy to have you help with PEP 8012 :-) -- Best regards, ?ukasz Langa > On Oct 4, 2018, at 15:02, Victor Stinner wrote: > > Hi, > > I was waiting for other governance PEPs to decide if I would write > mine or not. Since I don't see other PEPs, I decided that I will write > mine. Please give me between one and three weeks to write it. > > Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if > this mailing list should be used or not. > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Thu Oct 4 11:56:15 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 4 Oct 2018 17:56:15 +0200 Subject: [python-committers] Please wait for my governance PEP In-Reply-To: <4BC2EE69-10AF-4D82-A274-9D4CFA6B51E2@langa.pl> References: <4BC2EE69-10AF-4D82-A274-9D4CFA6B51E2@langa.pl> Message-ID: Oh. Things changed since one week, I will have a look. Victor Le jeu. 4 oct. 2018 ? 15:18, ?ukasz Langa a ?crit : > > There are already three published PEPs: > - PEP 8012: discussion on https://discuss.python.org/t/pep-8012-the-community-model/156/5 > - PEP 8013: some discussion here > - PEP 8014: no discussion yet > > I expect PEP 8010 and PEP 8011 to be done by the deadline which was extended to October 8. You are free to write your own PEP but you might save significant effort and time by looking at the existing ones and teaming up with one of them. You can reach out to Mariatta or Barry to learn how far along they are. > > I know I'd be very happy to have you help with PEP 8012 :-) > > -- > Best regards, > ?ukasz Langa > > > On Oct 4, 2018, at 15:02, Victor Stinner wrote: > > Hi, > > I was waiting for other governance PEPs to decide if I would write > mine or not. Since I don't see other PEPs, I decided that I will write > mine. Please give me between one and three weeks to write it. > > Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if > this mailing list should be used or not. > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From barry at python.org Thu Oct 4 16:05:41 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 4 Oct 2018 13:05:41 -0700 Subject: [python-committers] Please wait for my governance PEP In-Reply-To: <4BC2EE69-10AF-4D82-A274-9D4CFA6B51E2@langa.pl> References: <4BC2EE69-10AF-4D82-A274-9D4CFA6B51E2@langa.pl> Message-ID: <87048732-2249-4E50-838F-0D8D48B72452@python.org> I am planning on finishing up 8010 tomorrow and doing a check in of the initial draft. Happy to have collaborators! -Barry > On Oct 4, 2018, at 06:18, ?ukasz Langa wrote: > > There are already three published PEPs: > - PEP 8012: discussion on https://discuss.python.org/t/pep-8012-the-community-model/156/5 > - PEP 8013: some discussion here > - PEP 8014: no discussion yet > > I expect PEP 8010 and PEP 8011 to be done by the deadline which was extended to October 8. You are free to write your own PEP but you might save significant effort and time by looking at the existing ones and teaming up with one of them. You can reach out to Mariatta or Barry to learn how far along they are. > > I know I'd be very happy to have you help with PEP 8012 :-) > > -- > Best regards, > ?ukasz Langa > > > On Oct 4, 2018, at 15:02, Victor Stinner wrote: > >> Hi, >> >> I was waiting for other governance PEPs to decide if I would write >> mine or not. Since I don't see other PEPs, I decided that I will write >> mine. Please give me between one and three weeks to write it. >> >> Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if >> this mailing list should be used or not. >> >> Victor >> _______________________________________________ >> python-committers mailing list >> python-committers at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From nad at python.org Sun Oct 7 01:34:19 2018 From: nad at python.org (Ned Deily) Date: Sun, 7 Oct 2018 01:34:19 -0400 Subject: [python-committers] 3.7.1 and 3.6.7 Release Update Message-ID: [duplicated from https://discuss.python.org/c/committers] We issued the 3.7.1rc1 and 3.6.7rc1 release candidates a little over 11 days ago with the plan to have final releases for each available by today, assuming no new issues arose since the rc1 cutoffs. While the good news is that, to the best of my knowledge, no regressions have been reported for the release candidates (or remain unfixed), several critical and security-related issues have identified during the rc phase. Most of these have already been addressed (thanks for the quick responses!) but there remain a couple that still need to be finalized. Since there is a non-zero amount of fixes going in after rc1, I think we need to do another set of release candidates once everything is resolved. Because a number of core developers are right now attending various Python-related events, I am going to aim for tagging 3.7.1rc2 and 3.6.7rc2 after 2018-10-09 23:59 AoE, if at all possible, with final releases targeted for about 10 days later. I will send out an update as we approach that time. Just a reminder to core developers: as always please try to get fixes merged in to all relevant branches as soon as you feel they are ready. There is no need to hold off during a release candidate phase. Release managers will cherry pick as necessary appropriate fixes from the release branches into subsequent release candidates or final releases. The sooner changes are merged, the sooner they will get buildbot exposure and potential exposure in the wider community. Thanks! -- Ned Deily nad at python.org -- [] From vstinner at redhat.com Mon Oct 8 16:07:38 2018 From: vstinner at redhat.com (Victor Stinner) Date: Mon, 8 Oct 2018 22:07:38 +0200 Subject: [python-committers] PEP 8015: Organization of the Python community Message-ID: 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 `_ 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 `_. 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 `_. 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 `_ * Mailing list: `distutils-sig `_ * 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 `_ (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 `_ * 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 at python.org`` (to report vulnerabilities) * `security-sig `_ (public list) * Stdlib modules: ``hashlib``, ``secrets`` and ``ssl`` * Example of members: Christian Heimes, Benjamin Peterson The ``security at 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 `_ * 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 `_ * 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. From vstinner at redhat.com Mon Oct 8 16:22:54 2018 From: vstinner at redhat.com (Victor Stinner) Date: Mon, 8 Oct 2018 22:22:54 +0200 Subject: [python-committers] Please wait for my governance PEP In-Reply-To: References: Message-ID: I published my PEP as the PEP 8015: Organization of the Python community. Victor Le jeu. 4 oct. 2018 ? 15:02, Victor Stinner a ?crit : > > Hi, > > I was waiting for other governance PEPs to decide if I would write > mine or not. Since I don't see other PEPs, I decided that I will write > mine. Please give me between one and three weeks to write it. > > Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if > this mailing list should be used or not. > > Victor From vstinner at redhat.com Mon Oct 8 16:44:22 2018 From: vstinner at redhat.com (Victor Stinner) Date: Mon, 8 Oct 2018 22:44:22 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: I saw some complains against Discourse (some people prefer emails, some people didn't the bad timing with discussions on the new governance, etc.), but I'm not sure about the conclusion. Where should we discuss governance PEPs? Since it was unclear to me, I posted me PEP 8015 to discuss.python.org and to python-committers... And now we can enjoy discussions splitted between the two :-) Victor Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : > > On 29.09.2018 03:21, Barry Warsaw wrote: > > On Sep 28, 2018, at 15:03, Victor Stinner wrote: > > > >> It seems like anyone can subscribe. Is the Committer group reserved to > >> core developers? If yes, how do you know which accounts are linked to > >> core developers? > > > > You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? > > I hope it does, since otherwise python-committers is not only moving > to discourse, but also losing its functionality as forum for > core developers. We'd just have another python-dev or python-ideas > forum. > > I've never used Discourse. Does it allow to subscribe in a way that > I can still get emails for the discussions or is it browser only ? > > If the latter, then I'm pretty much out of the game, since I live > in email and cannot have 10 browser tabs open and regularly check > these just to keep up with everything. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Sep 29 2018) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From mal at egenix.com Mon Oct 8 21:29:13 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 8 Oct 2018 21:29:13 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: FYI: I did sign up on Discourse and have enabled email notifications, but it seems that you have to do this on a per forum entry basis, since I have not received any notifications for the newer entries (only ones for the ones which were already available at the time I subscribed). Is there a way to get notifications for all new topics as well ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ On 08.10.2018 16:44, Victor Stinner wrote: > I saw some complains against Discourse (some people prefer emails, > some people didn't the bad timing with discussions on the new > governance, etc.), but I'm not sure about the conclusion. Where should > we discuss governance PEPs? Since it was unclear to me, I posted me > PEP 8015 to discuss.python.org and to python-committers... And now we > can enjoy discussions splitted between the two :-) > > Victor > Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : >> >> On 29.09.2018 03:21, Barry Warsaw wrote: >>> On Sep 28, 2018, at 15:03, Victor Stinner wrote: >>> >>>> It seems like anyone can subscribe. Is the Committer group reserved to >>>> core developers? If yes, how do you know which accounts are linked to >>>> core developers? >>> >>> You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? >> >> I hope it does, since otherwise python-committers is not only moving >> to discourse, but also losing its functionality as forum for >> core developers. We'd just have another python-dev or python-ideas >> forum. >> >> I've never used Discourse. Does it allow to subscribe in a way that >> I can still get emails for the discussions or is it browser only ? >> >> If the latter, then I'm pretty much out of the game, since I live >> in email and cannot have 10 browser tabs open and regularly check >> these just to keep up with everything. >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts (#1, Sep 29 2018) >>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >> ________________________________________________________________________ >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> http://www.malemburg.com/ >> >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ From mal at egenix.com Tue Oct 9 08:12:54 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 9 Oct 2018 08:12:54 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <2A61F224-1D06-4451-AD63-163B63AE2420@mac.com> References: <2A61F224-1D06-4451-AD63-163B63AE2420@mac.com> Message-ID: <894bf8a5-be8d-473e-3f36-161b0879e1d6@egenix.com> On 09.10.2018 05:33, Ronald Oussoren wrote: > > >> On 9 Oct 2018, at 03:29, M.-A. Lemburg wrote: >> >> FYI: I did sign up on Discourse and have enabled email notifications, >> but it seems that you have to do this on a per forum entry basis, >> since I have not received any notifications for the newer entries >> (only ones for the ones which were already available at the time >> I subscribed). >> >> Is there a way to get notifications for all new topics as well ? > > I turned on mailing list mode and appear to get mail for new topics as well. I have this turned on as well, but don't get those emails. Perhaps there's some other setting I'm missing. Thanks. >> Thanks, >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts >>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >> ________________________________________________________________________ >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> http://www.malemburg.com/ >> >> >> On 08.10.2018 16:44, Victor Stinner wrote: >>> I saw some complains against Discourse (some people prefer emails, >>> some people didn't the bad timing with discussions on the new >>> governance, etc.), but I'm not sure about the conclusion. Where should >>> we discuss governance PEPs? Since it was unclear to me, I posted me >>> PEP 8015 to discuss.python.org and to python-committers... And now we >>> can enjoy discussions splitted between the two :-) >>> >>> Victor >>> Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : >>>> >>>> On 29.09.2018 03:21, Barry Warsaw wrote: >>>>> On Sep 28, 2018, at 15:03, Victor Stinner wrote: >>>>> >>>>>> It seems like anyone can subscribe. Is the Committer group reserved to >>>>>> core developers? If yes, how do you know which accounts are linked to >>>>>> core developers? >>>>> >>>>> You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? >>>> >>>> I hope it does, since otherwise python-committers is not only moving >>>> to discourse, but also losing its functionality as forum for >>>> core developers. We'd just have another python-dev or python-ideas >>>> forum. >>>> >>>> I've never used Discourse. Does it allow to subscribe in a way that >>>> I can still get emails for the discussions or is it browser only ? >>>> >>>> If the latter, then I'm pretty much out of the game, since I live >>>> in email and cannot have 10 browser tabs open and regularly check >>>> these just to keep up with everything. >>>> >>>> -- >>>> Marc-Andre Lemburg >>>> eGenix.com >>>> >>>> Professional Python Services directly from the Experts (#1, Sep 29 2018) >>>>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >>>> ________________________________________________________________________ >>>> >>>> ::: We implement business ideas - efficiently in both time and costs ::: >>>> >>>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>>> http://www.egenix.com/company/contact/ >>>> http://www.malemburg.com/ >>>> >>>> _______________________________________________ >>>> python-committers mailing list >>>> python-committers at 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 at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From donald at stufft.io Tue Oct 9 08:24:39 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 9 Oct 2018 08:24:39 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <2ACB4737-4276-4FA1-87AD-6BCF816BE49A@stufft.io> On a specific category page, in the top right you can select a watch level for the whole category, the two relevant ones for you will be either ?Watching? which will default all new topics in a category to watching or ?first post?, which won?t set them to watching, but will email you for *only* the first post in any new topic, unless you set a topic to watching after that. > On Oct 8, 2018, at 9:29 PM, M.-A. Lemburg wrote: > > FYI: I did sign up on Discourse and have enabled email notifications, > but it seems that you have to do this on a per forum entry basis, > since I have not received any notifications for the newer entries > (only ones for the ones which were already available at the time > I subscribed). > > Is there a way to get notifications for all new topics as well ? > > Thanks, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts >>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>> Python Database Interfaces ... http://products.egenix.com/ >>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > > On 08.10.2018 16:44, Victor Stinner wrote: >> I saw some complains against Discourse (some people prefer emails, >> some people didn't the bad timing with discussions on the new >> governance, etc.), but I'm not sure about the conclusion. Where should >> we discuss governance PEPs? Since it was unclear to me, I posted me >> PEP 8015 to discuss.python.org and to python-committers... And now we >> can enjoy discussions splitted between the two :-) >> >> Victor >> Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : >>> >>> On 29.09.2018 03:21, Barry Warsaw wrote: >>>> On Sep 28, 2018, at 15:03, Victor Stinner wrote: >>>> >>>>> It seems like anyone can subscribe. Is the Committer group reserved to >>>>> core developers? If yes, how do you know which accounts are linked to >>>>> core developers? >>>> >>>> You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? >>> >>> I hope it does, since otherwise python-committers is not only moving >>> to discourse, but also losing its functionality as forum for >>> core developers. We'd just have another python-dev or python-ideas >>> forum. >>> >>> I've never used Discourse. Does it allow to subscribe in a way that >>> I can still get emails for the discussions or is it browser only ? >>> >>> If the latter, then I'm pretty much out of the game, since I live >>> in email and cannot have 10 browser tabs open and regularly check >>> these just to keep up with everything. >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Experts (#1, Sep 29 2018) >>>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >>> ________________________________________________________________________ >>> >>> ::: We implement business ideas - efficiently in both time and costs ::: >>> >>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>> http://www.egenix.com/company/contact/ >>> http://www.malemburg.com/ >>> >>> _______________________________________________ >>> python-committers mailing list >>> python-committers at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From antoine at python.org Tue Oct 9 08:26:12 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 9 Oct 2018 14:26:12 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <2ACB4737-4276-4FA1-87AD-6BCF816BE49A@stufft.io> References: <2ACB4737-4276-4FA1-87AD-6BCF816BE49A@stufft.io> Message-ID: Thank you! I hadn't noticed this setting and it will be helpful. Regards Antoine. Le 09/10/2018 ? 14:24, Donald Stufft a ?crit?: > On a specific category page, in the top right you can select a watch level for the whole category, the two relevant ones for you will be either ?Watching? which will default all new topics in a category to watching or ?first post?, which won?t set them to watching, but will email you for *only* the first post in any new topic, unless you set a topic to watching after that. > >> On Oct 8, 2018, at 9:29 PM, M.-A. Lemburg wrote: >> >> FYI: I did sign up on Discourse and have enabled email notifications, >> but it seems that you have to do this on a per forum entry basis, >> since I have not received any notifications for the newer entries >> (only ones for the ones which were already available at the time >> I subscribed). >> >> Is there a way to get notifications for all new topics as well ? >> >> Thanks, >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts >>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >> ________________________________________________________________________ >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> http://www.malemburg.com/ >> >> >> On 08.10.2018 16:44, Victor Stinner wrote: >>> I saw some complains against Discourse (some people prefer emails, >>> some people didn't the bad timing with discussions on the new >>> governance, etc.), but I'm not sure about the conclusion. Where should >>> we discuss governance PEPs? Since it was unclear to me, I posted me >>> PEP 8015 to discuss.python.org and to python-committers... And now we >>> can enjoy discussions splitted between the two :-) >>> >>> Victor >>> Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : >>>> >>>> On 29.09.2018 03:21, Barry Warsaw wrote: >>>>> On Sep 28, 2018, at 15:03, Victor Stinner wrote: >>>>> >>>>>> It seems like anyone can subscribe. Is the Committer group reserved to >>>>>> core developers? If yes, how do you know which accounts are linked to >>>>>> core developers? >>>>> >>>>> You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? >>>> >>>> I hope it does, since otherwise python-committers is not only moving >>>> to discourse, but also losing its functionality as forum for >>>> core developers. We'd just have another python-dev or python-ideas >>>> forum. >>>> >>>> I've never used Discourse. Does it allow to subscribe in a way that >>>> I can still get emails for the discussions or is it browser only ? >>>> >>>> If the latter, then I'm pretty much out of the game, since I live >>>> in email and cannot have 10 browser tabs open and regularly check >>>> these just to keep up with everything. >>>> >>>> -- >>>> Marc-Andre Lemburg >>>> eGenix.com >>>> >>>> Professional Python Services directly from the Experts (#1, Sep 29 2018) >>>>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >>>> ________________________________________________________________________ >>>> >>>> ::: We implement business ideas - efficiently in both time and costs ::: >>>> >>>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>>> http://www.egenix.com/company/contact/ >>>> http://www.malemburg.com/ >>>> >>>> _______________________________________________ >>>> python-committers mailing list >>>> python-committers at 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 at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > From mal at egenix.com Tue Oct 9 08:30:22 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 9 Oct 2018 08:30:22 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <2ACB4737-4276-4FA1-87AD-6BCF816BE49A@stufft.io> References: <2ACB4737-4276-4FA1-87AD-6BCF816BE49A@stufft.io> Message-ID: <66270d9a-1a9e-6970-7096-c98cad98d14c@egenix.com> On 09.10.2018 08:24, Donald Stufft wrote: > On a specific category page, in the top right you can select a watch level for the whole category, the two relevant ones for you will be either ?Watching? which will default all new topics in a category to watching or ?first post?, which won?t set them to watching, but will email you for *only* the first post in any new topic, unless you set a topic to watching after that. Thanks, I'll give that a try. >> On Oct 8, 2018, at 9:29 PM, M.-A. Lemburg wrote: >> >> FYI: I did sign up on Discourse and have enabled email notifications, >> but it seems that you have to do this on a per forum entry basis, >> since I have not received any notifications for the newer entries >> (only ones for the ones which were already available at the time >> I subscribed). >> >> Is there a way to get notifications for all new topics as well ? >> >> Thanks, >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts >>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >> ________________________________________________________________________ >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> http://www.malemburg.com/ >> >> >> On 08.10.2018 16:44, Victor Stinner wrote: >>> I saw some complains against Discourse (some people prefer emails, >>> some people didn't the bad timing with discussions on the new >>> governance, etc.), but I'm not sure about the conclusion. Where should >>> we discuss governance PEPs? Since it was unclear to me, I posted me >>> PEP 8015 to discuss.python.org and to python-committers... And now we >>> can enjoy discussions splitted between the two :-) >>> >>> Victor >>> Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : >>>> >>>> On 29.09.2018 03:21, Barry Warsaw wrote: >>>>> On Sep 28, 2018, at 15:03, Victor Stinner wrote: >>>>> >>>>>> It seems like anyone can subscribe. Is the Committer group reserved to >>>>>> core developers? If yes, how do you know which accounts are linked to >>>>>> core developers? >>>>> >>>>> You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? >>>> >>>> I hope it does, since otherwise python-committers is not only moving >>>> to discourse, but also losing its functionality as forum for >>>> core developers. We'd just have another python-dev or python-ideas >>>> forum. >>>> >>>> I've never used Discourse. Does it allow to subscribe in a way that >>>> I can still get emails for the discussions or is it browser only ? >>>> >>>> If the latter, then I'm pretty much out of the game, since I live >>>> in email and cannot have 10 browser tabs open and regularly check >>>> these just to keep up with everything. >>>> >>>> -- >>>> Marc-Andre Lemburg >>>> eGenix.com >>>> >>>> Professional Python Services directly from the Experts (#1, Sep 29 2018) >>>>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >>>> ________________________________________________________________________ >>>> >>>> ::: We implement business ideas - efficiently in both time and costs ::: >>>> >>>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>>> http://www.egenix.com/company/contact/ >>>> http://www.malemburg.com/ >>>> >>>> _______________________________________________ >>>> python-committers mailing list >>>> python-committers at 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 at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From donald at stufft.io Tue Oct 9 08:31:38 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 9 Oct 2018 08:31:38 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <66270d9a-1a9e-6970-7096-c98cad98d14c@egenix.com> References: <2ACB4737-4276-4FA1-87AD-6BCF816BE49A@stufft.io> <66270d9a-1a9e-6970-7096-c98cad98d14c@egenix.com> Message-ID: <899C1083-21E5-4AAA-AB8E-6570527E47BC@stufft.io> > On Oct 9, 2018, at 8:30 AM, M.-A. Lemburg wrote: > > On 09.10.2018 08:24, Donald Stufft wrote: >> On a specific category page, in the top right you can select a watch level for the whole category, the two relevant ones for you will be either ?Watching? which will default all new topics in a category to watching or ?first post?, which won?t set them to watching, but will email you for *only* the first post in any new topic, unless you set a topic to watching after that. > > Thanks, I'll give that a try. > One thing to clarify? Changing that setting will only apply to *new* topics in that category. It basically lets you set a category specific default for the notification level of new topics. Once the topic has been created that setting has no effect which allows you to adjust your notification level on a per topic basis after the fact. If for instance you default to watching, but a noisy thread happens you don?t care about, you can just unwatch that particular thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackdied at gmail.com Tue Oct 9 23:20:08 2018 From: jackdied at gmail.com (Jack Diederich) Date: Tue, 9 Oct 2018 23:20:08 -0400 Subject: [python-committers] discuss.python.org participation Message-ID: I'm worried about the new format combined with governance discussions. As best I can tell 51 CPython committers have signed up for an account [I think that is a big number, btw] but only 17 have posted anything; That 17 is about 5 more people than put their name on a governance PEP. And maybe 5 people have half the total posts. This does not feel like a discussion at all. I don't think it was deliberate, but it looks like the new format is actively discouraging everyone but those most deeply invested with the most free time from participating. -Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at fdrake.net Wed Oct 10 00:21:38 2018 From: fred at fdrake.net (Fred Drake) Date: Wed, 10 Oct 2018 00:21:38 -0400 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: On Tue, Oct 9, 2018 at 11:25 PM Jack Diederich wrote: > I'm worried about the new format combined with governance discussions. > As best I can tell 51 CPython committers have signed up for an account > [I think that is a big number, btw] but only 17 have posted anything; That > 17 is about 5 more people than put their name on a governance PEP. > And maybe 5 people have half the total posts. This does not feel like a > discussion at all. It can (reasonably) take months for a small-ish group to migrate to a new type of forum; large groups take longer. > I don't think it was deliberate, but it looks like the new format is actively discouraging everyone but those most deeply invested with the most free time from participating. I doubt anyone intended to cut anyone out of discussions, but a new medium at this time just wasn't a good idea. It also didn't seem to work well when I first tried to sign up (the round-trip email never came through; yes, I checked my spam-box). Things like this make uptake even slower. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein From ronaldoussoren at mac.com Tue Oct 9 05:33:58 2018 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 09 Oct 2018 11:33:58 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <2A61F224-1D06-4451-AD63-163B63AE2420@mac.com> > On 9 Oct 2018, at 03:29, M.-A. Lemburg wrote: > > FYI: I did sign up on Discourse and have enabled email notifications, > but it seems that you have to do this on a per forum entry basis, > since I have not received any notifications for the newer entries > (only ones for the ones which were already available at the time > I subscribed). > > Is there a way to get notifications for all new topics as well ? I turned on mailing list mode and appear to get mail for new topics as well. Ronald > > Thanks, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts >>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>> Python Database Interfaces ... http://products.egenix.com/ >>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > > On 08.10.2018 16:44, Victor Stinner wrote: >> I saw some complains against Discourse (some people prefer emails, >> some people didn't the bad timing with discussions on the new >> governance, etc.), but I'm not sure about the conclusion. Where should >> we discuss governance PEPs? Since it was unclear to me, I posted me >> PEP 8015 to discuss.python.org and to python-committers... And now we >> can enjoy discussions splitted between the two :-) >> >> Victor >> Le sam. 29 sept. 2018 ? 09:50, M.-A. Lemburg a ?crit : >>> >>> On 29.09.2018 03:21, Barry Warsaw wrote: >>>> On Sep 28, 2018, at 15:03, Victor Stinner wrote: >>>> >>>>> It seems like anyone can subscribe. Is the Committer group reserved to >>>>> core developers? If yes, how do you know which accounts are linked to >>>>> core developers? >>>> >>>> You must be approved to join python-committers, but its archive is public for anyone to read. Does Discourse provide the same level of access for core developers and non-core developers? >>> >>> I hope it does, since otherwise python-committers is not only moving >>> to discourse, but also losing its functionality as forum for >>> core developers. We'd just have another python-dev or python-ideas >>> forum. >>> >>> I've never used Discourse. Does it allow to subscribe in a way that >>> I can still get emails for the discussions or is it browser only ? >>> >>> If the latter, then I'm pretty much out of the game, since I live >>> in email and cannot have 10 browser tabs open and regularly check >>> these just to keep up with everything. >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Experts (#1, Sep 29 2018) >>>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>>>> Python Database Interfaces ... http://products.egenix.com/ >>>>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >>> ________________________________________________________________________ >>> >>> ::: We implement business ideas - efficiently in both time and costs ::: >>> >>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>> http://www.egenix.com/company/contact/ >>> http://www.malemburg.com/ >>> >>> _______________________________________________ >>> python-committers mailing list >>> python-committers at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.png Type: image/png Size: 247154 bytes Desc: not available URL: From stefan at bytereef.org Wed Oct 10 18:57:34 2018 From: stefan at bytereef.org (Stefan Krah) Date: Thu, 11 Oct 2018 00:57:34 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: <20181010225734.GA7772@bytereef.org> On Tue, Oct 09, 2018 at 11:20:08PM -0400, Jack Diederich wrote: > I don't think it was deliberate, but it looks like the new format is > actively discouraging everyone but those most deeply invested with the most > free time from participating. I'm actively discouraged by various visual effects on the Discourse site. Fade-in, progress spinner, moving elements when scrolling, long load times. There are recurrent discussions about attracting developers. As far as C developers are concerned, I doubt that this forum is going to attract any. Stefan Krah From greg at krypto.org Thu Oct 11 01:33:41 2018 From: greg at krypto.org (Gregory P. Smith) Date: Wed, 10 Oct 2018 22:33:41 -0700 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: On Tue, Oct 9, 2018 at 8:24 PM Jack Diederich wrote: > I'm worried about the new format combined with governance discussions. As > best I can tell 51 CPython committers have signed up for an account [I > think that is a big number, btw] but only 17 have posted anything; That 17 > is about 5 more people than put their name on a governance PEP. And maybe 5 > people have half the total posts. This does not feel like a discussion at > all. > I'm not participating in discussions on them because I have limited bandwidth. I'm waiting to be told we're ready to read PEPs and how to cast votes. ie: exactly the same way I behave with mailing lists. -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Thu Oct 11 04:10:10 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 11 Oct 2018 10:10:10 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> <7EE20D66-C7AC-4051-8F5B-4588CA2D182D@me.com> <9da87c2c-ac2e-8997-f705-1b50074d5136@egenix.com> Message-ID: Le jeu. 27 sept. 2018 ? 01:28, Mariatta Wijaya a ?crit : > Really sorry folks, but I also would like to request an extension, by one week to Oct 8. The PEP 8000 lists 5 governance PEPs: """ PEPs in the 8010s describe the actual proposals for Python governance. It is expected that these PEPs will cover the broad scope of governance, and that differences in details (such as the size of a governing council) will be covered in the same PEP, rather than in potentially vote-splitting individual PEPs. * PEP 8010 - The BDFL Governance Model This is a placeholder PEP for the continuation of the `Benevolent Dictator For Life `_ model. The name is an homage to Guido's title and does not necessarily imply that the next BDFL will be required to serve without time limit. Also within scope is whether an advisory council aids or supports the BDFL. This PEP does *not* name either the next BDFL, nor members of such an advisory council. For that, see PEP 13. * PEP 8011 - Python Governance Model Lead by Trio of Pythonistas This PEP describes a new model of Python governance lead by a Trio of Pythonistas (TOP). It describes the role and responsibilities of the Trio. This PEP does *not* name members of the Trio. For that, see PEP 13. * PEP 8012 - The Community Governance Model This is a placeholder PEP for a new model of Python governance based on consensus and voting, without the role of a centralized singular leader or a governing council. It describes how, when, and why votes are conducted for decisions affecting the Python language. It also describes the criteria for voting eligibility. * PEP 8013 - The External Governance Model This PEP describes a new model of Python governance based on an external council who are responsible for ensuring good process. Elected by the core development team, this council may reject proposals that are not sufficiently detailed, do not consider all affected users, or are not appropriate for the upcoming release. This PEP does *not* name members of such a council. For that, see PEP 13. * PEP 8014 - The Commons Governance Model This PEP describes a new model of Python governance based on a council of elders who are responsible for ensuring a PEP is supported by a sufficient majority of the Python community before being accepted. Unlike some of the other governance PEPs it explicitly does *not* specify who has voting rights and what a majority vote consists of. In stead this is determined by the council of elders on a case by case basis. * PEP 8015 - Organization of the Python community 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). """ The PEP 8000 still says "Additional governance models may be added before the final selection.": are we still expecting new governance PEPs? Or should we remove this sentence? In clear, does anyone want to write a new governance PEP? Victor From vstinner at redhat.com Thu Oct 11 04:11:16 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 11 Oct 2018 10:11:16 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> <7EE20D66-C7AC-4051-8F5B-4588CA2D182D@me.com> <9da87c2c-ac2e-8997-f705-1b50074d5136@egenix.com> Message-ID: > The PEP 8000 lists 5 governance PEPs: Oops, there are even 6 governance PEPs :-) Victor From antoine at python.org Thu Oct 11 04:30:01 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 11 Oct 2018 10:30:01 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: What concerns me is that there are several long-time and/or prominent developers who are not even registered (*) on discuss.python.org. For example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan Krah, Terry Reedy. I would be worried if a decision is taken without them. (*) https://discuss.python.org/u Regards Antoine. Le 10/10/2018 ? 05:20, Jack Diederich a ?crit?: > I'm worried about the new format combined with governance discussions. > As best I can tell 51 CPython committers have signed up for an account > [I think that is a big number, btw] but only 17 have posted anything; > That 17 is about 5 more people than put their name on a governance PEP. > And maybe 5 people have half the total posts. This does not feel like a > discussion at all. > > I don't think it was deliberate, but it looks like the new format is > actively discouraging everyone but those most deeply invested with the > most free time from participating.? > > -Jack > > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > From vstinner at redhat.com Thu Oct 11 04:40:10 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 11 Oct 2018 10:40:10 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: Le jeu. 11 oct. 2018 ? 10:30, Antoine Pitrou a ?crit : > What concerns me is that there are several long-time and/or prominent > developers who are not even registered (*) on discuss.python.org. For > example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan > Krah, Terry Reedy. > > I would be worried if a decision is taken without them. > > (*) https://discuss.python.org/u Well, the PEP 8001 which explains how we will take a decision is still empty :-) https://www.python.org/dev/peps/pep-8001/ Victor From tjreedy at udel.edu Thu Oct 11 18:38:03 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 11 Oct 2018 18:38:03 -0400 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: <73bc6ae1-466c-7e32-2ee0-db417627fc9f@udel.edu> On 10/11/2018 4:30 AM, Antoine Pitrou wrote: > > What concerns me is that there are several long-time and/or prominent > developers who are not even registered (*) on discuss.python.org. For > example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan > Krah, Terry Reedy. This provoked me to sign up and spend a few hours reading and practicing. It seems to mix features from github issues and StackOverflow questions. One main difference from the latter is using categories instead of tags. If I wanted an IDLE category, should I post to Discourse Feedback? Could I be made the moderator, with full powers at least for that category? tjr From lukasz at langa.pl Fri Oct 12 05:56:10 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Fri, 12 Oct 2018 11:56:10 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: <73bc6ae1-466c-7e32-2ee0-db417627fc9f@udel.edu> References: <73bc6ae1-466c-7e32-2ee0-db417627fc9f@udel.edu> Message-ID: <1DB6B4C9-C091-472D-B149-E38624818C15@langa.pl> > On 12 Oct 2018, at 00:38, Terry Reedy wrote: > > On 10/11/2018 4:30 AM, Antoine Pitrou wrote: >> What concerns me is that there are several long-time and/or prominent >> developers who are not even registered (*) on discuss.python.org. For >> example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan >> Krah, Terry Reedy. > > This provoked me to sign up and spend a few hours reading and practicing. It seems to mix features from github issues and StackOverflow questions. One main difference from the latter is using categories instead of tags. > > If I wanted an IDLE category, should I post to Discourse Feedback? Hi, Terry! Glad to see you. We are trying not to have too many top-level categories because it increases friction for first-comers. When you mentioned tags, I remembered that we can actually have those on Discourse, too. Maybe IDLE-specific topics could be tagged with "IDLE"? To show you how this works, I created a "governance" tag. You can filter the main page by tags using a dropdown next to "all categories". If you don't see it, your browser probably cached the main page, hit Refresh. By filtering on the main page, you're getting all topics on discuss.python.org which are tagged with "governance": https://discuss.python.org/tags/governance You can also filter a specific category. These are topics tagged with "governance" in "Committers": https://discuss.python.org/tags/c/committers/governance I think tags are attractive because you could have IDLE, AsyncIO, Typing, and so on. Sometimes they overlap so you could have a few tags on a single topic. And depending whether it's a Committers, Users, or an Ideas discussion, the topic would belong to the right category. What do you think, Terry? > Could I be made the moderator, with full powers at least for that category? Discourse does not currently allow per-category moderation yet. This is planned but not implemented yet: https://meta.discourse.org/t/category-specific-moderators-phase-1-rfc/21900/64 As for global moderation, our current hosted Discourse plan (that we are getting from Discourse.org for free) allows up to five staff members (admins + moderators). We'd probably want a few more so I'll talk with Ernest to maybe bump this a bit. - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brett at python.org Fri Oct 12 14:48:59 2018 From: brett at python.org (Brett Cannon) Date: Fri, 12 Oct 2018 11:48:59 -0700 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: One data point in all of this is Victor's PEP 8015. Here on the mailing list I seem to be the first and only person to reply since the PEP was posted on Monday. But over on Discourse there have been 3 people who have replied and there's already been some back-and-forth. So with a sample size of one, it looks like Discourse isn't discouraging anyone, otherwise I would have assumed people who don't want to start with Discourse would have simply started a discussion here on the mailing list about Victor's PEP. On Tue, 9 Oct 2018 at 20:24, Jack Diederich wrote: > I'm worried about the new format combined with governance discussions. As > best I can tell 51 CPython committers have signed up for an account [I > think that is a big number, btw] but only 17 have posted anything; That 17 > is about 5 more people than put their name on a governance PEP. And maybe 5 > people have half the total posts. This does not feel like a discussion at > all. > > I don't think it was deliberate, but it looks like the new format is > actively discouraging everyone but those most deeply invested with the most > free time from participating. > > -Jack > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Oct 12 14:55:32 2018 From: brett at python.org (Brett Cannon) Date: Fri, 12 Oct 2018 11:55:32 -0700 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: On Thu, 11 Oct 2018 at 01:30, Antoine Pitrou wrote: > > What concerns me is that there are several long-time and/or prominent > developers who are not even registered (*) on discuss.python.org. For > example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan > Krah, Terry Reedy. > I believe Larry is currently busy so he might simply have not taken the time (and will be occupied into I believe November). I will also note that Benjamin, Larry, and Raymond can be a bit quiet at times and so they may not have signed up yet because they have not had anything to say to compel them to create accounts (Stefan has already stated he doesn't like this idea so I'm assuming that might be why he has not signed up yet). -Brett > > I would be worried if a decision is taken without them. > > (*) https://discuss.python.org/u > > Regards > > Antoine. > > > > Le 10/10/2018 ? 05:20, Jack Diederich a ?crit : > > I'm worried about the new format combined with governance discussions. > > As best I can tell 51 CPython committers have signed up for an account > > [I think that is a big number, btw] but only 17 have posted anything; > > That 17 is about 5 more people than put their name on a governance PEP. > > And maybe 5 people have half the total posts. This does not feel like a > > discussion at all. > > > > I don't think it was deliberate, but it looks like the new format is > > actively discouraging everyone but those most deeply invested with the > > most free time from participating. > > > > -Jack > > > > > > _______________________________________________ > > python-committers mailing list > > python-committers at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Fri Oct 12 15:35:54 2018 From: stefan at bytereef.org (Stefan Krah) Date: Fri, 12 Oct 2018 21:35:54 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: <20181012193554.GA12845@bytereef.org> On Fri, Oct 12, 2018 at 11:55:32AM -0700, Brett Cannon wrote: > I will also note that Benjamin, Larry, and Raymond can be a bit quiet at > times and so they may not have signed up yet because they have not had > anything to say to compel them to create accounts (Stefan has already > stated he doesn't like this idea so I'm assuming that might be why he has > not signed up yet). FTR, I have signed up, but Jack's original point still stands. Very few people apart from PEP stakeholders are participating, so merely signing up should not be considered an endorsement of Discourse. Even participating shouldn't, because folks might choose their battles, especially in a pre-election situation. In order to get an overview if I'm the only one: I've searched for people's opinions on Discourse, and its reputation is far from spotless even among people who explicitly *want* a web forum. Stefan Krah From doug at doughellmann.com Fri Oct 12 16:03:15 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 12 Oct 2018 16:03:15 -0400 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: Brett Cannon writes: > One data point in all of this is Victor's PEP 8015. Here on the mailing > list I seem to be the first and only person to reply since the PEP was > posted on Monday. But over on Discourse there have been 3 people who have > replied and there's already been some back-and-forth. > > So with a sample size of one, it looks like Discourse isn't discouraging > anyone, otherwise I would have assumed people who don't want to start with > Discourse would have simply started a discussion here on the mailing list > about Victor's PEP. I don't think it is safe to interpret the current level of engagement there as a definitive endorsement of the tool. I believed this discussion was *supposed* to be happening over there and *not* on the mailing list (the initial messages about it were worded very strongly). If others who want to have a say in the future governance of the project had the same impression, then I would expect them to sign up and use Discourse regardless of their opinion of the tool. I don't dislike Discourse, but I would have rather used the mailing list for the governance discussion and used some other, less critical, topic as a trigger for experimenting with a new tool. If the trouble with the mailing lists is moderation, then some other list that requires more moderation work would have been a good candidate. > > On Tue, 9 Oct 2018 at 20:24, Jack Diederich wrote: > >> I'm worried about the new format combined with governance discussions. As >> best I can tell 51 CPython committers have signed up for an account [I >> think that is a big number, btw] but only 17 have posted anything; That 17 >> is about 5 more people than put their name on a governance PEP. And maybe 5 >> people have half the total posts. This does not feel like a discussion at >> all. >> >> I don't think it was deliberate, but it looks like the new format is >> actively discouraging everyone but those most deeply invested with the most >> free time from participating. >> >> -Jack >> _______________________________________________ >> python-committers mailing list >> python-committers at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From brett at python.org Fri Oct 12 14:33:07 2018 From: brett at python.org (Brett Cannon) Date: Fri, 12 Oct 2018 11:33:07 -0700 Subject: [python-committers] PEP 8015: Organization of the Python community In-Reply-To: References: Message-ID: On Mon, 8 Oct 2018 at 13:08, Victor Stinner 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 > `_ 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 `_. 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 `_. > 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 `_ > * Mailing list: `distutils-sig > `_ > * 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 > `_ (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 > `_ > * 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 at python.org`` (to report vulnerabilities) > * `security-sig > >`_ > (public list) > > * Stdlib modules: ``hashlib``, ``secrets`` and ``ssl`` > * Example of members: Christian Heimes, Benjamin Peterson > > The ``security at 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 > `_ > * 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 > `_ > * 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Sat Oct 13 17:40:00 2018 From: nad at python.org (Ned Deily) Date: Sat, 13 Oct 2018 17:40:00 -0400 Subject: [python-committers] [RELEASE] Python 3.7.1rc2 and 3.6.7rc2 now available for testing Message-ID: <65B2DFC8-F64D-4E48-B33F-9AE88BC440F4@python.org> Python 3.7.1rc2 and 3.6.7rc2 are now available. 3.7.1rc2 is a release preview of the first maintenance release of Python 3.7, the latest feature release of Python. 3.6.7rc2 is a release preview of the next maintenance release of Python 3.6, the previous feature release of Python. Assuming no further critical problems are found prior to 2018-10-20, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find these releases and more information here: https://www.python.org/downloads/release/python-371rc2/ https://www.python.org/downloads/release/python-367rc2/ -- Ned Deily nad at python.org -- [] From vstinner at redhat.com Mon Oct 15 04:30:30 2018 From: vstinner at redhat.com (Victor Stinner) Date: Mon, 15 Oct 2018 10:30:30 +0200 Subject: [python-committers] PEP 8015: Organization of the Python community In-Reply-To: References: Message-ID: Le ven. 12 oct. 2018 ? 20:33, Brett Cannon 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 `_. > > 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 From antoine at python.org Mon Oct 15 05:35:25 2018 From: antoine at python.org (Antoine Pitrou) Date: Mon, 15 Oct 2018 11:35:25 +0200 Subject: [python-committers] PEP 8015: Organization of the Python community In-Reply-To: References: Message-ID: Le 15/10/2018 ? 10:30, Victor Stinner a ?crit?: > >>> The organization of this workgroup is defined by the >>> `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. From vstinner at redhat.com Mon Oct 15 06:00:31 2018 From: vstinner at redhat.com (Victor Stinner) Date: Mon, 15 Oct 2018 12:00:31 +0200 Subject: [python-committers] PEP 8015: Organization of the Python community In-Reply-To: References: Message-ID: Le lun. 15 oct. 2018 ? 11:35, Antoine Pitrou 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-the-creator-of-linux-steps-aside 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 From lukasz at langa.pl Mon Oct 15 07:21:08 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Mon, 15 Oct 2018 12:21:08 +0100 Subject: [python-committers] Note: I published the first draft of PEP 8001 Message-ID: See: https://discuss.python.org/t/pep-8001-python-governance-voting-process/233 Cheers, ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From antoine at python.org Mon Oct 15 08:02:08 2018 From: antoine at python.org (Antoine Pitrou) Date: Mon, 15 Oct 2018 14:02:08 +0200 Subject: [python-committers] PEP 8015: Organization of the Python community In-Reply-To: References: Message-ID: Le 15/10/2018 ? 12:00, Victor Stinner a ?crit?: > Le lun. 15 oct. 2018 ? 11:35, Antoine Pitrou 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. From benjamin at python.org Tue Oct 16 00:22:16 2018 From: benjamin at python.org (Benjamin Peterson) Date: Mon, 15 Oct 2018 21:22:16 -0700 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> On Fri, Oct 12, 2018, at 11:55, Brett Cannon wrote: > On Thu, 11 Oct 2018 at 01:30, Antoine Pitrou wrote: > > > > > What concerns me is that there are several long-time and/or prominent > > developers who are not even registered (*) on discuss.python.org. For > > example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan > > Krah, Terry Reedy. > > > > I believe Larry is currently busy so he might simply have not taken the > time (and will be occupied into I believe November). > > I will also note that Benjamin, Larry, and Raymond can be a bit quiet at > times and so they may not have signed up yet because they have not had > anything to say to compel them to create accounts (Stefan has already > stated he doesn't like this idea so I'm assuming that might be why he has > not signed up yet). Brett is exactly right about me. I'm following along on Discourse and this mailing list when I have the time. I plan to read the governance PEPs and vote when the time comes. But, I don't have anything useful to say. At the sprint, I verbally supported ?ukasz's plans to try out Discourse. Discourse isn't perfect and may feel uncomfortable, but we're also losing potential contributors because they find mailing lists uncomfortable. From antoine at python.org Tue Oct 16 04:12:55 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 16 Oct 2018 10:12:55 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> References: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> Message-ID: Le 16/10/2018 ? 06:22, Benjamin Peterson a ?crit?: > > > On Fri, Oct 12, 2018, at 11:55, Brett Cannon wrote: >> On Thu, 11 Oct 2018 at 01:30, Antoine Pitrou wrote: >> >>> >>> What concerns me is that there are several long-time and/or prominent >>> developers who are not even registered (*) on discuss.python.org. For >>> example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan >>> Krah, Terry Reedy. >>> >> >> I believe Larry is currently busy so he might simply have not taken the >> time (and will be occupied into I believe November). >> >> I will also note that Benjamin, Larry, and Raymond can be a bit quiet at >> times and so they may not have signed up yet because they have not had >> anything to say to compel them to create accounts (Stefan has already >> stated he doesn't like this idea so I'm assuming that might be why he has >> not signed up yet). > > Brett is exactly right about me. I'm following along on Discourse and this mailing list when I have the time. I plan to read the governance PEPs and vote when the time comes. But, I don't have anything useful to say. Thank you. My worries are appeased :-) Regards Antoine. From ethan at stoneleaf.us Tue Oct 16 21:56:06 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Tue, 16 Oct 2018 18:56:06 -0700 Subject: [python-committers] discuss.python.org participation In-Reply-To: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> References: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> Message-ID: On 10/15/2018 09:22 PM, Benjamin Peterson wrote: > Brett is exactly right about me. I'm following along on Discourse and > this mailing list when I have the time. I plan to read the governance > PEPs and vote when the time comes. But, I don't have anything useful > to say. > > At the sprint, I verbally supported ?ukasz's plans to try out > Discourse. Discourse isn't perfect and may feel uncomfortable, but > we're also losing potential contributors because they find mailing > lists uncomfortable. I also supported the trial of Discourse. However, now that I have tried it, it will be a no from me. I find the presentation of threaded conversations in linear format to be confusing, figuring out what I have and have not read to be difficult, and the overall frustration to not be worth it. It definitely has some nice features, but I won't be using them because I won't be using Discourse. -- ~Ethan~ From lukasz at langa.pl Wed Oct 17 09:30:33 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 17 Oct 2018 14:30:33 +0100 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> Message-ID: <4034166C-2876-4900-8428-EF3DC4AC4B1B@langa.pl> > On Oct 17, 2018, at 02:56, Ethan Furman wrote: > > I find the presentation of threaded conversations in linear format to be confusing, figuring out what I have and have not read to be difficult, and the overall frustration to not be worth it. Are there any linear-formatted communication methods that you find more comfortable? Or is the entire idea not workable for you? Paul Moore also raised the issue you're mentioning around "figuring out what I have and have not read". Discourse is supposed to help with this with a timeline view and a "Back" button. So far the "Back" button behavior is to say the least surprising to us, if not just buggy. Some discussion here: https://discuss.python.org/t/is-this-really-better-than-a-mailing-list/57/19?u=ambv I agree we need to address this for Discourse to be a proper upgrade over mailing lists. - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Wed Oct 17 09:48:17 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 17 Oct 2018 15:48:17 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> Message-ID: Le mer. 17 oct. 2018 ? 03:56, Ethan Furman a ?crit : > I also supported the trial of Discourse. > > However, now that I have tried it, it will be a no from me. I find the > presentation of threaded conversations in linear format to be confusing, > figuring out what I have and have not read to be difficult, and the > overall frustration to not be worth it. It definitely has some nice > features, but I won't be using them because I won't be using Discourse. I don't think that we should see mailing lists and Discourse as exclusive. There is maybe a middle ground, like keep some mailing lists, but slowly migrate some specific mailing lists to Discourse? IMHO Discourse is more appropriate for python-ideas than for python-committers. python-committers is more for short discussions with few people. On python-ideas, there are more long discussions with many people who throw many new ideas in the middle of a thread. We can also imagine to have Discourse and mailing lists who coexist, even if I know that Lukasz dislikes this idea :-) Jonathan Corbet just wrote an article on LWN about Fedora and Python migrating to Discourse :-) "A farewell to email" https://lwn.net/SubscriberLink/768483/1b32a21a6e30e1b7/ Victor From stefan at bytereef.org Wed Oct 17 09:55:44 2018 From: stefan at bytereef.org (Stefan Krah) Date: Wed, 17 Oct 2018 15:55:44 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: <4034166C-2876-4900-8428-EF3DC4AC4B1B@langa.pl> References: <1539663736.726250.1543362224.2E013A2C@webmail.messagingengine.com> <4034166C-2876-4900-8428-EF3DC4AC4B1B@langa.pl> Message-ID: <20181017135544.GA6092@bytereef.org> On Wed, Oct 17, 2018 at 02:30:33PM +0100, ?ukasz Langa wrote: > > I find the presentation of threaded conversations in linear format to be confusing, figuring out what I have and have not read to be difficult, and the overall frustration to not be worth it. > > Are there any linear-formatted communication methods that you find more comfortable? For discussing a single PEP honestly I'd find even Mediawiki - not any Wiki, exactly the one used at Wikipedia! - more suitable. There'd need to be a tacit understanding that only the PEP author is allowed to edit. Discourse gets more tolerable if one disables Javascript in uBlockOrigin and adds a filter for loading pictures. But I can't login without Javascript, so it's not a great solution. Stefan Krah From vstinner at redhat.com Wed Oct 17 10:03:59 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 17 Oct 2018 16:03:59 +0200 Subject: [python-committers] Moderation of the Python community Message-ID: Hi, I see more and more discussions about the moderation of the Python community. There is a PSF "conduct" Working Group: https://wiki.python.org/psf/ConductWG/Charter I noticed the following questions: * Lack of transparency on how moderation is decided * Lack of transparency on the number of received Code of Conduct incidents: maybe start to produce "Code of Conduct transparency report"? (If such reports already exist, I'm sorry, I wasn't aware :-)) * Should the PSF conduct-WG handle conflicts between core developers? Would it be possible to write down rules to formalize the moderation? For example: * First try to contact the author of an incident and warn them? Only take an action immediately for exceptional cases like obvious spam? * Maybe define numbers for ban: 1 week, then 3 months, then 6 months, then 1 year? I would prefer to never ban someone forever. People can change. * Scope: does the moderationg apply to *any* public space? Or only to a restricted list like: mailing lists and bug tracker? What about Twitter and conferences? * Should the incidents which occur in the private space be handled as well? Bullying can occur in the private space. * How to handle conflict between core developers? Not directly related to the code of conduct. I'm not interested for work on such rules. I'm not sure neither if it's the role of the Python core developers to propose something. Maybe the PSF conduct WG should propose something, or even decide directly? Handling conflicts between core developers is the most difficult question. I don't think that it's the role of the conduct working group to handle that. Moreover, the Code of Conduct should be seen as a way to evict a core developer out of Python. The Code of Conduct is supposed to protect members of the Python community against people who misbehave. But I'm unable to describe the limit between "misbehave" and "conflict" between two developers. My main concern is that the PSF conduct WG should not be seen as a threat to core developers. Victor Note: I decided to write on python-committers mailing rather than Discourse, since all previous discussions related to moderation occurred on this list. From mail at timgolden.me.uk Wed Oct 17 10:06:32 2018 From: mail at timgolden.me.uk (Tim Golden) Date: Wed, 17 Oct 2018 15:06:32 +0100 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: On 17/10/2018 15:03, Victor Stinner wrote: > Moreover, the Code of Conduct should be seen as > a way to evict a core developer out of Python. I'm assuming you missed a "not" in that last sentence? TJG From vstinner at redhat.com Wed Oct 17 10:20:01 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 17 Oct 2018 16:20:01 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: Le mer. 17 oct. 2018 ? 16:06, Tim Golden a ?crit : > On 17/10/2018 15:03, Victor Stinner wrote: > > Moreover, the Code of Conduct should be seen as > > a way to evict a core developer out of Python. > > I'm assuming you missed a "not" in that last sentence? (Oops, I should read my emails before sending them.) Correct, the code of conduct should *NOT* be seen as a way to evict a core developer out of Python. Victor From brian at python.org Wed Oct 17 11:34:10 2018 From: brian at python.org (Brian Curtin) Date: Wed, 17 Oct 2018 09:34:10 -0600 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: On Wed, Oct 17, 2018 at 8:04 AM Victor Stinner wrote: > Hi, > > I see more and more discussions about the moderation of the Python > community. > > There is a PSF "conduct" Working Group: > https://wiki.python.org/psf/ConductWG/Charter > > I noticed the following questions: > > * Lack of transparency on how moderation is decided > * Lack of transparency on the number of received Code of Conduct > incidents: maybe start to produce "Code of Conduct transparency > report"? (If such reports already exist, I'm sorry, I wasn't aware > :-)) > * Should the PSF conduct-WG handle conflicts between core developers? > > Would it be possible to write down rules to formalize the moderation? > Yes. For any medium applying a code of conduct there should be some guidelines applicable to said medium for how things are handled. To get this out of the way early, as the author of the current CoC, it intentionally doesn't prescribe any specific moderation because it depends on how and where it's applied given the people and tools available. Moderating Discourse might be different than moderating a mailing list which is different than a bug tracker. > For example: > > * First try to contact the author of an incident and warn them? Only > take an action immediately for exceptional cases like obvious spam? > * Maybe define numbers for ban: 1 week, then 3 months, then 6 months, > then 1 year? I would prefer to never ban someone forever. People can > change. > * Scope: does the moderationg apply to *any* public space? Or only to > a restricted list like: mailing lists and bug tracker? What about > Twitter and conferences? > For conferences, there are specific codes of conduct and applicable event handling guides that go with them, and I would just leave that area alone from this angle. I don't know that we should start meddling with conferences; leave that up to organizers who are dedicated to that and in several cases have actual training on this topic. Twitter can't even moderate itself, but I don't think that makes it anyone here's job. I would scope moderation to any spaces provided by or for this group, so tracker, mailing lists, GitHub, Discourse, and I think that's it? I don't really know if IRC and Zulip are still in play. * Should the incidents which occur in the private space be handled as > well? Bullying can occur in the private space. > We can't police everything, but I think handling private issues within the space of PSF resources (or whatever the governing body of what we're talking about is) is to be expected. For example, if I harass you via a private message on Discourse, that is a situation to be handled here. It doesn't need to go to everyone's inbox for it to be a problem we need to handle. I don't know that you can moderate other private things?private in the meaning of "PSF provided or not"?though. If I send you an inappropriate email just between you and I, that's between us and our email providers. I think it might be overstepping this group's bounds for you to say I can't use the bug tracker for a month due to something I did entirely outside of the scope of said group. It feels similar to some corporate policies, where if I'm inappropriate to you when I see you at the grocery store, that's not really the company's problem, but if I'm like that at our team dinner then it is a problem. There probably does exist some threshold where out-of-scope behavior crosses to where someone isn't welcome, but I don't know that it's generally quantifiable. That's probably something for a council or triad or working group to discuss on a case-by-case basis as it's above and beyond a reasonable range of behaviors that this group can have their eye on. * How to handle conflict between core developers? Not directly related > to the code of conduct. > If it's not CoC related conflict, do you mean conflict related to code, as in technical conflict over implementation details? I think we naturally have a few mediators in this case depending on the level of where it occurs. Release managers, delegates for PEPs, code area experts, and then I think there are a few who act in such a way due to longevity with the project. If we're looking for people to be specifically identified as mediators, we have a bunch of good ones around here. I'm not interested for work on such rules. I'm not sure neither if > it's the role of the Python core developers to propose something. > Maybe the PSF conduct WG should propose something, or even decide > directly? > Is anyone from this group on said working group? If not, I don't think they should be wholesale deciding guidelines for a group they're not a part of. They would seem to be a group of people we should work with as they've presumably come up with other guidelines and could be a useful set of people to help shape things. > Handling conflicts between core developers is the most difficult > question. I don't think that it's the role of the conduct working > group to handle that. Moreover, the Code of Conduct should be seen as > a way to evict a core developer out of Python. The Code of Conduct is > supposed to protect members of the Python community against people who > misbehave. But I'm unable to describe the limit between "misbehave" > and "conflict" between two developers. > It is unfortunate that conflict?which can be a healthy thing for a team?is potentially reaching past this toward misbehavior. A lot of developers, especially those of us involved in open source, come into this type of work with strong opinions. When they're too strongly held, we can go beyond productive conflict and end with one or more of us finding ways of avoiding that topic (work on other areas), avoiding further conflict at all (only work on easier bugs), and possibly onto misbehavior, none of which are healthy for the team. I think this type of issue is better solved internally to our team, perhaps via some form of mediator(s) I mentioned earlier, rather than involving a wholly external group. Time is of course a finite resource in open source, and people work is often/usually harder than code work, but I think we do have some people around who care about the success of the project to spend time mediating these kinds of conflicts so that we keep everyone involved and solve whatever problem at hand in a satisfactory manner. My main concern is that the PSF conduct WG should not be seen as a > threat to core developers. > I don't think it should be used that way, but I also know nothing about it and have heard nothing from it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at gmail.com Wed Oct 17 11:45:19 2018 From: willingc at gmail.com (Carol Willing) Date: Wed, 17 Oct 2018 08:45:19 -0700 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: Brian, thanks for a very well written response, and Victor, thanks for asking for clarification. I think Brian has covered my thoughts very thoroughly. As an FYI, Brett, Thomas Wouters, and I are on the Code of Conduct workgroup so the core devs are represented. > On Oct 17, 2018, at 8:34 AM, Brian Curtin wrote: > > On Wed, Oct 17, 2018 at 8:04 AM Victor Stinner wrote: > Hi, > > I see more and more discussions about the moderation of the Python community. > > There is a PSF "conduct" Working Group: > https://wiki.python.org/psf/ConductWG/Charter > > I noticed the following questions: > > * Lack of transparency on how moderation is decided > * Lack of transparency on the number of received Code of Conduct > incidents: maybe start to produce "Code of Conduct transparency > report"? (If such reports already exist, I'm sorry, I wasn't aware > :-)) > * Should the PSF conduct-WG handle conflicts between core developers? > > Would it be possible to write down rules to formalize the moderation? > > Yes. For any medium applying a code of conduct there should be some guidelines applicable to said medium for how things are handled. > > To get this out of the way early, as the author of the current CoC, it intentionally doesn't prescribe any specific moderation because it depends on how and where it's applied given the people and tools available. Moderating Discourse might be different than moderating a mailing list which is different than a bug tracker. > > For example: > > * First try to contact the author of an incident and warn them? Only > take an action immediately for exceptional cases like obvious spam? > * Maybe define numbers for ban: 1 week, then 3 months, then 6 months, > then 1 year? I would prefer to never ban someone forever. People can > change. > * Scope: does the moderationg apply to *any* public space? Or only to > a restricted list like: mailing lists and bug tracker? What about > Twitter and conferences? > > For conferences, there are specific codes of conduct and applicable event handling guides that go with them, and I would just leave that area alone from this angle. I don't know that we should start meddling with conferences; leave that up to organizers who are dedicated to that and in several cases have actual training on this topic. > > Twitter can't even moderate itself, but I don't think that makes it anyone here's job. > > I would scope moderation to any spaces provided by or for this group, so tracker, mailing lists, GitHub, Discourse, and I think that's it? I don't really know if IRC and Zulip are still in play. > > * Should the incidents which occur in the private space be handled as > well? Bullying can occur in the private space. > > We can't police everything, but I think handling private issues within the space of PSF resources (or whatever the governing body of what we're talking about is) is to be expected. For example, if I harass you via a private message on Discourse, that is a situation to be handled here. It doesn't need to go to everyone's inbox for it to be a problem we need to handle. > > I don't know that you can moderate other private things?private in the meaning of "PSF provided or not"?though. If I send you an inappropriate email just between you and I, that's between us and our email providers. I think it might be overstepping this group's bounds for you to say I can't use the bug tracker for a month due to something I did entirely outside of the scope of said group. It feels similar to some corporate policies, where if I'm inappropriate to you when I see you at the grocery store, that's not really the company's problem, but if I'm like that at our team dinner then it is a problem. > > There probably does exist some threshold where out-of-scope behavior crosses to where someone isn't welcome, but I don't know that it's generally quantifiable. That's probably something for a council or triad or working group to discuss on a case-by-case basis as it's above and beyond a reasonable range of behaviors that this group can have their eye on. > > * How to handle conflict between core developers? Not directly related > to the code of conduct. > > If it's not CoC related conflict, do you mean conflict related to code, as in technical conflict over implementation details? I think we naturally have a few mediators in this case depending on the level of where it occurs. Release managers, delegates for PEPs, code area experts, and then I think there are a few who act in such a way due to longevity with the project. > > If we're looking for people to be specifically identified as mediators, we have a bunch of good ones around here. > > I'm not interested for work on such rules. I'm not sure neither if > it's the role of the Python core developers to propose something. > Maybe the PSF conduct WG should propose something, or even decide > directly? > > Is anyone from this group on said working group? If not, I don't think they should be wholesale deciding guidelines for a group they're not a part of. They would seem to be a group of people we should work with as they've presumably come up with other guidelines and could be a useful set of people to help shape things. > > Handling conflicts between core developers is the most difficult > question. I don't think that it's the role of the conduct working > group to handle that. Moreover, the Code of Conduct should be seen as > a way to evict a core developer out of Python. The Code of Conduct is > supposed to protect members of the Python community against people who > misbehave. But I'm unable to describe the limit between "misbehave" > and "conflict" between two developers. > > It is unfortunate that conflict?which can be a healthy thing for a team?is potentially reaching past this toward misbehavior. A lot of developers, especially those of us involved in open source, come into this type of work with strong opinions. When they're too strongly held, we can go beyond productive conflict and end with one or more of us finding ways of avoiding that topic (work on other areas), avoiding further conflict at all (only work on easier bugs), and possibly onto misbehavior, none of which are healthy for the team. > > I think this type of issue is better solved internally to our team, perhaps via some form of mediator(s) I mentioned earlier, rather than involving a wholly external group. Time is of course a finite resource in open source, and people work is often/usually harder than code work, but I think we do have some people around who care about the success of the project to spend time mediating these kinds of conflicts so that we keep everyone involved and solve whatever problem at hand in a satisfactory manner. > > My main concern is that the PSF conduct WG should not be seen as a > threat to core developers. > > I don't think it should be used that way, but I also know nothing about it and have heard nothing from it. > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From donald at stufft.io Wed Oct 17 14:40:51 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 17 Oct 2018 14:40:51 -0400 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: <6E7650E4-0EAA-453D-A61D-48196F2A9B3D@stufft.io> > On Oct 17, 2018, at 10:03 AM, Victor Stinner wrote: > > Handling conflicts between core developers is the most difficult > question. I don't think that it's the role of the conduct working > group to handle that. Moreover, the Code of Conduct should be seen as > a way to evict a core developer out of Python. The Code of Conduct is > supposed to protect members of the Python community against people who > misbehave. But I'm unable to describe the limit between "misbehave" > and "conflict" between two developers. I don?t think core developers are special here, the CoC and the enforcement mechanisms for it should apply to all interactions within our space equally, whether those people are core developers or not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed Oct 17 15:08:56 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 17 Oct 2018 15:08:56 -0400 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> > On Oct 17, 2018, at 11:34 AM, Brian Curtin wrote: > > I think this type of issue is better solved internally to our team, perhaps via some form of mediator(s) I mentioned earlier, rather than involving a wholly external group. Time is of course a finite resource in open source, and people work is often/usually harder than code work, but I think we do have some people around who care about the success of the project to spend time mediating these kinds of conflicts so that we keep everyone involved and solve whatever problem at hand in a satisfactory manner. > Honestly, I think an independent group managing these issues is the right way to handle them. I?m loathe to bring it up because the situation was a long time ago, and has been resolved, but I?ve personally had to engage the CoC process in regards to another core developers behavior. At the time the way that was handled was contacting the PSF board, if the process was instead to contact python-committers or something I likely would?t have done it at all. I think it is important that if someone feels they?re having a problem in a particular space, that they feel they have an impartial and independent group of people to raise those concerns with. With regards to whether the CoC can evict a core developer of Python.. I think it absolutely needs to be able to do that. Otherwise it?s basically stating that it?s fine for someone to harass someone else? as long as the person doing the harassing is a core developer. If anything, core developers should be held to a higher, not a lower standard. Obviously excommunication is not step 1 on any CoC, and such a thing would only be used after a history of repeated, on going unacceptable behavior, but if the CoC doesn?t have any teeth, than it?s not worth the metaphorical paper it?s written on. So, when it comes to the conduct we expect from people, core developers should not be treated specially in either expectations nor process. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at python.org Wed Oct 17 15:44:20 2018 From: brian at python.org (Brian Curtin) Date: Wed, 17 Oct 2018 13:44:20 -0600 Subject: [python-committers] Moderation of the Python community In-Reply-To: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: On Wed, Oct 17, 2018 at 1:09 PM Donald Stufft wrote: > > > On Oct 17, 2018, at 11:34 AM, Brian Curtin wrote: > > I think this type of issue is better solved internally to our team, > perhaps via some form of mediator(s) I mentioned earlier, rather than > involving a wholly external group. Time is of course a finite resource in > open source, and people work is often/usually harder than code work, but I > think we do have some people around who care about the success of the > project to spend time mediating these kinds of conflicts so that we keep > everyone involved and solve whatever problem at hand in a satisfactory > manner. > > > Honestly, I think an independent group managing these issues is the right > way to handle them. I?m loathe to bring it up because the situation was a > long time ago, and has been resolved, but I?ve personally had to engage the > CoC process in regards to another core developers behavior. At the time the > way that was handled was contacting the PSF board, if the process was > instead to contact python-committers or something I likely would?t have > done it at all. I think it is important that if someone feels they?re > having a problem in a particular space, that they feel they have an > impartial and independent group of people to raise those concerns with. > Especially given who I've now found out is on that working group, I'm fine with them managing issues of behavior, but we should be able to (responsible for, even) handle standard team dynamics amongst ourselves. Maybe I was/am missing something, but I got the sense that Victor was describing something like technical discussions that get heated because two sides are passionate about their stance?a common and generally reasonable thing to occur?and that was where some people might find the distinction between conflict and misbehavior blurred. To me that's still a thing we should at least start to work on amongst ourselves, as opposed to something like the issues of offensive word choice or name calling. With the former we have some things to work on smoothing out towards a common goal, and the latter we just want none of. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Wed Oct 17 16:19:44 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 17 Oct 2018 22:19:44 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: <9a9c9e56-5935-da03-6efd-437b0215de48@python.org> Le 17/10/2018 ? 21:44, Brian Curtin a ?crit?: > > Especially given who I've now found out is on that working group, I'm > fine with them managing issues of behavior, but we should be able to > (responsible for, even) handle standard team dynamics amongst ourselves. > Maybe I was/am missing something, but I got the sense that Victor was > describing something like technical discussions that get heated because > two sides are passionate about their stance?a common and generally > reasonable thing to occur?and that was where some people might find the > distinction between conflict and misbehavior blurred. To me that's still > a thing we should at least start to work on amongst ourselves, as > opposed to something like the issues of offensive word choice or name > calling. With the former we have some things to work on smoothing out > towards a common goal, and the latter we just want none of. That's how I understand Victor's message too. Conflicts between core developers that may occur because of different visions and frequent friction on topic both developers are passionate about (and perhaps conflicts of authority on a given topic). Regards Antoine. From vstinner at redhat.com Wed Oct 17 18:03:03 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 18 Oct 2018 00:03:03 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: Le mer. 17 oct. 2018 ? 21:09, Donald Stufft a ?crit : > Honestly, I think an independent group managing these issues is the right way to handle them. I?m loathe to bring it up because the situation was a long time ago, and has been resolved, but I?ve personally had to engage the CoC process in regards to another core developers behavior. At the time the way that was handled was contacting the PSF board, if the process was instead to contact python-committers or something I likely would?t have done it at all. I think it is important that if someone feels they?re having a problem in a particular space, that they feel they have an impartial and independent group of people to raise those concerns with. > > With regards to whether the CoC can evict a core developer of Python.. I think it absolutely needs to be able to do that. Otherwise it?s basically stating that it?s fine for someone to harass someone else? as long as the person doing the harassing is a core developer. If anything, core developers should be held to a higher, not a lower standard. Obviously excommunication is not step 1 on any CoC, and such a thing would only be used after a history of repeated, on going unacceptable behavior, but if the CoC doesn?t have any teeth, than it?s not worth the metaphorical paper it?s written on. > > So, when it comes to the conduct we expect from people, core developers should not be treated specially in either expectations nor process. Ok, now in the case of my PEP 8015: do you think that the "Python Core Board" should be involved in the process to evict a core developer of Python? https://www.python.org/dev/peps/pep-8015/#python-core-board For example, can we imagine that a core developer would only be evicted if the PSF conduct WG *and* the Python Core Board would agree to evict the core dev? Such situation should be very exceptional, and it may be unpopular if the conduct WG and the Python Core Board disagree :-( If the Python Core Board can block an eviction (have "a veto" on the final vote), the risk is that friends of the Board are "protected" by their friendship. And it also opens the question of an evicting a member of the Python Core Board in case of extremely severe Code of Conduct violation... But this question can be asked as well for members of the PSF conduct WG :-) I don't know the answers to my question. But maybe it would be safer for everyone that the *worst* case (evict a core dev) would be defined somewhere, as in a PEP. Victor From vstinner at redhat.com Wed Oct 17 18:05:11 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 18 Oct 2018 00:05:11 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: Oh, by the way, should we have two different choices: remove the commit bit from a core dev (downgrade a core dev as a regular contributor) and ban a core dev? Victor Le jeu. 18 oct. 2018 ? 00:03, Victor Stinner a ?crit : > > Le mer. 17 oct. 2018 ? 21:09, Donald Stufft a ?crit : > > Honestly, I think an independent group managing these issues is the right way to handle them. I?m loathe to bring it up because the situation was a long time ago, and has been resolved, but I?ve personally had to engage the CoC process in regards to another core developers behavior. At the time the way that was handled was contacting the PSF board, if the process was instead to contact python-committers or something I likely would?t have done it at all. I think it is important that if someone feels they?re having a problem in a particular space, that they feel they have an impartial and independent group of people to raise those concerns with. > > > > With regards to whether the CoC can evict a core developer of Python.. I think it absolutely needs to be able to do that. Otherwise it?s basically stating that it?s fine for someone to harass someone else? as long as the person doing the harassing is a core developer. If anything, core developers should be held to a higher, not a lower standard. Obviously excommunication is not step 1 on any CoC, and such a thing would only be used after a history of repeated, on going unacceptable behavior, but if the CoC doesn?t have any teeth, than it?s not worth the metaphorical paper it?s written on. > > > > So, when it comes to the conduct we expect from people, core developers should not be treated specially in either expectations nor process. > > Ok, now in the case of my PEP 8015: do you think that the "Python Core > Board" should be involved in the process to evict a core developer of > Python? > > https://www.python.org/dev/peps/pep-8015/#python-core-board > > For example, can we imagine that a core developer would only be > evicted if the PSF conduct WG *and* the Python Core Board would agree > to evict the core dev? Such situation should be very exceptional, and > it may be unpopular if the conduct WG and the Python Core Board > disagree :-( > > If the Python Core Board can block an eviction (have "a veto" on the > final vote), the risk is that friends of the Board are "protected" by > their friendship. And it also opens the question of an evicting a > member of the Python Core Board in case of extremely severe Code of > Conduct violation... But this question can be asked as well for > members of the PSF conduct WG :-) > > I don't know the answers to my question. But maybe it would be safer > for everyone that the *worst* case (evict a core dev) would be defined > somewhere, as in a PEP. > > Victor From alex.gaynor at gmail.com Wed Oct 17 18:06:33 2018 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 17 Oct 2018 18:06:33 -0400 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: I think you're dramatically overestimating a) the possibility that someone would attempt to use the CoC process frivolously, b) the possibility that the CoC WG would act on such a complaint without good cause. FWIW I was involved in removing a core developer from another community for CoC violations. It was fucking exhausting, and I think basically everyone involved was burned by the process. I cannot imagine anyone trying to maliciously or frivolously use such a process. Alex On Wed, Oct 17, 2018 at 6:03 PM Victor Stinner wrote: > Le mer. 17 oct. 2018 ? 21:09, Donald Stufft a ?crit : > > Honestly, I think an independent group managing these issues is the > right way to handle them. I?m loathe to bring it up because the situation > was a long time ago, and has been resolved, but I?ve personally had to > engage the CoC process in regards to another core developers behavior. At > the time the way that was handled was contacting the PSF board, if the > process was instead to contact python-committers or something I likely > would?t have done it at all. I think it is important that if someone feels > they?re having a problem in a particular space, that they feel they have an > impartial and independent group of people to raise those concerns with. > > > > With regards to whether the CoC can evict a core developer of Python.. I > think it absolutely needs to be able to do that. Otherwise it?s basically > stating that it?s fine for someone to harass someone else? as long as the > person doing the harassing is a core developer. If anything, core > developers should be held to a higher, not a lower standard. Obviously > excommunication is not step 1 on any CoC, and such a thing would only be > used after a history of repeated, on going unacceptable behavior, but if > the CoC doesn?t have any teeth, than it?s not worth the metaphorical paper > it?s written on. > > > > So, when it comes to the conduct we expect from people, core developers > should not be treated specially in either expectations nor process. > > Ok, now in the case of my PEP 8015: do you think that the "Python Core > Board" should be involved in the process to evict a core developer of > Python? > > https://www.python.org/dev/peps/pep-8015/#python-core-board > > For example, can we imagine that a core developer would only be > evicted if the PSF conduct WG *and* the Python Core Board would agree > to evict the core dev? Such situation should be very exceptional, and > it may be unpopular if the conduct WG and the Python Core Board > disagree :-( > > If the Python Core Board can block an eviction (have "a veto" on the > final vote), the risk is that friends of the Board are "protected" by > their friendship. And it also opens the question of an evicting a > member of the Python Core Board in case of extremely severe Code of > Conduct violation... But this question can be asked as well for > members of the PSF conduct WG :-) > > I don't know the answers to my question. But maybe it would be safer > for everyone that the *worst* case (evict a core dev) would be defined > somewhere, as in a PEP. > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- All that is necessary for evil to succeed is for good people to do nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Wed Oct 17 18:16:14 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 17 Oct 2018 15:16:14 -0700 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: <8a96dd3d-8482-6320-03d5-fffa3e77a5a8@stoneleaf.us> On 10/17/2018 03:05 PM, Victor Stinner wrote: > Oh, by the way, should we have two different choices: remove the > commit bit from a core dev (downgrade a core dev as a regular > contributor) and ban a core dev? No. If it comes to this, then the dev needs to be banned. I would not expect this to happen except maybe once in what's left of my lifetime. -- ~Ethan~ From lukasz at langa.pl Wed Oct 17 18:39:50 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 17 Oct 2018 23:39:50 +0100 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: <9AD4F58C-71C6-4476-9D06-EA7D9E5704D8@langa.pl> > On 17 Oct 2018, at 20:44, Brian Curtin wrote: > > To me that's still a thing we should at least start to work on amongst ourselves, as opposed to something like the issues of offensive word choice or name calling. With the former we have some things to work on smoothing out towards a common goal, and the latter we just want none of. We should all strive to be professional. The CoC is there to give everyone the ability to work toward, as you say, a common goal. While I would like to believe that we judge ideas on technical merit, since we are invested in this project, all too often we see conversations get heated. Things spill over from the technical ideas to ad hominems. I hope that we can improve discussions and moderation. If we do, then the CoC becomes infrequently used. Yet, it is important to have as a reminder and a signal to pause when things get overly heated or personal. - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From vstinner at redhat.com Wed Oct 17 19:23:13 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 18 Oct 2018 01:23:13 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: <8a96dd3d-8482-6320-03d5-fffa3e77a5a8@stoneleaf.us> References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> <8a96dd3d-8482-6320-03d5-fffa3e77a5a8@stoneleaf.us> Message-ID: Le jeu. 18 oct. 2018 ? 00:16, Ethan Furman a ?crit : > > On 10/17/2018 03:05 PM, Victor Stinner wrote: > > > Oh, by the way, should we have two different choices: remove the > > commit bit from a core dev (downgrade a core dev as a regular > > contributor) and ban a core dev? > > No. If it comes to this, then the dev needs to be banned. I would not > expect this to happen except maybe once in what's left of my lifetime. Ok. In that case, I would suggest to ban the core dev *and* drop their commit bit. I'm not sure that we want to keep a banned user as part of core developers. Extract of my PEP: "Core developers are also expected to be exemplary when it comes to the Code of Conduct." Let's say that a core dev is banned for, let's say 6 months. What happens next? Can we reconsider later to open a vote to "promote" again the developer if they proved that they changed their behaviour? Again, I'm really dislike the idea of banning someone for their own life. IMHO that would be either unfair and counter-productive. It's really difficult to find core developers, so we should remain open if people change their behaviour. Moreover, banning someone for life puts more pressure on the people who decide on the ban. It's way easier to decide to only ban someone for 1 week rather than banning someone for their own life. I proposed to start with a ban of 1 week if discussion and warnings didn't work. I suggest to drop the commit bit at the first ban (of 1 week). Again, to be consistent with "be exemplary when it comes to the Code of Conduct". Context: I would like to formalize everything in my PEP :-) https://www.python.org/dev/peps/pep-8015/ Note: I'm really not comfortable to talk about banning someone. But it seems like we all are on the same page, such case is really exceptional and will only be the very last resort if all other attempts failed. Victor From vstinner at redhat.com Wed Oct 17 19:48:05 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 18 Oct 2018 01:48:05 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> <8a96dd3d-8482-6320-03d5-fffa3e77a5a8@stoneleaf.us> Message-ID: Ok, I proposed an update to my PEP to explain the process to ban a core developer: https://github.com/python/peps/pull/810/files Victor Le jeu. 18 oct. 2018 ? 01:23, Victor Stinner a ?crit : > > Le jeu. 18 oct. 2018 ? 00:16, Ethan Furman a ?crit : > > > > On 10/17/2018 03:05 PM, Victor Stinner wrote: > > > > > Oh, by the way, should we have two different choices: remove the > > > commit bit from a core dev (downgrade a core dev as a regular > > > contributor) and ban a core dev? > > > > No. If it comes to this, then the dev needs to be banned. I would not > > expect this to happen except maybe once in what's left of my lifetime. > > Ok. In that case, I would suggest to ban the core dev *and* drop their > commit bit. I'm not sure that we want to keep a banned user as part of > core developers. Extract of my PEP: > > "Core developers are also expected to be exemplary when it comes to > the Code of Conduct." > > Let's say that a core dev is banned for, let's say 6 months. What > happens next? Can we reconsider later to open a vote to "promote" > again the developer if they proved that they changed their behaviour? > > Again, I'm really dislike the idea of banning someone for their own > life. IMHO that would be either unfair and counter-productive. It's > really difficult to find core developers, so we should remain open if > people change their behaviour. > > Moreover, banning someone for life puts more pressure on the people > who decide on the ban. It's way easier to decide to only ban someone > for 1 week rather than banning someone for their own life. > > I proposed to start with a ban of 1 week if discussion and warnings > didn't work. I suggest to drop the commit bit at the first ban (of 1 > week). Again, to be consistent with "be exemplary when it comes to the > Code of Conduct". > > Context: I would like to formalize everything in my PEP :-) > https://www.python.org/dev/peps/pep-8015/ > > Note: I'm really not comfortable to talk about banning someone. But it > seems like we all are on the same page, such case is really > exceptional and will only be the very last resort if all other > attempts failed. > > Victor From antoine at python.org Thu Oct 18 03:36:34 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 18 Oct 2018 09:36:34 +0200 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: <35737263-3B90-440A-B410-AB80B109B6DA@stufft.io> Message-ID: <74659acf-4b7a-d66a-9045-41828e587cdd@python.org> Le 18/10/2018 ? 00:06, Alex Gaynor a ?crit?: > I think you're dramatically overestimating a) the possibility that > someone would attempt to use the CoC process frivolously, b) the > possibility that the CoC WG would act on such a complaint without good > cause. > > FWIW I was involved in removing a core developer from another community > for CoC violations. It was fucking exhausting, and I think basically > everyone involved was burned by the process. I cannot imagine anyone > trying to maliciously or frivolously use such a process. Can you explain in a few words what happened and/or the cause for banning? Regards Antoine. From brett at python.org Fri Oct 19 14:27:59 2018 From: brett at python.org (Brett Cannon) Date: Fri, 19 Oct 2018 11:27:59 -0700 Subject: [python-committers] Moderation of the Python community In-Reply-To: References: Message-ID: And just to follow up because I don't think this made it out to python-committers, the questions Victor brought up are all part of what the conduct WG is thinking about while we start ramping up on things. Once the WG has gotten things to a point that we think it's ready to provide e.g. enforcement guidelines, reporting, etc. then we will come back here to the team and bring this up again (hopefully in the next couple of months, but usual "we're all volunteers" caveat applies ;) . On Wed, 17 Oct 2018 at 08:45, Carol Willing wrote: > Brian, thanks for a very well written response, and Victor, thanks for > asking for clarification. > > I think Brian has covered my thoughts very thoroughly. As an FYI, Brett, > Thomas Wouters, and I are on the Code of Conduct workgroup so the core devs > are represented. > > > > On Oct 17, 2018, at 8:34 AM, Brian Curtin wrote: > > > > On Wed, Oct 17, 2018 at 8:04 AM Victor Stinner > wrote: > > Hi, > > > > I see more and more discussions about the moderation of the Python > community. > > > > There is a PSF "conduct" Working Group: > > https://wiki.python.org/psf/ConductWG/Charter > > > > I noticed the following questions: > > > > * Lack of transparency on how moderation is decided > > * Lack of transparency on the number of received Code of Conduct > > incidents: maybe start to produce "Code of Conduct transparency > > report"? (If such reports already exist, I'm sorry, I wasn't aware > > :-)) > > * Should the PSF conduct-WG handle conflicts between core developers? > > > > Would it be possible to write down rules to formalize the moderation? > > > > Yes. For any medium applying a code of conduct there should be some > guidelines applicable to said medium for how things are handled. > > > > To get this out of the way early, as the author of the current CoC, it > intentionally doesn't prescribe any specific moderation because it depends > on how and where it's applied given the people and tools available. > Moderating Discourse might be different than moderating a mailing list > which is different than a bug tracker. > > > > For example: > > > > * First try to contact the author of an incident and warn them? Only > > take an action immediately for exceptional cases like obvious spam? > > * Maybe define numbers for ban: 1 week, then 3 months, then 6 months, > > then 1 year? I would prefer to never ban someone forever. People can > > change. > > * Scope: does the moderationg apply to *any* public space? Or only to > > a restricted list like: mailing lists and bug tracker? What about > > Twitter and conferences? > > > > For conferences, there are specific codes of conduct and applicable > event handling guides that go with them, and I would just leave that area > alone from this angle. I don't know that we should start meddling with > conferences; leave that up to organizers who are dedicated to that and in > several cases have actual training on this topic. > > > > Twitter can't even moderate itself, but I don't think that makes it > anyone here's job. > > > > I would scope moderation to any spaces provided by or for this group, so > tracker, mailing lists, GitHub, Discourse, and I think that's it? I don't > really know if IRC and Zulip are still in play. > > > > * Should the incidents which occur in the private space be handled as > > well? Bullying can occur in the private space. > > > > We can't police everything, but I think handling private issues within > the space of PSF resources (or whatever the governing body of what we're > talking about is) is to be expected. For example, if I harass you via a > private message on Discourse, that is a situation to be handled here. It > doesn't need to go to everyone's inbox for it to be a problem we need to > handle. > > > > I don't know that you can moderate other private things?private in the > meaning of "PSF provided or not"?though. If I send you an inappropriate > email just between you and I, that's between us and our email providers. I > think it might be overstepping this group's bounds for you to say I can't > use the bug tracker for a month due to something I did entirely outside of > the scope of said group. It feels similar to some corporate policies, where > if I'm inappropriate to you when I see you at the grocery store, that's not > really the company's problem, but if I'm like that at our team dinner then > it is a problem. > > > > There probably does exist some threshold where out-of-scope behavior > crosses to where someone isn't welcome, but I don't know that it's > generally quantifiable. That's probably something for a council or triad or > working group to discuss on a case-by-case basis as it's above and beyond a > reasonable range of behaviors that this group can have their eye on. > > > > * How to handle conflict between core developers? Not directly related > > to the code of conduct. > > > > If it's not CoC related conflict, do you mean conflict related to code, > as in technical conflict over implementation details? I think we naturally > have a few mediators in this case depending on the level of where it > occurs. Release managers, delegates for PEPs, code area experts, and then I > think there are a few who act in such a way due to longevity with the > project. > > > > If we're looking for people to be specifically identified as mediators, > we have a bunch of good ones around here. > > > > I'm not interested for work on such rules. I'm not sure neither if > > it's the role of the Python core developers to propose something. > > Maybe the PSF conduct WG should propose something, or even decide > > directly? > > > > Is anyone from this group on said working group? If not, I don't think > they should be wholesale deciding guidelines for a group they're not a part > of. They would seem to be a group of people we should work with as they've > presumably come up with other guidelines and could be a useful set of > people to help shape things. > > > > Handling conflicts between core developers is the most difficult > > question. I don't think that it's the role of the conduct working > > group to handle that. Moreover, the Code of Conduct should be seen as > > a way to evict a core developer out of Python. The Code of Conduct is > > supposed to protect members of the Python community against people who > > misbehave. But I'm unable to describe the limit between "misbehave" > > and "conflict" between two developers. > > > > It is unfortunate that conflict?which can be a healthy thing for a > team?is potentially reaching past this toward misbehavior. A lot of > developers, especially those of us involved in open source, come into this > type of work with strong opinions. When they're too strongly held, we can > go beyond productive conflict and end with one or more of us finding ways > of avoiding that topic (work on other areas), avoiding further conflict at > all (only work on easier bugs), and possibly onto misbehavior, none of > which are healthy for the team. > > > > I think this type of issue is better solved internally to our team, > perhaps via some form of mediator(s) I mentioned earlier, rather than > involving a wholly external group. Time is of course a finite resource in > open source, and people work is often/usually harder than code work, but I > think we do have some people around who care about the success of the > project to spend time mediating these kinds of conflicts so that we keep > everyone involved and solve whatever problem at hand in a satisfactory > manner. > > > > My main concern is that the PSF conduct WG should not be seen as a > > threat to core developers. > > > > I don't think it should be used that way, but I also know nothing about > it and have heard nothing from it. > > _______________________________________________ > > python-committers mailing list > > python-committers at 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 at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Oct 19 15:04:59 2018 From: brett at python.org (Brett Cannon) Date: Fri, 19 Oct 2018 12:04:59 -0700 Subject: [python-committers] GitHub logins now supported on discuss.python.org Message-ID: In case anyone was waiting for that before trying out our Discourse instance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Fri Oct 19 19:58:03 2018 From: larry at hastings.org (Larry Hastings) Date: Fri, 19 Oct 2018 16:58:03 -0700 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: On 10/12/2018 11:55 AM, Brett Cannon wrote: > On Thu, 11 Oct 2018 at 01:30, Antoine Pitrou > wrote: > > > What concerns me is that there are several long-time and/or prominent > developers who are not even registered (*) on discuss.python.org > .? For > example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan > Krah, Terry Reedy. > > > I believe Larry is currently busy so he might simply have not taken > the time (and will be occupied into I believe November). You kids!? Yeah, I was just on a two-week trip to London, and I had a vacation right before that too.? Right now I'm dealing with the aftermath of so much vacation.? And next week I'm doing the PyWeek programming challenge: https://pyweek.org/26/ I'll also admit I've been dragging my feet about setting up yet-another-online-account for yet-another-form-of-online-communication.? (But this time!? It'll solve all our problems!? Finally, our conversational deliverance is at hand!) //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Fri Oct 19 20:09:50 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 20 Oct 2018 02:09:50 +0200 Subject: [python-committers] discuss.python.org participation In-Reply-To: References: Message-ID: Le sam. 20 oct. 2018 ? 01:58, Larry Hastings a ?crit : > I'll also admit I've been dragging my feet about setting up yet-another-online-account for yet-another-form-of-online-communication. (But this time! It'll solve all our problems! Finally, our conversational deliverance is at hand!) discuss.python.org now supports log in using GitHub since today :-) Victor From nad at python.org Sat Oct 20 13:37:57 2018 From: nad at python.org (Ned Deily) Date: Sat, 20 Oct 2018 13:37:57 -0400 Subject: [python-committers] [RELEASE] Python 3.7.1 and 3.6.7 are now available Message-ID: On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.1. Python 3.7.1 is the first maintenance release of the newest feature release of the Python language. You can find Python 3.7.1 here: https://www.python.org/downloads/release/python-371/ See the What?s New In Python 3.7 document for more information about the many new features and optimizations included in the 3.7 series. Detailed information about the changes made in 3.7.1 can be found in its change log: https://docs.python.org/3.7/whatsnew/3.7.html https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-1-final We are also happy to announce the availability of Python 3.6.7, the next maintenance release of Python 3.6: https://www.python.org/downloads/release/python-367/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. -- Ned Deily nad at python.org -- [] From lukasz at langa.pl Mon Oct 22 16:38:30 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Mon, 22 Oct 2018 21:38:30 +0100 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 Message-ID: The voting procedure is described in PEP 8001. I flipped it from "Draft" to "Active" without further changes a few minutes ago. That's in the interest of giving everybody enough lead time as well as resolving the situation "well before PyCon 2019" as per Guido's and Carol's requests. Please read all the governance PEPs, ask for clarifications, voice all your concerns now. Ideally we will make all of the required changes to the PEPs early and not last minute before the vote. There were some suggestions on Discourse for changes to the selected model, the biggest being Stefan's suggestion to encrypt the votes and Donald's suggestion to use STAR instead of IRV for counting votes. We ended up not going with those suggestions. See Brett's comment here as to why: https://discuss.python.org/t/pep-8001-python-governance-voting-process/233/46 - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Tue Oct 23 07:06:51 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 23 Oct 2018 21:06:51 +1000 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: Message-ID: On Tue, 23 Oct 2018 at 06:38, ?ukasz Langa wrote: > > The voting procedure is described in PEP 8001. I flipped it from "Draft" to "Active" without further changes a few minutes ago. That's in the interest of giving everybody enough lead time as well as resolving the situation "well before PyCon 2019" as per Guido's and Carol's requests. > > Please read all the governance PEPs, ask for clarifications, voice all your concerns now. Ideally we will make all of the required changes to the PEPs early and not last minute before the vote. > > There were some suggestions on Discourse for changes to the selected model, the biggest being Stefan's suggestion to encrypt the votes and Donald's suggestion to use STAR instead of IRV for counting votes. We ended up not going with those suggestions. See Brett's comment here as to why: > https://discuss.python.org/t/pep-8001-python-governance-voting-process/233/46 My main concern was about the potential for vote-splitting with multiple "council" type proposals on the ballot, and IRV is enough to address that (having been an Australian voter for ~22 years, I'm also very familiar with it, and given the specific set of proposals we're voting on, I don't think the case where STAR would give a different answer is likely to come up - the various draft PEPs have too much in common with either each other or the status quo for it to be likely that a significant proportion of the folks voting will find any of them completely unacceptable) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From antoine at python.org Tue Oct 23 07:45:54 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 23 Oct 2018 13:45:54 +0200 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: Message-ID: <1e9a3036-3e44-48c5-17c4-cf6dadcee142@python.org> Le 23/10/2018 ? 13:06, Nick Coghlan a ?crit?: > On Tue, 23 Oct 2018 at 06:38, ?ukasz Langa wrote: >> >> The voting procedure is described in PEP 8001. I flipped it from "Draft" to "Active" without further changes a few minutes ago. That's in the interest of giving everybody enough lead time as well as resolving the situation "well before PyCon 2019" as per Guido's and Carol's requests. >> >> Please read all the governance PEPs, ask for clarifications, voice all your concerns now. Ideally we will make all of the required changes to the PEPs early and not last minute before the vote. >> >> There were some suggestions on Discourse for changes to the selected model, the biggest being Stefan's suggestion to encrypt the votes and Donald's suggestion to use STAR instead of IRV for counting votes. We ended up not going with those suggestions. See Brett's comment here as to why: >> https://discuss.python.org/t/pep-8001-python-governance-voting-process/233/46 > > My main concern was about the potential for vote-splitting with > multiple "council" type proposals on the ballot, and IRV is enough to > address that (having been an Australian voter for ~22 years, I'm also > very familiar with it, and given the specific set of proposals we're > voting on, I don't think the case where STAR would give a different > answer is likely to come up - the various draft PEPs have too much in > common with either each other or the status quo for it to be likely > that a significant proportion of the folks voting will find any of > them completely unacceptable) I had the same concern and I'm glad the voting mechanism addresses it. Regards Antoine. From donald at stufft.io Tue Oct 23 07:55:19 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 23 Oct 2018 07:55:19 -0400 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: Message-ID: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> > On Oct 23, 2018, at 7:06 AM, Nick Coghlan wrote: > > On Tue, 23 Oct 2018 at 06:38, ?ukasz Langa wrote: >> >> The voting procedure is described in PEP 8001. I flipped it from "Draft" to "Active" without further changes a few minutes ago. That's in the interest of giving everybody enough lead time as well as resolving the situation "well before PyCon 2019" as per Guido's and Carol's requests. >> >> Please read all the governance PEPs, ask for clarifications, voice all your concerns now. Ideally we will make all of the required changes to the PEPs early and not last minute before the vote. >> >> There were some suggestions on Discourse for changes to the selected model, the biggest being Stefan's suggestion to encrypt the votes and Donald's suggestion to use STAR instead of IRV for counting votes. We ended up not going with those suggestions. See Brett's comment here as to why: >> https://discuss.python.org/t/pep-8001-python-governance-voting-process/233/46 > > My main concern was about the potential for vote-splitting with > multiple "council" type proposals on the ballot, and IRV is enough to > address that (having been an Australian voter for ~22 years, I'm also > very familiar with it, and given the specific set of proposals we're > voting on, I don't think the case where STAR would give a different > answer is likely to come up - the various draft PEPs have too much in > common with either each other or the status quo for it to be likely > that a significant proportion of the folks voting will find any of > them completely unacceptable) > We?re using IRV and I accept that, but I just want to point out that IRV still has a form vote splitting (in electoral parlance, vote splitting is the ?favorite betrayal criterion? - https://www.youtube.com/watch?v=JtKAScORevQ . IRV only protects against vote splitting when you have a very weak or a very strong candidate ranked first. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Oct 23 07:56:39 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 23 Oct 2018 13:56:39 +0200 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> Message-ID: <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> Le 23/10/2018 ? 13:55, Donald Stufft a ?crit?: > > We?re using IRV and I accept that, but I just want to point out that IRV > still has a form vote splitting (in electoral parlance, vote splitting > is the ?favorite betrayal criterion? > -?https://www.youtube.com/watch?v=JtKAScORevQ. IRV only protects against > vote splitting when you have a very weak or a very strong candidate > ranked first. Do you have a non-video link to an explanation? If some form of tactical voting is possible, as a voter I'd like to know about it. Regards Antoine. From donald at stufft.io Tue Oct 23 09:07:43 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 23 Oct 2018 09:07:43 -0400 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> Message-ID: <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> > On Oct 23, 2018, at 7:56 AM, Antoine Pitrou wrote: > > > Le 23/10/2018 ? 13:55, Donald Stufft a ?crit : >> >> We?re using IRV and I accept that, but I just want to point out that IRV >> still has a form vote splitting (in electoral parlance, vote splitting >> is the ?favorite betrayal criterion? >> - https://www.youtube.com/watch?v=JtKAScORevQ. IRV only protects against >> vote splitting when you have a very weak or a very strong candidate >> ranked first. > > Do you have a non-video link to an explanation? > > If some form of tactical voting is possible, as a voter I'd like to know > about it. > To be clear, *all* voting systems have some form of tactical voting as part of them, so this isn?t unique to IRV. I was mostly just pointing out that IRV isn?t a panacea, you can still get a vote splitting like effect. Interestingly, IRV also has the property that sometimes the simple act of voting your true preference *at all* can cause your true preference to lose, and sometimes you would have been better off not voting at all. I?m struggling to find a resource besides that doesn?t also include shilling for another voting system or isn?t a lengthy paper but https://rangevoting.org/IRVpartic.html gives an example and https://rangevoting.org/TarrIrv.html is a more complex example. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Tue Oct 23 12:05:58 2018 From: tim.peters at gmail.com (Tim Peters) Date: Tue, 23 Oct 2018 11:05:58 -0500 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: [Donald Stufft ] > ... > I?m struggling to find a resource besides that doesn?t also include > shilling for another voting system or isn?t a lengthy paper but > https://rangevoting.org/IRVpartic.html gives an example and > https://rangevoting.org/TarrIrv.html is a more complex example. > The rangevoting site has a great deal of info about all sorts of voting systems. Over a decade ago, Ka-Ping Yee (who used to be very active in Python development) ran some _visual_ voting simulations on 5 popular systems, which scared him (& me) away from IRV forever: http://zesty.ca/voting/sim/ """ The following images visually demonstrate how Plurality penalizes centrist candidates and Borda favours them; how Approval and Condorcet yield nearly identical results; and how the Hare method yields extremely strange behaviour. Alarmingly, the Hare method (also known as "IRV") is gaining momentum as the most popular type of election-method reform in the United States (in Berkeley, Oakland, and just last November in San Francisco, for example). """ That said, in the absence of political factions maneuvering to increase their own power over time, with money and marketing clout to persuade voters to play along, I'm not much concerned about the system used for a one-shot vote. Even if we all strive to be as "strategic" and/or "tactical" as possible, we'll all be pushing in different directions. One massive (to my eyes) advantage of range voting is that it never pays to give your true favorite less than your top score, or your true least-favorite more than your bottom score. (Note: the "approval voting" used for PSF elections is essentially range voting limited to two possible scores - and it should be very easy in that context to see that it can't pay to approve a candidate you don't approve of, or vice versa.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleax at google.com Tue Oct 23 12:51:00 2018 From: aleax at google.com (Alex Martelli) Date: Tue, 23 Oct 2018 09:51:00 -0700 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: While I suspect most participants are aware of this, just in care some don't I thought I'd just point out that it's futile to look for a "perfect" voting system -- Kenneth Arrow proved that long ago, see https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem Alex On Tue, Oct 23, 2018 at 9:08 AM Tim Peters wrote: > > [Donald Stufft ] > >> ... >> I?m struggling to find a resource besides that doesn?t also include >> shilling for another voting system or isn?t a lengthy paper but >> https://rangevoting.org/IRVpartic.html gives an example and >> https://rangevoting.org/TarrIrv.html is a more complex example. >> > > The rangevoting site has a great deal of info about all sorts of voting > systems. Over a decade ago, Ka-Ping Yee (who used to be very active in > Python development) ran some _visual_ voting simulations on 5 popular > systems, which scared him (& me) away from IRV forever: > > http://zesty.ca/voting/sim/ > > """ > The following images visually demonstrate how Plurality penalizes centrist > candidates and Borda favours them; how Approval and Condorcet yield nearly > identical results; and how the Hare method yields extremely strange > behaviour. Alarmingly, the Hare method (also known as "IRV") is gaining > momentum as the most popular type of election-method reform in the United > States (in Berkeley, Oakland, and just last November in San Francisco, for > example). > """ > > That said, in the absence of political factions maneuvering to increase > their own power over time, with money and marketing clout to persuade > voters to play along, I'm not much concerned about the system used for a > one-shot vote. Even if we all strive to be as "strategic" and/or > "tactical" as possible, we'll all be pushing in different directions. > > One massive (to my eyes) advantage of range voting is that it never pays > to give your true favorite less than your top score, or your true > least-favorite more than your bottom score. (Note: the "approval voting" > used for PSF elections is essentially range voting limited to two possible > scores - and it should be very easy in that context to see that it can't > pay to approve a candidate you don't approve of, or vice versa.) > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue Oct 23 13:13:29 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 24 Oct 2018 04:13:29 +1100 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: <20181023171329.GG3817@ando.pearwood.info> On Tue, Oct 23, 2018 at 11:05:58AM -0500, Tim Peters wrote: > The rangevoting site has a great deal of info about all sorts of voting > systems. Over a decade ago, Ka-Ping Yee (who used to be very active in > Python development) ran some _visual_ voting simulations on 5 popular > systems, which scared him (& me) away from IRV forever: > > http://zesty.ca/voting/sim/ > > """ > The following images visually demonstrate how Plurality penalizes centrist > candidates and Borda favours them; how Approval and Condorcet yield nearly > identical results; and how the Hare method yields extremely strange > behaviour. Alarmingly, the Hare method (also known as "IRV") is gaining > momentum as the most popular type of election-method reform in the United > States (in Berkeley, Oakland, and just last November in San Francisco, for > example). > """ Why am I not surprised that here in Australia, we use IRV for our House of Representatives and most state governments? -- Steve From tim.peters at gmail.com Tue Oct 23 13:14:45 2018 From: tim.peters at gmail.com (Tim Peters) Date: Tue, 23 Oct 2018 12:14:45 -0500 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: [Alex Martelli ] > While I suspect most participants are aware of this, just in care some > don't I thought I'd just point out that it's futile to look for a "perfect" > voting system -- Kenneth Arrow proved that long ago, see > https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem > Yup! Ping's page acknowledges that explicitly: http://zesty.ca/voting/sim/ and goes on to explain why he doesn't care ;-) """ ...so one can always invent situations where a particular method violates one of these criteria. Thus, presenting individual cases of strange behaviour proves little. A more substantive way to argue for or against a particular election method would be to compare how frequently failures occur, under what conditions they occur, and how severe they are. """ Which his visual simulations go on to do. Even a brief glance strikingly shows that IRV frequently delivers outcomes that can only be called "bizarre", not just that it's possible to contrive cases where one of Arrow's criteria isn't met. For example, """ For four candidates in a perfect square (red, yellow, green, and blue at (0.3, 0.3), (0.7, 0.3), (0.3, 0.7), and (0.7, 0.7) respectively), Plurality, Approval, Borda, and Condorcet yield the obvious expected outcomes here. But even in this simplest of cases, Hare behaves unreasonably. """ So there's a real difference between perfection being unreachable and behaving incomprehensibly in symmetric simple-as-possible cases no other method has any problems with. As scenarios become more complex, IRV just gets weirder. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Tue Oct 23 13:17:35 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 23 Oct 2018 13:17:35 -0400 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: <92EA4610-E330-4670-9E33-DC6A782300F2@stufft.io> > On Oct 23, 2018, at 1:14 PM, Tim Peters wrote: > > [Alex Martelli >] > While I suspect most participants are aware of this, just in care some don't I thought I'd just point out that it's futile to look for a "perfect" voting system -- Kenneth Arrow proved that long ago, see https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem > > Yup! Ping's page acknowledges that explicitly: Important to note that Arrow?s theorem applies only to ranked or ordinal systems, cardinal/rated systems are not covered by it (though the larger point of no perfect system still holds true). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Tue Oct 23 13:24:32 2018 From: tim.peters at gmail.com (Tim Peters) Date: Tue, 23 Oct 2018 12:24:32 -0500 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: <20181023171329.GG3817@ando.pearwood.info> References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> <20181023171329.GG3817@ando.pearwood.info> Message-ID: [Tim, quoting Ping]> The following images visually demonstrate how Plurality penalizes centrist > > candidates and Borda favours them; how Approval and Condorcet yield > nearly > > identical results; and how the Hare method yields extremely strange > > behaviour. ... [Steven D'Aprano][ > Why am I not surprised that here in Australia, we use IRV for our House > of Representatives and most state governments? > > This is getting off-topic, so I'll stop with this: the push for iRV in the United States is mostly by 3rd parties who are essentially wholly locked out of any chance of winning under our plurality "winner takes all" voting systems. But, while Ping's page doesn't address this, there are good arguments on the rangevoting site for why IRV is just as likely to ensure 2-party dominance. Which historical evidence appears to support. Indeed, on an Australian government web page I can't find right now, it explicitly said that your version of IRV favored 2-party dominance too. But that's not really relevant here until we form pro-Inquisition and anti-Inquisition parties (which, over time, will come to support the opposites of their names say) :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Oct 23 13:46:09 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 23 Oct 2018 19:46:09 +0200 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: Le 23/10/2018 ? 18:05, Tim Peters a ?crit?: > > [Donald Stufft >] > > ... > I?m struggling to find a resource besides that doesn?t also include > shilling for another voting system or isn?t a lengthy paper > but?https://rangevoting.org/IRVpartic.html?gives an example > and?https://rangevoting.org/TarrIrv.html?is a more complex example. > > > The rangevoting site has a great deal of info about all sorts of voting > systems.? Over a decade ago, Ka-Ping Yee (who used to be very active in > Python development) ran some _visual_ voting simulations on 5 popular > systems, which scared him (& me) away from IRV forever: > > ? ? http://zesty.ca/voting/sim/ Thanks! This is a great resource. I agree that IRV looks scary, while Approval or Condorcet look reasonable IMHO. Regards Antoine. From chris.jerdonek at gmail.com Tue Oct 23 19:04:14 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Tue, 23 Oct 2018 16:04:14 -0700 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: On Tue, Oct 23, 2018 at 10:46 AM Antoine Pitrou wrote: > Le 23/10/2018 ? 18:05, Tim Peters a ?crit : > > The rangevoting site has a great deal of info about all sorts of voting > > systems. Over a decade ago, Ka-Ping Yee (who used to be very active in > > Python development) ran some _visual_ voting simulations on 5 popular > > systems, which scared him (& me) away from IRV forever: > > > > http://zesty.ca/voting/sim/ > > Thanks! This is a great resource. I agree that IRV looks scary, while > Approval or Condorcet look reasonable IMHO. A major problem with approval voting IMO (and range and score) is that it constrains how voters can express themselves: If you really like one candidate but your second choice is so-so but better than the third, do you "approve" of your second choice? If you do, you'll be helping to defeat the candidate you really like. So as a voter your hands are artificially tied. Regarding Tim's point about IRV and third parties, what third parties in the US *really* want is proportional representation. PR is much harder to make progress towards here, but still possible. One reason third parties support IRV is that it can be a huge challenge even to be "qualified" (i.e. recognized) as an official party in many states. Some states require parties to get a certain threshold of voter support at a statewide election (e.g. have a candidate win at least 5%). Plurality makes this much harder because of the spoiler effect / wasted vote dynamics. With IRV, the idea is that parties will be able to see their true support. Another reason some advocates favor IRV is that it's a special case (the n=1 case) of single transferable voting (STV). This is a form of PR that many advocates feel would be a lot easier to take hold in the US than, say, the party list systems more common in Europe and elsewhere. Indeed, over twenty cities in the US once used STV in the earlier parts of the 20th century. (But it was eventually repealed in all but one city, in part because of its success in electing minority candidates.) --Chris From tim.peters at gmail.com Tue Oct 23 20:37:43 2018 From: tim.peters at gmail.com (Tim Peters) Date: Tue, 23 Oct 2018 19:37:43 -0500 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: [Chris Jerdonek [ > A major problem with approval voting IMO (and range and score) is that > it constrains how voters can express themselves: > Well, that's an objection I never heard before - and expect I'll never hear again ;-) To the contrary, range/score voting are the _most_ expressive, allowing to you make both gross and fine distinctions, and even to say "no opinion at all about this one". The only thing you can't do is express non-linear preferences (whether flat-out intransitive, such as "I like A better than B, and B better than C, but C better than A", or seemingly inconsistent, such as "I like A 2x better than B, and B 4x better than C, but A only 3x better than C"). In range/score voting, you give each a score according to your true preferences as the granularity of the universe of possible scores allows. For example, if scores are limited to be in range(100), give your most favorite score 99, and if you favor them 3x more than your second-favorite, give the latter score 33. If you can't stand your second-favorite at all, give them score 0. If you like both your top choices the same, give them both score 99. If you only _know_ about your top candidate, and really don't know anything about the other two, don't give the latter two scores at all. Then you're effectively saying "I did all the research I had time for, and will leave it to others who did research the other two to rate them". This seems to me supremely relevant for the task at hand: a substantial number of detailed proposals that, in fact, won't _all_ be carefully studied by the people asked to vote on them. Merely ranking them from 1 to 6 (whatever) _forces_ people to fabricate opinions about proposals they may not have even read, forbids them from saying, e.g., "I like #2 and #5 equally", forbids them from saying "#1 is ten times more attractive to me than #3", forbids them from saying "I have the tiniest of preferences for #5 over #4", forbids them from saying "I didn't even read #6, and so have no opinion about it", and so on. In approval voting, the universe of scores effectively shrinks to {0, 1}. It's not _as_ expressive by far. There you're limited to saying one of "I can live with this" (score 1) or "I can't live with this" (score 0). The winner is whichever one the most people can live with. Or, if people can't refrain from playing dishonest tactical games , whichever one the most people _claimed_ they could live with. What more can you ask for? If people lie about their true preferences, it's hardly a voting system's fault if it delivers a result consistent with the lies it's told. > If you really like one candidate but your second choice is so-so but > better than the third, do you "approve" of your second choice? If you > do, you'll be helping to defeat the candidate you really like. So as a > voter your hands are artificially tied. > If you're stuck with the relatively inexpressive approval (0 or 1) voting, as above: you can live with your second-favorite or not. Vote accordingly. If you vote "I can live with them" and they win, what's your _actual_ complaint? You _said_ you could live with them. If that's an outcome you can't live with, you should have voted 0 for them instead. If you want to specify _degrees_ of approval, then you want range/score (with a larger universe of possible scores) voting instead. > [skipping stuff about elections-in-general] -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Oct 25 14:15:55 2018 From: brett at python.org (Brett Cannon) Date: Thu, 25 Oct 2018 11:15:55 -0700 Subject: [python-committers] Vote on governance will happen between Nov 16 - Nov 30 In-Reply-To: References: <01938BCE-6A28-48F1-B3B4-40B3FA1E8859@stufft.io> <5341f17c-a9d1-1597-ce56-a463a1d57968@python.org> <49F23CDD-E8A0-4549-BDA1-A3B31E9848DB@stufft.io> Message-ID: FYI I posted a suggestion on how to resolve the "should we change from IRV?" question at https://discuss.python.org/t/pep-8001-python-governance-voting-process/233/56 On Tue, 23 Oct 2018 at 17:38, Tim Peters wrote: > [Chris Jerdonek [ > >> A major problem with approval voting IMO (and range and score) is that >> it constrains how voters can express themselves: >> > > Well, that's an objection I never heard before - and expect I'll never > hear again ;-) > > To the contrary, range/score voting are the _most_ expressive, allowing to > you make both gross and fine distinctions, and even to say "no opinion at > all about this one". The only thing you can't do is express non-linear > preferences (whether flat-out intransitive, such as "I like A better than > B, and B better than C, but C better than A", or seemingly inconsistent, > such as "I like A 2x better than B, and B 4x better than C, but A only 3x > better than C"). > > In range/score voting, you give each a score according to your true > preferences as the granularity of the universe of possible scores allows. > For example, if scores are limited to be in range(100), give your most > favorite score 99, and if you favor them 3x more than your second-favorite, > give the latter score 33. If you can't stand your second-favorite at all, > give them score 0. If you like both your top choices the same, give them > both score 99. If you only _know_ about your top candidate, and really > don't know anything about the other two, don't give the latter two scores > at all. Then you're effectively saying "I did all the research I had time > for, and will leave it to others who did research the other two to rate > them". > > This seems to me supremely relevant for the task at hand: a substantial > number of detailed proposals that, in fact, won't _all_ be carefully > studied by the people asked to vote on them. Merely ranking them from 1 to > 6 (whatever) _forces_ people to fabricate opinions about proposals they may > not have even read, forbids them from saying, e.g., "I like #2 and #5 > equally", forbids them from saying "#1 is ten times more attractive to me > than #3", forbids them from saying "I have the tiniest of preferences for > #5 over #4", forbids them from saying "I didn't even read #6, and so have > no opinion about it", and so on. > > In approval voting, the universe of scores effectively shrinks to {0, 1}. > It's not _as_ expressive by far. There you're limited to saying one of "I > can live with this" (score 1) or "I can't live with this" (score 0). The > winner is whichever one the most people can live with. Or, if people can't > refrain from playing dishonest tactical games , whichever one the most > people _claimed_ they could live with. What more can you ask for? If > people lie about their true preferences, it's hardly a voting system's > fault if it delivers a result consistent with the lies it's told. > > >> If you really like one candidate but your second choice is so-so but >> better than the third, do you "approve" of your second choice? If you >> do, you'll be helping to defeat the candidate you really like. So as a >> voter your hands are artificially tied. >> > > If you're stuck with the relatively inexpressive approval (0 or 1) voting, > as above: you can live with your second-favorite or not. Vote > accordingly. If you vote "I can live with them" and they win, what's your > _actual_ complaint? You _said_ you could live with them. If that's an > outcome you can't live with, you should have voted 0 for them instead. If > you want to specify _degrees_ of approval, then you want range/score (with > a larger universe of possible scores) voting instead. > > > [skipping stuff about elections-in-general] > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sun Oct 28 15:37:31 2018 From: brett at python.org (Brett Cannon) Date: Sun, 28 Oct 2018 12:37:31 -0700 Subject: [python-committers] Josh Rosenburg (josh.r) now has triage rights Message-ID: On Serhiy's recommendation I just gave Josh triage rights on bugs.python.org . -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Tue Oct 30 15:52:21 2018 From: tim.peters at gmail.com (Tim Peters) Date: Tue, 30 Oct 2018 14:52:21 -0500 Subject: [python-committers] If you care about the voting method, please vote ; -) Message-ID: 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. From nad at python.org Mon Oct 29 23:04:23 2018 From: nad at python.org (Ned Deily) Date: Mon, 29 Oct 2018 23:04:23 -0400 Subject: [python-committers] Julien Palard joins the Python Release Team as Documentation Expert Message-ID: https://discuss.python.org/t/julien-palard-joins-the-python-release-team-as-documentation-expert/313 -- Ned Deily nad at python.org -- []