From andrew.svetlov at gmail.com Mon Sep 10 15:52:46 2018 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Mon, 10 Sep 2018 12:52:46 -0700 Subject: [python-committers] MSDN subscription renewal Message-ID: Hi. I've found that my MSDN subscription has expired. I don't use Window for daily tasks but sometimes need it for fixing Windows-specific bugs. Could you renew it or issue a new one? -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Mon Sep 10 18:17:00 2018 From: nad at python.org (Ned Deily) Date: Mon, 10 Sep 2018 15:17:00 -0700 Subject: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon Message-ID: <3ABAB3B5-6346-49F2-98F7-185303166016@python.org> I have updated the schedules for the next maintenance releases of Python 3.7.x and 3.6.x. My original plan had been to get 3.7.1, the first 3.7 maintenance release, out by the end of July. It was solely my fault that that did not happen so I hope you'll accept my apologies; I will try to not let it happen again. I have now scheduled a 3.7.1 release candidate and rescheduled the 3.6.7 release candidate for 2018-09-18, about a week from today, and 3.7.1 final and 3.6.7 final for 2018-09-28. That allows us to take advantage of fixes generated at the Core Developers sprint taking place this week. Please review any open issues you are working on or are interested in and try to get them merged in to the 3.7 and/or 3.6 branches soon - by the beginning of next week at the latest. As usual, if there are any issues you believe need to be addressed prior to these releases, please ensure there are open issues for them in the bug tracker (bugs.python.org) and that their priorities are set accordingly (e.g. "release blocker"). Thanks for your support! --Ned -- Ned Deily nad at python.org -- [] From mariatta.wijaya at gmail.com Tue Sep 11 00:49:56 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Mon, 10 Sep 2018 21:49:56 -0700 Subject: [python-committers] 3 weeks to Oct 1 Message-ID: Friendly reminder that it is now 3 weeks until October 1, the deadline for coming up with Python Governance PEPs. Barry has started several Governance PEPs: - https://www.python.org/dev/peps/pep-8000/ Python Language Governance Proposal Overview - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process - https://www.python.org/dev/peps/pep-8002 Open source governance survey The following three PEPs are for placeholders. I believe the idea is to have people claim the PEP they're planning to write, and finish writing the PEP. - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model - https://www.python.org/dev/peps/pep-8011 The Council Governance Model - https://www.python.org/dev/peps/pep-8012 The Community Governance Model And don't forget about the lucky PEP number 13. https://www.python.org/dev/peps/pep-0013/ Mariatta ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Tue Sep 11 16:48:05 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Tue, 11 Sep 2018 13:48:05 -0700 Subject: [python-committers] Automerge bot deployed Message-ID: I've deployed the bot to automerge CPython pull request on the master branch. One benefit of this is you don't need to worry about replacing "#" into "GH-". To get the bot to automerge: - first edit the PR title and description, to be the commit message you want to use. - approve the PR (so it will have "awaiting merge" label) - apply the "? automerge" label. It will wait for ALL status checks to pass, and merge the PR, replacing `#` with `GH-` I've made a demo video on YouTube: https://youtu.be/p85YtKKLNno See also previous discussions in https://github.com/python/core-workflow/issues/29 https://github.com/python/bedevere/issues/14 The previous way of merging PR still works. If you prefer merging the PR yourself, just don't apply the "? automerge" label. Mariatta ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Tue Sep 11 16:56:35 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 11 Sep 2018 13:56:35 -0700 Subject: [python-committers] Automerge bot deployed In-Reply-To: References: Message-ID: W00t! ???????? On Tue, Sep 11, 2018 at 1:48 PM Mariatta Wijaya wrote: > I've deployed the bot to automerge CPython pull request on the master > branch. > > One benefit of this is you don't need to worry about replacing "#" into > "GH-". > > To get the bot to automerge: > - first edit the PR title and description, to be the commit message you > want to use. > - approve the PR (so it will have "awaiting merge" label) > - apply the "? automerge" label. > > It will wait for ALL status checks to pass, and merge the PR, replacing > `#` with `GH-` > > I've made a demo video on YouTube: https://youtu.be/p85YtKKLNno > > See also previous discussions in > https://github.com/python/core-workflow/issues/29 > https://github.com/python/bedevere/issues/14 > > The previous way of merging PR still works. If you prefer merging the PR > yourself, just don't apply the "? automerge" label. > > Mariatta > ? > _______________________________________________ > 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/ > -- --Guido (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Wed Sep 12 12:52:33 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 12 Sep 2018 09:52:33 -0700 Subject: [python-committers] Automerge bot deployed In-Reply-To: References: Message-ID: Update to the automerge bot: It will not merge unless there is "CLA signed" label, and no "DO-NOT-MERGE" label. Again, please edit the PR title and description before adding the `? automerge` label. The PR title and description will be used as the squashed commit message. Mariatta? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Thu Sep 13 02:30:26 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 13 Sep 2018 08:30:26 +0200 Subject: [python-committers] Automerge bot deployed In-Reply-To: References: Message-ID: Today I created a PR with a description containing "type.__format__()". To display it properly, I chose to edit the description and write "type.\_\_format\_\_()". I guess that the bot will merge a description like that unchanged, right? So we should also be careful of description using Markdown syntax. Victor Le mer. 12 sept. 2018 ? 18:52, Mariatta Wijaya a ?crit : > Update to the automerge bot: > > It will not merge unless there is "CLA signed" label, and no > "DO-NOT-MERGE" label. > > Again, please edit the PR title and description before adding the `? > automerge` label. > The PR title and description will be used as the squashed commit message. > > Mariatta? > ? > _______________________________________________ > 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 encukou at gmail.com Thu Sep 13 10:54:30 2018 From: encukou at gmail.com (Petr Viktorin) Date: Thu, 13 Sep 2018 07:54:30 -0700 Subject: [python-committers] Automerge bot deployed In-Reply-To: References: Message-ID: On Wed, Sep 12, 2018, 23:30 Victor Stinner wrote: > Today I created a PR with a description containing "type.__format__()". To > display it properly, I chose to edit the description and write > "type.\_\_format\_\_()". I guess that the bot will merge a description like > that unchanged, right? So we should also be careful of description using > Markdown syntax. > Use `type.__format__`, with backticks, for code. That looks OK in plain text. Or edit before merging :) > Victor > > Le mer. 12 sept. 2018 ? 18:52, Mariatta Wijaya > a ?crit : > >> Update to the automerge bot: >> >> It will not merge unless there is "CLA signed" label, and no >> "DO-NOT-MERGE" label. >> >> Again, please edit the PR title and description before adding the `? >> automerge` label. >> The PR title and description will be used as the squashed commit message. >> >> Mariatta? >> ? >> _______________________________________________ >> 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 Thu Sep 13 12:17:49 2018 From: brett at python.org (Brett Cannon) Date: Thu, 13 Sep 2018 09:17:49 -0700 Subject: [python-committers] I have blocked someone from the Python org Message-ID: Someone left https://github.com/python/cpython/pull/9195#issuecomment-420646466 which was clearly written to upset Victor and insult him. I warned the person that such behaviour is not okay and future insults would have ramifications (I was actually asked to ban this person to begin with but I gave them the benefit of the doubt considering how heated the topic involved has become). They then decided to seek me out on Twitter berate me there for my warning: https://twitter.com/dolkensp/status/1039949212832722944 . For that I have followed through with my warning and banned them from the org. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Thu Sep 13 12:19:46 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Thu, 13 Sep 2018 09:19:46 -0700 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: References: Message-ID: Thanks for handling it, Brett. That kind of behavior is not something we need to allow or tolerate in this community. I'm fine with banning. Mariatta ? On Thu, Sep 13, 2018 at 9:18 AM Brett Cannon wrote: > Someone left > https://github.com/python/cpython/pull/9195#issuecomment-420646466 which > was clearly written to upset Victor and insult him. I warned the person > that such behaviour is not okay and future insults would have > ramifications (I was actually asked to ban this person to begin with but I > gave them the benefit of the doubt considering how heated the topic > involved has become). They then decided to seek me out on Twitter berate me > there for my warning: > https://twitter.com/dolkensp/status/1039949212832722944 . For that I have > followed through with my warning and banned them from the org. > _______________________________________________ > 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 antoine at python.org Thu Sep 13 12:23:03 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 13 Sep 2018 18:23:03 +0200 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: References: Message-ID: <345b1b82-ce9c-d9a6-6741-4bdc11ff864b@python.org> Regardless of whether that behaviour should be tolerated or not, there should be a procedure for this and not a single person banning other people at will, especially if it follows their own involvement on the topic at hand. Regards Antoine. Le 13/09/2018 ? 18:19, Mariatta Wijaya a ?crit?: > Thanks for handling it, Brett. > > That kind of behavior is not something we need to allow or tolerate in > this community. > I'm fine with banning. > > Mariatta > > ? > > On Thu, Sep 13, 2018 at 9:18 AM Brett Cannon > wrote: > > Someone left > https://github.com/python/cpython/pull/9195#issuecomment-420646466 > which was clearly written to upset Victor and insult him. I warned > the person that such behaviour is not okay and future insults would > have? ramifications (I was actually asked to ban this person to > begin with but I gave them the benefit of the doubt considering how > heated the topic involved has become). They then decided to seek me > out on Twitter berate me there for my warning: > https://twitter.com/dolkensp/status/1039949212832722944 . For that I > have followed through with my warning and banned them from the org. > _______________________________________________ > 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 kushaldas at gmail.com Thu Sep 13 12:24:16 2018 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 13 Sep 2018 21:54:16 +0530 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: References: Message-ID: On Thu, Sep 13, 2018 at 9:48 PM Brett Cannon wrote: > > Someone left https://github.com/python/cpython/pull/9195#issuecomment-420646466 which was clearly written to upset Victor and insult him. I warned the person that such behaviour is not okay and future insults would have ramifications (I was actually asked to ban this person to begin with but I gave them the benefit of the doubt considering how heated the topic involved has become). They then decided to seek me out on Twitter berate me there for my warning: https://twitter.com/dolkensp/status/1039949212832722944 . For that I have followed through with my warning and banned them from the org. Thank you for doing this. Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in From brett at python.org Thu Sep 13 12:35:46 2018 From: brett at python.org (Brett Cannon) Date: Thu, 13 Sep 2018 09:35:46 -0700 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: <345b1b82-ce9c-d9a6-6741-4bdc11ff864b@python.org> References: <345b1b82-ce9c-d9a6-6741-4bdc11ff864b@python.org> Message-ID: On Thu, 13 Sep 2018 at 09:23 Antoine Pitrou wrote: > > Regardless of whether that behaviour should be tolerated or not, there > should be a procedure for this and not a single person banning other > people at will, especially if it follows their own involvement on the > topic at hand. > There should be, but there currently isn't one and with no governance model we unfortunately won't have one for at least a little while. I'm hoping that getting clarification on this sort of thing will happen under whatever governance model we end up choosing. The last time we tried to establish a procedure I remember the one thing we could agree on was that this list be made aware of any actions taken, hence my email. If people disagree with the ban or want to time-box it then that discussion can happen. I will also mention that I asked other core developers here at the dev sprints to make sure this action was not being too reactionary due to how I was involved and the consensus was to proceed with the ban and the email as planned (there was only some disagreement on for how long and they said they would follow up here). I will also say that other core devs actually wanted a ban to start based on the GitHub comment left and I argued the person deserved a chance based on how heated the topic involved has become. -Brett > > Regards > > Antoine. > > > Le 13/09/2018 ? 18:19, Mariatta Wijaya a ?crit : > > Thanks for handling it, Brett. > > > > That kind of behavior is not something we need to allow or tolerate in > > this community. > > I'm fine with banning. > > > > Mariatta > > > > ? > > > > On Thu, Sep 13, 2018 at 9:18 AM Brett Cannon > > wrote: > > > > Someone left > > https://github.com/python/cpython/pull/9195#issuecomment-420646466 > > which was clearly written to upset Victor and insult him. I warned > > the person that such behaviour is not okay and future insults would > > have ramifications (I was actually asked to ban this person to > > begin with but I gave them the benefit of the doubt considering how > > heated the topic involved has become). They then decided to seek me > > out on Twitter berate me there for my warning: > > https://twitter.com/dolkensp/status/1039949212832722944 . For that I > > have followed through with my warning and banned them from the org. > > _______________________________________________ > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Thu Sep 13 12:38:05 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 13 Sep 2018 18:38:05 +0200 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: References: <345b1b82-ce9c-d9a6-6741-4bdc11ff864b@python.org> Message-ID: <608a82c0-a5d7-5039-4523-3e417fdcdd48@python.org> Thanks for clarifying. I agree we should probably time-box the banning (by how long isn't very important, and would depend whether they are otherwise an active contributor or not). Regards Antoine. Le 13/09/2018 ? 18:35, Brett Cannon a ?crit?: > > > On Thu, 13 Sep 2018 at 09:23 Antoine Pitrou > wrote: > > > Regardless of whether that behaviour should be tolerated or not, there > should be a procedure for this and not a single person banning other > people at will, especially if it follows their own involvement on the > topic at hand. > > > There should be, but there currently isn't one and with no governance > model we unfortunately won't have one for at least a little while. I'm > hoping that getting clarification on this sort of thing will happen > under whatever governance model we end up choosing. > > The last time we tried to establish a procedure I remember the one thing > we could agree on was that this list be made aware of any actions taken, > hence my email. If people disagree with the ban or want to time-box it > then that discussion can happen. > > I will also mention that I asked other core developers here at the dev > sprints to make sure this action was not being too reactionary due to > how I was involved and the consensus was to proceed with the ban and the > email as planned (there was only some disagreement on for how long and > they said they would follow up here). I will also say that other core > devs actually wanted a ban to start based on the GitHub comment left and > I argued the person deserved a chance based on how heated the topic > involved has become. > > -Brett > > ? > > > Regards > > Antoine. > > > Le 13/09/2018 ? 18:19, Mariatta Wijaya a ?crit?: > > Thanks for handling it, Brett. > > > > That kind of behavior is not something we need to allow or tolerate in > > this community. > > I'm fine with banning. > > > > Mariatta > > > > ? > > > > On Thu, Sep 13, 2018 at 9:18 AM Brett Cannon > > >> wrote: > > > >? ? ?Someone left > >? ? ?https://github.com/python/cpython/pull/9195#issuecomment-420646466 > >? ? ?which was clearly written to upset Victor and insult him. I warned > >? ? ?the person that such behaviour is not okay and future insults > would > >? ? ?have? ramifications (I was actually asked to ban this person to > >? ? ?begin with but I gave them the benefit of the doubt > considering how > >? ? ?heated the topic involved has become). They then decided to > seek me > >? ? ?out on Twitter berate me there for my warning: > >? ? ?https://twitter.com/dolkensp/status/1039949212832722944 . For > that I > >? ? ?have followed through with my warning and banned them from the > org. > >? ? ?_______________________________________________ > >? ? ?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 brett at python.org Thu Sep 13 12:55:14 2018 From: brett at python.org (Brett Cannon) Date: Thu, 13 Sep 2018 09:55:14 -0700 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: <608a82c0-a5d7-5039-4523-3e417fdcdd48@python.org> References: <345b1b82-ce9c-d9a6-6741-4bdc11ff864b@python.org> <608a82c0-a5d7-5039-4523-3e417fdcdd48@python.org> Message-ID: They are not active in our community, although I don't know if we want to start treating people different simply because they are in our community (treating them differently because we know something is out of character is different). Because I'm in no position mentally to keep an eye on this (I'm rather shaken by the fact someone decided to track me down on Twitter to go after me, but I'm trying to keep context of the actual severity of it), I have switched it to an automated 30 day ban (the maximum available for a time-restricted ban). If people feel that's the wrong decision and it should switch to year-long or permanent then we can discuss that. On Thu, 13 Sep 2018 at 09:38 Antoine Pitrou wrote: > > Thanks for clarifying. I agree we should probably time-box the banning > (by how long isn't very important, and would depend whether they are > otherwise an active contributor or not). > > Regards > > Antoine. > > > Le 13/09/2018 ? 18:35, Brett Cannon a ?crit : > > > > > > On Thu, 13 Sep 2018 at 09:23 Antoine Pitrou > > wrote: > > > > > > Regardless of whether that behaviour should be tolerated or not, > there > > should be a procedure for this and not a single person banning other > > people at will, especially if it follows their own involvement on the > > topic at hand. > > > > > > There should be, but there currently isn't one and with no governance > > model we unfortunately won't have one for at least a little while. I'm > > hoping that getting clarification on this sort of thing will happen > > under whatever governance model we end up choosing. > > > > The last time we tried to establish a procedure I remember the one thing > > we could agree on was that this list be made aware of any actions taken, > > hence my email. If people disagree with the ban or want to time-box it > > then that discussion can happen. > > > > I will also mention that I asked other core developers here at the dev > > sprints to make sure this action was not being too reactionary due to > > how I was involved and the consensus was to proceed with the ban and the > > email as planned (there was only some disagreement on for how long and > > they said they would follow up here). I will also say that other core > > devs actually wanted a ban to start based on the GitHub comment left and > > I argued the person deserved a chance based on how heated the topic > > involved has become. > > > > -Brett > > > > > > > > > > Regards > > > > Antoine. > > > > > > Le 13/09/2018 ? 18:19, Mariatta Wijaya a ?crit : > > > Thanks for handling it, Brett. > > > > > > That kind of behavior is not something we need to allow or > tolerate in > > > this community. > > > I'm fine with banning. > > > > > > Mariatta > > > > > > ? > > > > > > On Thu, Sep 13, 2018 at 9:18 AM Brett Cannon > > > > >> wrote: > > > > > > Someone left > > > > https://github.com/python/cpython/pull/9195#issuecomment-420646466 > > > which was clearly written to upset Victor and insult him. I > warned > > > the person that such behaviour is not okay and future insults > > would > > > have ramifications (I was actually asked to ban this person to > > > begin with but I gave them the benefit of the doubt > > considering how > > > heated the topic involved has become). They then decided to > > seek me > > > out on Twitter berate me there for my warning: > > > https://twitter.com/dolkensp/status/1039949212832722944 . For > > that I > > > have followed through with my warning and banned them from the > > org. > > > _______________________________________________ > > > 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/ > > > _______________________________________________ > 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 ethan at stoneleaf.us Thu Sep 13 12:59:29 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 13 Sep 2018 09:59:29 -0700 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: References: Message-ID: <3934a016-c6f2-f153-a60d-2685f3924a86@stoneleaf.us> Thanks, Brett. -- ~Ethan~ From christian at python.org Thu Sep 13 13:01:12 2018 From: christian at python.org (Christian Heimes) Date: Thu, 13 Sep 2018 10:01:12 -0700 Subject: [python-committers] I have blocked someone from the Python org In-Reply-To: References: Message-ID: <4b526ed0-d0ec-69c8-0f75-6b278f78373e@python.org> +1 Thanks, Brett! From vstinner at redhat.com Thu Sep 13 14:16:35 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 13 Sep 2018 20:16:35 +0200 Subject: [python-committers] Automerge bot deployed In-Reply-To: References: Message-ID: Ah yes, it works and I agree that it's OK in plain text. But we have careful if a contributor uses "\_" or something like that in a description. Maybe always edit to see the "source" of the description? Victor Le jeu. 13 sept. 2018 ? 16:54, Petr Viktorin a ?crit : > > > On Wed, Sep 12, 2018, 23:30 Victor Stinner wrote: > >> Today I created a PR with a description containing "type.__format__()". >> To display it properly, I chose to edit the description and write >> "type.\_\_format\_\_()". I guess that the bot will merge a description like >> that unchanged, right? So we should also be careful of description using >> Markdown syntax. >> > > Use `type.__format__`, with backticks, for code. That looks OK in plain > text. > Or edit before merging :) > > >> Victor >> >> Le mer. 12 sept. 2018 ? 18:52, Mariatta Wijaya >> a ?crit : >> >>> Update to the automerge bot: >>> >>> It will not merge unless there is "CLA signed" label, and no >>> "DO-NOT-MERGE" label. >>> >>> Again, please edit the PR title and description before adding the `? >>> automerge` label. >>> The PR title and description will be used as the squashed commit message. >>> >>> Mariatta? >>> ? >>> _______________________________________________ >>> 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 donald at stufft.io Thu Sep 13 14:18:14 2018 From: donald at stufft.io (Donald Stufft) Date: Thu, 13 Sep 2018 14:18:14 -0400 Subject: [python-committers] Automerge bot deployed In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From raymond.hettinger at gmail.com Fri Sep 14 15:28:45 2018 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Fri, 14 Sep 2018 12:28:45 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel Message-ID: At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. Please join me in welcoming them to the team. Raymond ------------------------------- Emily is the Director of Engineering at Cuttlesoft. She has previously attended two Language Summits and three core development sprints at PyCon. Since July, Emily has worked with Guido's guidance to implement PEP 572, Assignment Expressions. She has also worked with Eric Snow to dive into CPython's runtime as well as subinterpreters. This year at PyCon she gave a talk on Python's AST. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk video: https://www.youtube.com/watch?v=XhWvz4dK4ng Lisa has a background in network engineering and supported the Cisco sale engineer team to develop high quality Python product demonstrations. Later she moved to the Facebook security team. This is her third core developer sprint. She and Guido are co-authors of PEP 526, Syntax for Variable Annotations. Last year, she worked with Eric Smith on PEP 557, Data Classes. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and https://www.youtube.com/watch?v=ww1UsGZV8fQ From guido at python.org Fri Sep 14 15:36:12 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 14 Sep 2018 12:36:12 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Congrats Emily and Lisa! ? ? ? ? ? ? On Fri, Sep 14, 2018 at 12:28 PM Raymond Hettinger < raymond.hettinger at gmail.com> wrote: > At the developer sprints this week, we collectively decided to grant core > committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Raymond > > > ------------------------------- > > Emily is the Director of Engineering at Cuttlesoft. She has previously > attended two Language Summits and three core development sprints at PyCon. > Since July, Emily has worked with Guido's guidance to implement PEP 572, > Assignment Expressions. She has also worked with Eric Snow to dive into > CPython's runtime as well as subinterpreters. This year at PyCon she gave > a talk on Python's AST. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk > video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > Lisa has a background in network engineering and supported the Cisco sale > engineer team to develop high quality Python product demonstrations. Later > she moved to the Facebook security team. This is her third core developer > sprint. She and Guido are co-authors of PEP 526, Syntax for Variable > Annotations. Last year, she worked with Eric Smith on PEP 557, Data > Classes. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon > talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and > https://www.youtube.com/watch?v=ww1UsGZV8fQ > _______________________________________________ > 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/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericsnowcurrently at gmail.com Fri Sep 14 15:38:14 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Fri, 14 Sep 2018 12:38:14 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Welcome, Emily and Lisa! My interactions with Lisa have been limited to several conversations, albeit positive ones. I've been working closely with Emily since PyCon and have come to respect her intelligence, thoughtfulness, and insight. Furthermore I'm glad that we have another member of the core team with a deep understanding of the compiler and runtime. :) Anyway, congratulations to both for the well-deserved recognition. I'll looking forward to further collaboration. -eric On Fri, Sep 14, 2018 at 12:28 PM Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Raymond > > > ------------------------------- > > Emily is the Director of Engineering at Cuttlesoft. She has previously attended two Language Summits and three core development sprints at PyCon. Since July, Emily has worked with Guido's guidance to implement PEP 572, Assignment Expressions. She has also worked with Eric Snow to dive into CPython's runtime as well as subinterpreters. This year at PyCon she gave a talk on Python's AST. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > Lisa has a background in network engineering and supported the Cisco sale engineer team to develop high quality Python product demonstrations. Later she moved to the Facebook security team. This is her third core developer sprint. She and Guido are co-authors of PEP 526, Syntax for Variable Annotations. Last year, she worked with Eric Smith on PEP 557, Data Classes. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and https://www.youtube.com/watch?v=ww1UsGZV8fQ > _______________________________________________ > 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 willingc at gmail.com Fri Sep 14 15:53:51 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 14 Sep 2018 12:53:51 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Welcome!!!! Well deserved :-) On Fri, Sep 14, 2018, 12:38 PM Eric Snow wrote: > Welcome, Emily and Lisa! > > My interactions with Lisa have been limited to several conversations, > albeit positive ones. I've been working closely with Emily since > PyCon and have come to respect her intelligence, thoughtfulness, and > insight. Furthermore I'm glad that we have another member of the core > team with a deep understanding of the compiler and runtime. :) > > Anyway, congratulations to both for the well-deserved recognition. > I'll looking forward to further collaboration. > > -eric > > On Fri, Sep 14, 2018 at 12:28 PM Raymond Hettinger > wrote: > > > > At the developer sprints this week, we collectively decided to grant > core committer status to Emily and Lisa. > > > > Please join me in welcoming them to the team. > > > > > > Raymond > > > > > > ------------------------------- > > > > Emily is the Director of Engineering at Cuttlesoft. She has previously > attended two Language Summits and three core development sprints at PyCon. > Since July, Emily has worked with Guido's guidance to implement PEP 572, > Assignment Expressions. She has also worked with Eric Snow to dive into > CPython's runtime as well as subinterpreters. This year at PyCon she gave > a talk on Python's AST. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk > video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > > > Lisa has a background in network engineering and supported the Cisco > sale engineer team to develop high quality Python product demonstrations. > Later she moved to the Facebook security team. This is her third core > developer sprint. She and Guido are co-authors of PEP 526, Syntax for > Variable Annotations. Last year, she worked with Eric Smith on PEP 557, > Data Classes. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon > talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and > https://www.youtube.com/watch?v=ww1UsGZV8fQ > > _______________________________________________ > > 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 zachary.ware+pydev at gmail.com Fri Sep 14 16:12:43 2018 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Fri, 14 Sep 2018 13:12:43 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: On Fri, Sep 14, 2018 at 12:28 PM Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. Congratulations and welcome, Emily and Lisa! -- Zach From zachary.ware+pydev at gmail.com Fri Sep 14 17:02:19 2018 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Fri, 14 Sep 2018 14:02:19 -0700 Subject: [python-committers] Recent buildbot.python.org changes Message-ID: Hi all, Most of my effort this week has gone into improving the state of buildbot.python.org, which has largely gone into improving Buildbot itself. Here are the relevant highlights: - Anyone can now log into buildbot.python.org via GitHub by clicking the 'Anonymous' dropdown in the upper right corner, then 'Login with GitHub'. The first time, GitHub will ask you for approval; subsequently you'll just be logged right in. - Stopping builds and triggering rebuilds is now restricted to members of the `python-core` team and the "owner" of a build. I've not had opportunity to test whether the author of a commit actually qualifies as the "owner" or if only the committer does, but if anyone runs into trouble with it please open an issue on the buildmaster-config repo. - Disabling/enabling schedulers is now restricted to members of the `python-release-managers` team. We had an issue some months ago where someone had apparently disabled the scheduler for one of our branches, resulting in no builds on that branch for several days before we noticed. That shouldn't happen again! - Buildbot now reports results from our stable builders on each tested commit. For now, we're still only running tests post-merge, so you won't see new status checks on PRs, but you can find results on https://github.com/python/cpython/commits/ Let me know if any of these changes negatively impact you, or if you have suggestions for further improvement. Regards, -- Zach From njs at pobox.com Fri Sep 14 17:16:41 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 14 Sep 2018 14:16:41 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Congratulations! On Fri, Sep 14, 2018, 12:29 Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core > committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Raymond > > > ------------------------------- > > Emily is the Director of Engineering at Cuttlesoft. She has previously > attended two Language Summits and three core development sprints at PyCon. > Since July, Emily has worked with Guido's guidance to implement PEP 572, > Assignment Expressions. She has also worked with Eric Snow to dive into > CPython's runtime as well as subinterpreters. This year at PyCon she gave > a talk on Python's AST. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk > video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > Lisa has a background in network engineering and supported the Cisco sale > engineer team to develop high quality Python product demonstrations. Later > she moved to the Facebook security team. This is her third core developer > sprint. She and Guido are co-authors of PEP 526, Syntax for Variable > Annotations. Last year, she worked with Eric Smith on PEP 557, Data > Classes. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon > talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and > https://www.youtube.com/watch?v=ww1UsGZV8fQ > _______________________________________________ > 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 christian at python.org Fri Sep 14 17:25:48 2018 From: christian at python.org (Christian Heimes) Date: Fri, 14 Sep 2018 14:25:48 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: <6c6e64ee-ec2a-57df-1ccc-9c99dc75a1ac@python.org> On 14/09/2018 12.28, Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. Welcome on board! From p.f.moore at gmail.com Fri Sep 14 17:29:45 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 14 Sep 2018 22:29:45 +0100 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: On Fri, 14 Sep 2018 at 20:29, Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. Congratulations and welcome, Emily and Lisa! Paul From ethan at stoneleaf.us Fri Sep 14 17:41:49 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 14 Sep 2018 14:41:49 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: <0eed4e79-4977-5962-8573-25d54141960a@stoneleaf.us> On 09/14/2018 12:28 PM, Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. Woohoo!!! I thought you two were already core-devs -- I'm happy to see it is now so! -- ~Ethan~ From vstinner at redhat.com Fri Sep 14 18:05:15 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 15 Sep 2018 00:05:15 +0200 Subject: [python-committers] Recent buildbot.python.org changes In-Reply-To: References: Message-ID: Le ven. 14 sept. 2018 ? 23:02, Zachary Ware a ?crit : > - Stopping builds and triggering rebuilds is now restricted to members > of the `python-core` team (...) Cool, security! > - Buildbot now reports results from our stable builders on each tested > commit. For now, we're still only running tests post-merge, so you > won't see new status checks on PRs, but you can find results on > https://github.com/python/cpython/commits/ That's also cool, thanks Zach! Victor From pablogsal at gmail.com Fri Sep 14 18:06:07 2018 From: pablogsal at gmail.com (Pablo Galindo Salgado) Date: Fri, 14 Sep 2018 15:06:07 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Congratulations! Very well deserved :-) On Fri, 14 Sep 2018 at 12:28, Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core > committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Raymond > > > ------------------------------- > > Emily is the Director of Engineering at Cuttlesoft. She has previously > attended two Language Summits and three core development sprints at PyCon. > Since July, Emily has worked with Guido's guidance to implement PEP 572, > Assignment Expressions. She has also worked with Eric Snow to dive into > CPython's runtime as well as subinterpreters. This year at PyCon she gave > a talk on Python's AST. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk > video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > Lisa has a background in network engineering and supported the Cisco sale > engineer team to develop high quality Python product demonstrations. Later > she moved to the Facebook security team. This is her third core developer > sprint. She and Guido are co-authors of PEP 526, Syntax for Variable > Annotations. Last year, she worked with Eric Smith on PEP 557, Data > Classes. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon > talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and > https://www.youtube.com/watch?v=ww1UsGZV8fQ > _______________________________________________ > 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 benjamin at python.org Fri Sep 14 19:10:33 2018 From: benjamin at python.org (Benjamin Peterson) Date: Fri, 14 Sep 2018 16:10:33 -0700 Subject: [python-committers] Recent buildbot.python.org changes In-Reply-To: References: Message-ID: <1536966633.3632660.1508696128.04FD5EB7@webmail.messagingengine.com> On Fri, Sep 14, 2018, at 14:02, Zachary Ware wrote: > Hi all, > > Most of my effort this week has gone into improving the state of > buildbot.python.org, which has largely gone into improving Buildbot > itself. Here are the relevant highlights: > > - Anyone can now log into buildbot.python.org via GitHub by clicking > the 'Anonymous' dropdown in the upper right corner, then 'Login with > GitHub'. The first time, GitHub will ask you for approval; > subsequently you'll just be logged right in. > > - Stopping builds and triggering rebuilds is now restricted to members > of the `python-core` team and the "owner" of a build. I've not had > opportunity to test whether the author of a commit actually qualifies > as the "owner" or if only the committer does, but if anyone runs into > trouble with it please open an issue on the buildmaster-config repo. > > - Disabling/enabling schedulers is now restricted to members of the > `python-release-managers` team. We had an issue some months ago where > someone had apparently disabled the scheduler for one of our branches, > resulting in no builds on that branch for several days before we > noticed. That shouldn't happen again! > > - Buildbot now reports results from our stable builders on each tested > commit. For now, we're still only running tests post-merge, so you > won't see new status checks on PRs, but you can find results on > https://github.com/python/cpython/commits/ > > Let me know if any of these changes negatively impact you, or if you > have suggestions for further improvement. Thanks for all your work. From ethan at stoneleaf.us Fri Sep 14 20:11:29 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 14 Sep 2018 17:11:29 -0700 Subject: [python-committers] Recent buildbot.python.org changes In-Reply-To: References: Message-ID: <6e4f3a64-f6ab-23d3-dc60-b7ad1f047d3e@stoneleaf.us> On 09/14/2018 02:02 PM, Zachary Ware wrote: > Most of my effort this week has gone into improving the state of > buildbot.python.org, which has largely gone into improving Buildbot > itself. Excellent! Better tools are always welcome. Thank you! -- ~Ethan~ From antoine at python.org Sat Sep 15 11:47:29 2018 From: antoine at python.org (Antoine Pitrou) Date: Sat, 15 Sep 2018 17:47:29 +0200 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Emily and Lisa: welcome to the core team! (style note: I almost missed the presentations after the long line of dashes) Best regards Antoine. Le 14/09/2018 ? 21:28, Raymond Hettinger a ?crit?: > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Raymond > > > ------------------------------- > > Emily is the Director of Engineering at Cuttlesoft. She has previously attended two Language Summits and three core development sprints at PyCon. Since July, Emily has worked with Guido's guidance to implement PEP 572, Assignment Expressions. She has also worked with Eric Snow to dive into CPython's runtime as well as subinterpreters. This year at PyCon she gave a talk on Python's AST. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > Lisa has a background in network engineering and supported the Cisco sale engineer team to develop high quality Python product demonstrations. Later she moved to the Facebook security team. This is her third core developer sprint. She and Guido are co-authors of PEP 526, Syntax for Variable Annotations. Last year, she worked with Eric Smith on PEP 557, Data Classes. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and https://www.youtube.com/watch?v=ww1UsGZV8fQ > _______________________________________________ > 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 larry at hastings.org Sat Sep 15 13:47:38 2018 From: larry at hastings.org (Larry Hastings) Date: Sat, 15 Sep 2018 10:47:38 -0700 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: On 09/14/2018 12:28 PM, Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. Congratulations Emily and Lisa!? I look forward to many years of arguing working with you on our favorite language. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Sat Sep 15 23:20:17 2018 From: steve.dower at python.org (Steve Dower) Date: Sat, 15 Sep 2018 20:20:17 -0700 Subject: [python-committers] Governance Discussion #1 Notes Message-ID: <7e871cbd-4a9f-cf3a-6f2b-4b4957044385@python.org> Hi all At the sprints this last week, probably unsurprisingly, we had some discussions relating to the future of Python's governance. Since not everyone could be involved, I'm going to be posting the notes from these meetings (taken by an independent note-taken, and reviewed/redacted by the participants before being made public). I want to be very clear that no final decisions were made at these meetings, but they were very helpful in helping those of us working on concrete proposals. You should start seeing PEPs 80xx filling out with content over the next few weeks. *Those* are the reference documents - these notes are simply a record of what came out. If you want to reply to and discuss particular points from these, *please* reply to the list, change the subject line, and clearly quote only the relevant part. There is a lot of content here and nothing to be gained by repeating it endlessly. (Also, if you want to thank me for copy-pasting into an email, it really is unnecessary but please do it off-list. We've already passed on our thanks to the note-taker as well.) For this first meeting, roughly 30 of us sat/stood in a circle and briefly answered two questions: * what are you most concerned about right now? * in one word, what do you like most about Python? These notes are an anonymised, paraphrased, reorganised summary of the responses. Responses that deserved an immediate follow up have (as far as I'm aware) received it already. So take this as a bit more insight into community sentiment than could otherwise be obtained over email, but as nothing more significant than that. Cheers, Steve --- Python's Benevolent-Dictator-For-Life (BDFL) Guido has stepped down, which raises the question of how Python's core development team should proceed when making decisions about changes to Python. The attendees of the sprint had a meeting to sit down and all concisely express their biggest concerns. I took notes as people were speaking; hopefully I captured the gist of what they were saying if not their exact words. I'll start with a quick summary and the plan for immediate next steps, and then give individual points loosely grouped by broad area of concern. Executive summary: The biggest areas of concern are: * Choosing how to choose a new governance model * The principles that will guide the future of python * Effective, respectful communication and related social factors * related: Code of conduct issues, which already have a PSF working group looking into them. We went around the room and asked people to give a one or two word summary of what they like about Python. * community * people * elegance * consistency * ease for non-experts * good taste * accessibility * opportunity * productivity * trust * zen * fun * openness * thoughtfulness * Monty :-) Next steps: * Digest what we've discussed overnight * Meet in the morning and organize by areas of particular concern * Discuss further * Report back Specific concerns raised by individuals follow. These have been anonymized and rearranged, and are individual contributions and do not reflect any official position, or even necessarily a majority position of the core development team. Introductory thoughts: * Complexity is real * Any number of plans could work * What behaviours help communities be effective? * Which produce roadblocks and challenges? * What do we value about Python? Choosing how to choose: * There will be various proposals for governance models. How do we pick one? Can we get to consensus on that? * There's a PEP out to discuss how this process works in other languages. * Vote on a committee that makes governance recommendations * Give a small group of people a mandate to study and make recommendations * Can we determine what are roles that need to be filled? * Do not get bogged down in the meta-question of how to choose how to choose. * Any important change requires a working group of experts in the specific area affected by the change. How to choose members of this group? * Can we define the scope of problems that we need to bring to a higher authority? * Having working groups with autonomy is great, but there will be things where all the threads come together. Changes to the C API, changes to the core syntax. * We have always appealed to Guido's sensibilities, and that's where the power vacuum is now. Think about something like the Debian technical committee, where they make decisions that affect everyone in that community. * Some people will be unhappy with whatever decision is made, but we want people to agree that there is a clear authority and a process that is respected and legitimate. * Our existing model has BDFL delegates for specific issues. How should power be delegated to make specific decisions about features? Who can say "this will not happen"? * It's pretty nice to have a dictatorship when you have a good dictator. A democracy does not guarantee that the best choice will be made, or even that the will of the majority is carried out. * The language is now sufficiently complex that it may be difficult to have any individual that understands the whole thing enough to make decisions unilaterally. * Without a way to make the decision it is all talk; how do we have a consensus? * We should accept that we're not going to get to unanimity * What is the externally visible legitimacy of any decision process? If 52% say yes and the other 48% say no, is the decision legitimate? * The state we're in now is scary but many other projects have been here, like numpy. We need to shift from our respect for Guido to a shared sense of what's the right process, even if we don't agree on every detail. A 51% vote is not a good thing. * We are experts on programming languages, not on governance and decision making. Maybe bring in an expert on decision making models if this meta problem is going to get really thorny. * There are models of decision making that have been studied by experts and their characteristics are known. These models are all pretty good; pick a decision-making model and discuss it. * Think about what has worked well in the past and has not worked well. We've had a successful process delegating issues before. Maybe we don't need to worry too much about the fine details of delegation. We could fall into the trap of making this process too complicated, too overspecified and too legalistic. * The core development community is not as diverse as the broader Python community. Attitudes of the people making these governance decisions may not be aligned with those of the communities they're intending to serve. How can we address this? * People are too afraid of changes; we don't need a PEP or a formal process or a decision from Guido for everything. Some changes can just be made by people we trust to make good decisions. * Continue to rely on experts when making decisions about their areas of expertise. * There are disruption risks of changing too quickly but there are existential risks in changing too slowly. * The model so far is that the patriarch lets the kids run around but keeps them from running over the cliff. * Making one person or a small group an oracle for what is good is unfair and unrealistic, particularly if they have to not only understand and make decisions about every aspect of the language but also police bad process outcomes. * Consider models of projects that work; get people involved who are experts on project management and process. We need a Counsellor Troi for this project. Get a professional coach involved, who is already involved in successfully governed Python projects, for example the Jupyter project and the Django project. * If someone does not aspire to be leadership but still has something to offer, are they shut out of the decision-making process? If important things come up, people with depth of experience need to be heard and feel that they are heard. * No one really wants decision by committee and what that entails. * Historically we see that when there is a change in governance model and power structure, there will be a challenge. Hopefully there will not be a villain that brings us together. * Whatever we do, hopefully it will not require more effort by the volunteers of the core team; we like to work on technical issues rather than navigating political organizations and heavyweight processes. * Our work is founded on trust; take that into account and keep it from falling apart * Every core developer should have an idea of what they want to see from Python in the next five years. That will motivate choice of governance model. * Keep moving forward and get a governance decision made. We don't want to make a panic decision, but we don't want to sit and wait either. Figure out what we want and execute on it. * This is a human factors problem; burnout exists everywhere in an organization. Understand the roles that we are trying to refactor. * Things will not be the same, some changes will go smoothly, and some will not, and then they'll say that in the old days, things were great. * Define what roles need to be filled; that affects everything. * We should choose how we're going to choose before we leave, while being considerate of people who are not here. * Be clear that any new model of governance is specifically for core devs, not for the Python community as a whole What's important? * Python is a popular language; anything we change has a large impact and we need to take that seriously. Can we agree on how impactful decisions can be, and make sure that a governance process takes impact seriously? * Explicit is better than implicit; Guido is a mountain of implicit knowledge, and there is no one close to that. * We need a set of slogans or principles that summarize our design values; the Zen of Python is poetic and aspirational, but we should decide more specifically what Python should be or we will end up with C++ * What are the goals of Python as a language? Do we value stability, or evolving to achieve feature parity with other languages? Do we want to evolve fast or slow? Do we value performance or compatibility? It's easy to say "both", but design is about making compromises. The relationship between the PSF board and the core dev community * The role of a board member is to fulfill the mission of the organization in accordance with its guiding principles. * What are those guiding principles? Consistency, stability? What else? * What specific communities of users and developers are served? * Where does the PSF and its board of directors fit in to this decision? * Core developers don't see the PSF very often, and non-core-dev board members don't see much of what the developers are doing. * Does the board want to be involved in this process? * We should make sure that the board and the core devs are on the same track and share common goals * There is a clear difference between how the board sees the core developers and what the core developers do. New board members often ask how much influence they have on how core developers do their work. Very little. * The PSF owns the trademark and therefore what is done with the codebase. * Core developers are expected to participate in language development and writing code, not, say, raising money. The foundation manages that. Communicating decisions * How will this decision be communicated to the world? * People don't like to read long governance documents. * Get this sorted out well before the next pycon. The decision should be formally announced there, but it should be well known and accepted throughout the community long before that. Email is terrible, except when it isn't * The email list mechanism is both boring and annoying. Can we find another tool? * Python dev mailing list has 20K subscribers which is a scarily large number given the level of discussion. * The mailing list used to function better: * The participants were not necessarily nicer; some were mean, but the problem solving was effective. * How did those people interact together? * Get old timers out of retirement to participate and model effective problem solving. * What communication techniques can be used for problem solving that have intellectual depth while ensuring that everyone is heard? * It's easy to criticize the email lists but remember that these lists do in general work pretty well. Process suggestions and concerns * When someone exits a role, consider an exit interview. How do we not repeat mistakes of the past? (Not to put Guido on the spot.) * We took Guido for granted, and now need codification of those processes. * The PEP process is the biggest part of how we design python and it needs to be redesigned. We need a tighter PEP process with stages and rules. * The PEP process is more difficult than it needs to be. Conduct, and its code * The forum process dismisses and belittles people. That's not OK on the face of it, but worse, the people who are bullied are allies, contributors and advocates for this language. * The code of conduct feels like it is ostensibly there to protect people from abuse, but in fact can be used as a weapon against people who want to contribute * Python dev doesn't feel like a safe forum. We can't continue to let that happen. Women with deep knowledge and industry experience have real serious reasons to avoid this forum. * We need to change our interactions before a change of governance has a chance to work * There are "hot" topics that people are overly "active" in their participation; the code of conduct should be applied there. But let's remember that in general our communication mechanisms work well most of the time. We're capable of making good decisions. * If you see something that doesn't seem right on a list, mail a moderator; moderators don't see everything. * Maybe apologize once in a while. We have a responsibility to each other and to owning our mistakes. * Being a core developer is as much about establishing trust with each other as it does with technical ability. Work on establishing trust. * The metric of a successful technical decision is not its technical merit; it's whether everyone feels like they were heard. If it's a hard technical decision then you need a diverse set of opinions to get confidence that you've arrived at a good decision. And making people feel heard keeps them around and wanting to participate. * The code of conduct is supposed to make people feel more included but can make people feel excluded. * There are experts on this; get them involved. They're sensitive to being humane through this process. Pycon brought in consultants for this. * There is a conduct working group taking a holistic view, the board has approved getting help on this. * How does this affect core devs? We need buy-in. * The process is not far involved yet; just got budget. * Code of conduct enforcement should be prompt, kind and firm; don't get into a state where everyone is screaming at each other. From steve.dower at python.org Sat Sep 15 23:22:12 2018 From: steve.dower at python.org (Steve Dower) Date: Sat, 15 Sep 2018 20:22:12 -0700 Subject: [python-committers] Governance Discussion #2 Notes Message-ID: <0f755e9b-a910-4082-e29d-8d160bfcc860@python.org> Hi all At the sprints this last week, probably unsurprisingly, we had some discussions relating to the future of Python's governance. Since not everyone could be involved, I'm going to be posting the notes from these meetings (taken by an independent note-taken, and reviewed/redacted by the participants before being made public). I want to be very clear that no final decisions were made at these meetings, but they were very helpful in helping those of us working on concrete proposals. You should start seeing PEPs 80xx filling out with content over the next few weeks. *Those* are the reference documents - these notes are simply a record of what came out of discussions. If you want to reply to and discuss particular points from these, *please* reply to the list, change the subject line, and clearly quote only the relevant part. There is a lot of content here and nothing to be gained by repeating it endlessly. (Also, if you want to thank me for copy-pasting into an email, it really is unnecessary but please do it off-list. We've already passed on our thanks to the note-taker as well.) For this second meeting, we reduced the audience to those particularly interested in the governance models. We had four represented there, which will be written up as PEPs 8010, 8011, 8012 and 8013 over the next few weeks. I have inserted links to the current drafts of these in the notes, though at this stage they are mostly still placeholders. Again, the proposals that we will vote on will be accurately described in the PEPs. the notes here are basically inaccurate summaries of the discussion, but we are sharing the notes to help everyone get a sense of what values we are thinking about when designing proposals, and the aspects of Python development that we like and the ones we want to change. This is not the thread to start arguing about details - if anything in this email makes you upset or nervous, please assume that the email is at fault and wait for the actual proposals. Cheers, Steve --- The previous meeting showed that there were three main areas of concern: * What do we want the culture of the team to be? * How do we want to interact with each other and with the larger Python community? * How can we build a system that encourages those interactions? * Example: if we don't use a mailing list, what do we use? * What's the five year plan of python? * How do we decide on a governance model? These are deeply interrelated questions; notes that follow attempt to summarize various contributor's points: * The answers to the first two questions can be determined by the new governance, whatever that is. * We must quickly get away from the perception that Python is leaderless. * We need specific structures, with specific people. * Both those structures and the people must be selected by a process that is perceived to be fair and open, without all our energy being consumed by debate about minutia. * It will be difficult to decide anything else until there is a clear leadership structure. * If we have multiple people who want a focus on async, or on performance, or on typing, we need some way to resolve what should be the focus for the next five years. * These all influence each other. "Where do we want Python to go?" is very germane to "what should the leadership model be?" * We can end up in a rathole. Can we identify constituencies that we want to serve? Education, science, kids, whatever. The structure is less important than choosing a structure and working towards goals that serve constituencies within that structure. * Governance is also heavily tied to communication: how do we make mundane decisions, how do we resolve controversies? This is all about communication. Other languages have specified details of their communication models in their governance arrangement: we put our notes here, we communicate with this channel, and so on * There may be different decision-making and communication models for different areas. * If you have a BDFL, do they take on everything Guido took on? Or are they the titular spokesperson who interfaces with the public, and delegates other decisions to committees? * Having no governance model is worse than having a suboptimal model. * The US Constitution was written knowing that the first order of business would be the Bill of Rights. * What is our list of things that we know we need to deal with as soon as we have a governance model? * Deciding how to commit to a governance model has highest priority. * Our goal should be to achieve general consensus on what looks like a fair voting model before we vote. * Wherever we end up at the end, we want the leadership to be perceived as legitimate and backed by the community. * The greater good is more important than any particular desired detail. * The governance model has to be backed by goodwill. * Should we first determine where Python is going, in order to ensure that the governance model supports it? * "I disagree with the details but I support the process" should be the goal * Python's governance model has been an active, top-down decision maker; most open source projects have a much more hands-off steering council. Split Guido's current roles across both formal, hands-off top-down model, and an organic, bottom-up community based model. * Do we know who wants to take a leadership role? * Are there people who want to actively be involved as a BDFL, a triumvirate, a council, and so on? * If we only have one volunteer for BDFL, this is a waste of time. * Triumvirates form as a mechanism for resolving conflict amongst leaders. * What if no one wants to step into a leadership role? * More people will be involved in lesser roles. * We can probably find five people who want to be involved in a council. * But perhaps nothing will happen with a leadership group of that size. * What about looking at it the other way: who will go along with whatever structure gets put in place? * Those people are contributors, not leaders, and they don't have to be involved in the discussion. * Three main proposals: (1) BDFL with advisory council and working groups model. (2) No BDFL, steering committee of say three people. (3) pure democracy, community driven, only working groups. * Can we aim for initial draft PEPs October 1st? * Each of these can be parameterized * If no one is interested enough to even write a proposal, we can reject it. * A rejection of a specific proposal is not an endorsement of its opposite. * Roles granted in perpetuity? Or a cycle? * This question should go into a session * These are parameters to the proposals -------------------------------------------------- Follow up two: Champion your ideas But remember this is not a competition; this is about doing what's best for Python Quick summary of earlier voting discussion: restricted to core developers who currently have commit bit (or who have commit bit by end of this week) ask people who are not affected by the decision to abstain private repo to post votes * votes will be made public after; this is not an anonymous vote * voting for individual positions later will likely be anonymous * this system encourages dialog * many people are fine with any of the proposed options but they have opinions about what is best * a public process helps avoid backroom complaining * it seems acceptable to have public vote on governance issues * quorum is whoever shows up to vote * 50% + 1. Supermajority is only 14 people more, so seems unnecessary * there are only 93 people in the set of possible voters *When creating proposals that involve a BDFL, or other role, do not name a person or group of people. Name a mechanism for choosing that person or group of people. *Put in as many specifics as necessary to make your proposal attractive *The constitution of the united states says how to update itself; do the same in a governance proposal. Proposal One: No BDFL, all democracy all the time PEP 8012 - https://www.python.org/dev/peps/pep-8012/ * Inspired by Rust and Django * Working groups are self-selected from people interested in focus areas * Non-experts in an area trust that experts will do well in an area * Regular decision making process is mostly "go ahead and do it" * Controversial decisions require a process with documented phases: make a PEP, find a champion, get comments, set a deadline, decide on whether it is accepted, rejected or postponed * How does veto work? Put it to a vote. * The "voice of Python" is expressed not by a person, but by the design documents produced * If you don't want assignment expressions, vote for my proposal Proposal Two: external auditors PEP 8013 - https://www.python.org/dev/peps/pep-8013/ * Working groups should continue to go forward ? the people who are working on a specific PEP, and not necessarily core developers. * Normal decision process should continue * Controversial decisions should be taken to an elected group of three people who are NOT core developers who are arbiters of process concerns. Call them the auditors. * Appointed for how long? A year? Years? A release? This is a parameter. * No term limit; you can be re-elected * Not a developer; an escalation mechanism for when developers cannot reach consensus * Every time you take a controversial decision to the auditors, you have to explain the problem in detail well enough to convince them that you've done due diligence about design, user impact, and so on. * Auditors can veto controversial decisions until there is enough diligence done * Auditors can require that a decision goes to a vote if it is still controversial * Auditors can require that more people weigh in * Auditors cannot mess things up by proposing new bad stuff; they can only slow down (hopefully bad) decisions * We have a list of names of notable people who would be great at this; whether they'd be willing is another question * Microsoft would offer employees for this role, but maybe core developers are opposed to corporate influence Proposal Three: Trivumvirate of core developers PEP 8011 - https://www.python.org/dev/peps/pep-8011/ * a similar scheme to Proposal Two, but where the triumvirate must be core developers * We are too used to the BDFL model and may be worried to change it * Should be a diverse group of three people who can work together. * These people must be trusted; if that trust breaks down then we have a crisis ? but of course we can always change the governance model if this doesn't work * Elected for longer than a year; semi permanent * Role similar to previous BDFL, but with multiple people coming to consensus. Proposal Four: Find another BDFL PEP 8010 - https://www.python.org/dev/peps/pep-8010/ * Elect a BDFL * Continue with working groups * Create a council as an advisory group to the BDFL, help find delegates, and so on * The BDFL has a broad view of the python ecosystem, and weigh in on large scale changes, say to the grammar, or changes that have broad impact, like deciding between performance and compatibility. * Must be seen as "the voice of Python" * The BDFL champions the overall vision of the evolution of the language, with the support of the community * "For life" is a misnomer. There should be a recall process or vote of no confidence. * Release manager has an important advisory role Thoughts: * These proposals are consistent in that most of the work is done in informal groups, there is some sort of leadership council who ensures that processes are followed. * The working group and PEP process is pretty much the same in all these proposals * The fundamental differences are in who has authority: (1) no authority, self-policing, (2) authority over process vested in non-developers, (3) authority vested in a group of developers and (4) one BDFL * We can always make a decision, try it, and if it doesn't have good outcomes, have this conversation again in two years * Consider the role of release manager in all of these; they have a lot of power in that they can file a release-blocking bug against stuff they don't like * Are there issues with how we induct/vote in new core developers? * Individual working groups are autonomous and have authority to decide who is core to their working group * How do we solve controversial issues? Take it to a vote, take it to auditors, take it to the BDFL. * Do we have examples of community-based open-source projects that are run using proposal 2? No. But we have lots of examples of that model in business-run projects, non-profit-run projects, and so on. * There are examples of members of technical committees secretly proposing features and then approving them, sock puppeting, and so on. We would want to avoid that. Similarly a BDFL will need to appoint a delegate if they are also proposing PEPs, and so on. * Need a graceful way for a leader to step down when their life requires them to do so. Burnout is real and insidious. * Be aware of conflicts of interest, double dealing. Financial self dealing is probably not a problem for us. * How do we ensure consistency in decision making? * Excessive churn in leadership works against this. * Having a set of core principles will help. * Election campaigning for leadership roles is a mechanism for people to choose direction. * Would be helpful if every PEP had a core developer to sponsor it. Particularly if final approval moves to python core devs. From levkivskyi at gmail.com Sun Sep 16 10:20:33 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Sun, 16 Sep 2018 15:20:33 +0100 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Welcome, Lisa and Emily! -- Ivan On Fri, 14 Sep 2018 at 20:29, Raymond Hettinger wrote: > At the developer sprints this week, we collectively decided to grant core > committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Raymond > > > ------------------------------- > > Emily is the Director of Engineering at Cuttlesoft. She has previously > attended two Language Summits and three core development sprints at PyCon. > Since July, Emily has worked with Guido's guidance to implement PEP 572, > Assignment Expressions. She has also worked with Eric Snow to dive into > CPython's runtime as well as subinterpreters. This year at PyCon she gave > a talk on Python's AST. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk > video: https://www.youtube.com/watch?v=XhWvz4dK4ng > > Lisa has a background in network engineering and supported the Cisco sale > engineer team to develop high quality Python product demonstrations. Later > she moved to the Facebook security team. This is her third core developer > sprint. She and Guido are co-authors of PEP 526, Syntax for Variable > Annotations. Last year, she worked with Eric Smith on PEP 557, Data > Classes. Here is her speaker bio > https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon > talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and > https://www.youtube.com/watch?v=ww1UsGZV8fQ > _______________________________________________ > 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 andrew.svetlov at gmail.com Sun Sep 16 03:10:59 2018 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Sun, 16 Sep 2018 09:10:59 +0200 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Welcome! On Sat, Sep 15, 2018, 19:47 Larry Hastings wrote: > > > On 09/14/2018 12:28 PM, Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. > > Please join me in welcoming them to the team. > > > Congratulations Emily and Lisa! I look forward to many years of arguing > working with you on our favorite language. > > > */arry* > _______________________________________________ > 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/ > -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at palard.fr Sun Sep 16 17:47:39 2018 From: julien at palard.fr (Julien Palard) Date: Sun, 16 Sep 2018 21:47:39 +0000 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. Congratulations and Welcome!! --? Julien Palard https://mdk.fr From emilyemorehouse at gmail.com Mon Sep 17 11:57:50 2018 From: emilyemorehouse at gmail.com (Emily E Morehouse) Date: Mon, 17 Sep 2018 09:57:50 -0600 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Thank you all for the congratulations, and an even bigger thank you for your trust. I'm beyond happy to be here! On Sun, Sep 16, 2018 at 3:48 PM Julien Palard via python-committers < python-committers at python.org> wrote: > > At the developer sprints this week, we collectively decided to grant > core committer status to Emily and Lisa. > > Congratulations and Welcome!! > > -- > Julien Palard > https://mdk.fr > > _______________________________________________ > 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 Wed Sep 19 17:12:47 2018 From: nad at python.org (Ned Deily) Date: Wed, 19 Sep 2018 17:12:47 -0400 Subject: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon In-Reply-To: <3ABAB3B5-6346-49F2-98F7-185303166016@python.org> References: <3ABAB3B5-6346-49F2-98F7-185303166016@python.org> Message-ID: Update: not surprisingly, there have been a number of issues that have popped up during and since the sprint that we would like to ensure are addressed in 3.7.1 and 3.6.7. In order to do so, I've been holding off on starting the releases. I think we are now getting close to having the important ones resolved so I'm going to plan on cutting off code for 3.7.1rc1 and 3.6.7rc1 by the end of 2018-09-20 (23:59 AoE). That's roughly 38 hours from now. Thanks for all of your help in improving Python for everyone! --Ned On Sep 10, 2018, at 18:17, Ned Deily wrote: > I have now scheduled a 3.7.1 release candidate and rescheduled the 3.6.7 release candidate for 2018-09-18, about a week from today, and 3.7.1 final and 3.6.7 final for 2018-09-28. That allows us to take advantage of fixes generated at the Core Developers sprint taking place this week. > > Please review any open issues you are working on or are interested in and try to get them merged in to the 3.7 and/or 3.6 branches soon - by the beginning of next week at the latest. As usual, if there are any issues you believe need to be addressed prior to these releases, please ensure there are open issues for them in the bug tracker (bugs.python.org) and that their priorities are set accordingly (e.g. "release blocker"). -- Ned Deily nad at python.org -- [] From ncoghlan at gmail.com Thu Sep 20 08:54:00 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 20 Sep 2018 22:54:00 +1000 Subject: [python-committers] Recent buildbot.python.org changes In-Reply-To: References: Message-ID: On Sat, 15 Sep 2018 at 07:02, Zachary Ware wrote: > > Hi all, > > Most of my effort this week has gone into improving the state of > buildbot.python.org, which has largely gone into improving Buildbot > itself. [snip] Very nice! Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Thu Sep 20 09:09:23 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 20 Sep 2018 23:09:23 +1000 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: On Sat, 15 Sep 2018 at 05:28, Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. Congratulations, and welcome! Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From steve.dower at python.org Thu Sep 20 11:34:52 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 20 Sep 2018 08:34:52 -0700 Subject: [python-committers] Azure Pipelines Linux failures on PRs Message-ID: Hi all Just a heads-up that the Azure Pipelines build failures for Linux machines are a known issue that should be fixed by the end of the week. It seems the service has become so popular since last week's announcements that many more builds are being run on machines that have been freshly imaged, and so they are racing with a background 'apt update' command. This causes an explicit 'apt update' to (correctly) fail to acquire its lock. I believe it's also related to the move from running builds within Docker containers to actual VMs, which happened around the same time. Until it's fixed, feel free to ignore the Azure Pipelines status for Linux builds. Apologies for the inconvenience with backports not auto-merging. Cheers, Steve From taleinat at gmail.com Thu Sep 20 12:56:15 2018 From: taleinat at gmail.com (Tal Einat) Date: Thu, 20 Sep 2018 19:56:15 +0300 Subject: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel In-Reply-To: References: Message-ID: Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. Welcome aboard! Glad to have you with us :) From taleinat at gmail.com Thu Sep 20 12:59:10 2018 From: taleinat at gmail.com (Tal Einat) Date: Thu, 20 Sep 2018 19:59:10 +0300 Subject: [python-committers] Recent buildbot.python.org changes In-Reply-To: References: Message-ID: Zachary Ware wrote: > > Most of my effort this week has gone into improving the state of > buildbot.python.org, which has largely gone into improving Buildbot > itself. Here are the relevant highlights: > > [snip] Those are important improvements! I'm really happy buildbot appears to be receiving more attention recently. - Tal Einat From antoine at python.org Thu Sep 20 16:25:21 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 20 Sep 2018 22:25:21 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) Message-ID: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Hi, I'm choosing to forward this to python-committers because I don't think python-ideas is a reasonable place to discuss CoC decisions. I think the action taken by Brett (apparently decided with Titus and a mysterious "conduct working group") is not the right one: - a definitive ban is an extremely strong decision that should only be taken if nothing else works. May I remind that Anatoly was able to post prolifically and unconstructively for several years, being warned several times, before being finally banned? Comparatively, this one ban seems expeditive. - the reasons given, to me, don't make sense at all. The word "n-----" is not a forbidden word if you want to describe, precisely, linguistics and the relativity of meanings (instead of actually *qualifying* someone or a groupe of people), which is what the OP claimed to do. The other reasons look like a similar kind of over-reaction. Even if something there looks inappropriate to you, it's still enough of a grey area that a ban is absolutely the wrong answer. I deduce that it's ok to say "slave" in a discussion instead of using an expression such as "the s-word". Why one term is allowed and the other, not, may be clear to Americans (or, perhaps, a large fraction thereof), but hey, it's not clear to other people around the world. Banning a (apparently) Dutch person because he doesn't understand American standards of offense is not only unfair, but it makes our community *not* inclusive of other cultures. As a French person myself, I could not, even if I wanted to, turn myself into an authentic American: what is obvious to you is not obvious to me and it would be extremely brutal and humiliating to ban me for having the wrong nationality and the wrong culture. I will ask: please consider the work and effort that it *already* takes for other people to adapt to standards of discussion that are, obviously, those of a particular culture. Otherwise you're raising barriers even more, not lowering them. At the end of it, it looks like we have a real moderation problem. python-ideas threads frequently veer out into unconstructive back-and-forths (and, well, that's not *only* the ethically-sensitive threads). The CoC is being applied erratically, sometimes precipitately, by apparently overworked and emotionally exhausted moderators, with bad consequences on the quality of the decisions. Moderators should not become emotionally exhausted (which means we need a more adequate discussion system *and* a more collegial, spread out, team of moderators); and, if they become so, I would humbly suggest it's a better idea - even if not always easy to follow - to step back and take some rest than make decisions in such a state. We also need real guidelines to the moderators as to which decision on the scale of possible decisions to apply, depending on severity of the offense / violation and on the "offendor"'s past behaviour. In the end, I hope we can set ourselves better moderation standards. As for me, I find the current situation very worrying, including for my ability to contribute constructively to Python. If I have to fear banning for every word that I say and that might be deemed inappropriate in the moderators' culture, I might just as well leave instead of feeling stressed and anguished everytime I post something. I would not want to live this in paid work: why would I endure it as a volunteer, while my main gratification should be the pleasure taken in contributing? Regards Antoine. ----- Message Transf?r? ----- Date : Thu, 20 Sep 2018 11:56:05 -0700 De : Brett Cannon ? : Jacco van Dorp Cc : python-ideas Groupe de discussion : gmane.comp.python.ideas Sujet : CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) The below email was reported to the PSF board for code of conduct violations and then passed on to the conduct working group to decide on an appropriate response. Based on the WG's recommendation and after discussing it with Titus, the decision has been made to ban Jacco from python-ideas. Trivializing assault, using the n-word, and making inappropriate comments about someone's mental stability are all uncalled for and entirely unnecessary to carry on a reasonable discourse of conversation that remains welcoming to others. From alex.gaynor at gmail.com Thu Sep 20 16:33:50 2018 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 20 Sep 2018 16:33:50 -0400 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: Is there a copy of the original email? (I'm not a regular python-ideas reader) Based on Brett's description though, the content sounds very far over the line, and I wouldn't want to interfere with the WG's decision. Alex On Thu, Sep 20, 2018 at 4:25 PM Antoine Pitrou wrote: > > Hi, > > I'm choosing to forward this to python-committers because I don't think > python-ideas is a reasonable place to discuss CoC decisions. > > I think the action taken by Brett (apparently decided with Titus and a > mysterious "conduct working group") is not the right one: > > - a definitive ban is an extremely strong decision that should only be > taken if nothing else works. May I remind that Anatoly was able to post > prolifically and unconstructively for several years, being warned > several times, before being finally banned? Comparatively, this one ban > seems expeditive. > > - the reasons given, to me, don't make sense at all. The word "n-----" > is not a forbidden word if you want to describe, precisely, linguistics > and the relativity of meanings (instead of actually *qualifying* someone > or a groupe of people), which is what the OP claimed to do. The other > reasons look like a similar kind of over-reaction. Even if something > there looks inappropriate to you, it's still enough of a grey area that > a ban is absolutely the wrong answer. > > I deduce that it's ok to say "slave" in a discussion instead of using an > expression such as "the s-word". Why one term is allowed and the other, > not, may be clear to Americans (or, perhaps, a large fraction thereof), > but hey, it's not clear to other people around the world. Banning a > (apparently) Dutch person because he doesn't understand American > standards of offense is not only unfair, but it makes our community > *not* inclusive of other cultures. > > As a French person myself, I could not, even if I wanted to, turn myself > into an authentic American: what is obvious to you is not obvious to me > and it would be extremely brutal and humiliating to ban me for having > the wrong nationality and the wrong culture. I will ask: please > consider the work and effort that it *already* takes for other people to > adapt to standards of discussion that are, obviously, those of a > particular culture. Otherwise you're raising barriers even more, not > lowering them. > > > At the end of it, it looks like we have a real moderation problem. > python-ideas threads frequently veer out into unconstructive > back-and-forths (and, well, that's not *only* the ethically-sensitive > threads). The CoC is being applied erratically, sometimes > precipitately, by apparently overworked and emotionally exhausted > moderators, with bad consequences on the quality of the decisions. > > Moderators should not become emotionally exhausted (which means we need > a more adequate discussion system *and* a more collegial, spread out, > team of moderators); and, if they become so, I would humbly suggest it's > a better idea - even if not always easy to follow - to step back and > take some rest than make decisions in such a state. We also need real > guidelines to the moderators as to which decision on the scale of > possible decisions to apply, depending on severity of the offense / > violation and on the "offendor"'s past behaviour. > > In the end, I hope we can set ourselves better moderation standards. As > for me, I find the current situation very worrying, including for my > ability to contribute constructively to Python. If I have to fear > banning for every word that I say and that might be deemed inappropriate > in the moderators' culture, I might just as well leave instead of > feeling stressed and anguished everytime I post something. I would not > want to live this in paid work: why would I endure it as a volunteer, > while my main gratification should be the pleasure taken in contributing? > > Regards > > Antoine. > > > > ----- Message Transf?r? ----- > > Date : Thu, 20 Sep 2018 11:56:05 -0700 > De : Brett Cannon > ? : Jacco van Dorp > Cc : python-ideas > Groupe de discussion : gmane.comp.python.ideas > Sujet : CoC violation (was: Retire or reword the "Beautiful is better > than ugly" Zen clause) > > > The below email was reported to the PSF board for code of conduct > violations and then passed on to the conduct working group to decide on > an appropriate response. > > Based on the WG's recommendation and after discussing it with Titus, the > decision has been made to ban Jacco from python-ideas. Trivializing > assault, using the n-word, and making inappropriate comments about > someone's mental stability are all uncalled for and entirely > unnecessary to carry on a reasonable discourse of conversation that > remains welcoming to others. > _______________________________________________ > 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 antoine at python.org Thu Sep 20 16:37:45 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 20 Sep 2018 22:37:45 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: Apparently it's this one: https://mail.python.org/pipermail/python-ideas/2018-September/053482.html By the way, regardless of this single case, I would like people to think of the broader issue we're having. It's more than a single contentious decision. Regards Antoine. Le 20/09/2018 ? 22:33, Alex Gaynor a ?crit?: > Is there a copy of the original email? (I'm not a regular python-ideas > reader) > > Based on Brett's description though, the content sounds very far over > the line, and I wouldn't want to interfere with the WG's decision. > > Alex > > On Thu, Sep 20, 2018 at 4:25 PM Antoine Pitrou > wrote: > > > Hi, > > I'm choosing to forward this to python-committers because I don't think > python-ideas is a reasonable place to discuss CoC decisions. > > I think the action taken by Brett (apparently decided with Titus and a > mysterious "conduct working group") is not the right one: > > - a definitive ban is an extremely strong decision that should only be > taken if nothing else works.? May I remind that Anatoly was able to post > prolifically and unconstructively for several years, being warned > several times, before being finally banned?? Comparatively, this one ban > seems expeditive. > > - the reasons given, to me, don't make sense at all.? The word "n-----" > is not a forbidden word if you want to describe, precisely, linguistics > and the relativity of meanings (instead of actually *qualifying* someone > or a groupe of people), which is what the OP claimed to do.? The other > reasons look like a similar kind of over-reaction.? Even if something > there looks inappropriate to you, it's still enough of a grey area that > a ban is absolutely the wrong answer. > > I deduce that it's ok to say "slave" in a discussion instead of using an > expression such as "the s-word".? Why one term is allowed and the other, > not, may be clear to Americans (or, perhaps, a large fraction thereof), > but hey, it's not clear to other people around the world.? Banning a > (apparently) Dutch person because he doesn't understand American > standards of offense is not only unfair, but it makes our community > *not* inclusive of other cultures. > > As a French person myself, I could not, even if I wanted to, turn myself > into an authentic American: what is obvious to you is not obvious to me > and it would be extremely brutal and humiliating to ban me for having > the wrong nationality and the wrong culture.? I will ask: please > consider the work and effort that it *already* takes for other people to > adapt to standards of discussion that are, obviously, those of a > particular culture.? Otherwise you're raising barriers even more, not > lowering them. > > > At the end of it, it looks like we have a real moderation problem. > python-ideas threads frequently veer out into unconstructive > back-and-forths (and, well, that's not *only* the ethically-sensitive > threads).? The CoC is being applied erratically, sometimes > precipitately, by apparently overworked and emotionally exhausted > moderators, with bad consequences on the quality of the decisions. > > Moderators should not become emotionally exhausted (which means we need > a more adequate discussion system *and* a more collegial, spread out, > team of moderators); and, if they become so, I would humbly suggest it's > a better idea - even if not always easy to follow - to step back and > take some rest than make decisions in such a state.? We also need real > guidelines to the moderators as to which decision on the scale of > possible decisions to apply, depending on severity of the offense / > violation and on the "offendor"'s past behaviour. > > In the end, I hope we can set ourselves better moderation standards.? As > for me, I find the current situation very worrying, including for my > ability to contribute constructively to Python.? If I have to fear > banning for every word that I say and that might be deemed inappropriate > in the moderators' culture, I might just as well leave instead of > feeling stressed and anguished everytime I post something.? I would not > want to live this in paid work: why would I endure it as a volunteer, > while my main gratification should be the pleasure taken in > contributing? > > Regards > > Antoine. > > > > ----- Message Transf?r? ----- > > Date : Thu, 20 Sep 2018 11:56:05 -0700 > De : Brett Cannon > > ? : Jacco van Dorp > > > Cc : python-ideas > > > Groupe de discussion : gmane.comp.python.ideas > Sujet : CoC violation (was: Retire or reword the "Beautiful is better > than ugly" Zen clause) > > > The below email was reported to the PSF board for code of conduct > violations and then passed on to the conduct working group to decide on > an appropriate response. > > Based on the WG's recommendation and after discussing it with Titus, the > decision has been made to ban Jacco from python-ideas. Trivializing > assault, using the n-word, and making inappropriate comments about > someone's mental stability are all uncalled for and entirely > unnecessary to carry on a reasonable discourse of conversation that > remains welcoming to others. > _______________________________________________ > 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. From donald at stufft.io Thu Sep 20 16:57:19 2018 From: donald at stufft.io (Donald Stufft) Date: Thu, 20 Sep 2018 16:57:19 -0400 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> > On Sep 20, 2018, at 4:25 PM, Antoine Pitrou wrote: > > I think the action taken by Brett (apparently decided with Titus and a > mysterious "conduct working group") is not the right one: Just FTR, the conduct working group is the PSFs CoC Working Group, which I believe had an open call for membership at some point. I think it?s still getting setup so it hasn?t been added to the list of WGs yet or anything, but it was approved awhile back: https://www.python.org/psf/records/board/minutes/2017-08-22/#code-of-conduct-work-group At least, I?m pretty sure that?s what Brett means. With regards to the action, it seems reasonable to me, particularly since it was not a one-off done by one person, but was an action taken after discussion amongst the moderators and the CoC WG. I do agree that our tools are bad, and we need to come up with new ones. With limited moderation tooling we have limited ability to head off unproductive discussions before they delve too far into the bad end of the world. I think if there is concern about this, the best forum is probably discussion with the CoC WG, and probably not python-committers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Thu Sep 20 16:57:41 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 20 Sep 2018 16:57:41 -0400 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: On Thu, Sep 20, 2018 at 4:37 PM Antoine Pitrou wrote: > > > Apparently it's this one: > https://mail.python.org/pipermail/python-ideas/2018-September/053482.html After reading the original email I, personally, am in support of the WG & Brett's decision. I also think that we need a neutral third-party to enforce CoC; it's unfortunate that Brett is the one who has to be dragged though this. > > By the way, regardless of this single case, I would like people to think > of the broader issue we're having. It's more than a single contentious > decision. This is why we want to try Discourse for the upcoming governance discussions. We'll see if its tools to organize and moderate discussions (and some would agree better UX) make a difference. Yury Yury From brett at python.org Thu Sep 20 17:17:48 2018 From: brett at python.org (Brett Cannon) Date: Thu, 20 Sep 2018 14:17:48 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> Message-ID: On Thu, 20 Sep 2018 at 13:57 Donald Stufft wrote: > > > On Sep 20, 2018, at 4:25 PM, Antoine Pitrou wrote: > > I think the action taken by Brett (apparently decided with Titus and a > mysterious "conduct working group") is not the right one: > > > > Just FTR, the conduct working group is the PSFs CoC Working Group, which I > believe had an open call for membership at some point. I think it?s still > getting setup so it hasn?t been added to the list of WGs yet or anything, > but it was approved awhile back: > https://www.python.org/psf/records/board/minutes/2017-08-22/#code-of-conduct-work-group > > At least, I?m pretty sure that?s what Brett means. > Yep, that's exactly who I meant. Didn't realize the group had not been added to the WG list online yet. > With regards to the action, it seems reasonable to me, particularly since > it was not a one-off done by one person, but was an action taken after > discussion amongst the moderators and the CoC WG. > I will also say I didn't voice an opinion or participate in the discussion on the conduct WG when deciding how to handle it (beyond outlining our levels of escalation when handling these situations). So to Yury's point of neutrality in another email, I stayed out of the decision and basically just coordinated the handling of it. > > I do agree that our tools are bad, and we need to come up with new ones. > With limited moderation tooling we have limited ability to head off > unproductive discussions before they delve too far into the bad end of the > world. > My hope is we will end up with something that allows us to centralize managing things like CoC issues so there is a consistent neutral party to manage all of this. It's something I'm actively talking to the conduct WG about in hopes that they can support that somehow and help make it happen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Thu Sep 20 18:35:41 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 20 Sep 2018 15:35:41 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> Message-ID: <5BA420BD.8030802@stoneleaf.us> On 09/20/2018 02:17 PM, Brett Cannon wrote: > I will also say I didn't voice an opinion or participate in the discussion on the conduct WG when deciding how to handle > it (beyond outlining our levels of escalation when handling these situations). One thing missing from the ban notification is the length of time? If this is the first offense it should only be two months, right? And I have to argue against his use of the n-word* as being part of the reason -- he wasn't calling anybody that, he was using the word as an example of a taboo in one culture that is not in others. Using that as part of the reason to ban him helps me understand the sentiment voiced at the sprints of the feeling that the CoC is a weapon waiting to shoot us down. I fully appreciate the frustration of trying to moderate these lists with our limited tools, but we still need to be careful of the reasons we use for moderation actions. Does the CoC WG have an email address? I'm happy to forward my concerns to them about their decision. -- ~Ethan~ * Before this I wouldn't have spelled out the n-word anyway, but now I'm afraid to. From antoine at python.org Thu Sep 20 18:39:18 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 00:39:18 +0200 Subject: [python-committers] sprints summary? In-Reply-To: <5BA420BD.8030802@stoneleaf.us> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: Le 21/09/2018 ? 00:35, Ethan Furman a ?crit?: > > And I have to argue against his use of the n-word* as being part of the reason -- he wasn't calling anybody that, he was > using the word as an example of a taboo in one culture that is not in others. Using that as part of the reason to ban > him helps me understand the sentiment voiced at the sprints of the feeling that the CoC is a weapon waiting to shoot us > down. Is there a summary of the sprints somewhere or is it planned to post one somewhere? It would be more to read a bit more about the discussions that took place. Regards Antoine. From antoine at python.org Thu Sep 20 18:43:18 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 00:43:18 +0200 Subject: [python-committers] ban duration In-Reply-To: <5BA420BD.8030802@stoneleaf.us> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: Le 21/09/2018 ? 00:35, Ethan Furman a ?crit?: > On 09/20/2018 02:17 PM, Brett Cannon wrote: > >> I will also say I didn't voice an opinion or participate in the discussion on the conduct WG when deciding how to handle >> it (beyond outlining our levels of escalation when handling these situations). > > One thing missing from the ban notification is the length of time? If this is the first offense it should only be two > months, right? Note: in the few online discussion forums that I have seen, the ban duration for a first offense would be more on the order of a couple days, perhaps a week. Two months is, arguably, very long already. Just my 2 cents, though. There *should* be a ban duration in any case. Regards Antoine. From steve.dower at python.org Thu Sep 20 18:47:36 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 20 Sep 2018 15:47:36 -0700 Subject: [python-committers] sprints summary? In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: <6b531e5b-ddd8-80f7-ebb4-fa0f0b14123a@python.org> On 20Sep2018 1539, Antoine Pitrou wrote: > Is there a summary of the sprints somewhere or is it planned to post one > somewhere? It would be more to read a bit more about the discussions > that took place. Currently debating the contents of the high-level blog post among those who were there. Once that's settled, it'll go to the PSF to be posted on their site. But it's going to be very high level (and is currently becoming more high level), so you won't find it very informative I would expect. Mariatta has posted a good summary of her involvement at https://mariatta.ca/core-sprint-2018-part-1.html (with more parts to come), and I believe one or two other people are also planning to write posts. The most summary we have of the discussions are in the notes I posted earlier to -committers. Official results of the discussions will go into the PEPs, hopefully this week so that there's some time to review before they are locked down for us to choose between. Cheers, Steve From chris.jerdonek at gmail.com Thu Sep 20 19:25:27 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Thu, 20 Sep 2018 16:25:27 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <5BA420BD.8030802@stoneleaf.us> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: FWIW, as an American I don't think it's appropriate to spell out the n-word in a mailing list, even if it's not being directed at anybody or even just being used as an example. There's no need, and it can only cause discomfort or worse. --Chris On Thu, Sep 20, 2018 at 3:35 PM, Ethan Furman wrote: > On 09/20/2018 02:17 PM, Brett Cannon wrote: > >> I will also say I didn't voice an opinion or participate in the discussion >> on the conduct WG when deciding how to handle >> it (beyond outlining our levels of escalation when handling these >> situations). > > > One thing missing from the ban notification is the length of time? If this > is the first offense it should only be two months, right? > > And I have to argue against his use of the n-word* as being part of the > reason -- he wasn't calling anybody that, he was using the word as an > example of a taboo in one culture that is not in others. Using that as part > of the reason to ban him helps me understand the sentiment voiced at the > sprints of the feeling that the CoC is a weapon waiting to shoot us down. > > I fully appreciate the frustration of trying to moderate these lists with > our limited tools, but we still need to be careful of the reasons we use for > moderation actions. > > Does the CoC WG have an email address? I'm happy to forward my concerns to > them about their decision. > > -- > ~Ethan~ > > > * Before this I wouldn't have spelled out the n-word anyway, but now I'm > afraid to. > > _______________________________________________ > 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 njs at pobox.com Thu Sep 20 20:06:37 2018 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 20 Sep 2018 17:06:37 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <5BA420BD.8030802@stoneleaf.us> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: On Thu, Sep 20, 2018 at 3:35 PM, Ethan Furman wrote: > And I have to argue against his use of the n-word* as being part of the > reason -- he wasn't calling anybody that, he was using the word as an > example of a taboo in one culture that is not in others. Using that as part > of the reason to ban him helps me understand the sentiment voiced at the > sprints of the feeling that the CoC is a weapon waiting to shoot us down. But using that word, even with quote marks around it, *is* a serious taboo in American culture. And partly this is because "white person who finds convoluted excuse to use the n-word" is such a cliche that the affected folks have given up with arguing about it and just don't want to hear it anywhere, in or out of quotes, with or without an excuse attached. There's no reservoir of good-faith left to fall back on. Now sure, that taboo is an American thing, and I wouldn't support automatically banning someone who used it in genuine ignorance, was repentant when they realized what they'd done, etc. Context absolutely matters. But in context here it's clear that Jacco knew perfectly well that he was violating a taboo, and I can't read his usage as anything but an intentional provocation. Especially when combined with all the other things in his email. -n -- Nathaniel J. Smith -- https://vorpus.org From ethan at stoneleaf.us Thu Sep 20 20:25:20 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 20 Sep 2018 17:25:20 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: <5BA43A70.4050308@stoneleaf.us> On 09/20/2018 05:06 PM, Nathaniel Smith wrote: > On Thu, Sep 20, 2018 at 3:35 PM, Ethan Furman wrote: >> And I have to argue against his use of the n-word* as being part of the >> reason -- he wasn't calling anybody that, he was using the word as an >> example of a taboo in one culture that is not in others. Using that as part >> of the reason to ban him helps me understand the sentiment voiced at the >> sprints of the feeling that the CoC is a weapon waiting to shoot us down. > > But using that word, even with quote marks around it, *is* a serious > taboo in American culture. And partly this is because "white person > who finds convoluted excuse to use the n-word" is such a cliche that > the affected folks have given up with arguing about it and just don't > want to hear it anywhere, in or out of quotes, with or without an > excuse attached. There's no reservoir of good-faith left to fall back > on. > > Now sure, that taboo is an American thing, and I wouldn't support > automatically banning someone who used it in genuine ignorance, was > repentant when they realized what they'd done, etc. Context absolutely > matters. But in context here it's clear that Jacco knew perfectly well > that he was violating a taboo, and I can't read his usage as anything > but an intentional provocation. Especially when combined with all the > other things in his email. You make good points. -Ideas is not, after all, a sociology course, and he did already know that. I withdraw my objection. -- ~Ethan~ From brett at python.org Thu Sep 20 20:47:44 2018 From: brett at python.org (Brett Cannon) Date: Thu, 20 Sep 2018 17:47:44 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <5BA420BD.8030802@stoneleaf.us> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: On Thu, 20 Sep 2018 at 15:35 Ethan Furman wrote: > On 09/20/2018 02:17 PM, Brett Cannon wrote: > > > I will also say I didn't voice an opinion or participate in the > discussion on the conduct WG when deciding how to handle > > it (beyond outlining our levels of escalation when handling these > situations). > > One thing missing from the ban notification is the length of time? If > this is the first offense it should only be two > months, right? > The request was for a permanent ban based on the severity and calculated infraction that it was. (And we have always been clear on the list that we reserved the right to skip steps based on severity, so this is not a change in policy.) > > And I have to argue against his use of the n-word* as being part of the > reason -- he wasn't calling anybody that, he was > using the word as an example of a taboo in one culture that is not in > others. Using that as part of the reason to ban > him helps me understand the sentiment voiced at the sprints of the feeling > that the CoC is a weapon waiting to shoot us > down. > > I fully appreciate the frustration of trying to moderate these lists with > our limited tools, but we still need to be > careful of the reasons we use for moderation actions. > Which is why I'm hoping we can eventually get a clear enforcement guide written for all the mailing lists and then have a specific group of people manage all of these incident reports and deciding how to handle them for consistency. Otherwise we have our current situation where every list admin has to figure this out for themselves and do the best they can on their own. And it's all stuff I'm bringing up in the WG, but I also have to stop drowning in conduct issues before I can put in the emotional energy to even have that conversation. I already lost sleep last night over having to institute this ban knowing there was a strong chance of a backlash based on how things have been going as of late. And I now dread reading my personal email, half-expecting there to be yet another issue I have to go deal with. At the current rate I'm going I will have to do my month-long volunteer detox in October which I really don't want to do as that's probably when we are going to discuss governance proposals and I want to participate in those discussions, but I also would rather bow out of those than burn out entirely. And I quickly want to say thanks to everyone who has checked in with me to ask how I'm doing and offering to somehow help (which my answer to the latter is "get the Discourse test instance up"). And thanks to Mariatta, Zach, and anyone else who have been leading on GitHub and bugs.python.org where people are still acting out. > Does the CoC WG have an email address? I'm happy to forward my concerns > to them about their decision. > conduct-wg at python.org. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Thu Sep 20 21:11:38 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 20 Sep 2018 18:11:38 -0700 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: <5BA4454A.8010206@stoneleaf.us> On 09/20/2018 05:47 PM, Brett Cannon wrote: > Which is why I'm hoping we can eventually get a clear enforcement guide written for all the mailing lists and then have > a specific group of people manage all of these incident reports and deciding how to handle them for consistency. > Otherwise we have our current situation where every list admin has to figure this out for themselves and do the best > they can on their own. > conduct-wg at python.org. I'll start running issues from -list by them to get advice/counsel. No reason we can't opt-in to consistency. :) -- ~Ethan~ From christian at python.org Fri Sep 21 05:37:25 2018 From: christian at python.org (Christian Heimes) Date: Fri, 21 Sep 2018 11:37:25 +0200 Subject: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon In-Reply-To: References: <3ABAB3B5-6346-49F2-98F7-185303166016@python.org> Message-ID: On 19/09/2018 23.12, Ned Deily wrote: > Update: not surprisingly, there have been a number of issues that have popped up during and since the sprint that we would like to ensure are addressed in 3.7.1 and 3.6.7. In order to do so, I've been holding off on starting the releases. I think we are now getting close to having the important ones resolved so I'm going to plan on cutting off code for 3.7.1rc1 and 3.6.7rc1 by the end of 2018-09-20 (23:59 AoE). That's roughly 38 hours from now. > > Thanks for all of your help in improving Python for everyone! Hi Ned, I'm really sorry, but would it be possible to delay the RCs until Sunday or Monday AoE? Some of the XML security fixes, OpenSSL 1.1.1 fixes (TLS 1.3 post-handshake authentication), and SSL module regression haven't landed yet. I'm confident that I can land most to all fixes during the weekend. Related PRs are: * https://github.com/python/cpython/pull/9468 * https://github.com/python/cpython/pull/9460 * https://github.com/python/cpython/pull/9217 * https://github.com/python/cpython/pull/9265 I'm also still collaborating with Sebastian Pipping (libexpat maintainer) on the DoS mitigations (CVE-2013-0340). My initial patch had some flaws. I might be able to get expat release 2.3.0 in time, too. https://github.com/libexpat/libexpat/pull/220 Christian From antoine at python.org Fri Sep 21 06:46:32 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 12:46:32 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> Message-ID: <5961a1a0-3882-591c-d766-5e27723390c8@python.org> Le 21/09/2018 ? 02:06, Nathaniel Smith a ?crit?: > Now sure, that taboo is an American thing, and I wouldn't support > automatically banning someone who used it in genuine ignorance, was > repentant when they realized what they'd done, etc. So why are American taboos specifically forbidden, and not other taboos? Is there anything special about Americans that deserves this? Does it mean that Python is a community for Americans foremost, and others are just second-class participants? The more this is going on, the more it is the impression I get, and things have become distinctly *worse* recently. Regards Antoine. From christian at python.org Fri Sep 21 06:55:24 2018 From: christian at python.org (Christian Heimes) Date: Fri, 21 Sep 2018 12:55:24 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <5961a1a0-3882-591c-d766-5e27723390c8@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> Message-ID: <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> On 21/09/2018 12.46, Antoine Pitrou wrote: > > Le 21/09/2018 ? 02:06, Nathaniel Smith a ?crit?: >> Now sure, that taboo is an American thing, and I wouldn't support >> automatically banning someone who used it in genuine ignorance, was >> repentant when they realized what they'd done, etc. > > So why are American taboos specifically forbidden, and not other taboos? > Is there anything special about Americans that deserves this? Does it > mean that Python is a community for Americans foremost, and others are > just second-class participants? The more this is going on, the more it > is the impression I get, and things have become distinctly *worse* recently. I don't understand why you are drawing the reverse conclusion here. Can you give me one concrete example, in which a French, German, or any other non-US American taboo was violated and not counteracted with swift reaction? From donald at stufft.io Fri Sep 21 07:01:12 2018 From: donald at stufft.io (Donald Stufft) Date: Fri, 21 Sep 2018 07:01:12 -0400 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> Message-ID: > On Sep 21, 2018, at 6:55 AM, Christian Heimes wrote: > > I don't understand why you are drawing the reverse conclusion here. Can > you give me one concrete example, in which a French, German, or any > other non-US American taboo was violated and not counteracted with swift > reaction? Right, I would assume that if someone knowingly posted a similar post, but using say a French taboo, the same would have happened. The key thing is that the author obviously *knew* it was a taboo, it wasn?t an accident. If someone accidentally posted something like that, then I presume the outcome would be something more like a warning and telling them not to do it again? for any culture?s taboo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at python.org Fri Sep 21 07:06:17 2018 From: christian at python.org (Christian Heimes) Date: Fri, 21 Sep 2018 13:06:17 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: On 20/09/2018 22.25, Antoine Pitrou wrote: > > Hi, > > I'm choosing to forward this to python-committers because I don't think > python-ideas is a reasonable place to discuss CoC decisions. > > I think the action taken by Brett (apparently decided with Titus and a > mysterious "conduct working group") is not the right one: > > - a definitive ban is an extremely strong decision that should only be > taken if nothing else works. May I remind that Anatoly was able to post > prolifically and unconstructively for several years, being warned > several times, before being finally banned? Comparatively, this one ban > seems expeditive. In my opinion it's both wrong and unfair to compare the ban with Anatoly's ban. For one we didn't have a process and general consent for bans. It took us a while to agree on the procedure. Also Anatoly wasn't flat out hostile and insulting. He was mentally draining and exhausting on a more subtle level. I'm all in favor to ban people from python-dev or python-ideas for deliberate misuse and insults. Participation on these mailing lists is a privilege, not a right. We grant the privilege to everybody, but also reserve the right to remove the privilege. Brett, Titus, I support your decision. Christian From antoine at python.org Fri Sep 21 07:07:42 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 13:07:42 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> Message-ID: <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> Le 21/09/2018 ? 12:55, Christian Heimes a ?crit?: > On 21/09/2018 12.46, Antoine Pitrou wrote: >> >> Le 21/09/2018 ? 02:06, Nathaniel Smith a ?crit?: >>> Now sure, that taboo is an American thing, and I wouldn't support >>> automatically banning someone who used it in genuine ignorance, was >>> repentant when they realized what they'd done, etc. >> >> So why are American taboos specifically forbidden, and not other taboos? >> Is there anything special about Americans that deserves this? Does it >> mean that Python is a community for Americans foremost, and others are >> just second-class participants? The more this is going on, the more it >> is the impression I get, and things have become distinctly *worse* recently. > > I don't understand why you are drawing the reverse conclusion here. Can > you give me one concrete example, in which a French, German, or any > other non-US American taboo was violated and not counteracted with swift > reaction? I don't know of specifically French linguistic taboos, so I'm unable to answer this. French culture generally doesn't ban words wholesale, even when used in quotes. The very idea that you can't *quote* something despicable is foreign here. But, were it to exist, I have a hard time imagining it would face immediate permanent banning on python-XXX. And I would be against such immediate permanent banning, because that's inappropriately strong and definitive. Regards Antoine. From antoine at python.org Fri Sep 21 07:37:47 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 13:37:47 +0200 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: Le 21/09/2018 ? 13:06, Christian Heimes a ?crit?: > > In my opinion it's both wrong and unfair to compare the ban with > Anatoly's ban. For one we didn't have a process and general consent for > bans. AFAIK we still don't. I don't know where such a procedure is written out, and I don't remember my opinion being asked or considered on the matter. I certainly don't remember consenting to immediate permanent bans as a response to use of culture-specific taboos (rather than actual insults or racist discourse). As it is, the current "process" is vague and privately decided. That's not an acceptable standard on a mature project. > It took us a while to agree on the procedure. Also Anatoly wasn't > flat out hostile and insulting. He was mentally draining and exhausting > on a more subtle level. Yeah... no, not so subtle. You're painting things in a rosy colour here. He had been a problem for months or years. It was obvious something had to be done. But apparently the "key people" were reluctant to take a decision, even though there was frequent outrage at Anatoly's contributions. Now we're facing the inverse problem: the "key people" feel like they have to take overhanded decisions extremely quickly, as if it was going to make the atmosphere more peaceful (which, by construction, it won't). > Participation on these mailing lists is a > privilege, not a right. We grant the privilege to everybody, but also > reserve the right to remove the privilege. "Privilege" is a weird way to describe volunteer labour. Regards Antoine. From willingc at gmail.com Fri Sep 21 07:38:21 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 21 Sep 2018 07:38:21 -0400 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> Message-ID: <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> > On Sep 21, 2018, at 7:07 AM, Antoine Pitrou wrote: > > > Le 21/09/2018 ? 12:55, Christian Heimes a ?crit : >> On 21/09/2018 12.46, Antoine Pitrou wrote: >>> >>> Le 21/09/2018 ? 02:06, Nathaniel Smith a ?crit : >>>> Now sure, that taboo is an American thing, and I wouldn't support >>>> automatically banning someone who used it in genuine ignorance, was >>>> repentant when they realized what they'd done, etc. >>> >>> So why are American taboos specifically forbidden, and not other taboos? >>> Is there anything special about Americans that deserves this? Does it >>> mean that Python is a community for Americans foremost, and others are >>> just second-class participants? The more this is going on, the more it >>> is the impression I get, and things have become distinctly *worse* recently. >> >> I don't understand why you are drawing the reverse conclusion here. Can >> you give me one concrete example, in which a French, German, or any >> other non-US American taboo was violated and not counteracted with swift >> reaction? > > I don't know of specifically French linguistic taboos, so I'm unable to > answer this. French culture generally doesn't ban words wholesale, even > when used in quotes. The very idea that you can't *quote* something > despicable is foreign here. > > But, were it to exist, I have a hard time imagining it would face > immediate permanent banning on python-XXX. And I would be against such > immediate permanent banning, because that's inappropriately strong and > definitive. > Much of the discussion here has focused on the use of a few words. IMHO, discussing violence, assault, and implying that its okay to accept and trivialize this violence do not belong in posts about the Python language. From the original post: Being triggered by a word this simple is not exactly a sign of mental stability. I know a girl who's been raped more than she can count - but the word doesn't trigger her like this(only makes her want to beat up rapists). If people can do that, then surely a playground insult wont reduce you to tears, right ? > Regards > > Antoine. > _______________________________________________ > 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 p.f.moore at gmail.com Fri Sep 21 07:39:19 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 21 Sep 2018 12:39:19 +0100 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> Message-ID: On Thu, 20 Sep 2018 at 21:37, Antoine Pitrou wrote: > > > Apparently it's this one: > https://mail.python.org/pipermail/python-ideas/2018-September/053482.html > > By the way, regardless of this single case, I would like people to think > of the broader issue we're having. It's more than a single contentious > decision. Before I say anything else, I want to point out that (a) I'm not objecting to the ban, or the process that took place to impose it, and (b) I'm extremely appreciative of the work our moderators put into trying to police things in an increasingly difficult environment. So please take anything I say in that context - as perspective from someone who is concerned about the direction that certain of our groups are taking, but understands that it's not an easy problem to solve. But in the interest of looking at the broader issue (which I agree with Antoine is something we should be concerned about)... I understand that the taboo in question is a strong one in American culture, and as such violating that is inconsiderate and insensitive. Doing so deliberately is both unacceptable, and a cheap form of debate (if giving offense is the only way you have to make your point, maybe your point's not good enough?) But it is still very much one culture's position, and American sensibilities often seem to be very clear and present in a lot of the debates we see that "get out of hand" in one way or another. I'm British (and my age may also be relevant - I grew up in the 1960s and 70s), and from my perspective, it feels like a lot of people are over-sensitive, and very quick to perceive offense - to the extent that entirely natural (to many British people) and accepted tones, like sarcasm and irony, are almost impossible to express without having to completely obscure meaning by adding clarifications and explanations. I'll also comment on the point made here, can anyone point to a non-American taboo that has been violated and hasn't been dealt with the same way? Not really, but in my case that's because I don't think the British *have* strong taboos like that (and Antoine indicates that the same is true of the French). The only thing I can think of is religious taboos, such as Muslim concerns about taking the name of the Prophet in vain, but I don't think I've ever seen that sort of violation (and I would expect that to be dealt with just as swiftly). Personally, as a Catholic, arguing religious taboos on a list about a language based on Monty Python feels ironic anyway - but for the record, please don't ban references to the Spanish Inquisition or the Holy Grail on my account :-) Openness needs to be a two way street, in my view. Certainly people from cultures that have a more "robust" (shall we say) natural form of expression need to be aware that other cultures and people may not be able to deal with that - but conversely, people from cultures with a strong sense of certain words and expressions being unacceptable need to be open to the fact that others don't have that sense, and expect thicker skins in debate. That's not how I see the Python community going at the moment - rather we're moving towards a "lowest common denominator" approach, where *everyone* needs to skirt around all possible forms of offense, and the person claiming to be offended is in effect always in the right. That, to me, is taking the easy option, and I think that the Python community should aspire to do something better than that, even if it's hard. The internet in general is a hugely beneficial technology, allowing us to interact with people in radically different cultures and situations than we were ever able to in the past. That's a massive step forward for humanity as a whole in understanding each other - and we shouldn't undermine it by putting up barriers to communication in the form of preventing people from making (and learning from) dumb social mistakes. As things stand, everyone is living in fear of giving offense. As an example, some time ago, I was participating in a discussion where some participant made a comment that I thought was a bit out of line with the list's policy,. It didn't bother me, personally, at all (as I say, I'm British :-)) but rather than let it lie, I felt that I should mention this, rather than leave it to someone else. However, what ended up happening was that I got a lot of criticism for "taking offense unnecessarily". (I don't have a link, and I don't want to provide one - it's an example, not something I feel the need to analyze further). So rather than *helping*, I ended up being the bad guy simply from trying to channel other people's views and getting it wrong. And I ended up with a strong sense that everyone viewed me as the sort of over-sensitive complainer that I try very, very hard not to be. When I write mails for the lists, it's an exhausting process. The technical content is easy, but policing my own tone against an increasingly complex and restrictive set of standards that I don't personally subscribe to, nor do I really understand, is becoming a burden that puts me off contributing. That is *not* to say that I have any problem with the CoC - I certainly wouldn't consider myself to be anything other than "Open, Considerate and Respectful" - but I constantly feel that I have to word my contributions in a way that's unnatural to me, simply because I have to take the view that people reading my words have no sense of who I am, and cannot get any such sense because if I were to "loosen up", there's too much of a risk that someone would take offense. (As an example, people who know me in real life would be used to me referring to things as "stupid" and "idiotic" and wouldn't worry or take offense - because I call *myself* "stupid" and "idiotic" far more often than I use the terms about anything else - but how would I ever get to the point where I could do that in a list conversation? So I have to find alternative words which convey the same sense that I get when I say "stupid" - and that basically means a 5 or 6 word phrase with a couple of footnotes saying "no, I don't mean you personally" or similar. Which destroys the readability of my comment. Much like my having to over-expand this parenthetical note has done ;-)) We have to take care. There are no visual or body language cues when writing emails. I'm not arguing that people should be given license to say whatever they want. But nor should people be made to live in fear of making a genuine mistake. Paul From p.f.moore at gmail.com Fri Sep 21 08:01:15 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 21 Sep 2018 13:01:15 +0100 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: On Fri, 21 Sep 2018 at 12:38, Carol Willing wrote: > Much of the discussion here has focused on the use of a few words. > > IMHO, discussing violence, assault, and implying that its okay to accept and trivialize this violence do not belong in posts about the Python language. > > From the original post: > > Being triggered by a word this simple is not exactly a > sign of mental stability. I know a girl who's been raped more than she can > count - but the word doesn't trigger her like this(only makes her want to > beat up rapists). If people can do that, then surely a playground insult > wont reduce you to tears, right ? I agree - *but* there's a whole lot more I wish I could say, about context, and looking at how the conversation reached that point. But I won't, because frankly I'm scared to do so. I don't trust myself to explain my feelings without doing so in a way that people find offensive, and suffering a backlash that I didn't intend to trigger, and which won't help the discussion. I'm not sure that "I'm too scared to participate in this discussion" is where we want to be, though... Paul From willingc at gmail.com Fri Sep 21 08:26:36 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 21 Sep 2018 08:26:36 -0400 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: Hi Paul, Thanks for sharing your thoughts. Fear of speaking or fear of reading - both are not ideal. The balance of respectful discourse likely falls somewhere between the two. Context is important. I wonder though if the author's intent was constructive comment... On Fri, Sep 21, 2018, 8:01 AM Paul Moore wrote: > On Fri, 21 Sep 2018 at 12:38, Carol Willing wrote: > > > Much of the discussion here has focused on the use of a few words. > > > > IMHO, discussing violence, assault, and implying that its okay to accept > and trivialize this violence do not belong in posts about the Python > language. > > > > From the original post: > > > > Being triggered by a word this simple is not exactly a > > sign of mental stability. I know a girl who's been raped more than she > can > > count - but the word doesn't trigger her like this(only makes her want to > > beat up rapists). If people can do that, then surely a playground insult > > wont reduce you to tears, right ? > > I agree - *but* there's a whole lot more I wish I could say, about > context, and looking at how the conversation reached that point. > > But I won't, because frankly I'm scared to do so. I don't trust myself > to explain my feelings without doing so in a way that people find > offensive, and suffering a backlash that I didn't intend to trigger, > and which won't help the discussion. > > I'm not sure that "I'm too scared to participate in this discussion" > is where we want to be, though... > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Fri Sep 21 08:30:40 2018 From: donald at stufft.io (Donald Stufft) Date: Fri, 21 Sep 2018 08:30:40 -0400 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: > On Sep 21, 2018, at 8:01 AM, Paul Moore wrote: > > On Fri, 21 Sep 2018 at 12:38, Carol Willing wrote: > >> Much of the discussion here has focused on the use of a few words. >> >> IMHO, discussing violence, assault, and implying that its okay to accept and trivialize this violence do not belong in posts about the Python language. >> >> From the original post: >> >> Being triggered by a word this simple is not exactly a >> sign of mental stability. I know a girl who's been raped more than she can >> count - but the word doesn't trigger her like this(only makes her want to >> beat up rapists). If people can do that, then surely a playground insult >> wont reduce you to tears, right ? > > I agree - *but* there's a whole lot more I wish I could say, about > context, and looking at how the conversation reached that point. > > But I won't, because frankly I'm scared to do so. I don't trust myself > to explain my feelings without doing so in a way that people find > offensive, and suffering a backlash that I didn't intend to trigger, > and which won't help the discussion. > > I'm not sure that "I'm too scared to participate in this discussion" > is where we want to be, though? I think that this is being framed somewhat poorly. The idea that the problem is that someone might be ?offended? is I think the wrong take away. People can choose all manner of things to be offended by and just because someone might take offense to a statement, doesn?t mean that the statement is inherently something that cannot be uttered here. For instance, someone might take offense if you say that you think it?s easier to write clean code in Python than Brainfuck (or perhaps that pip is the best or worst package installer ;) ), but that doesn?t mean that you can?t express that opinion. What I think the real problem is, things that attack people, particularly for some inherent thing they are or something that has happened to them outside of their control or the like. Sometimes that can come across as ?well someone might take offense to the use of this word?, and it?s important I think to remember why that word has that particular connotation. If you spent a lifetime having someone shout ?Python!? and then a bucket of cold water dumped on you, you would likely start to get a bit afraid anytime you heard someone say ?Python?, when you?d look for that next bucket. That?s a really silly example, but there are groups of people who *to this day* are attacked in one form of another simply for who they are, and there are a lot of things associated with those attacks, be it words, or images, or what have you, and the mere use of those words, images, or whatever can make those groups of people feel like the space they?re in is one that is likely to attack them too. That?s not just about the specific word used in the original post, but also things like making joke of assault and similar as well. It?s particularly troublesome in a society that doesn?t entirely believe that those things are wrong. So part of being and open and welcoming community, is knowing and understanding that words, images, etc like that can make people feel like we?re either a group that will directly engage in those attacks that have been associated with them in the past, or at least won?t come to their aid if someone does initiate those kinds of attack. This is a bit different than say the use of Master/slave. Those words might make some people feel uncomfortable for sure, but they don?t have the same connotations. Because they make people feel uncomfortable, it?s generally a good idea to avoid using them (particularly when there are better, more descriptive terms available) but that you?re not going to be cast out into the wilderness if you happened to use them. Overall, I think people are generally reasonable, and if you say something ?bad?, but you weren?t aware or didn?t mean it that way, people generally accept an apology and then will move on [1]. They might be a bit less unsure of you after that, but if you don?t continue to repeat it, then most people will forget about it and look at it as an isolated incidence. Obviously if you keep doing it, and apologizing each time, at some point people are going to just assume the apology isn?t in earnest. [1] I know this, because I?ve done it. I grew up in let?s say, a very rural setting, and I had expressions that were disparaging to groups of people, that I didn?t really intend to be, it was just something I had always said because it was a common idiom where I grew up. I got called out on it, apologized, and everyone went on their way. From p.f.moore at gmail.com Fri Sep 21 08:45:14 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 21 Sep 2018 13:45:14 +0100 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: On Fri, 21 Sep 2018 at 13:26, Carol Willing wrote: > Context is important. I wonder though if the author's intent was constructive comment... I'm sure it wasn't. But in context, it was a statement made in a thread that had long previously become nothing more than non-constructive invective. Calling one person out (even though his comments were significantly more extreme than others') strikes me as looking for a culprit, rather than addressing the situation. It's not likely to be a practical option on a mailing list, but in primary school (which the whole conversation felt like) a likely response would have been to put *everyone* involved in a time-out for a period of cooling off, to think about how their behaviour was unacceptable. Think for example of a group of kids taunting each other until one of them snaps and hits someone. Paul From alexander.belopolsky at gmail.com Fri Sep 21 08:52:17 2018 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Fri, 21 Sep 2018 08:52:17 -0400 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> Message-ID: On Fri, Sep 21, 2018 at 7:07 AM Antoine Pitrou wrote: > > I don't know of specifically French linguistic taboos, so I'm unable to > answer this. French culture generally doesn't ban words wholesale, even > when used in quotes. The very idea that you can't *quote* something > despicable is foreign here. > Russian has a handful of taboo word and a long tradition of censoring them, but most of such words have no English equivalent, so you won't see them in this forum. BTW, the "n-word" exists in Russian and is not a taboo, so like Antoine I have to trust the moderators on the graveness of the offense of spelling it out. Still, this whole discussion reminds me an old Russian joke: "A lesson in a kindergarten: ... and now, children, let's recite the words that you should never use." -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Fri Sep 21 08:59:52 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 21 Sep 2018 13:59:52 +0100 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: On Fri, 21 Sep 2018 at 13:30, Donald Stufft wrote: > So part of being and open and welcoming community, is knowing and understanding that words, images, etc like that can make people feel like we?re either a group that will directly engage in those attacks that have been associated with them in the past, or at least won?t come to their aid if someone does initiate those kinds of attack. I'm going to take this one comment and respond to it out of context. But generally, I agree with everything you said. My biggest concern is that we're starting to build a community where people feel exposed to attack for "CoC violation" accusations over simple misunderstandings, or careless wordings. Or, for that matter, using terminology that they weren't aware was unacceptable. Not "being called out (by the offended party), apologising and moving on", but going straight to policy complaints by people (maybe even people not directly upset) assuming offense could be claimed. That's clearly nothing like the sort of problems people with real reason for sensitivity have to live under, but nevertheless it's not a comfortable place for people to learn how to interact. Balance, forgiveness, and a mature level of empathy are what's *really* needed ("among the things that are needed...":-)). Not policies. Policies should be weapons of last resort. Paul From nad at python.org Fri Sep 21 09:08:52 2018 From: nad at python.org (Ned Deily) Date: Fri, 21 Sep 2018 09:08:52 -0400 Subject: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon In-Reply-To: References: <3ABAB3B5-6346-49F2-98F7-185303166016@python.org> Message-ID: <8629D385-F3BF-417C-A12E-4FC3FA4F4F12@python.org> On Sep 21, 2018, at 05:37, Christian Heimes wrote: > On 19/09/2018 23.12, Ned Deily wrote: >> Update: not surprisingly, there have been a number of issues that have popped up during and since the sprint that we would like to ensure are addressed in 3.7.1 and 3.6.7. In order to do so, I've been holding off on starting the releases. I think we are now getting close to having the important ones resolved so I'm going to plan on cutting off code for 3.7.1rc1 and 3.6.7rc1 by the end of 2018-09-20 (23:59 AoE). That's roughly 38 hours from now. > I'm really sorry, but would it be possible to delay the RCs until Sunday > or Monday AoE? > > Some of the XML security fixes, OpenSSL 1.1.1 fixes (TLS 1.3 > post-handshake authentication), and SSL module regression haven't landed > yet. I'm confident that I can land most to all fixes during the weekend. > > Related PRs are: > > * https://github.com/python/cpython/pull/9468 > * https://github.com/python/cpython/pull/9460 > * https://github.com/python/cpython/pull/9217 > * https://github.com/python/cpython/pull/9265 > > I'm also still collaborating with Sebastian Pipping (libexpat > maintainer) on the DoS mitigations (CVE-2013-0340). My initial patch had > some flaws. I might be able to get expat release 2.3.0 in time, too. > > https://github.com/libexpat/libexpat/pull/220 I agree that it would be good to get the security-related and OpenSSL-related fixes in sooner than later and there has been a lot going on recently. Since you have asked so nicely, I have rescheduled the cutoffs for 3.7.1rc1 and 3.6.7rc1 to be by the end of 2018-09-24 (23:59 AoE) and the final releases now on 2018-10-04. Everyone else: here are a few more days to get important things in to these releases. -- Ned Deily nad at python.org -- [] From donald at stufft.io Fri Sep 21 09:37:58 2018 From: donald at stufft.io (Donald Stufft) Date: Fri, 21 Sep 2018 09:37:58 -0400 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: <686AC3FC-2EBF-4A3D-B814-C6EEADEAE12D@stufft.io> > On Sep 21, 2018, at 8:59 AM, Paul Moore wrote: > > On Fri, 21 Sep 2018 at 13:30, Donald Stufft wrote: >> So part of being and open and welcoming community, is knowing and understanding that words, images, etc like that can make people feel like we?re either a group that will directly engage in those attacks that have been associated with them in the past, or at least won?t come to their aid if someone does initiate those kinds of attack. > > I'm going to take this one comment and respond to it out of context. > But generally, I agree with everything you said. > > My biggest concern is that we're starting to build a community where > people feel exposed to attack for "CoC violation" accusations over > simple misunderstandings, or careless wordings. Or, for that matter, > using terminology that they weren't aware was unacceptable. Not "being > called out (by the offended party), apologising and moving on", but > going straight to policy complaints by people (maybe even people not > directly upset) assuming offense could be claimed. That's clearly > nothing like the sort of problems people with real reason for > sensitivity have to live under, but nevertheless it's not a > comfortable place for people to learn how to interact. > > Balance, forgiveness, and a mature level of empathy are what's > *really* needed ("among the things that are needed...":-)). Not > policies. Policies should be weapons of last resort. > > Paul So I don?t think that being called out by the aggrieved party is the right response generally for these sorts of things. I mean, ultimately it depends on the specific instance, but often times having the person who is feeling attacked call out the other person, what?s going to happen is that person is going to feel compelled to respond back in kind and ?defend? themselves. Having a neutral third party there to mediate and calm the situation down is immensely helpful. I mean, if you personally did something that made me feel uncomfortable, I?d probably personally handle it, because we have a rapport already, but if someone else did there?s a chance I wouldn?t (either because there might be history there where a specific instance finally spilled over, or because I?m angry/hurt/whatever and I don?t trust myself to respond). This also falls into the feeling exposed to attack bit. Generally what the CoC does should be private, though it?s tough to balance that out with being transparent too. For instance, we don?t really want to turn CoC enforcement into it?s own sort of shame. If you were to report me, ideally the way it would play out is some member of the moderation team / CoC team / whatever would privately contact me, and tell me to knock it off or whatever. Generally other people shouldn?t know (unless one of the two sides of the issues chooses to divulge it) that it happened (although it?s good to publish anonymized reports too). There should not be some sort of record that the dastardly Paul said something bad once and had to get reprimanded. Where it gets harder is when more drastic measures are to be taken. If someone gets banned for a day in a sort of timeout, should that be public? Probably not since we want them to come back and ideally be positive contributors from that point out, and feeling like they?ve been put up on display is probably not conducive towards that, and being gone for a day is not likely to be something where other people notice the absence and start to question it. What about a week? A month? Permanent? Personally I think that publicizing that a particular person had some action taken against them is probably the wrong path to take in all severity levels, and that the CoC team should probably publish some sort of anonymized reports. These reports basically serve to show people who are worried about feeling safe/welcome in the community, that if they have a problem they?re likely to be heard and helped, without putting particular people ?on blast?. Unfortunately our tooling and process isn?t really ?here? yet, for instance in the specific case we?re talking about, if that person was jsut silently banned than it can feel a bit kafkaesque and since the record of his statement is permanent and can?t be hidden or something, people looking in from the outside don?t know that it wasn?t acceptable since they don?t see any action to have taken place. The ideal situation is probably that the original post ends up edited, marked, or hidden in some fashion (but doesn?t just disappear) to say that it was inappropriate in some way (think what GitHub does here with hidden posts) but that doesn?t otherwise create some sort of notification. I however, think policies are great! Particularly in a diverse community where the cultural norms may vary widely amongst all of the participants. It helps document what the community expects from people, tells you what the process to take is for remediation of a bad situation, and for the people taking those steps, provides a framework to determine what the best possible outcome is. Or to put another way, the choice isn?t between not having a policy, and having a policy, the choice is between having an implicit policy where what is allowed and what isn?t is left up to the whims of whoever happens to be around at the moment, where enforcement is likely to be very uneven based on who the offender is etc, versus an explicit policy that spells out the expectations for everyone (and explicit is better than implicit after all ;)). The PSF CoC falls short in this area, since it?s mostly a vague, aspirational document that leaves a lot to be implicit versus one that is more specific. From guido at python.org Fri Sep 21 10:35:09 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 21 Sep 2018 07:35:09 -0700 Subject: [python-committers] =?utf-8?q?Fwd=3A_=5BPython-ideas=5D_JS?= =?utf-8?q?=E2=80=99_governance_model_is_worth_inspecting?= In-Reply-To: References: Message-ID: Perhaps worth including in PEP 8002, the overview of other governance models? (Though the process described here seems to be JS's equivalent of our PEP process -- it doesn't say anything about how TC39 gets formed or how non-technical decisions are handled.) ---------- Forwarded message --------- From: James Lu Date: Fri, Sep 21, 2018 at 4:25 AM Subject: [Python-ideas] JS? governance model is worth inspecting To: JS? decisions are made by a body known as TC39, a fairly/very small group of JS implementers. First, JS has an easy and widely supported way to modify the language for yourself: Babel. Babel transpires your JS to older JS, which is then run. You can publish your language modification on the JS package manager, npm. When a feature is being considered for inclusion in mainline JS, the proposal must first gain a champion (represented by ?)that is a member of TC-39. The guidelines say that the proposal?s features should already have found use in the community. Then it moves through three stages, and the champion must think the proposal is ready for the next stage before it can move on. I?m hazy on what the criterion for each of the three stages is. The fourth stage is approved. I believe the global TC39 committee meets regularly in person, and at those meetings, proposals can advance stages- these meetings are frequent enough for the process to be fast and slow enough that people can have the time to try out a feature before it becomes main line JS. Meeting notes are made public. The language and its future features are discussed on ESDiscuss.org, which is surprisingly filled with quality and respectful discussion, largely from experts in the JavaScript language. I?m fairly hazy on the details, this is just the summary off the top of my head. ? I?m not saying this should be Python?s governance model, just to keep JS? in mind. _______________________________________________ Python-ideas mailing list Python-ideas at python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Fri Sep 21 10:38:09 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 16:38:09 +0200 Subject: [python-committers] =?utf-8?q?Fwd=3A_=5BPython-ideas=5D_JS?= =?utf-8?q?=E2=80=99_governance_model_is_worth_inspecting?= In-Reply-To: References: Message-ID: Le 21/09/2018 ? 16:35, Guido van Rossum a ?crit?: > Perhaps worth including in PEP 8002, the overview of other governance > models? (Though the process described here seems to be JS's equivalent > of our PEP process -- it doesn't say anything about how TC39 gets formed > or how non-technical decisions are handled.) Right, I think further research (and/or a contact with the right persons to answer our questions) may be necessary before including it in the survey. I don't have much time myself, unfortunately (I didn't even get a chance to entirely read the other contributions to the PEP :-/). Regards Antoine. > > ---------- Forwarded message --------- > From: *James Lu* > > Date: Fri, Sep 21, 2018 at 4:25 AM > Subject: [Python-ideas] JS? governance model is worth inspecting > To: > > > > JS? decisions are made by a body known as TC39, a fairly/very small > group of JS implementers. > > First, JS has an easy and widely supported way to modify the language > for yourself: Babel. Babel transpires your JS to older JS, which is then > run. > > You can publish your language modification on the JS package manager, npm. > > When a feature is being considered for inclusion in mainline JS, the > proposal must first gain a champion (represented by ?)that is a member > of TC-39. The guidelines say that the proposal?s features should already > have found use in the community. Then it moves through three stages, and > the champion must think the proposal is ready for the next stage before > it can move on. I?m hazy on what the criterion for each of the three > stages is. The fourth stage is approved. > > I believe the global TC39 committee meets regularly in person, and at > those meetings, proposals can advance stages- these meetings are > frequent enough for the process to be fast and slow enough that people > can have the time to try out a feature before it becomes main line JS. > Meeting notes are made public. > > The language and its future features are discussed on ESDiscuss.org, > which is surprisingly filled with quality and respectful discussion, > largely from experts in the JavaScript language. > > I?m fairly hazy on the details, this is just the summary off the top of > my head. > > ? > I?m not saying this should be Python?s governance model, just to keep > JS? in mind. > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > -- > --Guido van Rossum (python.org/~guido ) > > > _______________________________________________ > 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 Fri Sep 21 10:51:19 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 21 Sep 2018 16:51:19 +0200 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: <26858404-1da8-3fd6-73de-463c7bc41675@python.org> Le 21/09/2018 ? 14:45, Paul Moore a ?crit?: > > It's not likely to be a practical option on a mailing list, but in > primary school (which the whole conversation felt like) a likely > response would have been to put *everyone* involved in a time-out for > a period of cooling off, to think about how their behaviour was > unacceptable. Think for example of a group of kids taunting each other > until one of them snaps and hits someone. With a forum system, the thread would just have been locked. However, you may not physically lock a mailing-list thread, but you can post a moderator's announcement asking everyone to stop posting to that thread, and warning that failing to comply would get the offender e.g. a 7-day ban (regardless of the contents of their post). Regards Antoine. From willingc at gmail.com Fri Sep 21 11:12:06 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 21 Sep 2018 11:12:06 -0400 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <26858404-1da8-3fd6-73de-463c7bc41675@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> <26858404-1da8-3fd6-73de-463c7bc41675@python.org> Message-ID: > On Sep 21, 2018, at 10:51 AM, Antoine Pitrou wrote: > > > Le 21/09/2018 ? 14:45, Paul Moore a ?crit : >> >> It's not likely to be a practical option on a mailing list, but in >> primary school (which the whole conversation felt like) a likely >> response would have been to put *everyone* involved in a time-out for >> a period of cooling off, to think about how their behaviour was >> unacceptable. Think for example of a group of kids taunting each other >> until one of them snaps and hits someone. > > With a forum system, the thread would just have been locked. > > However, you may not physically lock a mailing-list thread, but you can > post a moderator's announcement asking everyone to stop posting to that > thread, and warning that failing to comply would get the offender e.g. a > 7-day ban (regardless of the contents of their post). > This seems like a very reasonable stop gap until we have better moderation tools. > Regards > > Antoine. > _______________________________________________ > 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 tjreedy at udel.edu Fri Sep 21 15:17:18 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 21 Sep 2018 15:17:18 -0400 Subject: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> Message-ID: <0d3755df-44ed-140e-3b59-056beb0ee0f1@udel.edu> On 9/21/2018 6:55 AM, Christian Heimes wrote: > I don't understand why you are drawing the reverse conclusion here. Can > you give me one concrete example, in which a French, German, or any > other non-US American taboo was violated and not counteracted with swift > reaction? Are you talking about someone posting a non-American 'taboo' word in the native language or an English translation thereof? From ethan at stoneleaf.us Fri Sep 21 17:34:13 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 21 Sep 2018 14:34:13 -0700 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: <26858404-1da8-3fd6-73de-463c7bc41675@python.org> References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> <26858404-1da8-3fd6-73de-463c7bc41675@python.org> Message-ID: <2e92b645-cc53-96d8-e187-998c3060f929@stoneleaf.us> On 09/21/2018 07:51 AM, Antoine Pitrou wrote: > Le 21/09/2018 ? 14:45, Paul Moore a ?crit?: >> It's not likely to be a practical option on a mailing list, but in >> primary school (which the whole conversation felt like) a likely >> response would have been to put *everyone* involved in a time-out for >> a period of cooling off, to think about how their behaviour was >> unacceptable. Think for example of a group of kids taunting each other >> until one of them snaps and hits someone. > > With a forum system, the thread would just have been locked. It is certainly not as convenient, but with the current system we can set a spam filter on subject lines and stop threads that way. It is still a pretty rough tool (whole thread, not sub-thread) and a bit awkward to use, but doable. Of course, we still have the problem of speed -- some threads blow up in a matter of hours. -- ~Ethan~ From zachary.ware+pydev at gmail.com Sun Sep 23 15:41:02 2018 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Sun, 23 Sep 2018 14:41:02 -0500 Subject: [python-committers] bpo triage privileges for Karthikeyan Singaravelan Message-ID: On the recommendation of Ammar Askar and with Serhiy's endorsement on Zulip [0], I've given Karthikeyan Singaravelan (CC'd) triage privileges on bugs.python.org. Karthikeyan, please use your new-found powers for good, and don't hesitate to ask for guidance if you need it. Keep up the good work, and thank you! [0] https://python.zulipchat.com/#narrow/stream/116501-workflow/subject/bug.20tracker.20triage.20permissions -- Zach From willingc at gmail.com Sun Sep 23 16:00:57 2018 From: willingc at gmail.com (Carol Willing) Date: Sun, 23 Sep 2018 16:00:57 -0400 Subject: [python-committers] bpo triage privileges for Karthikeyan Singaravelan In-Reply-To: References: Message-ID: <29812879-89D0-428A-9697-8F3E65E33F94@me.com> Congratulations Karthikeyan. Thanks for the good work. Carol > On Sep 23, 2018, at 3:41 PM, Zachary Ware wrote: > > On the recommendation of Ammar Askar and with Serhiy's endorsement on > Zulip [0], I've given Karthikeyan Singaravelan (CC'd) triage > privileges on bugs.python.org. > > Karthikeyan, please use your new-found powers for good, and don't > hesitate to ask for guidance if you need it. Keep up the good work, > and thank you! > > [0] https://python.zulipchat.com/#narrow/stream/116501-workflow/subject/bug.20tracker.20triage.20permissions > -- > Zach > _______________________________________________ > 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 mariatta.wijaya at gmail.com Mon Sep 24 14:32:18 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Mon, 24 Sep 2018 11:32:18 -0700 Subject: [python-committers] 1 week to Oct 1 Message-ID: It is now 7 days until October 1, the deadline for coming up with Python Governance PEPs. Some still relevant links: - https://www.python.org/dev/peps/pep-8000/ Python Language Governance Proposal Overview - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process - https://www.python.org/dev/peps/pep-8002 Open source governance survey These are current ideas and proposals, some are placeholders still. - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm claiming this PEP) - https://www.python.org/dev/peps/pep-8012 The Community Governance Model - https://www.python.org/dev/peps/pep-8013/ The External Council Governance Model - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model I have some questions: 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? 2. How do we discuss these PEPs? 3. At the sprint, there's a small workgroup formed for coming up with the procedure to vote. How is that coming? Could someone please write up a brief summary? (perhaps as a separate email thread) I think it would be great to have this written up soon, before Oct 1. Thanks. Mariatta ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Sep 24 17:46:56 2018 From: brett at python.org (Brett Cannon) Date: Mon, 24 Sep 2018 14:46:56 -0700 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: Message-ID: On Mon, 24 Sep 2018 at 11:32, Mariatta Wijaya wrote: > It is now 7 days until October 1, the deadline for coming up with Python > Governance PEPs. > > Some still relevant links: > > - https://www.python.org/dev/peps/pep-8000/ Python Language Governance > Proposal Overview > - https://www.python.org/dev/peps/pep-8001 Python Governance Voting > Process > - https://www.python.org/dev/peps/pep-8002 Open source governance survey > > These are current ideas and proposals, some are placeholders still. > > - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model > - https://www.python.org/dev/peps/pep-8011 The Council Governance Model > (I'm claiming this PEP) > - https://www.python.org/dev/peps/pep-8012 The Community Governance Model > - https://www.python.org/dev/peps/pep-8013/ The External Council > Governance Model > - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model > > I have some questions: > > 1. Is everyone still ok with the Oct 1 as deadline for coming up with > governance PEPs? > > 2. How do we discuss these PEPs? > I assume people will start threads about their PEPs to discuss them here (I'm also personally fine with discussing on Zulip, but I don't know how others feels about that). The one thing I would say is I would propose all discussion threads have a subject line that clearly denotes which PEP is being discussed to help keep it straight (e.g. "[PEP 8011] ..."). That way it's easy to keep the threads straight. > > 3. At the sprint, there's a small workgroup formed for coming up with the > procedure to vote. How is that coming? Could someone please write up a > brief summary? (perhaps as a separate email thread) I think it would be > great to have this written up soon, before Oct 1. > Raymond agreed to write up the approach we all agreed upon in our little breakout group as a draft PEP so they can be presented here to make sure people overall are happy with the ideas we reached consensus on. I'm not sure what his ETA is on that, but we were tentatively aiming for the last half of November for a vote so there isn't a hard deadline to have it posted and agreed to necessarily within the week (although obviously we would want to make sure people have plenty of notice of when the voting will occur so people aren't taken by surprise). -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Sep 25 02:58:19 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 08:58:19 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: Message-ID: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> Le 24/09/2018 ? 20:32, Mariatta Wijaya a ?crit?: > It is now 7 days until October 1, the deadline for coming up with Python > Governance PEPs. > > Some still relevant links: > > -?https://www.python.org/dev/peps/pep-8000/?Python Language Governance > Proposal Overview > -?https://www.python.org/dev/peps/pep-8001?Python Governance Voting Process > -?https://www.python.org/dev/peps/pep-8002?Open source governance survey > > These are current ideas and proposals, some are placeholders still. > > -?https://www.python.org/dev/peps/pep-8010?The BDFL Governance Model > -?https://www.python.org/dev/peps/pep-8011?The Council Governance Model > (I'm claiming this PEP) > -?https://www.python.org/dev/peps/pep-8012?The Community Governance Model > -?https://www.python.org/dev/peps/pep-8013/ The External Council > Governance Model > -?https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model > > I have some questions: > > 1. Is everyone still ok with the Oct 1 as deadline for coming up with > governance PEPs? As I predicted, Oct 1 seems to be coming up too early. Regards Antoine. From vstinner at redhat.com Tue Sep 25 03:40:57 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 25 Sep 2018 09:40:57 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: Message-ID: I wanted to read these 4 PEPs: Le lun. 24 sept. 2018 ? 20:32, Mariatta Wijaya a ?crit : > - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process > - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model > - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm claiming this PEP) > - https://www.python.org/dev/peps/pep-8012 The Community Governance Model All of them are empty. > 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? It doesn't make sense to me: * Nothing explains how we take a decision: PEP 8001 is empty * Governance PEPs are empty: how are we supposed to take a decision on an empty PEP? > 2. How do we discuss these PEPs? I suggest to use emails as we did previously, but only on python-committers. If someone wants to change that, I suggest to wait after the new governance is decided. Victor From mal at egenix.com Tue Sep 25 05:25:54 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 25 Sep 2018 11:25:54 +0200 Subject: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) In-Reply-To: References: <8d30ef1f-b9d5-fa97-4480-953afd819a65@python.org> <6277721B-70CD-44B2-B42C-5A61C8C3073C@stufft.io> <5BA420BD.8030802@stoneleaf.us> <5961a1a0-3882-591c-d766-5e27723390c8@python.org> <64a6edec-7907-5e5d-9cdd-723ae21ec16a@python.org> <87ecdf0b-552a-1ceb-90e4-7caeb06d58d5@python.org> <697CBF45-4F3B-4340-825F-94A1A89D82F8@me.com> Message-ID: <455f11d7-0bdf-7c1b-79aa-d68fd455d0b8@egenix.com> On 21.09.2018 14:59, Paul Moore wrote: > Balance, forgiveness, and a mature level of empathy are what's > *really* needed ("among the things that are needed...":-)). Not > policies. Policies should be weapons of last resort. Agreed. I guess we'll also have to learn that flamebait as we had it in the old days is now often launched as cocbait. It'll take some time to get used to this, but we'll have to try not to fall for it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 25 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/ From vstinner at redhat.com Tue Sep 25 06:14:24 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 25 Sep 2018 12:14:24 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: Message-ID: Hi, Since there are no concrete PEPs, I don't know where I should post my comments. I decided to send them here :-) For the new council/board idea (group of 3 or 5 peoples): * Can we require that each people comes from a different company? At least, require that no all of them work for the same company. I would mean that a member of this council would have to nominate someone else if they decide to move to a different company which already has ("too many") council members. * Mariatta proposed to require to have a least one woman in that council. What do you think of this idea? Honestly, I have no opinion yet, since I don't think this idea has been discussed enough yet. I would expect that only core developers could join the council and right now, there are 4 women core developers: Mariatta, Carol, Emily, Lisa. By the way, what's the process if someone wants to leave this council? Does they have to nominate someone? Or should we organize a new vote open to new candidates? I'm not sure that we decided how long members should stay in the council. I like the idea of a fixed duration. Or maybe align it to a release. For example, usually a development cycle takes 18 months. Maybe it's a good fit? A full release cycle allows to implement some ideas. Obviously, some ideas require multiple cycles, so maybe some candidates would like to reapply for the next cycle to continue their projects? Victor Le mar. 25 sept. 2018 ? 09:40, Victor Stinner a ?crit : > > I wanted to read these 4 PEPs: > > Le lun. 24 sept. 2018 ? 20:32, Mariatta Wijaya > a ?crit : > > - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process > > - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model > > - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm claiming this PEP) > > - https://www.python.org/dev/peps/pep-8012 The Community Governance Model > > All of them are empty. > > > 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? > > It doesn't make sense to me: > > * Nothing explains how we take a decision: PEP 8001 is empty > * Governance PEPs are empty: how are we supposed to take a decision on > an empty PEP? > > > 2. How do we discuss these PEPs? > > I suggest to use emails as we did previously, but only on > python-committers. If someone wants to change that, I suggest to wait > after the new governance is decided. > > Victor From antoine at python.org Tue Sep 25 07:24:14 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 13:24:14 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: Message-ID: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Hi, Le 25/09/2018 ? 12:14, Victor Stinner a ?crit?: > > Since there are no concrete PEPs, I don't know where I should post my > comments. I decided to send them here :-) > > For the new council/board idea (group of 3 or 5 peoples): > > * Can we require that each people comes from a different company? At > least, require that no all of them work for the same company. I would > mean that a member of this council would have to nominate someone else > if they decide to move to a different company which already has ("too > many") council members. The details must be ironed out, but that sounds like a good idea. There were routinely concerns about influencing the Python development process. Once it was Google, nowadays it seems to be Microsoft. (admittedly, Google probably didn't influence us very much in the end, but I'm not sure it's because we are immune to such a danger, rather than Python simply not being an attractive target enough, as opposed to e.g. Go or Javascript) > * Mariatta proposed to require to have a least one woman in that > council. What do you think of this idea? Honestly, I have no opinion > yet, since I don't think this idea has been discussed enough yet. I > would expect that only core developers could join the council and > right now, there are 4 women core developers: Mariatta, Carol, Emily, > Lisa. Why stop at women? There are many underrepresented groups. You could discriminate based on gender, skin colour, nationality, socio-economic origins, etc. The main problem, though, is we are talking about a very little group chosen amongst a likely very small number of candidates (I don't expect more than a dozen candidates, two dozens at most). If you start doing positive discrimination amongst such a small number of people, you disrupt the democratic process (by which I mean voting) a *lot*. Regards Antoine. From mariatta at python.org Tue Sep 25 07:52:31 2018 From: mariatta at python.org (Mariatta Wijaya) Date: Tue, 25 Sep 2018 04:52:31 -0700 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: > * Mariatta proposed to require to have a least one woman in that > council. > Why stop at women? My actual wording was: "not all white men", which actually means quite different from "must include one woman". I don't appreciate you jumping straight to accusing me for discrimination. Assume positive intent, and ask for clarity before scrutinizing and making accusations. My PEP will provide guideline on how members of the group should be nominated, and it is a long list. It will not name names. Only once the PEP has been accepted that people can nominate folks to fill the role, and there will be another round of voting. Some of the questions asked by Victor will be answered in the PEP that I'm writing, so I will not answer now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Sep 25 07:57:42 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 13:57:42 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: <0da36b4f-48fb-d029-71b7-0979f44bd776@python.org> Le 25/09/2018 ? 13:52, Mariatta Wijaya a ?crit?: > I don't appreciate you jumping straight to accusing me for > discrimination. Assume positive intent, and ask for clarity before > scrutinizing and making accusations. Not sure what you mean here. What you are asking for is routinely called, AFAIK, "positive discrimination". Please correct me if I'm wrong. You ask me to assume positive intent, but you are the one assuming negative intent on my part... Regards Antoine. From g.rodola at gmail.com Tue Sep 25 08:42:27 2018 From: g.rodola at gmail.com (Giampaolo Rodola') Date: Tue, 25 Sep 2018 14:42:27 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: On Tue, Sep 25, 2018 at 1:52 PM Mariatta Wijaya wrote: > > > * Mariatta proposed to require to have a least one woman in that > > council. > > > Why stop at women? > > > My actual wording was: "not all white men", which actually means quite different from "must include one woman". > > I don't appreciate you jumping straight to accusing me for discrimination. Assume positive intent, and ask for clarity before scrutinizing and making accusations. "white men", "women", "slave"... Personally I find this tendency quite worrying and discriminating and frankly I don't understand what it has to do with a programming language nor why it's emerging only recently. Whoever ends up in the council, approves a PEP, writes a patch, merges a PR... I think that person should be elected based *entirely* on their merits, not because of their gender or skin color. Electing someone just to represent a minority doesn't have anything to do with IT and cannot lead to a good outcome in the long run IMHO. -- Giampaolo - http://grodola.blogspot.com From barry at python.org Tue Sep 25 10:07:34 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Sep 2018 10:07:34 -0400 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: Message-ID: On Sep 24, 2018, at 14:32, Mariatta Wijaya wrote: > > 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? I?m afraid that I may not be, actually. I expected to have time to work on my PEP while I was on leave for my son?s wedding, but y?know, family! :) Mariatta and I are collaborating a bit on 8011, but I haven?t really had time to work on 8010. I don?t want to push it back too far, but a couple of weeks would really help. -Barry -------------- 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 Tue Sep 25 10:11:33 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 16:11:33 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: Message-ID: <3ae19ded-9ba8-f0b4-f28d-3ad46f1a1b11@python.org> Le 25/09/2018 ? 16:07, Barry Warsaw a ?crit?: > On Sep 24, 2018, at 14:32, Mariatta Wijaya wrote: >> >> 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? > > I?m afraid that I may not be, actually. I expected to have time to work on my PEP while I was on leave for my son?s wedding, but y?know, family! :) Mariatta and I are collaborating a bit on 8011, but I haven?t really had time to work on 8010. I don?t want to push it back too far, but a couple of weeks would really help. I would suggest November 1st, so that nobody feels pressured. Regards Antoine. From mariatta at python.org Tue Sep 25 10:28:10 2018 From: mariatta at python.org (Mariatta Wijaya) Date: Tue, 25 Sep 2018 07:28:10 -0700 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: My proposal is taking into consideration The PSF's mission and diversity statement. I will not remove the diversity clause from PEP 8011. To save us all trouble of discussing this particular issue, for those of you who disagree completely, and have other ideas about how you'd like Python to be governed and who should be in it, you can do one or more of the following: - not vote on my PEP - vote on the other PEPs - write their own PEP -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Tue Sep 25 10:54:16 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 25 Sep 2018 15:54:16 +0100 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: On Tue, 25 Sep 2018 at 15:28, Mariatta Wijaya wrote: > > My proposal is taking into consideration The PSF's mission and diversity statement. I will not remove the diversity clause from PEP 8011. > > To save us all trouble of discussing this particular issue, for those of you who disagree completely, and have other ideas about how you'd like Python to be governed and who should be in it, you can do one or more of the following: > > - not vote on my PEP > - vote on the other PEPs > - write their own PEP Or presumably - discuss the concerns during the debate phase of the process ? At the moment the discussion seems to be about a possible misinterpretation of a possible misquote of something the PEP might end up saying. It seems like it's probably worth waiting until the facts are clear before saying anything more. But once there's an actual PEP (not a placeholder) in place, I assume that discussions about the content *will* be acceptable (as long as they are reasonable and respectful, obviously). I don't recall the expected details of the actual process (if they've been published yet) but I don't expect them to be simply "here's the PEPs, let's vote!". Paul From steve.dower at python.org Tue Sep 25 11:24:13 2018 From: steve.dower at python.org (Steve Dower) Date: Tue, 25 Sep 2018 11:24:13 -0400 Subject: [python-committers] [PEP 8013] The External Council Governance Model Message-ID: <7f28da9c-a0f4-074d-9c49-38a0e64387e9@python.org> Here is the text of PEP 8013 for discussion and improvement (in isolation from the other proposals, of course -- we're not ready for the shoot-out yet.) I'm keen to see the model be considered, but I don't feel the need to tightly control the specific content in the PEP, so feel free to send your own PRs if you have definitive improvements. For the next few days I'm also going to have varying amounts of ability to read and respond to email. I'll try and catch up by the weekend or early next week. Rendered version at: https://www.python.org/dev/peps/pep-8013/ --- PEP: 8013 Title: The External Council Governance Model Author: Steve Dower Status: Draft Type: Informational Content-Type: text/x-rst Created: 2018-09-14 Abstract ======== This PEP proposes a new model of Python governance based on a Group of Unbiased Independent Directors of Order (GUIDO) tasked with making final decisions for the language. It differs from PEP 8010 by specifically not proposing a central singular leader, and from PEP 8011 by disallowing core committers from being council members. It describes the size and role of the council, how the initial group of council members will be chosen, any term limits of the council members, and how successors will be elected. It also spends significant time discussing the intended behaviour of this model. By design, many processes are not specified here but are left to the people involved. In order to select people who will make the best decisions, it is important for those involved to understand the expectations of GUIDO but it is equally important to allow GUIDO the freedom to adjust process requirements for varying circumstances. This only works when process is unspecified, but all participants have similar expectations. This PEP does *not* name the members of GUIDO. Should this model be adopted, it will be codified in PEP 13 along with the names of all officeholders described in this PEP. Open Discussion Points ====================== Some suggestions in this document are currently weak suggestions, and are open to change during the discussion period. These include: * We can change the name of the group. "Council of Auditors" is the suggested alternative, though "Python Inquisition" is very tempting if we believe we can be clear about the source of the name [1]_ * We can change voting procedures, timelines, and tie-breakage rules The Importance of the Grey Area =============================== In any actual decision-making process, there is going to be grey area. This includes unexpected scenarios, and cases where there is no "correct" answer. Many process plans attempt to minimise grey area by defining processes clearly enough that no flexibility is required. This proposal deliberately goes the other way. The aim is to provide a robust framework for choosing the best people to handle unexpected situations, without defining how those people should handle those situations. Examples are provided of "good" responses to some situations as an illustration. The hope is that the "best" people are the best because they would live up to those examples. The process that is proposed has been designed to minimise the damage that may be caused when those people turn out not to be the best. Grey area is guaranteed to exist. This proposal deliberately embraces and works within that, rather than attempting to prevent it. Model Overview ============== Key people and their functions ------------------------------ The Group of Unbiased Independent Directors of Order (GUIDO) is a council of varying size, typically two to four people, who are elected for the duration of a Python release. One member of GUIDO is considered the President, who has some minor points of authority over the other members. GUIDO has responsibility for reviewing controversial decisions in the form of PEPs written by members of the core development team. GUIDO may choose to accept a PEP exactly as presented, or may request clarification or changes. These changes may be of any form and for any reason. This flexibility is intentional, and allows the process to change over time as different members are elected to GUIDO. See the later sections of this document for examples of the kinds of requests that are expected. GUIDO only pronounces on PEPs submitted to python-committers. There is no expectation that GUIDO follows or participates on any other mailing lists. (Note that this implies that only core developers may submit PEPs. Non-core developers may write and discuss proposals on other mailing lists, but without a core developer willing to support the proposal by requesting pronouncement, it cannot proceed to acceptance. This is essentially the same as the current system, but is made explicit here to ensure that members of GUIDO are not expected to deal with proposals that are not supported by at least one core developer.) GUIDO may not delegate authority to individuals who have not been elected by the core developer team. (One relevant case here is that this changes the implementation of the existing BDFL-Delegate system, though without necessarily changing the spirit of that system. See the later sections for more discussion on this point.) The Release Manager (RM) is also permitted the same ability to request changes on any PEPs that specify the release they are responsible for. After feature freeze, the RM retains this responsibility for their release, while GUIDO rotates and begins to focus on the subsequent release. This is no different from the current process. The process for selection of a RM is not changed in this proposal. Core developers are responsible for electing members of GUIDO, and have the ability to call a "vote of no confidence" against a member of GUIDO. The details of these votes are discussed in a later section. Where discussions between core developers and members of GUIDO appear to be ongoing but unfruitful, the President may step in to overrule either party. Where the discussion involves the President, it should be handled using a vote of no confidence. Members of GUIDO may choose to resign at any point. If at least two members of GUIDO remain, they may request a new election to refill the group. If only one member remains, the election is triggered automatically. (The scenario when the President resigns is described in a later section.) The intended balance of power is that the core developers will elect members of GUIDO who reflect the direction and have the trust of the development team, and also have the ability to remove members who do not honour commitments made prior to election. Regular decision process ------------------------ Regular decisions continue to be made as at present. For the sake of clarity, controversial decisions require a PEP, and any decisions requiring a PEP are considered as controversial. GUIDO may be asked to advise on whether a decision would be better made using the controversial decision process, or individual members of GUIDO may volunteer such a suggestion, but the core development team is not bound by this advice. Controversial decision process ------------------------------ Controversial decisions are always written up as PEPs, following the existing process. The approver (formerly "BDFL-Delegate") is always GUIDO, and can no longer be delegated. Note that this does not prevent GUIDO from deciding to nominate a core developer to assess the proposal and provide GUIDO with a recommendation, which is essentially the same as the current delegation process. GUIDO will pronounce on PEPs submitted to python-committers with a request for pronouncement. Any member of GUIDO, or the current RM, may request changes to a PEP for any reason, provided they include some indication of what additional work is required to meet their expectations. See later sections for examples of expected reasons. When all members of GUIDO and the RM indicate that they have no concerns with a PEP, it is formally accepted. When one or more members of GUIDO fail to respond in a reasonable time, the President of GUIDO may choose to interpret that as implied approval. Failure of the President to respond should be handled using a vote of no confidence. Election terms -------------- Members of GUIDO are elected for the duration of a release. The members are elected prior to feature freeze for the previous release, and hold their position until feature freeze for their release. Members may seek re-election as many times as they like. There are no term limits. It is up to the core developers to prevent re-election of GUIDO members where there is consensus that the individual should not serve again. Election voting process ------------------------ The election process for each member of GUIDO proceeds as follows: * a nomination email is sent to python-committers * a seconding email is sent * the nominee is temporarily added to python-committers for the purpose of introducing themselves and presenting their position * voting opens two weeks prior to the scheduled feature freeze of the previous release * votes are contributed by modifying a document in a private github repository * each core developer may add +1 votes for as many candidates as they like * after seven days, voting closes * the nominee with the most votes is elected as President of GUIDO * the next three nominees with the most votes and also at least 50% the number of votes received by the President are elected as the other members of GUIDO * where ties need to be resolved, the RM may apply one extra vote for their preferred candidates * accepted nominees remain on python-committers; others are removed No-confidence voting process ---------------------------- A vote of no confidence proceeds as follows: * a vote of no confidence email is sent to python-committers, naming the affected member of GUIDO, justifying the nomination, and optionally listing accepted PEPs that the nominator believes should be reverted * a seconding email is sent within seven days * the nominated member of GUIDO is allowed seven days to respond, after which the nominator or the seconder may withdraw * if no nominator or seconder is available, no further action is taken * voting opens immediately * each core developer may add a +1 vote (remove the GUIDO member) or a -1 vote (keep the GUIDO member) by modifying a document in a private github repository * after seven days, voting closes * if +1 votes exceed -1 votes, the GUIDO member is removed from python-committers and any nominated PEPs are reverted * if requested by the remaining members of GUIDO, or if only one member of GUIDO remains, a new election to replace the removed member may be held following the usual process. * in the case of removing the President of GUIDO, the candidate who originally received the second-most votes becomes President Examples of intended behaviour ============================== This section describes some examples of the kind of interactions that we hope to see between GUIDO and the core developers. None of these are binding descriptions, but are intended to achieve some consensus on the types of processes we expect. GUIDO candidates may campaign on the basis of whatever process they prefer, and core developers should allocate votes on this basis. Scenario 1 - The Case of the Vague PEP -------------------------------------- Often in the past, initial proposals have lacked sufficient detail to be implementable by anyone other than the proposer. To avoid this, GUIDO should read proposals "fresh" when submitted, and without inferring or using any implied context. Then, when an aspect of a PEP is not clear, GUIDO can reject the proposal and request clarifications. Since the proposal is rejected, it must be modified and resubmitted in order to be reviewed again. GUIDO will determine how much guidance to provide when rejecting the PEP, as that will affect how many times it will likely be resubmitted (and hence affect GUIDO's own workload). This ensures that the final PEP text stands alone with all required information. Scenario 2 - The Case of the Endless Discussion ----------------------------------------------- From time to time, a discussion between Python contributors may seem to be no longer providing value. For example, when a large number of emails are repeating points that have already been dealt with, or are actively hostile towards others, there is no point continuing the "discussion". When such a discussion is occurring on python-committers as part of a request for pronouncement, a member of GUIDO should simply declare the thread over by rejecting the proposal. In most known cases, discussion of this sort indicates that not all concerns have been sufficiently addressed in the proposal and the author may need to enhance some sections. Alternatively, and in the absence of any rejection from the other members of GUIDO, the President may declare the thread over by accepting the proposal. Ideally this would occur after directly confirming with the rest of GUIDO and the RM that there are no concerns among them. When such a discussion is occurring on another list, members of GUIDO should be viewed as respected voices similar to other core developers (particularly those core developers who are the named experts for the subject area). While none have specific authority to end a thread, preemptively stating an intent to block a proposal is a useful way to defuse potentially useless discussions. Members of GUIDO who voluntarily follow discussions other than on python-committers are allowed to suggest the proposer withdraw, but can only actually approve or reject a proposal that is formally submitted for pronouncement. Scenario 3 - The Case of the Unconsidered Users ----------------------------------------------- Some proposals in the past may be written up and submitted for pronouncement without considering the impact on particular groups of users. For example, a proposal that affects the dependencies required to use Python on various machines may have an adverse impact on some users, even if many are unaffected due to the dependencies being typically available by default. Where a proposal does not appear to consider all users, GUIDO might choose to use their judgement and past experience to determine that more users are affected by the change than described in the PEP, and request that the PEP also address these users. They should identify the group of users clearly enough that the proposer is able to also identify these users, and either clarify how they were addressed, or made amendments to the PEP to explicitly address them. (Note that this does not involve evaluating the usefulness of the feature to various user groups, but simply whether the PEP indicates that the usefulness of the feature has been evaluated.) Where a proposal appears to have used flawed logic or incorrect data to come to a certain conclusion, GUIDO might choose to use other sources of information (such as the prior discussion or a submission from other core developers) to request reconsideration of certain points. The proposer does not necessarily need to use the exact information obtained by GUIDO to update their proposal, provided that whatever amendments they make are satisfactory to GUIDO. For example, a PEP may indicate that 30% of users would be affected, while GUIDO may argue that 70% of users are affected. A successful amendment may include a different but more reliable percentage, or may be rewritten to no longer depend on the number of affected users. References ========== .. [1] The Spanish Inquisition, ``_ Copyright ========= This document has been placed in the public domain. From vstinner at redhat.com Tue Sep 25 11:49:45 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 25 Sep 2018 17:49:45 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: Le mar. 25 sept. 2018 ? 13:57, Antoine Pitrou a ?crit : > Not sure what you mean here. What you are asking for is routinely > called, AFAIK, "positive discrimination". Please correct me if I'm wrong. > > You ask me to assume positive intent, but you are the one assuming > negative intent on my part... Note: in french, we say "discrimation positive", but in english, we prefer "positive action". Le mar. 25 sept. 2018 ? 14:42, Giampaolo Rodola' a ?crit : > "white men", "women", "slave"... Personally I find this tendency quite > worrying and discriminating and frankly I don't understand what it has > to do with a programming language nor why it's emerging only recently. > (...) If anyone is interested to talk about diversity, code of conduct and things like that: please contact me in private. These topics are difficult to discuss in a public space. At least, I'm not comfortable today to talk about them in public. There are good reasons why people don't talk about things like that in public. Victor From guido at python.org Tue Sep 25 11:54:00 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 25 Sep 2018 08:54:00 -0700 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: <3ae19ded-9ba8-f0b4-f28d-3ad46f1a1b11@python.org> References: <3ae19ded-9ba8-f0b4-f28d-3ad46f1a1b11@python.org> Message-ID: On Tue, Sep 25, 2018 at 7:11 AM Antoine Pitrou wrote: > I would suggest November 1st, so that nobody feels pressured. > You realize that then exactly the same will happen around that date, right? Have you ever been on the organizing side of a conference? Both paper/talk submissions and attendee registrations tend to happen immediately before the deadline. I propose not to move the deadline *unless* the PEP authors ask for an extension on the eve of Oct 1st. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Sep 25 11:58:58 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 17:58:58 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: References: <3ae19ded-9ba8-f0b4-f28d-3ad46f1a1b11@python.org> Message-ID: Le 25/09/2018 ? 17:54, Guido van Rossum a ?crit?: > On Tue, Sep 25, 2018 at 7:11 AM Antoine Pitrou > wrote: > > I would suggest November 1st, so that nobody feels pressured. > > > You realize that then exactly the same will happen around that date, right? Not really. > Have you ever been on the organizing side of a conference? Both > paper/talk submissions and attendee registrations tend to happen > immediately before the deadline. I'll take your word for it. Regards Antoine. From antoine at python.org Tue Sep 25 12:02:18 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 18:02:18 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: Le 25/09/2018 ? 17:49, Victor Stinner a ?crit?: > Le mar. 25 sept. 2018 ? 13:57, Antoine Pitrou a ?crit : >> Not sure what you mean here. What you are asking for is routinely >> called, AFAIK, "positive discrimination". Please correct me if I'm wrong. >> >> You ask me to assume positive intent, but you are the one assuming >> negative intent on my part... > > Note: in french, we say "discrimation positive", but in english, we > prefer "positive action". Well, apparently it may be about British English vs. American English: https://en.oxforddictionaries.com/definition/positive_discrimination ... which brings us back to the linguistic issues I pointed out in a previous message. > If anyone is interested to talk about diversity, code of conduct and > things like that: please contact me in private. > > These topics are difficult to discuss in a public space. At least, I'm > not comfortable today to talk about them in public. There are good > reasons why people don't talk about things like that in public. Perhaps, but there are also good reasons why debates that lead to governance decisions should be help publicly. While it's ok for personal anecdotes to only be shared privately, mandating that general debate takes place privately will only shut down debate. Regards Antoine. From guido at python.org Tue Sep 25 12:10:36 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 25 Sep 2018 09:10:36 -0700 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: On Tue, Sep 25, 2018 at 7:28 AM Mariatta Wijaya wrote: > My proposal is taking into consideration The PSF's mission and diversity > statement. I will not remove the diversity clause from PEP 8011. > +1 > To save us all trouble of discussing this particular issue, for those of > you who disagree completely, and have other ideas about how you'd like > Python to be governed and who should be in it, you can do one or more of > the following: > > - not vote on my PEP > - vote on the other PEPs > - write their own PEP > I would remind people that it's well documented that diverse group make better decisions. And given that there is a historical bias, often unconscious, towards white men I think it's good to try to counter this bias explicitly. I should also think that "merit-based" criteria tend to reinforce the existing unconscious bias. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Tue Sep 25 12:18:06 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 25 Sep 2018 18:18:06 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: On 25.09.2018 16:28, Mariatta Wijaya wrote: > My proposal is taking into consideration The PSF's mission and diversity > statement. I will not remove the diversity clause from PEP 8011. I cannot comment on what you actually have in PEP 8011 as diversity clause, since the page is just a placeholder at the moment, but please take into consideration that we're *not* debating a council which is to represent the Python community or other group of people. The council is intended to be a technical body for steering language design and needs experts as members who we all trust and respect to make good decisions - regardless of any other criteria and, of course, open to all core developers, regardless of background (which is what the PSF diversity statement is all about). > To save us all trouble of discussing this particular issue, for those of > you who disagree completely, and have other ideas about how you'd like > Python to be governed and who should be in it, you can do one or more of > the following: > > - not vote on my PEP > - vote on the other PEPs > - write their own PEP I think we're grown up enough to work on these PEPs together and in the usual spirit of coming up with good solutions. We owe this to the Python community at large who will be affected by whatever we decide. Personal agendas should put be aside for the time being. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 25 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/ From antoine at python.org Tue Sep 25 12:24:38 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 18:24:38 +0200 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: Le 25/09/2018 ? 18:10, Guido van Rossum a ?crit?: > To save us all trouble of discussing this particular issue, for > those of you who disagree completely, and have other ideas about how > you'd like Python to be governed and who should be in it, you can do > one or more of the following: > > - not vote on my PEP > - vote on the other PEPs > - write their own PEP > > > I would remind people that it's well documented that diverse group make > better decisions. Can you point us to such documentation? It would be nice to know under which conditions the assertion holds, according to which metrics, etc. Also, may I make the matter more concrete? You have been the BDFL during 20+ years. A one-person deciding group of a single white male is not exactly diverse. Retrospectively, do you think this led you to take worse decisions? Regards Antoine. From donald at stufft.io Tue Sep 25 12:29:35 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 25 Sep 2018 12:29:35 -0400 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: <508AB79D-4E66-4147-AA4B-4AC52D2ACE5C@stufft.io> > On Sep 25, 2018, at 12:24 PM, Antoine Pitrou wrote: > > > Le 25/09/2018 ? 18:10, Guido van Rossum a ?crit : >> To save us all trouble of discussing this particular issue, for >> those of you who disagree completely, and have other ideas about how >> you'd like Python to be governed and who should be in it, you can do >> one or more of the following: >> >> - not vote on my PEP >> - vote on the other PEPs >> - write their own PEP >> >> >> I would remind people that it's well documented that diverse group make >> better decisions. > > Can you point us to such documentation? It would be nice to know under > which conditions the assertion holds, according to which metrics, etc. https://hbr.org/2016/11/why-diverse-teams-are-smarter includes links to several studies. There are a lot more results as well to the search ?diverse teams make better decisions? or ?diverse groups decision making? on Google as well if those studies are lacking to you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Sep 25 14:40:43 2018 From: brett at python.org (Brett Cannon) Date: Tue, 25 Sep 2018 11:40:43 -0700 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: On Tue, 25 Sep 2018 at 09:18, M.-A. Lemburg wrote: > On 25.09.2018 16:28, Mariatta Wijaya wrote: > > My proposal is taking into consideration The PSF's mission and diversity > > statement. I will not remove the diversity clause from PEP 8011. > > I cannot comment on what you actually have in PEP 8011 as > diversity clause, since the page is just a placeholder at the > moment, but please take into consideration that we're *not* debating a > council which is to represent the Python community or other group of > people. > > The council is intended to be a technical body for steering language > design and needs experts as members who we all trust and respect > to make good decisions - regardless of any other criteria and, > of course, open to all core developers, regardless of background > (which is what the PSF diversity statement is all about). > > > To save us all trouble of discussing this particular issue, for those of > > you who disagree completely, and have other ideas about how you'd like > > Python to be governed and who should be in it, you can do one or more of > > the following: > > > > - not vote on my PEP > > - vote on the other PEPs > > - write their own PEP > > I think we're grown up enough to work on these PEPs together and > in the usual spirit of coming up with good solutions. We owe > this to the Python community at large who will be affected by > whatever we decide. Correct, but since the PEP isn't ready to be published for discussion this thread is all speculation based on imperfect information since Mariatta tried to summarize something ahead of time. For me personally, I am not going to participate in any discussion about any PEP until there is a published text to refer to, otherwise the discussion is ripe for misunderstandings. If a PEP comes out which people disagree with and want an alternative for I'm sure we can give them an opportunity to create a tweaked PEP (but I also assume we will have a civil discussion first in hopes of finding consensus first). -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Tue Sep 25 15:11:08 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Sep 2018 15:11:08 -0400 Subject: [python-committers] Council / board (Was: 1 week to Oct 1) In-Reply-To: References: <897dc90a-a7c2-f0ad-540c-fe248b8c34b0@python.org> Message-ID: <2F8A53B6-B123-446C-AB73-3CFAEF7485D1@python.org> On Sep 25, 2018, at 14:40, Brett Cannon wrote: > For me personally, I am not going to participate in any discussion about any PEP until there is a published text to refer to, otherwise the discussion is ripe for misunderstandings. If a PEP comes out which people disagree with and want an alternative for I'm sure we can give them an opportunity to create a tweaked PEP (but I also assume we will have a civil discussion first in hopes of finding consensus first). Agreed. Also, something we discussed at the sprints was the idea of each of the general governing PEPs will have certain knobs that can be tweaked. E.g. the exact number of folks on a committee, or their term limits, etc. It?s probably counterproductive to have competing PEPs that differ only in some of these details. Ultimately, it?s up to the PEP authors, but I think we?ll come to consensus much more quickly when we can use the PEPs to describe the general shape of governance, and work the details out in the subsequent conversations. At least, that?s how I see it working for the PEP I?ve promised to author. Cheers, -Barry -------------- 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 yselivanov.ml at gmail.com Tue Sep 25 15:30:03 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Tue, 25 Sep 2018 15:30:03 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? Message-ID: What's the current plan for what version of Python we release after 3.9? The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9. I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :) Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this. Yury From antoine at python.org Tue Sep 25 15:31:54 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 25 Sep 2018 21:31:54 +0200 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> Le 25/09/2018 ? 21:30, Yury Selivanov a ?crit?: > What's the current plan for what version of Python we release after 3.9? > > The reason I'm asking this is because I frequently need to refer to > *that version* of Python in the documentation, especially when I'm > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > implying that 4.0 will be released right after 3.9. > > I've heard multiple opinions on this subject. One of them is that we > should release 4.0 when we have a major new change, like removal of > the GIL or introduction of a JIT compiler. On the other hand, we have > no estimate when we have such a change. We also don't want Python 4.0 > to be backwards incompatible with Python 3.0 (at least not at the > scale of 2 vs 3). So to me, it seems logical that we simply release > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > drastically different from 3.0 and from 2.7. It sounds better. :) Many people have bad memories of the Py2->3 transition, so I think we should avoid triggering their sensitivities by announcing a Py4 if there's nothing, in terms of changes, to justify the jump. So my preference would be on 3.10. Regards Antoine. From doko at ubuntu.com Tue Sep 25 15:34:07 2018 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 25 Sep 2018 21:34:07 +0200 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: <01de0f7e-5018-0104-3346-6c5d2e534c61@ubuntu.com> On 25.09.2018 21:30, Yury Selivanov wrote: > What's the current plan for what version of Python we release after 3.9? > > The reason I'm asking this is because I frequently need to refer to > *that version* of Python in the documentation, especially when I'm > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > implying that 4.0 will be released right after 3.9. > > I've heard multiple opinions on this subject. One of them is that we > should release 4.0 when we have a major new change, like removal of > the GIL or introduction of a JIT compiler. On the other hand, we have > no estimate when we have such a change. We also don't want Python 4.0 > to be backwards incompatible with Python 3.0 (at least not at the > scale of 2 vs 3). So to me, it seems logical that we simply release > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > drastically different from 3.0 and from 2.7. It sounds better. :) why call it 4.0 when there are no significant changes? Just calling it 4.something sends the wrong signal, that probably people try to skip 3.x and keep going with 2.7 ... > Finally, I'm not sure we need a new governance in place to make this > decision or maybe we can make it now. That's why I'm posting this to > python-committers to see if core devs already have a consensus on > this. sorry, for me that sounds like a non-decision. From barry at python.org Tue Sep 25 15:40:48 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Sep 2018 15:40:48 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> Message-ID: <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> On Sep 25, 2018, at 15:31, Antoine Pitrou wrote: > > So my preference would be on 3.10. 3.9 + 0.1 :) Renaming it to Python 4 is fraught with knock-on effects, so I think we do reserve that for major changes. I doubt we?ll ever need for a disruptive backward incompatible change *at the Python level* in a Python 4, but I absolutely can see the possibility of incompatible changes at the public C API layer. I?m not saying it *will* happen, but that?s what we should reserve ?Python 4? for if or when it happens. -Barry -------------- 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 p.f.moore at gmail.com Tue Sep 25 15:44:13 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 25 Sep 2018 20:44:13 +0100 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> Message-ID: On Tue, 25 Sep 2018 at 20:32, Antoine Pitrou wrote: > > > Le 25/09/2018 ? 21:30, Yury Selivanov a ?crit : > > What's the current plan for what version of Python we release after 3.9? > > > > The reason I'm asking this is because I frequently need to refer to > > *that version* of Python in the documentation, especially when I'm > > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > > implying that 4.0 will be released right after 3.9. > > > > I've heard multiple opinions on this subject. One of them is that we > > should release 4.0 when we have a major new change, like removal of > > the GIL or introduction of a JIT compiler. On the other hand, we have > > no estimate when we have such a change. We also don't want Python 4.0 > > to be backwards incompatible with Python 3.0 (at least not at the > > scale of 2 vs 3). So to me, it seems logical that we simply release > > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > > drastically different from 3.0 and from 2.7. It sounds better. :) > > Many people have bad memories of the Py2->3 transition, so I think we > should avoid triggering their sensitivities by announcing a Py4 if > there's nothing, in terms of changes, to justify the jump. > > So my preference would be on 3.10. I agree. 3.10 seems like the best choice. Even though we don't expect 4.0 to be a major breaking change like 3.0, people do assume something like semantic versioning, and therefore expect 3.9 -> 4.0 to be a "bigger" change than 3.9 -> 3.10. One thing that *will* need work is places that assume single-digit version components (for example the wheel spec uses pyXY to mark compatibility with Python X.Y - that will need tweaking to allow for 3.10). IMO, we should make it clear sooner rather than later that version numbering will be going 3.8, 3.9, 3.10, 3.11, ... to give people a chance to prepare. Otherwise we might inadvertently have another major compatibility issue right after 3.9 :-( The uncertainty simply lets people assume whatever's least disruptive for them, and not be ready. Paul From ericsnowcurrently at gmail.com Tue Sep 25 16:19:59 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Tue, 25 Sep 2018 14:19:59 -0600 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: On Tue, Sep 25, 2018 at 1:30 PM Yury Selivanov wrote: > What's the current plan for what version of Python we release after 3.9? One idea I've heard is to switch to calendar versioning after 3.9. So we'd start with something like "2021" (year) or "2021.06" (year + month). sys.version_info would stay monotonic and so would the version macro in the C-API. The executable would still be "python3" so it may still make sense to incorporate "3" into the version. When we do get to a major/breaking change we'd change the executable to "python4" and incorporate "4" into the version. Switching to calver doesn't necessarily mean we'd tie ourselves to a fixed release schedule, but doing so would probably fit better with calver. :) Anyway, this is just something I've heard discussed which I kind of liked. -eric From storchaka at gmail.com Tue Sep 25 16:38:36 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Tue, 25 Sep 2018 23:38:36 +0300 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> Message-ID: <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> 25.09.18 22:40, Barry Warsaw ????: > On Sep 25, 2018, at 15:31, Antoine Pitrou wrote: >> So my preference would be on 3.10. > 3.9 + 0.1 :) > > Renaming it to Python 4 is fraught with knock-on effects, so I think we do reserve that for major changes. I doubt we?ll ever need for a disruptive backward incompatible change *at the Python level* in a Python 4, but I absolutely can see the possibility of incompatible changes at the public C API layer. I?m not saying it *will* happen, but that?s what we should reserve ?Python 4? for if or when it happens. I concur. And changing the major version number itself is significant breaking change. From the name of the executable (python3 vs python4) hardcoded in Python and shell scripts to a number of third-party scripts that contain in the best case: ??? PY3 = sys.version_info[0] == 3 ??? if not PY3: ??????? ... # implies Python 2 and in the worst case: ??? PY3 = sys.version[0] == '3' Changing the minor version number from a single-digit to a two-digits will break some software too, but I think that this breakage is smaller. From yselivanov.ml at gmail.com Tue Sep 25 16:42:10 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Tue, 25 Sep 2018 16:42:10 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Tue, Sep 25, 2018 at 4:38 PM Serhiy Storchaka wrote: [..] > And changing the major version number itself is significant breaking > change. From the name of the executable (python3 vs python4) hardcoded > in Python and shell scripts to a number of third-party scripts that > contain in the best case: > > PY3 = sys.version_info[0] == 3 > if not PY3: > ... # implies Python 2 > > and in the worst case: > > PY3 = sys.version[0] == '3' > > Changing the minor version number from a single-digit to a two-digits > will break some software too, but I think that this breakage is smaller. I think this is the last nail in the coffin of the "Python 4.0 after 3.9" idea. Seems that we've reached the consensus: we release Python 3.10 after Python 3.9. We maybe release Python 4.0 at some point if there's a significant backwards incompatible change. Yury From brian at python.org Tue Sep 25 17:09:19 2018 From: brian at python.org (Brian Curtin) Date: Tue, 25 Sep 2018 15:09:19 -0600 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka wrote: > 25.09.18 22:40, Barry Warsaw ????: > > On Sep 25, 2018, at 15:31, Antoine Pitrou wrote: > >> So my preference would be on 3.10. > > 3.9 + 0.1 :) > > > > Renaming it to Python 4 is fraught with knock-on effects, so I think we > do reserve that for major changes. I doubt we?ll ever need for a > disruptive backward incompatible change *at the Python level* in a Python > 4, but I absolutely can see the possibility of incompatible changes at the > public C API layer. I?m not saying it *will* happen, but that?s what we > should reserve ?Python 4? for if or when it happens. > > I concur. > > And changing the major version number itself is significant breaking > change. From the name of the executable (python3 vs python4) hardcoded > in Python and shell scripts to a number of third-party scripts that > contain in the best case: > > PY3 = sys.version_info[0] == 3 > if not PY3: > ... # implies Python 2 > > and in the worst case: > > PY3 = sys.version[0] == '3' > > Changing the minor version number from a single-digit to a two-digits > will break some software too, but I think that this breakage is smaller. > FWIW, we had a similar bump in 2015 (?) when 2.7.10 was about to come out. Moving up to two digits might break some assumptions, though users misusing things isn't really our problem. Someone out there is parsing `sys.version[:5]` or `platform.python_version()` instead of the alternatives that are better suited to getting specific parts of the version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Tue Sep 25 17:17:46 2018 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 25 Sep 2018 14:17:46 -0700 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: On Tue, Sep 25, 2018, 12:30 Yury Selivanov wrote: > The reason I'm asking this is because I frequently need to refer to > *that version* of Python in the documentation, especially when I'm > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > implying that 4.0 will be released right after 3.9. > I don't know what we'll end up calling it, but I don't think it matters for this. For warnings about future deprecations and removals, I would use "3.10" regardless. No one can predict the future; maybe our future selves will change their minds when we get there. But for people reading the documentation now, "3.10" clearly means "the version after 3.9", so they'll understand what you mean. And if it ends up being called 4.0 then that's higher than 3.10 anyway, so no one can claim you didn't warn them. OTOH if you write "4.0", at least some people will misunderstand, and be grumpy if the feature disappears in 3.10. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Tue Sep 25 17:30:02 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Tue, 25 Sep 2018 17:30:02 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: On Tue, Sep 25, 2018 at 5:18 PM Nathaniel Smith wrote: > > On Tue, Sep 25, 2018, 12:30 Yury Selivanov wrote: >> >> The reason I'm asking this is because I frequently need to refer to >> *that version* of Python in the documentation, especially when I'm >> deprecating APIs or behavior. Right now I'm saying "Python 4.0" >> implying that 4.0 will be released right after 3.9. > > > I don't know what we'll end up calling it, but I don't think it matters for this. For warnings about future deprecations and removals, I would use "3.10" regardless. > > No one can predict the future; maybe our future selves will change their minds when we get there. But for people reading the documentation now, "3.10" clearly means "the version after 3.9", so they'll understand what you mean. And if it ends up being called 4.0 then that's higher than 3.10 anyway, so no one can claim you didn't warn them. > > OTOH if you write "4.0", at least some people will misunderstand, and be grumpy if the feature disappears in 3.10. Yeah, this makes sense. Yury From facundobatista at gmail.com Tue Sep 25 17:50:12 2018 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 25 Sep 2018 18:50:12 -0300 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: 2018-09-25 16:30 GMT-03:00 Yury Selivanov : > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > implying that 4.0 will be released right after 3.9. > > I've heard multiple opinions on this subject. One of them is that we > should release 4.0 when we have a major new change, like removal of > the GIL or introduction of a JIT compiler. On the other hand, we have > no estimate when we have such a change. We also don't want Python 4.0 > to be backwards incompatible with Python 3.0 (at least not at the > scale of 2 vs 3). So to me, it seems logical that we simply release > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > drastically different from 3.0 and from 2.7. It sounds better. :) On the other hand... the best chance we have to let the world know that "we will never ever again break everything as we did with the 2 to 3 transition" is to just release 4.0 after 3.9 as a simple follow up release with just the minor and usual glitches we have from minor to minor release. IOW, we're breaking the major/minor revision evolution, but we're firmly signaling that a transition that could take a decade will not happen anymore in the future, that we learned the lesson and all evolution steps will be smooth. See it as more a political/social decision, than a technical one. Note 1: I remember Guido saying something like this, but to be fair I couldn't find any mail with a statement like that in a 10' exploration I just did. Note 2: I know we planned 2.7.10 after 2.7.9, but that just reinforces my point: the idea is to communicate that we'll never have again a dead end like 2.7. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista From vstinner at redhat.com Tue Sep 25 18:33:18 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 26 Sep 2018 00:33:18 +0200 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: Hi, I would prefer to never ever break the backward compatibility in Python. To make it clear I suggest to use 4.0 for the release following Python 3.7. More and more data confirm me frequently that we already reached the critical mass to declare that the migration to Python 3 is done. There was no Python 2.8, I suggest to skip 3.8. Ten years is enough between two major versions... To be clear, I only propose to change the version number. Not break anything. Not remove anything. Any pending removal scheduled for 4.0 must be postponed, maybe to 4.1, maybe 4.2, maybe never. Linux switched from 3.x to 4.x and didn't break anything. We can do the same. -- Ok, some people like me want to break the backward compatibility. You have to fight against that and make sure that incompatible changes are limited and very small per release. Please don't use the C API as any promise of anything. This project is highly experimental and don't iffer anaything except pain at this point ;-) Victor Le mardi 25 septembre 2018, Yury Selivanov a ?crit : > What's the current plan for what version of Python we release after 3.9? > > The reason I'm asking this is because I frequently need to refer to > *that version* of Python in the documentation, especially when I'm > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > implying that 4.0 will be released right after 3.9. > > I've heard multiple opinions on this subject. One of them is that we > should release 4.0 when we have a major new change, like removal of > the GIL or introduction of a JIT compiler. On the other hand, we have > no estimate when we have such a change. We also don't want Python 4.0 > to be backwards incompatible with Python 3.0 (at least not at the > scale of 2 vs 3). So to me, it seems logical that we simply release > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > drastically different from 3.0 and from 2.7. It sounds better. :) > > Finally, I'm not sure we need a new governance in place to make this > decision or maybe we can make it now. That's why I'm posting this to > python-committers to see if core devs already have a consensus on > this. > > Yury > _______________________________________________ > 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 yselivanov.ml at gmail.com Tue Sep 25 18:39:51 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Tue, 25 Sep 2018 18:39:51 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: On Tue, Sep 25, 2018 at 6:33 PM Victor Stinner wrote: > > Hi, > > I would prefer to never ever break the backward compatibility in Python. To make it clear I suggest to use 4.0 for the release following Python 3.7. I think Serhiy made a strong argument that the code like below would break if we release Python 4.0: PY3 = sys.version_info[0] == 3 if not PY3: ... # implies Python 2 I think we all have seen code like that; it's a common pattern. So by just bumping the version to 4.0 you would break the compatibility for some libraries and frameworks. And maybe breaking it is fine if there's a very strong technical reason, but doing that just to make a statement isn't worth it, IMHO. Yury From donald at stufft.io Tue Sep 25 18:47:08 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 25 Sep 2018 18:47:08 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: <55AC2B97-689C-4A12-965C-15B035A8249B@stufft.io> > On Sep 25, 2018, at 6:39 PM, Yury Selivanov wrote: > > I think we all have seen code like that; it's a common pattern. So by > just bumping the version to 4.0 you would break the compatibility for > some libraries and frameworks. And maybe breaking it is fine if > there's a very strong technical reason, but doing that just to make a > statement isn't worth it, IMHO. Breaking a bunch of software to make the statement that you?re not going to break backwards compatibility anymore sounds like something out of a Monty Python skit though ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Tue Sep 25 18:57:52 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 26 Sep 2018 00:57:52 +0200 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: Serhiy: > And changing the major version number itself is significant breaking change. From the name of the executable (python3 vs python4) hardcoded in Python IMHO It's time to discuss again modifying the "python" program to always point to the latest Python version. What is the status of Brett's UNIX Python launcher "py" by the way? Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Tue Sep 25 21:06:44 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Sep 2018 21:06:44 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Sep 25, 2018, at 18:57, Victor Stinner wrote: > > IMHO It's time to discuss again modifying the "python" program to always point to the latest Python version. This just came up again on linux-sig, but... > What is the status of Brett's UNIX Python launcher "py" by the way? ...I forgot to mention this. FWIW, I still think we shouldn?t recommend a change here until 2.7 is done and done. However, the launcher might be a good way out. -Barry -------------- 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 willingc at gmail.com Wed Sep 26 04:16:33 2018 From: willingc at gmail.com (Carol Willing) Date: Wed, 26 Sep 2018 04:16:33 -0400 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> References: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> Message-ID: <7EE20D66-C7AC-4051-8F5B-4588CA2D182D@me.com> I'm still optimistic that the October 1 deadline is achievable. It's important for the larger Python community to have confidence that we enter 2019 with a governance plan. > On Sep 25, 2018, at 2:58 AM, Antoine Pitrou wrote: > > > Le 24/09/2018 ? 20:32, Mariatta Wijaya a ?crit : >> It is now 7 days until October 1, the deadline for coming up with Python >> Governance PEPs. >> >> Some still relevant links: >> >> - https://www.python.org/dev/peps/pep-8000/ Python Language Governance >> Proposal Overview >> - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process >> - https://www.python.org/dev/peps/pep-8002 Open source governance survey >> >> These are current ideas and proposals, some are placeholders still. >> >> - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model >> - https://www.python.org/dev/peps/pep-8011 The Council Governance Model >> (I'm claiming this PEP) >> - https://www.python.org/dev/peps/pep-8012 The Community Governance Model >> - https://www.python.org/dev/peps/pep-8013/ The External Council >> Governance Model >> - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model >> >> I have some questions: >> >> 1. Is everyone still ok with the Oct 1 as deadline for coming up with >> governance PEPs? > > As I predicted, Oct 1 seems to be coming up too early. > > Regards > > Antoine. > _______________________________________________ > 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 Wed Sep 26 04:37:40 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 26 Sep 2018 10:37:40 +0200 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: <7EE20D66-C7AC-4051-8F5B-4588CA2D182D@me.com> References: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> <7EE20D66-C7AC-4051-8F5B-4588CA2D182D@me.com> Message-ID: <9da87c2c-ac2e-8997-f705-1b50074d5136@egenix.com> Could the authors of those PEPs please at least publish a rough outline of what their model is all about ? It doesn't help if we set a deadline only to find that we should have written up a competing PEP shortly before the deadline passes. The only text we have at this point is PEP 8013: https://www.python.org/dev/peps/pep-8013/ On 26.09.2018 10:16, Carol Willing wrote: > I'm still optimistic that the October 1 deadline is achievable. It's important for the larger Python community to have confidence that we enter 2019 with a governance plan. > >> On Sep 25, 2018, at 2:58 AM, Antoine Pitrou wrote: >> >> >> Le 24/09/2018 ? 20:32, Mariatta Wijaya a ?crit : >>> It is now 7 days until October 1, the deadline for coming up with Python >>> Governance PEPs. >>> >>> Some still relevant links: >>> >>> - https://www.python.org/dev/peps/pep-8000/ Python Language Governance >>> Proposal Overview >>> - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process >>> - https://www.python.org/dev/peps/pep-8002 Open source governance survey >>> >>> These are current ideas and proposals, some are placeholders still. >>> >>> - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model >>> - https://www.python.org/dev/peps/pep-8011 The Council Governance Model >>> (I'm claiming this PEP) >>> - https://www.python.org/dev/peps/pep-8012 The Community Governance Model >>> - https://www.python.org/dev/peps/pep-8013/ The External Council >>> Governance Model >>> - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model >>> >>> I have some questions: >>> >>> 1. Is everyone still ok with the Oct 1 as deadline for coming up with >>> governance PEPs? >> >> As I predicted, Oct 1 seems to be coming up too early. >> >> Regards >> >> Antoine. >> _______________________________________________ >> 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 (#1, Sep 26 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/ From mal at egenix.com Wed Sep 26 04:53:46 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 26 Sep 2018 10:53:46 +0200 Subject: [python-committers] [PEP 8013] The External Council Governance Model In-Reply-To: <7f28da9c-a0f4-074d-9c49-38a0e64387e9@python.org> References: <7f28da9c-a0f4-074d-9c49-38a0e64387e9@python.org> Message-ID: <93175b5f-266e-ac03-c51d-c5f234dc9c5a@egenix.com> Thanks, Steve, for writing this up: https://www.python.org/dev/peps/pep-8013/ A couple of comments: I like the council model, but don't understand why the core developers should be stripped from any decision powers. External people will not have the institutional knowledge core developers have, know why past decisions were reached and thus cannot use this knowledge to base the new decisions on. To give you an example: As much as I admire people such as Larry Wall for designing popular programming languages, I would not want to see Python take a Perl'ish approach to language design. Additionally, we'd have to transfer knowledge of how work is done on the council for every new member. I've seen how long this takes on the PSF and EPS boards. It effectively causes the council to not be fully operable for a couple of months at least. This will not happen with core developers as council members. Could you give a reason why the council members should be external ? Another point I don't understand is why we should drop the BDFL- Delegate system. This has proven to work well. Perhaps PEP 8011 is a better approach, but it's not available yet, so I'm focusing on your PEP for now. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 26 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/ From mark at hotpy.org Wed Sep 26 05:52:20 2018 From: mark at hotpy.org (Mark Shannon) Date: Wed, 26 Sep 2018 10:52:20 +0100 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: Hi, On 25/09/18 20:30, Yury Selivanov wrote: > What's the current plan for what version of Python we release after 3.9? [snip] For the record, we account for the following version tests when analysing code (on lgtm.com): sys.version == "3" sys.version_info > (3,) sys.version_info[0] == 3 sys.version_info[:2] >= (3,0) sys.hexversion > 0x03000000 Of these forms, `sys.version[0] == "3"` and `sys.version_info[0] == 3` will be broken by changing the major version to 4. Personally, I prefer 3.10 to 4.0 unless there is a significant language change involved. Cheers, Mark. From songofacandy at gmail.com Wed Sep 26 06:01:51 2018 From: songofacandy at gmail.com (INADA Naoki) Date: Wed, 26 Sep 2018 19:01:51 +0900 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: For the record, Guido prefer 3.10 to 4.0, before he retired BDFL. https://python.zulipchat.com/#narrow/stream/116503-core/subject/rhel/near/124934902 Regards, -- INADA Naoki -------------- next part -------------- An HTML attachment was scrubbed... URL: From encukou at gmail.com Wed Sep 26 06:27:00 2018 From: encukou at gmail.com (Petr Viktorin) Date: Wed, 26 Sep 2018 12:27:00 +0200 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: Message-ID: <6920a0d7-7ef6-5fdc-02a8-d12e0a171368@gmail.com> On 9/25/18 9:30 PM, Yury Selivanov wrote: > What's the current plan for what version of Python we release after 3.9? > > The reason I'm asking this is because I frequently need to refer to > *that version* of Python in the documentation, especially when I'm > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > implying that 4.0 will be released right after 3.9. > > I've heard multiple opinions on this subject. One of them is that we > should release 4.0 when we have a major new change, like removal of > the GIL or introduction of a JIT compiler. On the other hand, we have > no estimate when we have such a change. We also don't want Python 4.0 > to be backwards incompatible with Python 3.0 (at least not at the > scale of 2 vs 3). So to me, it seems logical that we simply release > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > drastically different from 3.0 and from 2.7. It sounds better. :) > > Finally, I'm not sure we need a new governance in place to make this > decision or maybe we can make it now. That's why I'm posting this to > python-committers to see if core devs already have a consensus on > this. > > Yury As someone who's still fighting every day to make people switch from "python2" (or "python") to "python3", I'd be very, very happy if I didn't have to start telling them to use "python4" instead now. Or explaining that the way to launch Python 4 is "python3". Same story with Python 2020 instead of Python 4. (And unfortunately, a "py" launcher is not an answer here -- it won't be very useful unless it is everywhere, and that will take years in the best case.) I'd much, much rather explain that `sys.version[2]` is not correct, and solve the "python310" < "python39" problem. From brett at python.org Wed Sep 26 12:27:34 2018 From: brett at python.org (Brett Cannon) Date: Wed, 26 Sep 2018 09:27:34 -0700 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Tue, 25 Sep 2018 at 15:58, Victor Stinner wrote: > Serhiy: > > And changing the major version number itself is significant breaking > change. From the name of the executable (python3 vs python4) hardcoded in > Python > > IMHO It's time to discuss again modifying the "python" program to always > point to the latest Python version. > > What is the status of Brett's UNIX Python launcher "py" by the way? > You can see the current TODO list at https://crates.io/crates/python-launcher . Basically I need to implement "--help" and "--list" to fill in the last two low-hanging fruit features, but at long as you don't need to customize the search mechanism then it's already working. And BTW it's already compatible with either 3.10 or 4.0. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Wed Sep 26 13:15:17 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Wed, 26 Sep 2018 13:15:17 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Wed, Sep 26, 2018 at 12:28 PM Brett Cannon wrote: [..] >> What is the status of Brett's UNIX Python launcher "py" by the way? > > > You can see the current TODO list at https://crates.io/crates/python-launcher . Basically I need to implement "--help" and "--list" to fill in the last two low-hanging fruit features, but at long as you don't need to customize the search mechanism then it's already working. And BTW it's already compatible with either 3.10 or 4.0. :) Looks like it's possible to either request a specific version (e.g. 3.6), or a major version (e.g. any Python 3). Is it possible to request "3.6 or greater (be it Python 3.10 or Python 4.0+)"? Yury From p.f.moore at gmail.com Wed Sep 26 13:24:50 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 26 Sep 2018 18:24:50 +0100 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Wed, 26 Sep 2018 at 18:15, Yury Selivanov wrote: > > On Wed, Sep 26, 2018 at 12:28 PM Brett Cannon wrote: > [..] > >> What is the status of Brett's UNIX Python launcher "py" by the way? > > > > > > You can see the current TODO list at https://crates.io/crates/python-launcher . Basically I need to implement "--help" and "--list" to fill in the last two low-hanging fruit features, but at long as you don't need to customize the search mechanism then it's already working. And BTW it's already compatible with either 3.10 or 4.0. :) > > Looks like it's possible to either request a specific version (e.g. > 3.6), or a major version (e.g. any Python 3). Is it possible to > request "3.6 or greater (be it Python 3.10 or Python 4.0+)"? That's not possible for the Windows launcher. As the idea is to have a uniform interface for the Windows and Unix launchers, I'd assume that this would need to be a feature request for both the Windows and Unix launchers. (It's a reasonable-seeming idea, but I don't know how useful it would be in practice - can you give some examples of use cases?) Paul From yselivanov.ml at gmail.com Wed Sep 26 13:54:11 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Wed, 26 Sep 2018 13:54:11 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Wed, Sep 26, 2018 at 1:25 PM Paul Moore wrote: [..] > but I don't know how > useful it would be in practice - can you give some examples of use > cases?) It's hard to give a real life example as "py" doesn't support this, but I can imagine the following scenario: if I have a script that uses some new 3.6 feature I could probably run it from other scripts with 'py --min=3.6 myscript.py'. That way I wouldn't need to write more code or use other tools to check if the target system has a Python 3.6+ interpreter. Yury From mariatta at python.org Wed Sep 26 19:28:02 2018 From: mariatta at python.org (Mariatta Wijaya) Date: Wed, 26 Sep 2018 16:28:02 -0700 Subject: [python-committers] 1 week to Oct 1 In-Reply-To: <9da87c2c-ac2e-8997-f705-1b50074d5136@egenix.com> References: <0a2cf631-04f1-e877-fda4-b4f481c5bb71@python.org> <7EE20D66-C7AC-4051-8F5B-4588CA2D182D@me.com> <9da87c2c-ac2e-8997-f705-1b50074d5136@egenix.com> Message-ID: Really sorry folks, but I also would like to request an extension, by one week to Oct 8. It's not because I've been slacking; I've started a five-page document (only Barry has seen it), but I still need his help before it can be ready for the public. In addition, I'm facing personal health issue. I'll be unable to work on the proposal for the next few days. I hope this will be ok with you all. Sorry again for delaying this process. Although we should still be good to "vote" on proposals by Mid November. I still think it would be good for that PEP 8001 to be ready sooner, so we all have good understanding of how this all will go down. Thanks. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Wed Sep 26 20:46:35 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 26 Sep 2018 20:46:35 -0400 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: On Sep 26, 2018, at 19:28, Mariatta Wijaya wrote: > > Really sorry folks, but I also would like to request an extension, by one week to Oct 8. > It's not because I've been slacking; I've started a five-page document (only Barry has seen it), but I still need his help before it can be ready for the public. > In addition, I'm facing personal health issue. I'll be unable to work on the proposal for the next few days. +1 - I just got back from a whirlwind three weeks of the core sprint followed by my son?s wedding. I did get a chance to start fleshing out PEP 8010, but I have a lot of catching up to do, plus two talks to give by October 1st, so a week?s delay would be very helpful. I don?t think I?ll need more than that. -Barry -------------- 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 Wed Sep 26 22:21:30 2018 From: nad at python.org (Ned Deily) Date: Wed, 26 Sep 2018 22:21:30 -0400 Subject: [python-committers] [RELEASE] Python 3.7.1rc1 and 3.6.7rc1 now available for testing Message-ID: <5C0A8514-FE4D-46DB-A4A3-8EC5F36D8F9B@python.org> Python 3.7.1rc1 and 3.6.7rc1 are now available. 3.7.1rc1 is the release preview of the first maintenance release of Python 3.7, the latest feature release of Python. 3.6.7rc1 is the release preview of the next maintenance release of Python 3.6, the previous feature release of Python. Assuming no critical problems are found prior to 2018-10-06, 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-371rc1/ https://www.python.org/downloads/release/python-367rc1/ -- Ned Deily nad at python.org -- [] From brett at python.org Thu Sep 27 14:19:18 2018 From: brett at python.org (Brett Cannon) Date: Thu, 27 Sep 2018 11:19:18 -0700 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: Since there isn't a way to do this in any fashion I never really thought about it. I think most people either set the shebang to the version of Python they want it to work with, have pip install the entry point which will also set the entry point, or assume that e.g. python3 is new enough to work. But even setting a minimum is potentially troublesome if there's an incompatibility, e.g. you used 'async' as a variable name and suddenly you installed Python 3.7. :) So I don't know if the desire/utility of having a minimum is worth the added complexity. On Wed, 26 Sep 2018 at 10:54, Yury Selivanov wrote: > On Wed, Sep 26, 2018 at 1:25 PM Paul Moore wrote: > [..] > > but I don't know how > > useful it would be in practice - can you give some examples of use > > cases?) > > It's hard to give a real life example as "py" doesn't support this, > but I can imagine the following scenario: if I have a script that uses > some new 3.6 feature I could probably run it from other scripts with > 'py --min=3.6 myscript.py'. That way I wouldn't need to write more > code or use other tools to check if the target system has a Python > 3.6+ interpreter. > > Yury > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Thu Sep 27 14:36:20 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 27 Sep 2018 14:36:20 -0400 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Thu, Sep 27, 2018 at 2:19 PM Brett Cannon wrote: > > Since there isn't a way to do this in any fashion I never really thought about it. I think most people either set the shebang to the version of Python they want it to work with, have pip install the entry point which will also set the entry point, or assume that e.g. python3 is new enough to work. > > But even setting a minimum is potentially troublesome if there's an incompatibility, e.g. you used 'async' as a variable name and suddenly you installed Python 3.7. :) So I don't know if the desire/utility of having a minimum is worth the added complexity. I agree. Yury From ncoghlan at gmail.com Fri Sep 28 09:49:23 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 28 Sep 2018 23:49:23 +1000 Subject: [python-committers] [PEP 8013] The External Council Governance Model In-Reply-To: <7f28da9c-a0f4-074d-9c49-38a0e64387e9@python.org> References: <7f28da9c-a0f4-074d-9c49-38a0e64387e9@python.org> Message-ID: On Wed, 26 Sep 2018 at 01:25, Steve Dower wrote: > > Here is the text of PEP 8013 for discussion and improvement (in > isolation from the other proposals, of course -- we're not ready for the > shoot-out yet.) > > I'm keen to see the model be considered, but I don't feel the need to > tightly control the specific content in the PEP, so feel free to send > your own PRs if you have definitive improvements. Thanks for the write-up Steve. If we did go down the "independent advisory council" route, I'd actually prefer to see it used to strengthen the BDFL-Delegate system rather than weaken it: the role of the advisory council would only be to step in when there was a dispute amongst the core developers as to whether or not there was a suitable volunteer available to serve as BDFL-Delegate, or if there was a proposal where nobody was volunteering to be the final decision maker, but the council thought the prospective gains on offer were sufficiently large to make it worthwhile to attempt to change that state of affairs. The other aspects would pretty much remain the same as you suggest - the advisory council would mainly be there to help BDFL-Delegates out when it came time to end discussion of a proposal and make their decision (whether for or against) stick. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Fri Sep 28 10:05:38 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 29 Sep 2018 00:05:38 +1000 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: References: <5c7187ef-b93b-86c4-34b9-b04444d41a30@python.org> <9A786CFD-E1A5-4CCB-BA01-0768BB265336@python.org> <944999a0-8ca4-c315-3889-32d6946541a0@gmail.com> Message-ID: On Wed, 26 Sep 2018 at 07:09, Brian Curtin wrote: > On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka wrote: >> And changing the major version number itself is significant breaking >> change. From the name of the executable (python3 vs python4) hardcoded >> in Python and shell scripts to a number of third-party scripts that >> contain in the best case: >> >> PY3 = sys.version_info[0] == 3 >> if not PY3: >> ... # implies Python 2 >> >> and in the worst case: >> >> PY3 = sys.version[0] == '3' >> >> Changing the minor version number from a single-digit to a two-digits >> will break some software too, but I think that this breakage is smaller. > > FWIW, we had a similar bump in 2015 (?) when 2.7.10 was about to come out. Moving up to two digits might break some assumptions, though users misusing things isn't really our problem. Someone out there is parsing `sys.version[:5]` or `platform.python_version()` instead of the alternatives that are better suited to getting specific parts of the version. At the 2017 core dev sprint, Ezio Mellotti and I also discussed the possibility of adding a string subclass that emits warnings when used in ordered comparisons, and switching to that for the result of sys.version. It wouldn't catch all cases of inappropriate comparisons against sys.version, but it would catch a lot of them. Either way, +1 from me for running with a 3.10 release after 3.9, such that we're well and truly clear of the Python 2 end of life when Python 4.0 comes around, and we'll have time to either introduce the py launcher, or else reintroduce the default "python" symlink, before the major version number gets bumped again. Cheers, Nick. P.S. Note that I say this even though we use the "X.Y" version in a lot more places than just sys.version (think filesystem paths, PyPI artifact names and tags, etc). While those do have ways of coping with 3 digit version strings (either already including an "X.Y" separator, or stating that "X_Y" should be used when "XY" would be ambiguous), we can expect actually making such a release to find latent defects in assorted different pieces of software. However, unlike the 3.x compatibility breaks, adapting software to cope with a 3.10.0 release isn't going to break support for older releases. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Fri Sep 28 10:12:29 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 29 Sep 2018 00:12:29 +1000 Subject: [python-committers] Python 4.0 or Python 3.10? In-Reply-To: <6920a0d7-7ef6-5fdc-02a8-d12e0a171368@gmail.com> References: <6920a0d7-7ef6-5fdc-02a8-d12e0a171368@gmail.com> Message-ID: On Wed, 26 Sep 2018 at 20:27, Petr Viktorin wrote: > I'd much, much rather explain that `sys.version[2]` is not correct, and > solve the "python310" < "python39" problem. One of the perks of the way PEP 425 deals with this [1] is that ASCII underscores sort higher than ASCII digits, so: >>> "py31" < "py39" < "py310" < "py311" False >>> "py31" < "py39" < "py3_10" < "py3_11" True (I'm not sure if that's true for all collation orders, but if we find one where it isn't, then we'd just specify a collation order to use for Python version comparisons) Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0425/#python-tag -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From lukasz at langa.pl Fri Sep 28 17:45:54 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Fri, 28 Sep 2018 22:45:54 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org Message-ID: 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. And now the long version. What's the issue? During the core sprint in Redmond we discussed how we discuss. The overwhelming feel is that we have reached the limits of what is possible with mailing lists. We identified e-mail as a contributor to some of the problems we're dealing with now. To fix more and whine less, I talked with everybody in Redmond about a possible replacement for the trusty mailing list. We identified one: Discourse. What is it? Discourse is forum software started in 2013 by Jeff Atwood, Robin Ward, and Sam Saffron. It's used by many large scale open source projects and companies, including Github Atom, Twitter Developers, Rust, Kotlin, Elixir, Docker, Codeacademy, Patreon, EVE Online, and Imgur. It's open source (Ruby, GPL2), it supports plugins and has an API. Why is it better than e-mail? It's both a Web app and a terrific mobile application. It supports regular flat conversational threads and collapsible replies. There is community moderation where users can flag inappropriate messages to notify moderators, moderators and authors can lock topics, move discussions between categories, archive things that are no longer applicable, and so on. You can edit posts, quote posts, link between posts, add rich media, code snippets with syntax highlighting, there's Markdown support. You can still use it via e-mail similarly to how GitHub notifications work. See: https://meta.discourse.org/t/set-up-reply-via-email-support/14003 There is a user trust system where proven community members get more power in time, for example to fix typos and move topics to a better category. There's much more: dynamic notifications, topic summaries, emojis, spam blocking, single sing-on, two-factor authentication, social login support, and so on. Read: https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298 . What about Zulip? Zulip is chat software which some of us find useful but its UI is proving to be challenging for many of us, the mobile application leaves a lot to be desired, and it did not end up moving discussions out of the mailing lists. I see Zulip as replacement for IRC whereas Discourse is replacement for mailing lists (or both; we'll see!). Where do I sign up? Create an account at https://discuss.python.org/ . You'll recognize the set up as essentially mirroring the main mailing lists: - Committers - Users - Ideas There's also Discourse-specific sections: - Discourse Feedback (post here if things don't work like you'd like) - Discourse Staff (hidden category for moderators and admins of the instance, boring discussion) - Inquisition (hidden category for users with trust level 3+) As you can see, I combined python-committers and python-dev into just "Committers". If we find in the future that this is too limiting, we can always open up another category. For now though I'd like to avoid the fate of python-dev where there's 20k+ subscribers and we don't know who is who. CALL TO ACTION We'd like to heavily test this new forum. As such, I would like to ask you to NOT USE python-committers for the remainder of the year and direct all conversation to Discourse. The goal to replace the mailing lists with Discourse met unanimous support at the core sprint. As long as we don't identify any deal breakers in October, I will send an e-mail like this to python-dev on November 1st, and to python-list and python-ideas on December 1st. If everything goes smoothly, those four mailing lists will be archived by end of this year. Other mailing lists are welcome to port over to Discourse too. Acknowledgements Pablo and Ernest worked on setting up this instance for us (thank you both! ?). The question whether Discourse or the Python Software Foundation are going to pay for this infrastructure is still open but, as Elon Musk likes to say, funding is secured. Yury and I are helping in configuring the instance. Future work We'll be enabling GitHub and social logins soon, ideally with adding identified committers to the committers group by default. We are looking into this right now. In the mean time, please request membership, an existing member will add you. We'd like to migrate old discussion off of the mailing lists to our Discourse instance so that search is immediately useful. We'll look into that after the governance crisis is resolved. - ? -------------- 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 Fri Sep 28 18:03:37 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 29 Sep 2018 00:03:37 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: Le ven. 28 sept. 2018 ? 23:46, ?ukasz Langa a ?crit : > - go to https://discuss.python.org/ and create your account there; 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? Oh, I just saw that Berker sent a message: "Membership Request for @committers" https://discuss.python.org/t/membership-request-for-committers/27/2 I don't see this message in any category. Is it a private message? Victor From storchaka at gmail.com Fri Sep 28 18:04:05 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Sat, 29 Sep 2018 01:04:05 +0300 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> 29.09.18 00:45, ?ukasz Langa ????: > 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. Does it support NNTP? From lukasz at langa.pl Fri Sep 28 18:18:01 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Fri, 28 Sep 2018 23:18:01 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <101F61D2-0C22-4339-BEFB-EA1FD82427C2@langa.pl> > On 28 Sep 2018, at 23:03, Victor Stinner wrote: > > Le ven. 28 sept. 2018 ? 23:46, ?ukasz Langa a ?crit : >> - go to https://discuss.python.org/ and create your account there; > > It seems like anyone can subscribe. Yes. > Is the Committer group reserved to core developers? Yes, so far we just approve by hand until we get the GitHub automation going. > If yes, how do you know which accounts are linked to > core developers? I'm confirming by looking at the e-mail with which an account was registered. > Oh, I just saw that Berker sent a message: > "Membership Request for @committers" > https://discuss.python.org/t/membership-request-for-committers/27/2 > > I don't see this message in any category. Is it a private message? Yes. Now, further questions go to https://discuss.python.org/c/site-feedback ! :> - ? -------------- 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 berker.peksag at gmail.com Fri Sep 28 18:19:16 2018 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Sat, 29 Sep 2018 01:19:16 +0300 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: On Sat, Sep 29, 2018 at 1:03 AM Victor Stinner wrote: > Oh, I just saw that Berker sent a message: > "Membership Request for @committers" > https://discuss.python.org/t/membership-request-for-committers/27/2 > > I don't see this message in any category. Is it a private message? If I understood it correctly, all members of @committers also marked as owners, so you will get notifications for membership requests, flagged posts etc. --Berker From chris.jerdonek at gmail.com Fri Sep 28 18:55:31 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Fri, 28 Sep 2018 15:55:31 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: On Fri, Sep 28, 2018 at 2:45 PM, ?ukasz Langa wrote: > There is a user trust system where proven community members get more power > in time, for example to fix typos and move topics to a better category. > Will committers start out as "proven," or will we need to "re-prove" ourselves to gain additional privileges? How is the trust evaluation bootstrapped in Python's case, and who can confer additional trust (e.g. can it be non-committers, etc)? *CALL TO ACTION* > We'd like to heavily test this new forum. As such, I would like to ask you > to *NOT USE* python-committers for the remainder of the year and direct > all conversation to Discourse. > I hope this thread about transitioning is exempt from this call to action! :) --Chris On Fri, Sep 28, 2018 at 2:45 PM, ?ukasz Langa wrote: > 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. > > And now the long version. > > *What's the issue?* > During the core sprint in Redmond we discussed how we discuss. The > overwhelming feel is that we have reached the limits of what is possible > with mailing lists. We identified e-mail as a contributor to some of the > problems we're dealing with now. To fix more and whine less, I talked with > everybody in Redmond about a possible replacement for the trusty mailing > list. We identified one: Discourse. > > *What is it?* > Discourse is forum software started in 2013 by Jeff Atwood, Robin Ward, > and Sam Saffron. It's used by many large scale open source projects and > companies, including Github Atom, Twitter Developers, Rust, Kotlin, Elixir, > Docker, Codeacademy, Patreon, EVE Online, and Imgur. It's open source > (Ruby, GPL2), it supports plugins and has an API. > > *Why is it better than e-mail?* > It's both a Web app and a terrific mobile application. It supports regular > flat conversational threads and collapsible replies. There is community > moderation where users can flag inappropriate messages to notify > moderators, moderators and authors can lock topics, move discussions > between categories, archive things that are no longer applicable, and so on. > > You can edit posts, quote posts, link between posts, add rich media, code > snippets with syntax highlighting, there's Markdown support. You can still > use it via e-mail similarly to how GitHub notifications work. See: > https://meta.discourse.org/t/set-up-reply-via-email-support/14003 > > There is a user trust system where proven community members get more power > in time, for example to fix typos and move topics to a better category. > > There's much more: dynamic notifications, topic summaries, emojis, spam > blocking, single sing-on, two-factor authentication, social login support, > and so on. Read: https://meta.discourse.org/t/discourse-vs-email- > mailing-lists/54298. > > *What about Zulip?* > Zulip is chat software which some of us find useful but its UI is proving > to be challenging for many of us, the mobile application leaves a lot to be > desired, and it did not end up moving discussions out of the mailing lists. > I see Zulip as replacement for IRC whereas Discourse is replacement for > mailing lists (or both; we'll see!). > > *Where do I sign up?* > Create an account at https://discuss.python.org/. You'll recognize the > set up as essentially mirroring the main mailing lists: > - Committers > - Users > - Ideas > There's also Discourse-specific sections: > - Discourse Feedback (post here if things don't work like you'd like) > - Discourse Staff (hidden category for moderators and admins of the > instance, boring discussion) > - Inquisition (hidden category for users with trust level 3+) > > As you can see, I combined python-committers and python-dev into just > "Committers". If we find in the future that this is too limiting, we can > always open up another category. For now though I'd like to avoid the fate > of python-dev where there's 20k+ subscribers and we don't know who is who. > > *CALL TO ACTION* > We'd like to heavily test this new forum. As such, I would like to ask you > to *NOT USE* python-committers for the remainder of the year and direct > all conversation to Discourse. > > The goal to replace the mailing lists with Discourse met unanimous support > at the core sprint. As long as we don't identify any deal breakers in > October, I will send an e-mail like this to python-dev on November 1st, and > to python-list and python-ideas on December 1st. If everything goes > smoothly, those four mailing lists will be archived by end of this year. > Other mailing lists are welcome to port over to Discourse too. > > *Acknowledgements* > Pablo and Ernest worked on setting up this instance for us (thank you > both! ?). The question whether Discourse or the Python Software > Foundation are going to pay for this infrastructure is still open but, as > Elon Musk likes to say, funding is secured. Yury and I are helping in > configuring the instance. > > *Future work* > We'll be enabling GitHub and social logins soon, ideally with adding > identified committers to the committers group by default. We are looking > into this right now. In the mean time, please request membership, an > existing member will add you. We'd like to migrate old discussion off of > the mailing lists to our Discourse instance so that search is immediately > useful. We'll look into that after the governance crisis is resolved. > > - ? > > _______________________________________________ > 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 lukasz at langa.pl Fri Sep 28 19:47:06 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 00:47:06 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <5A2CA85B-277B-40DD-9EA5-09F5480200B6@langa.pl> > On 28 Sep 2018, at 23:55, Chris Jerdonek wrote: > > On Fri, Sep 28, 2018 at 2:45 PM, ?ukasz Langa > wrote: > There is a user trust system where proven community members get more power in time, for example to fix typos and move topics to a better category. > > Will committers start out as "proven," or will we need to "re-prove" ourselves to gain additional privileges? How is the trust evaluation bootstrapped in Python's case, and who can confer additional trust (e.g. can it be non-committers, etc)? Regular users start at trust level 0. Committers are at trust level 3. There is only one more level and this is for moderators and admins of the instance. This models what we had on the mailing lists, what we have on GitHub, and so on. I hope it makes sense. > 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 :-) - ? -------------- 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 lukasz at langa.pl Fri Sep 28 20:45:52 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 01:45:52 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> Message-ID: <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> > On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: > > Does it support NNTP? Do you use NNTP? Like with IRC, you won't find the next generation of core developers on it. And no, there is no support for it in Discourse. We could probably figure something out with Gmane if there's interest. - ? -------------- 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 barry at python.org Fri Sep 28 21:19:37 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 28 Sep 2018 18:19:37 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> Message-ID: <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> On Sep 28, 2018, at 17:45, ?ukasz Langa wrote: > Do you use NNTP? Like with IRC, you won't find the next generation of core developers on it. And no, there is no support for it in Discourse. > > We could probably figure something out with Gmane if there's interest. Yes, I use NNTP to read many of the Python mailing lists. Gmane, even in its current state, is fantastic. I?m all for supporting the next generation of developers, but not necessarily at the expense of *decades* of established workflow for current developers. Moving to Discourse breaks this and proliferates browser tab syndrome. It?s an experiment worth conducting, but I do think it?s a bit cavalier to shut down python-committers without further discussion. Cheers, -Barry -------------- 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 barry at python.org Fri Sep 28 21:21:13 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 28 Sep 2018 18:21:13 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: 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? -Barry -------------- 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 lukasz at langa.pl Fri Sep 28 21:32:08 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 02:32:08 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <2B62351F-B1BB-42B6-A130-C7A12764C21D@langa.pl> As you already witnessed, yes it does. -- Best regards, ?ukasz Langa > On Sep 29, 2018, at 02: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? > > -Barry > > _______________________________________________ > 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 Sat Sep 29 03:50:12 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 29 Sep 2018 09:50:12 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: 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/ From robertc at robertcollins.net Sat Sep 29 03:51:21 2018 From: robertc at robertcollins.net (Robert Collins) Date: Sat, 29 Sep 2018 19:51:21 +1200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: +1 If someone can tell me how to configure discourse to work like a mailing list; specifically: - email me messsages rather than 'X new messages" nuisance-mails - work sanely with replies-from-mail then I'm certainly happy to adapt. -Rob On Sat, 29 Sep 2018 at 13:19, Barry Warsaw wrote: > > On Sep 28, 2018, at 17:45, ?ukasz Langa wrote: > > > Do you use NNTP? Like with IRC, you won't find the next generation of core developers on it. And no, there is no support for it in Discourse. > > > > We could probably figure something out with Gmane if there's interest. > > Yes, I use NNTP to read many of the Python mailing lists. Gmane, even in its current state, is fantastic. > > I?m all for supporting the next generation of developers, but not necessarily at the expense of *decades* of established workflow for current developers. Moving to Discourse breaks this and proliferates browser tab syndrome. It?s an experiment worth conducting, but I do think it?s a bit cavalier to shut down python-committers without further discussion. > > Cheers, > -Barry > > _______________________________________________ > 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 Sat Sep 29 03:52:40 2018 From: donald at stufft.io (Donald Stufft) Date: Sat, 29 Sep 2018 03:52:40 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: <2EBBEA6B-CBA4-40C0-AFE7-8041F45F7C4E@stufft.io> Log into your account, go into preferences, enable Mailing List Mode. > On Sep 29, 2018, at 3:51 AM, Robert Collins wrote: > > +1 > > If someone can tell me how to configure discourse to work like a > mailing list; specifically: > > - email me messsages rather than 'X new messages" nuisance-mails > - work sanely with replies-from-mail > > then I'm certainly happy to adapt. > > -Rob > On Sat, 29 Sep 2018 at 13:19, Barry Warsaw wrote: >> >> On Sep 28, 2018, at 17:45, ?ukasz Langa wrote: >> >>> Do you use NNTP? Like with IRC, you won't find the next generation of core developers on it. And no, there is no support for it in Discourse. >>> >>> We could probably figure something out with Gmane if there's interest. >> >> Yes, I use NNTP to read many of the Python mailing lists. Gmane, even in its current state, is fantastic. >> >> I?m all for supporting the next generation of developers, but not necessarily at the expense of *decades* of established workflow for current developers. Moving to Discourse breaks this and proliferates browser tab syndrome. It?s an experiment worth conducting, but I do think it?s a bit cavalier to shut down python-committers without further discussion. >> >> Cheers, >> -Barry >> >> _______________________________________________ >> 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 lukasz at langa.pl Sat Sep 29 04:23:06 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 09:23:06 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> > On Sep 29, 2018, at 08:50, M.-A. Lemburg wrote: > > 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 assume it's the faulty mailing list medium that made you miss my response to Barry where I say that this is indeed supported ;-) See, Discourse would already save you a paragraph of worry. Why don't you try it out for a while and see how it feels? I understand the power of habit but I promise you that there's plenty of things that make the adjustment worthwhile. - ? From storchaka at gmail.com Sat Sep 29 04:51:07 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Sat, 29 Sep 2018 11:51:07 +0300 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> Message-ID: 29.09.18 03:45, ?ukasz Langa ????: >> On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: > Do you use NNTP? Like with IRC, you won't find the next generation of core developers on it. And no, there is no support for it in Discourse. Yes, I do. I read all Python-related mailing list via the Gmane gate. It is convenient in case of large discussions, when I can read selected branches and ignore others. The great advantage of NNTP is that it provides access to past discussions. I can read Python-Dev discussions back from 1999. > We could probably figure something out with Gmane if there's interest. Would be nice. It would be even better if provide the own NNTP gate and avoid depending on third-party services. From ncoghlan at gmail.com Sat Sep 29 04:53:58 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 29 Sep 2018 18:53:58 +1000 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote: > On Sep 28, 2018, at 17:45, ?ukasz Langa wrote: > > > Do you use NNTP? Like with IRC, you won't find the next generation of > core developers on it. And no, there is no support for it in Discourse. > > > > We could probably figure something out with Gmane if there's interest. > > Yes, I use NNTP to read many of the Python mailing lists. Gmane, even in > its current state, is fantastic. > > I?m all for supporting the next generation of developers, but not > necessarily at the expense of *decades* of established workflow for current > developers. Moving to Discourse breaks this and proliferates browser tab > syndrome. It?s an experiment worth conducting, but I do think it?s a bit > cavalier to shut down python-committers without further discussion. > Especially on the eve of critical governance discussions that will heavily impact the future of python-dev. This is exactly the kind of arbitrary decision making by an insufficiently representative group that led to us banning making any binding decisions at language summits: their in-person nature means that they're inherently exclusive environments that lead to requirements being overlooked and decisions being made without involving most of the people affected. Regards, Nick. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Sat Sep 29 05:23:41 2018 From: stefan at bytereef.org (Stefan Krah) Date: Sat, 29 Sep 2018 11:23:41 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: <20180929092340.GA4152@bytereef.org> On Sat, Sep 29, 2018 at 06:53:58PM +1000, Nick Coghlan wrote: > On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote: > > I?m all for supporting the next generation of developers, but not > > necessarily at the expense of *decades* of established workflow for current > > developers. Moving to Discourse breaks this and proliferates browser tab > > syndrome. It?s an experiment worth conducting, but I do think it?s a bit > > cavalier to shut down python-committers without further discussion. > > > > Especially on the eve of critical governance discussions that will heavily > impact the future of python-dev. Indeed. > This is exactly the kind of arbitrary decision making by an insufficiently > representative group that led to us banning making any binding decisions at > language summits: their in-person nature means that they're inherently > exclusive environments that lead to requirements being overlooked and > decisions being made without involving most of the people affected. I'm surprised how decisions are made on summits as well. It's quite telling that already 6 core devs, most of whom have contributed huge amounts of code, apparently have not been at that exclusive summit and have indicated that they are uncomfortable with that decision. Stefan Krah From njs at pobox.com Sat Sep 29 05:24:07 2018 From: njs at pobox.com (Nathaniel Smith) Date: Sat, 29 Sep 2018 02:24:07 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> Message-ID: On Sat, Sep 29, 2018 at 1:51 AM, Serhiy Storchaka wrote: > 29.09.18 03:45, ?ukasz Langa ????: >>> >>> On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: >> >> Do you use NNTP? Like with IRC, you won't find the next generation of core >> developers on it. And no, there is no support for it in Discourse. > > > Yes, I do. I read all Python-related mailing list via the Gmane gate. It is > convenient in case of large discussions, when I can read selected branches > and ignore others. The great advantage of NNTP is that it provides access to > past discussions. I can read Python-Dev discussions back from 1999. The reason the general public has settled on web forums rather than mailing lists is basically that web forums give you many of the advantages of NNTP -- including first-class access to archives, replying to threads that predate your arrival, muting topics, the ability to skim the topic list before downloading everything, etc. -- without the need to install specialized software. Of course it's not going to be the same as your favorite NNTP client that you've spent a decade tweaking, but it might be worth giving it a try? That said, there is this: https://github.com/sman591/discourse-nntp-bridge No idea how usable it is in practice, but apparently it works for at least one person... -n -- Nathaniel J. Smith -- https://vorpus.org From lukasz at langa.pl Sat Sep 29 05:40:02 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 10:40:02 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> > On Sep 29, 2018, at 09:53, Nick Coghlan wrote: > > Especially on the eve of critical governance discussions that will heavily impact the future of python-dev. Ironically it's the very gravity of those upcoming discussions that made us decide to move fast on this. Part of why we are in this mess in the first place is due to inadequate moderation controls available on mailing lists and the way they invite thundering herds of answers and the combinatorial explosion of posts in trees of discussion. The PEP 572 process exercised this painfully well. Discourse is a chance to address the problems that contributed to the BDFL stepping down. > arbitrary decision making ... > insufficiently representative group ... > without involving most of the people affected ... Hold on. Out of the 30-something committers active in the past two releases, 20-something were at the sprint. (I can pull more detailed stats but I'm on the phone now.) Setting up Discourse with the intent of replacing the mailing lists met no opposition at the sprint. By all counts, the group was sufficiently representative and involved most of the people affected. I would prefer for everybody to be there, of course. Some decided against it, some could not be there even though they wanted to. This is unfortunate. But if you have committer unanimity in mind, that's not something that was feasible regardless of the forum. - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Sat Sep 29 05:44:29 2018 From: stefan at bytereef.org (Stefan Krah) Date: Sat, 29 Sep 2018 11:44:29 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> Message-ID: <20180929094429.GA4660@bytereef.org> On Sat, Sep 29, 2018 at 10:40:02AM +0100, ?ukasz Langa wrote: > > Especially on the eve of critical governance discussions that will heavily impact the future of python-dev. > > Ironically it's the very gravity of those upcoming discussions that made us decide to move fast on this. Sorry if I misunderstand this, but is the plan to moderate *core developers* on python-committers? Stefan Krah From lukasz at langa.pl Sat Sep 29 06:00:48 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 11:00:48 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <20180929094429.GA4660@bytereef.org> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> Message-ID: <8165037E-158B-4198-A56D-2EF990150825@langa.pl> > On Sep 29, 2018, at 10:44, Stefan Krah wrote: > > Sorry if I misunderstand this, but is the plan to moderate *core developers* > on python-committers? If you label it with an abstract term like this, it sounds like we just formed the Python Thought Police ;-) But think about the concrete examples of moderation and discussion flow that are going to be useful: - ability to link between topics - ability to see if somebody is actively replying on something you are also replying to - ability to edit your own post afterwards for clarity, typos, sending mishaps - ability to move topics around to where they belong better - ability to close a topic (no more replies) to indicate for example: "this is about a resolved issue", "this is about an outdated version of the PEP" - ability to make multiple quotes in a single post (which correctly link back for broader context) - ability to collapse out-of-band replies in a topic I could go on. In other words, unless the conversation REALLY gets heated, I doubt we will have to involve the code of conduct working group. But moderation and flow control is much more than banning abuse. - ? From p.f.moore at gmail.com Sat Sep 29 06:03:59 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 11:03:59 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> Message-ID: On Sat, 29 Sep 2018 at 09:23, ?ukasz Langa wrote: > > > > On Sep 29, 2018, at 08:50, M.-A. Lemburg wrote: > > > > 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 assume it's the faulty mailing list medium that made you miss my response to Barry where I say that this is indeed supported ;-) > > See, Discourse would already save you a paragraph of worry. Why don't you try it out for a while and see how it feels? I understand the power of habit but I promise you that there's plenty of things that make the adjustment worthwhile. I mentioned something similar on Discourse, but I'm going to add a comment here. This sort of dismissal of the validity of other people's long-established workflows is not very helpful. I use email, It's not because I've no idea how to use web forums, nor is it because I'm an old fuddy-duddy. It suits my workflow. I use a *lot* of web forums, as well as tools like Stack Overflow, reddit, Discord, etc. They simply do not always suit my requirements as well as email. Some examples: 1. Pull technology rather than push. The fact that email is *delivered* to me is a critical benefit for certain types of interaction, and one that's far too easily dismissed by people who promote pull solutions. It's baffling to me that such a fundamental difference is routinely treated as "minor". 2. Email-forum interfaces are in my experience uniformly suboptimal. I'm OK with the idea that I need to compromise and not expect people who prefer a forum to do all the work, but nevertheless, seeing the typical email response appear in a forum (with quoted text, signatures, etc) is very disruptive to conversation flow. 3. Maintaining accounts for various bits of forum software is a pain when you use as many devices as I do. 4. Browser tabs. Some of my devices are close to unusable *already* because of the RAM usage of my browser with multiple tabs open. Is someone going to suggest that there's a minimum hardware requirement to participate? Can we please consider that people have a lot of investment in email, and being willing to try a new approach is a big commitment. Responding to valid concerns with "just try it, you'll like it" is pretty non-constructive. Paul PS I *am* trying Discourse out. I'm somewhat interested in a "better than email" solution. So this is emphatically *not* a "do things my way or I won't play" posting. From njs at pobox.com Sat Sep 29 05:44:59 2018 From: njs at pobox.com (Nathaniel Smith) Date: Sat, 29 Sep 2018 02:44:59 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: On Sat, Sep 29, 2018 at 1:53 AM, Nick Coghlan wrote: > This is exactly the kind of arbitrary decision making by an insufficiently > representative group that led to us banning making any binding decisions at > language summits: their in-person nature means that they're inherently > exclusive environments that lead to requirements being overlooked and > decisions being made without involving most of the people affected. Did you see Brett's email here, especially the last few paragraphs? https://mail.python.org/pipermail/python-committers/2018-September/006100.html I don't know how the Discourse experiment will turn out, and I know it won't make everyone happy, but I hope it works. Because we *know* that what we're doing now is making people miserable and driving them away. The push to try Discourse may or may not be misguided, but it's not coming out of a few people having a whim over lunch together. -n P.S.: I found that link using my usual method for finding mailing list archive links, which is: first I did a search in my local MUA, found the email I wanted, noted the date, then manually went to the mailing list archives and clicked through the messages around that date until I found it. This *sucks*. -- Nathaniel J. Smith -- https://vorpus.org From p.f.moore at gmail.com Sat Sep 29 06:07:10 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 11:07:10 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: On Sat, 29 Sep 2018 at 09:57, Nick Coghlan wrote: > > On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote: >> >> On Sep 28, 2018, at 17:45, ?ukasz Langa wrote: >> >> > Do you use NNTP? Like with IRC, you won't find the next generation of core developers on it. And no, there is no support for it in Discourse. >> > >> > We could probably figure something out with Gmane if there's interest. >> >> Yes, I use NNTP to read many of the Python mailing lists. Gmane, even in its current state, is fantastic. >> >> I?m all for supporting the next generation of developers, but not necessarily at the expense of *decades* of established workflow for current developers. Moving to Discourse breaks this and proliferates browser tab syndrome. It?s an experiment worth conducting, but I do think it?s a bit cavalier to shut down python-committers without further discussion. > > > Especially on the eve of critical governance discussions that will heavily impact the future of python-dev. > > This is exactly the kind of arbitrary decision making by an insufficiently representative group that led to us banning making any binding decisions at language summits: their in-person nature means that they're inherently exclusive environments that lead to requirements being overlooked and decisions being made without involving most of the people affected. Strong +1. We've yet to see most of the governance PEPs, and now it's looking like the people involved in debating them will be hampered by struggling with a new communication medium as well? And the new medium was announced as a completely out of the blue surprise to most of us? Suggestion: We mandate that all discussion on governance must remain on the mailing list, and discussion on Discourse will be banned. That way, no-one who is in the process of switching and doesn't yet feel comfortable with the new medium will feel disenfranchised. Paul From p.f.moore at gmail.com Sat Sep 29 06:08:32 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 11:08:32 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> Message-ID: On Sat, 29 Sep 2018 at 10:24, Nathaniel Smith wrote: > > On Sat, Sep 29, 2018 at 1:51 AM, Serhiy Storchaka wrote: > > 29.09.18 03:45, ?ukasz Langa ????: > >>> > >>> On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: > >> > >> Do you use NNTP? Like with IRC, you won't find the next generation of core > >> developers on it. And no, there is no support for it in Discourse. > > > > > > Yes, I do. I read all Python-related mailing list via the Gmane gate. It is > > convenient in case of large discussions, when I can read selected branches > > and ignore others. The great advantage of NNTP is that it provides access to > > past discussions. I can read Python-Dev discussions back from 1999. > > The reason the general public has settled on web forums rather than > mailing lists is basically that web forums give you many of the > advantages of NNTP -- including first-class access to archives, > replying to threads that predate your arrival, muting topics, the > ability to skim the topic list before downloading everything, etc. -- > without the need to install specialized software. Of course it's not > going to be the same as your favorite NNTP client that you've spent a > decade tweaking, but it might be worth giving it a try? I don't use NNTP, but this is simply wrong. Forums miss one of the most significant advantages of NNTP - namely, the choice of client enabled by having a standardised protocol. Paul From donald at stufft.io Sat Sep 29 06:10:17 2018 From: donald at stufft.io (Donald Stufft) Date: Sat, 29 Sep 2018 06:10:17 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> Message-ID: <454C4215-A441-4529-9292-42035B85F627@stufft.io> > On Sep 29, 2018, at 6:03 AM, Paul Moore wrote: > > 1. Pull technology rather than push. The fact that email is > *delivered* to me is a critical benefit for certain types of > interaction, and one that's far too easily dismissed by people who > promote pull solutions. It's baffling to me that such a fundamental > difference is routinely treated as "minor". FWIW, Discourse can be configured to be push or pull based on a personal level. Not only on a personal level, but you can control at at the category (similar to different lists), tag, or individual topic level. I?ve responded to you on Discourse in more detail, but I find the level of control quite nice in a way that lets you choose push or pull based upon how much you care about a particular topic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Sat Sep 29 06:11:12 2018 From: antoine at python.org (Antoine Pitrou) Date: Sat, 29 Sep 2018 12:11:12 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <8165037E-158B-4198-A56D-2EF990150825@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> <8165037E-158B-4198-A56D-2EF990150825@langa.pl> Message-ID: Le 29/09/2018 ? 12:00, ?ukasz Langa a ?crit?: > >> On Sep 29, 2018, at 10:44, Stefan Krah wrote: >> >> Sorry if I misunderstand this, but is the plan to moderate *core developers* >> on python-committers? > > If you label it with an abstract term like this, it sounds like we just formed the Python Thought Police ;-) > > But think about the concrete examples of moderation and discussion flow that are going to be useful: > - ability to link between topics > - ability to see if somebody is actively replying on something you are also replying to > - ability to edit your own post afterwards for clarity, typos, sending mishaps Note this particular one *might* be a misfeature if someone edits their posting significantly after someone else already replied. I expect Discourse to mention that the post was edited, but it can still be confusing or misleading. Now I hope this wouldn't happen for core developer discussions, but I can see it easily happening in heated "ideas" discussions. On the more general idea of Discourse, I'm all for experimenting as I do agree with the advantages you mention. Like Serhiy I also like my Gmane workflow, but Gmane has worked less and less well recently, and admins basically don't respond anymore (for example, it's become impossible to start posting to new mailing-lists, since the autoresponder doesn't work anymore). I *am* worried, though, that the way this is being done is gonna exclude some core developers at a critical moment where we do want everyone included. I would rather have had this happen after governance is decided on. Regards Antoine. From donald at stufft.io Sat Sep 29 06:17:24 2018 From: donald at stufft.io (Donald Stufft) Date: Sat, 29 Sep 2018 06:17:24 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <8165037E-158B-4198-A56D-2EF990150825@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> <8165037E-158B-4198-A56D-2EF990150825@langa.pl> Message-ID: <93317FD8-A1EB-4B08-91C2-D107FA5DF263@stufft.io> > On Sep 29, 2018, at 6:00 AM, ?ukasz Langa wrote: > > >> On Sep 29, 2018, at 10:44, Stefan Krah wrote: >> >> Sorry if I misunderstand this, but is the plan to moderate *core developers* >> on python-committers? > > If you label it with an abstract term like this, it sounds like we just formed the Python Thought Police ;-) > > But think about the concrete examples of moderation and discussion flow that are going to be useful: > - ability to link between topics > - ability to see if somebody is actively replying on something you are also replying to > - ability to edit your own post afterwards for clarity, typos, sending mishaps > - ability to move topics around to where they belong better > - ability to close a topic (no more replies) to indicate for example: "this is about a resolved issue", "this is about an outdated version of the PEP" > - ability to make multiple quotes in a single post (which correctly link back for broader context) > - ability to collapse out-of-band replies in a topic > > I could go on. In other words, unless the conversation REALLY gets heated, I doubt we will have to involve the code of conduct working group. But moderation and flow control is much more than banning abuse. > I?d also say that perhaps it?s less required on python-committers due to the invite only nature of the list (though I don?t think we?re immune here either). But as I understand it, one of the goals if the experiment works out well here, is to expand the lists that we move onto discourse to ones that are not invite only. In that regard, even if we never need the ability to manage inappropriate behavior on python-committers, we likey will at some point on the more public lists from time to time. From p.f.moore at gmail.com Sat Sep 29 06:24:37 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 11:24:37 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: On Sat, 29 Sep 2018 at 11:04, Nathaniel Smith wrote: > > On Sat, Sep 29, 2018 at 1:53 AM, Nick Coghlan wrote: > > This is exactly the kind of arbitrary decision making by an insufficiently > > representative group that led to us banning making any binding decisions at > > language summits: their in-person nature means that they're inherently > > exclusive environments that lead to requirements being overlooked and > > decisions being made without involving most of the people affected. > > Did you see Brett's email here, especially the last few paragraphs? > > https://mail.python.org/pipermail/python-committers/2018-September/006100.html > > I don't know how the Discourse experiment will turn out, and I know it > won't make everyone happy, but I hope it works. Because we *know* that > what we're doing now is making people miserable and driving them away. > The push to try Discourse may or may not be misguided, but it's not > coming out of a few people having a whim over lunch together. Who's "we"? I thought I was part of "we" when it came to the Python core dev team... > P.S.: I found that link using my usual method for finding mailing list > archive links, which is: first I did a search in my local MUA, found > the email I wanted, noted the date, then manually went to the mailing > list archives and clicked through the messages around that date until > I found it. This *sucks*. But at least it was *possible*. Personally I do a Google search rather than using my MUA, but the point is that while it's clumsy, it's known technology. I don't even know how I'd find a link to an old message in Discourse, but I assume it's not searchable via Google? Sure, I can learn. But how about a member of the general public (after all, python-committers is supposed to be restricted for posting, but publicly visible)? On Sat, 29 Sep 2018 at 10:40, ?ukasz Langa wrote: > > Hold on. Out of the 30-something committers active in the past two releases, 20-something were at the sprint. (I can pull more detailed stats but I'm on the phone now.) Setting up Discourse with the intent of replacing the mailing lists met no opposition at the sprint. By all counts, the group was sufficiently representative and involved most of the people affected. Hold on in return. Are committers *not* active in the past two releases not considered? Your figures seem biased. (Was I part of that 30? I committed some changes in the last 2 releases. Barely anything, and I do *not* consider myself very active in terms of code changes, but how many tiers are we working with here? People who were at the sprints, people "active in the past 2 releases", "the rest"? I don't want to seem to accuse people of agendas - everyone's acting in the best interests of the community - but it does feel like the community is fragmenting at the moment :-( Paul From donald at stufft.io Sat Sep 29 06:29:49 2018 From: donald at stufft.io (Donald Stufft) Date: Sat, 29 Sep 2018 06:29:49 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: <4BEEC8B1-59DC-42BC-A073-6A56DF9F9E36@stufft.io> > On Sep 29, 2018, at 6:24 AM, Paul Moore wrote: > > But at least it was *possible*. Personally I do a Google search rather > than using my MUA, but the point is that while it's clumsy, it's known > technology. I don't even know how I'd find a link to an old message in > Discourse, but I assume it's not searchable via Google? Sure, I can > learn. But how about a member of the general public (after all, > python-committers is supposed to be restricted for posting, but > publicly visible)? Discourse is perfectly searchable using Google in exactly the same way as Mailman archives. It also has built in search. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at langa.pl Sat Sep 29 06:44:41 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 11:44:41 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> Message-ID: <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> > On Sep 29, 2018, at 11:24, Paul Moore wrote: > > Are committers *not* active in the past two > releases not considered? Your figures seem biased. (Was I part of that > 30? I committed some changes in the last 2 releases. Barely anything, > and I do *not* consider myself very active in terms of code changes, > but how many tiers are we working with here? People who were at the > sprints, people "active in the past 2 releases", "the rest"? There is discussion *just* about this here: https://discuss.python.org/t/which-list-of-core-developers-is-authoritative/55 - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Sat Sep 29 06:59:58 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 11:59:58 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <4BEEC8B1-59DC-42BC-A073-6A56DF9F9E36@stufft.io> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <4BEEC8B1-59DC-42BC-A073-6A56DF9F9E36@stufft.io> Message-ID: On Sat, 29 Sep 2018 at 11:29, Donald Stufft wrote: > Discourse is perfectly searchable using Google in exactly the same way as Mailman archives. Cool. > It also has built in search. Somewhat less relevant - I assumed that but "most people" won't use that, they'll use Google. Paul From antoine at python.org Sat Sep 29 07:01:15 2018 From: antoine at python.org (Antoine Pitrou) Date: Sat, 29 Sep 2018 13:01:15 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> Message-ID: <5e9dc052-edd6-c924-0df2-2d1b828bdc32@python.org> Le 29/09/2018 ? 12:44, ?ukasz Langa a ?crit?: > > On Sep 29, 2018, at 11:24, Paul Moore > wrote: > >> Are committers *not* active in the past two >> releases not considered? Your figures seem biased. (Was I part of that >> 30? I committed some changes in the last 2 releases. Barely anything, >> and I do *not* consider myself very active in terms of code changes, >> but how many tiers are we working with here? People who were at the >> sprints, people "active in the past 2 releases", "the rest"? > > There is discussion *just* about this here: > https://discuss.python.org/t/which-list-of-core-developers-is-authoritative/55 > It would be nice not to mingle different concerns, though. We may want to have a discussion over what an "active" core developer is (and perhaps reach an official decision if desired), but in the meantime we should avoid using the "active / inactive" distinction when discussing who can voice their opinion on topics such as communication tools. Regards Antoine. From p.f.moore at gmail.com Sat Sep 29 07:02:11 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 12:02:11 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> Message-ID: On Sat, 29 Sep 2018 at 11:44, ?ukasz Langa wrote: > > > On Sep 29, 2018, at 11:24, Paul Moore wrote: > > Are committers *not* active in the past two > releases not considered? Your figures seem biased. (Was I part of that > 30? I committed some changes in the last 2 releases. Barely anything, > and I do *not* consider myself very active in terms of code changes, > but how many tiers are we working with here? People who were at the > sprints, people "active in the past 2 releases", "the rest"? > > > There is discussion *just* about this here: > https://discuss.python.org/t/which-list-of-core-developers-is-authoritative/55 Isn't that just a restart of the conversation that happened on this list not too long ago (prompted by a question from MAL, IIRC) but missing the context of that previous question, and with less participants (so far)? Paul From lukasz at langa.pl Sat Sep 29 07:06:34 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 29 Sep 2018 12:06:34 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> Message-ID: > On Sep 29, 2018, at 12:02, Paul Moore wrote: > > Isn't that just a restart of the conversation that happened on this > list not too long ago (prompted by a question from MAL, IIRC) but > missing the context of that previous question, and with less > participants (so far)? Did you read it? I address this in the original post. I even link to the committers discussion. The context is not missed but different. - ? From p.f.moore at gmail.com Sat Sep 29 07:27:27 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Sep 2018 12:27:27 +0100 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <594FF203-481A-4823-B2C8-3D1ED6962712@langa.pl> Message-ID: On Sat, 29 Sep 2018 at 12:06, ?ukasz Langa wrote: > > > On Sep 29, 2018, at 12:02, Paul Moore wrote: > > > > Isn't that just a restart of the conversation that happened on this > > list not too long ago (prompted by a question from MAL, IIRC) but > > missing the context of that previous question, and with less > > participants (so far)? > > Did you read it? I address this in the original post. I even link to the committers discussion. > > The context is not missed but different. I thought I did, but I've reached a point where I'm struggling to follow the various threads and posts. At the moment, I've burned out on trying to cope with both email (for all my non python-committers emails) and Discourse, so I'm struggling to follow discussions. I'll probably stop following python-contributors for the rest of the day, and hope I can catch up on what I missed tomorrow. I consider that a negative indication of the usability of Discourse for me, but I'm willing to mark it down as "early days" for now. Apologies for misreading the mail in that thread. For the record, and adding it here because I'm done with Discourse for the day, I consider myself a core Python developer, and I am proud to do so - I enjoy being able to say that. I'm *not* particularly active in terms of commits - there are a number of reasons for that (other commitments, struggling to keep up with the details of the CPython workflow, ...) but it's a reality. However, I *do* contribute a lot to discussions, as I always have, and I feel a great responsibility to do that "as a core developer" and always try to ensure that my posts in that context are for the benefit of the language. I would fight to retain my right to call myself a "core Python developer", with the same implications as anyone else (I do *not* want to call myself "Emeritus" or "Inactive" or any of the other terms previously mentioned for "not contributing much these days"). I would feel very disappointed and rejected if it became the case because I didn't commit actual code, and I don't attend conferences/sprints, that my views were ignored or under-represented. I'm concerned already that it's becoming harder and harder to be heard in the core dev community. I'd really like it if experiments like Discord made it *easier* for people to be heard and represented - but I fear that they won't, and the voices of people with real life commitments that make working with forum software harder will be lost (and not having a good way for people to communicate "I can't effectively communicate via this new mechanism" is a particularly pernicious way of losing people's input). I'll catch up with discussions again in a day or two. For now, I need to go and read my emails :-) (Yeah, that's a joke - I really need to go and hang out with my family). Paul From mal at egenix.com Sat Sep 29 07:38:10 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 29 Sep 2018 13:38:10 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> Message-ID: On 29.09.2018 11:40, ?ukasz Langa wrote: > >> On Sep 29, 2018, at 09:53, Nick Coghlan wrote: >> >> Especially on the eve of critical governance discussions that will heavily impact the future of python-dev. > > Ironically it's the very gravity of those upcoming discussions that made us decide to move fast on this. > > Part of why we are in this mess in the first place is due to inadequate moderation controls available on mailing lists and the way they invite thundering herds of answers and the combinatorial explosion of posts in trees of discussion. The PEP 572 process exercised this painfully well. > > Discourse is a chance to address the problems that contributed to the BDFL stepping down. Hold on. The group of core developers is rather limited in size. I would understand such a move for e.g. python-ideas, but much less so for the committers list. I'm not opposed to trying Discourse, but don't think the timing is good to fork off discussions to yet another medium. This creates more noise than necessary and diverts discussions away from what we should really be concerned about, namely our model of decision making for PEP discussions which don't come out with a clear direction and a model of how to steer the overarching direction of where Python will go in the coming decades. >> arbitrary decision making > ... >> insufficiently representative group > ... >> without involving most of the people affected > ... > > Hold on. Out of the 30-something committers active in the past two releases, 20-something were at the sprint. (I can pull more detailed stats but I'm on the phone now.) Setting up Discourse with the intent of replacing the mailing lists met no opposition at the sprint. By all counts, the group was sufficiently representative and involved most of the people affected. Ouch. So those 20 core devs got to decide for whoever else considers themselves a core developer and at the same time fixed the very definition of who is allowed to vote and who is not without asking the complete set of core developers ? The reality is that we're a remote working group, so while in person meetings are nice and can seed new ideas, we do have to take into account that people not present at those meetings do have a stake in Python as core developers as well. > I would prefer for everybody to be there, of course. Some decided against it, some could not be there even though they wanted to. This is unfortunate. But if you have committer unanimity in mind, that's not something that was feasible regardless of the forum. I don't think we're discussing unanimity here, but democratic basics, i.e. who has a stake in Python, who will be heard in discussions and who has voting rights. On the https://discuss.python.org/t/which-list-of-core-developers-is-authoritative/55 posting, you summarize a discussion we've had here on the ML, but leave out parts such as the emeritus discussion (which AFAIR concluded in making this based on whether a core dev wants to switch to that role rather than making this based on PRs and Github activity), it also makes it look like we agreed on just giving "active" core devs voting rights in the governance discussions, which is not the case. This is a typical situation you run into with forum postings. The top posting often receives more attention and is seen as summary of the whole discussion. Unless the top poster updates the posting to reflect the outcome of the discussion below, this can easily to misinterpretations. In email discussions, such summaries are created after the discussions (eg. as PEP), which avoids such misinterpretations. To avoid the same on Discourse, we'd need to have a common understanding to keep the top posting updated to where the discussion is going. Regarding the topic of voting rights: Since we have never really had to vote on anything, the only democratic approach is to give everyone listed as core developer voting rights. Limiting this to an arbitrary definition of "active" is not democratic, since the definition of "active" represents a way to introduce representations, which we can, of course, have, but only after having elected those representatives. -- 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/ From stefan at bytereef.org Sat Sep 29 07:55:56 2018 From: stefan at bytereef.org (Stefan Krah) Date: Sat, 29 Sep 2018 13:55:56 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> <8165037E-158B-4198-A56D-2EF990150825@langa.pl> Message-ID: <20180929115556.GA3700@bytereef.org> On Sat, Sep 29, 2018 at 12:11:12PM +0200, Antoine Pitrou wrote: > On the more general idea of Discourse, I'm all for experimenting as I do > agree with the advantages you mention. Like Serhiy I also like my Gmane > workflow, but Gmane has worked less and less well recently, and admins > basically don't respond anymore (for example, it's become impossible to > start posting to new mailing-lists, since the autoresponder doesn't work > anymore). A couple of years ago http://news.individual.net/index.php (maintained by FU-Berlin (university)) worked well. It's not free though (EUR 10,- per year). Stefan Krah From antoine at python.org Sat Sep 29 08:01:20 2018 From: antoine at python.org (Antoine Pitrou) Date: Sat, 29 Sep 2018 14:01:20 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <20180929115556.GA3700@bytereef.org> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> <8165037E-158B-4198-A56D-2EF990150825@langa.pl> <20180929115556.GA3700@bytereef.org> Message-ID: <14f2c6db-4fd3-cf6b-46e9-07d359c97e2a@python.org> Le 29/09/2018 ? 13:55, Stefan Krah a ?crit?: > On Sat, Sep 29, 2018 at 12:11:12PM +0200, Antoine Pitrou wrote: >> On the more general idea of Discourse, I'm all for experimenting as I do >> agree with the advantages you mention. Like Serhiy I also like my Gmane >> workflow, but Gmane has worked less and less well recently, and admins >> basically don't respond anymore (for example, it's become impossible to >> start posting to new mailing-lists, since the autoresponder doesn't work >> anymore). > > A couple of years ago http://news.individual.net/index.php (maintained > by FU-Berlin (university)) worked well. Does it provide mailing-list mirrors? It's not obvious by the description. Regards Antoine. From stefan at bytereef.org Sat Sep 29 08:13:25 2018 From: stefan at bytereef.org (Stefan Krah) Date: Sat, 29 Sep 2018 14:13:25 +0200 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <14f2c6db-4fd3-cf6b-46e9-07d359c97e2a@python.org> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> <8165037E-158B-4198-A56D-2EF990150825@langa.pl> <20180929115556.GA3700@bytereef.org> <14f2c6db-4fd3-cf6b-46e9-07d359c97e2a@python.org> Message-ID: <20180929121325.GA3813@bytereef.org> On Sat, Sep 29, 2018 at 02:01:20PM +0200, Antoine Pitrou wrote: > > A couple of years ago http://news.individual.net/index.php (maintained > > by FU-Berlin (university)) worked well. > > Does it provide mailing-list mirrors? It's not obvious by the description. Ah yes, it only has comp.lang.python <==> python-list, which is useless of course: ftp://ftp.fu-berlin.de/doc/news/fu-berlin/active My good memories of the service were for other groups like sci.crypt. Stefan Krah From stefan at bytereef.org Sat Sep 29 09:09:45 2018 From: stefan at bytereef.org (Stefan Krah) Date: Sat, 29 Sep 2018 15:09:45 +0200 Subject: [python-committers] Non-active devs, become active! (was: python-committers is dead, long live discuss.python.org) In-Reply-To: <8165037E-158B-4198-A56D-2EF990150825@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> <20180929094429.GA4660@bytereef.org> <8165037E-158B-4198-A56D-2EF990150825@langa.pl> Message-ID: <20180929130945.GA4782@bytereef.org> On Sat, Sep 29, 2018 at 11:00:48AM +0100, ?ukasz Langa wrote: > > Sorry if I misunderstand this, but is the plan to moderate *core developers* > > on python-committers? > > If you label it with an abstract term like this, it sounds like we just formed the Python Thought Police ;-) Well, it gets worse. :-) I mean, moving the list *just* before the election and having a simultaneous discussion about who is considered a core developer might evoke associations with gerrymandering away the non-active people, who are probably more likely not to move to discourse or even miss this thread. You can all have the best motives, but I'm really taken aback by these developments. Has this concern not been mentioned at the summit? Perhaps that is what you get if only recently active devs are invited. I strongly suggest that the vote-eligibility and governance discussions take place here. Stefan Krah From steve at pearwood.info Sat Sep 29 10:16:12 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 30 Sep 2018 00:16:12 +1000 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> Message-ID: <20180929141612.GZ19437@ando.pearwood.info> On Sat, Sep 29, 2018 at 11:03:59AM +0100, Paul Moore wrote: > I mentioned something similar on Discourse, but I'm going to add a > comment here. This sort of dismissal of the validity of other people's > long-established workflows is not very helpful. [snip] Thank you Paul. Discourse may or may not be great, but this rush to change forums in the midst of not one but two community crises[1] seems ill-considered. Even if it works out in the long run, the way it has been done seems elitist and anti-democratic to me. Its especially worrisome since it isn't clear to me who has the authority to make this decision, and on what basis. Hypothetically speaking, could *I* announce next week that the Discourse experiment was a failure and we're all going to move to a Reddit forum? Well, I could announce it, but nobody would pay any attention. Why should we pay attention to this announcement? No offense to ?ukasz, but how did he get put in charge of this? If it had been put as "We want to change to Discourse, and intend to do so over the next few months. Any questions or objections?" things would have been better, but instead we get the change dumped in our lap as a fait accompli "the mailing list is dead, stop using it IMMEDIATELY, and go to Discourse". That's not open, considerate or respectful. Maybe some people and companies treat their staff like that, but we shouldn't treat our volunteers the same way. [1] Guido's retirement as BDFL; and the recent hostile, politically- driven bug reports and mailing list threads leading to bannings and potential burn-out of moderators. -- Steve From yselivanov.ml at gmail.com Sat Sep 29 11:30:46 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Sat, 29 Sep 2018 11:30:46 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <20180929141612.GZ19437@ando.pearwood.info> References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> <20180929141612.GZ19437@ando.pearwood.info> Message-ID: On Sat, Sep 29, 2018 at 10:16 AM Steven D'Aprano wrote: [..] > Well, I could announce it, but nobody would pay any attention. Why > should we pay attention to this announcement? No offense to ?ukasz, but > how did he get put in charge of this? You could and everybody would pay attention. As for ?ukasz and Discourse: (1) I remember asking Brett, ?ukasz, Victor, Guido and few other core devs if we can do something to "fix" python-ideas at the previous core devs sprint (2 years ago). I also remember Guido saying that PEPs discussions on mailing lists are super hard to manage, and that he wishes we can do that on GitHub. A frustration with our mailing lists has been a known issue for many core devs for a long time. (2) Brett has previously expressed that moderating and enforcing CoC on our mailing lists isn't a pleasant experience. Discourse provides way more tools to make discussions more manageable. Hopefully it will allow to diffuse heated discussions before anyone needs to even think about CoC. (3) We want to try Discource now because discussions on python-ideas, python-dev, and python-committers became *unbearable* to many core devs (including myself). Most of the time I find it inconvenient to even read them, left alone engage. (4) E-mail is clearly more convenient to *follow* the discussion to a lot core devs in this threads. Discourse, hopefully, will enable many other core developers to *want* to follow and feel *safe* to engage. Given all the above, ?ukasz *volunteered* his own time to help setup Discourse and help everyone to migrate to it so that we can all try it. When he announced that we want to try Discourse at the sprints, out of all people there I remember only Barry asking questions about email integration. Everybody else including Guido, Brett, Raymond, Victor, Mariatta, and many others were OK to try Discourse. As I can see, ?ukasz himself doesn't have any interests in this migration besides trying to make our communication more enjoyable and welcoming. Lastly, I understand everybody who likes e-mail and their e-mail clients. I'm such a person myself. Learning a completely new tool and using browser to access it isn't easy for me either. But I'm willing to try to sacrifice some of my convenience in order to see if the new medium can enable us to have more polite discussions and if core developers who don't want to engage now become comfortable to join us again. Yury From ericsnowcurrently at gmail.com Sat Sep 29 12:09:42 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Sat, 29 Sep 2018 10:09:42 -0600 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> <20180929141612.GZ19437@ando.pearwood.info> Message-ID: On Sat, Sep 29, 2018, 09:31 Yury Selivanov wrote: > Given all the above, ?ukasz *volunteered* his own time to help setup > Discourse and help everyone to migrate to it so that we can all try > it. Yes. Thank-you ?ukasz! :) When he announced that we want to try Discourse at the sprints, > out of all people there I remember only Barry asking questions about > email integration. Everybody else including Guido, Brett, Raymond, > Victor, Mariatta, and many others were OK to try Discourse. I expressed reservations as well, while also recognizing the benefits. I also didn't consider the impact on governance discussions, nor did I think there's be an abrupt switch nor so soon. FWIW, I don't recall being more than lukewarm on the idea (for the sake of the benefits), but didn't express strong objections because I figured that, for me personally, it would mostly be a matter of adjusting (which for me has a real cost in time and mental energy). As I can > see, ?ukasz himself doesn't have any interests in this migration > besides trying to make our communication more enjoyable and welcoming. > > Lastly, I understand everybody who likes e-mail and their e-mail > clients. I'm such a person myself. Learning a completely new tool > and using browser to access it isn't easy for me either. But I'm > willing to try to sacrifice some of my convenience in order to see if > the new medium can enable us to have more polite discussions +1 The catch is that it's an imposition on folks that don't feel exactly the same way. and if > core developers who don't want to engage now become comfortable to > join us again. > That's definitely worth aiming for. However, there are real limits to how much technology can help what is essentially a people/social problem. :/ -eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundobatista at gmail.com Sat Sep 29 12:40:13 2018 From: facundobatista at gmail.com (Facundo Batista) Date: Sat, 29 Sep 2018 13:40:13 -0300 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: Message-ID: El vie., 28 de sep. de 2018 a la(s) 18:45, ?ukasz Langa (lukasz at langa.pl) escribi?: > We'll be enabling GitHub and social logins soon, ideally with adding identified committers to the committers group by default. We are looking into this right now. In the mean time, please request membership, an existing member will add you. We'd like to migrate old discussion off of the mailing lists to our Discourse instance so that search is immediately useful. We'll look into that after the governance crisis is resolved. Hello! How do I request membership to the commiters group in Discourse? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista From guido at python.org Sat Sep 29 13:09:38 2018 From: guido at python.org (Guido van Rossum) Date: Sat, 29 Sep 2018 10:09:38 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> <20180929141612.GZ19437@ando.pearwood.info> Message-ID: Let's say that ?ukasz went a little overboard when he told everybody to abandon the mailing list right now, especially in the light of the upcoming elections (first we will vote to choose a constitution, then we'll vote according to the rules set by that constitution on the new leadership). That said, I am fully in favor of the current experiment where we're trying to figure out whether Discourse can work for us. I have signed up myself and it's pretty easy. There were a few moments where I didn't know how to do certain things, but these were quickly resolved. I recommend everyone at least give it a try for a few days. And the admins are pretty active right now so if you ask for help you'll get it almost instantly. Will it work in the long term? We don't know yet. We'll have to give it a serious try. But the mailing list isn't dead, and those who don't want to bother with the Discourse experiment can keep using the list. This will be an extra burden for those who feel the need to follow every discussion -- but I think it's worth it to ensure that nobody feels left behind. The people running the elections, in particular, will have to make sure that important deadlines and voting instructions are posted to the mailing list (in addition to Discourse) to ensure that we reach everyone. I will personally definitely follow both. A bit off-topic: For something as important as these elections I think we need to use voting software, rather than relying on +1 and -1 on the list (or Discourse polls, no matter how cute they are :-), and the voting software should also send each voter reminders and instructions for upcoming votes -- but realistically we won't have working email addresses for some voters, and the list might encourage them to register their email so they'll be able to vote. Note that there's no point in demanding that all election-related discussion happen in the mailing list -- there's always been chatter on other media such as IRC (which I myself never read), Twitter, and private email. What's happening here is important enough to non-core-devs that we'll inevitably also see outsiders debating our future in blogs, on Facebook and on Twitter. (And, alas, also on Reddit.) The election organizers will ensure that everyone can be aware of the elections and where to get info about them. But staying informed as a voter is work, and if you care about this community, you'll have to do that work. Getting to know a new online tool isn't going to kill you. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Sep 29 13:31:13 2018 From: brett at python.org (Brett Cannon) Date: Sat, 29 Sep 2018 10:31:13 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> <20180929141612.GZ19437@ando.pearwood.info> Message-ID: On Sat, 29 Sep 2018 at 08:31, Yury Selivanov wrote: > On Sat, Sep 29, 2018 at 10:16 AM Steven D'Aprano > wrote: > [..] > > Well, I could announce it, but nobody would pay any attention. Why > > should we pay attention to this announcement? No offense to ?ukasz, but > > how did he get put in charge of this? > > You could and everybody would pay attention. > > As for ?ukasz and Discourse: > > (1) I remember asking Brett, ?ukasz, Victor, Guido and few other core > devs if we can do something to "fix" python-ideas at the previous core > devs sprint (2 years ago). I also remember Guido saying that PEPs > discussions on mailing lists are super hard to manage, and that he > wishes we can do that on GitHub. A frustration with our mailing lists > has been a known issue for many core devs for a long time. > > (2) Brett has previously expressed that moderating and enforcing CoC > on our mailing lists isn't a pleasant experience. Discourse provides > way more tools to make discussions more manageable. Hopefully it will > allow to diffuse heated discussions before anyone needs to even think > about CoC. > I'll take this further and say that I've now reached burn-out and will be taking my annual month off from volunteering starting sometime today (I still need to write the announcement and then email all of my fellow admins on the various lists I'm in charge of before I declare my break officially on). But these past three weeks have been hell for me. I now dread checking my email because of what's going to be there. And the fact that fighting these CoC fires on multiple mailing lists with the tools they provide have not helped to improve my situation. The difficulty in locking down threads, the fact that there is no shared burden on each of these mailing lists because they are each viewed as independent entities when it comes to administration, and the barrier for people to feel comfortable in sending an email notifying admins when they feel a post has crossed a line has shown me that we have a problem. So I definitely would like to try Discourse out so we can potentially centralize and share the burden of out-of-control threads and have it be a click of a button to report disturbing posts so we can catch problems before they spiral out of control. Basically I'm worried we have simply gotten too big for email. > > (3) We want to try Discourse now because discussions on python-ideas, > python-dev, and python-committers became *unbearable* to many core > devs (including myself). Most of the time I find it inconvenient to > even read them, left alone engage. > Another way to think about this is if we wait until after our governance discussions and try this experiment the volume quite possibly won't be at a level to stress test how the interaction on Discourse works. And while I personally find day-to-day stuff manageable via email (but definitely not ideal), it's when the volume spikes horribly that I typically find email falls over the most. And I don't know about the rest of you, but I have not been looking forward to the governance discussions _because_ of the volume and I am too familiar with how difficult those discussions become difficult to manage via email. Now maybe we will call this experiment quits in a month instead of three because it fails that badly, but I personally would still like to give Discourse a solid try under load to help prevent us from prematurely saying "this is no better or worse than email, so I want to stick with what I'm used to" because we are all human beings who (understandably) like the familiar, especially when it comes to something we do in our spare time. > > (4) E-mail is clearly more convenient to *follow* the discussion to a > lot core devs in this threads. Discourse, hopefully, will enable many > other core developers to *want* to follow and feel *safe* to engage. > > Given all the above, ?ukasz *volunteered* his own time to help setup > Discourse and help everyone to migrate to it so that we can all try > it. When he announced that we want to try Discourse at the sprints, > out of all people there I remember only Barry asking questions about > email integration. Everybody else including Guido, Brett, Raymond, > Victor, Mariatta, and many others were OK to try Discourse. As I can > see, ?ukasz himself doesn't have any interests in this migration > besides trying to make our communication more enjoyable and welcoming. > > Lastly, I understand everybody who likes e-mail and their e-mail > clients. I'm such a person myself. Learning a completely new tool > and using browser to access it isn't easy for me either. But I'm > willing to try to sacrifice some of my convenience in order to see if > the new medium can enable us to have more polite discussions and if > core developers who don't want to engage now become comfortable to > join us again. > I also want to point out that we ask the same things of new contributors when we ask them to learn how to manage email volume that we produce. In my PyCon US keynote ( https://www.youtube.com/watch?v=tzFWz5fiVKU&list=PL4S0lvhXvdhIV2C28Ia_DeIeloBrsQBOW&index=20&t=2936s) I make the point that a project survives by attracting new members and retaining the current ones. This can get tricky, though, when the current ones have a practice that new ones simply are not attracted to or used to. My worry is that email is continuing to become less and less something kids, recent graduates, etc. use which means we are asking them to not only start using email seriously but be also be adept at managing a massive volume of it very abruptly. And in turn I'm worried that mailing lists are a turn-off that is going to cost us more and more potential future contributors. (I would actually be curious to know how many of us have children that are teenagers or older that are active users of email for any group-level discussions instead of e.g. Slack, WhatsApp, etc. compared to those that don't.) Now that isn't to say we should ignore what all of us current members want, and if Discourse doesn't work out because it doesn't suit our needs then I expect that will kill the idea. But I personally plan to give it a solid try, and under load if possible, so it's given a proper try under the conditions we are trying to solve for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Sat Sep 29 13:49:18 2018 From: donald at stufft.io (Donald Stufft) Date: Sat, 29 Sep 2018 13:49:18 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <87BFF8BD-0757-48EA-9F85-5CE864709CD2@langa.pl> <20180929141612.GZ19437@ando.pearwood.info> Message-ID: > On Sep 29, 2018, at 1:31 PM, Brett Cannon wrote: > > Another way to think about this is if we wait until after our governance discussions and try this experiment the volume quite possibly won't be at a level to stress test how the interaction on Discourse works. And while I personally find day-to-day stuff manageable via email (but definitely not ideal), it's when the volume spikes horribly that I typically find email falls over the most. And I don't know about the rest of you, but I have not been looking forward to the governance discussions _because_ of the volume and I am too familiar with how difficult those discussions become difficult to manage via email. I?d like to also point out that this isn?t a new idea, a year and a half ago we had the overload-sig whose idea was to solve this very thing (and Discourse was one of the options back then as well, as well as MM3, and uh? Github issues?). The results of the overload-sig were basically totally inconclusive because we never moved to the point of trying an *actual* list with *actual* traffic. So it just kind of fell to the wayside because we were never able to really test it out. Testing out a new medium for discussion is always hard, there is a fair amount of churn involved in getting everyone to move over to the new location, thus you tend to want to try it with a small group of people to limit the impact. Unfortunately the downside to a small group of people is that they tend not to produce a large amount of email (and when it?s invite only, are less likely to need some of the more advanced moderation facilities). So python-committers itself is still small enough that a mailing list doesn?t typically have the main problems that we?re trying to solve. However, the governance discussions give us a somewhat unique opportunity in that they?re likely going to increase the amount of discussion on this list by a fair amount. That gives us a chance to take an otherwise small list, and give it a more realistic test than it otherwise would be, without trying to tell the entirety of say, python-ideas, to switch to a new medium. I do believe we have a problem though, and I think it is getting worse. I?ve personally more or less completely checked out of python-dev and python-ideas, in large parts because of the problems with email and mailing lists. We?re burning Brett out, and quite frankly I think that the nature of large mailing lists makes all of our discussions more likely to become heated. With that, I urge everyone to give Discourse a fair shake for these next 3 months, and try to move as much of the discussion over there as we can. We?re unlikely to use either medium as the actual voting mechanism so if some people don?t come over, they?ll largely just miss out on discussion but will still ultimately end up able to vote. I personally am going to try to make this my last message on the mailing list during the duration of the test. I hope that you?ll all try it out as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Sat Sep 29 14:18:46 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 29 Sep 2018 14:18:46 -0400 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> Message-ID: <1083483d-7395-d56c-e543-f53bd279da91@udel.edu> On 9/29/2018 4:51 AM, Serhiy Storchaka wrote: > 29.09.18 03:45, ?ukasz Langa ????: >> (To paraphrase) 'We' are switching committers-list to Discourse. Who is this 'we'? I don't remember any discussion, let alone a vote. >>> On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: >> Do you use NNTP? Like with IRC, you won't find the next generation of >> core developers on it. And no, there is no support for it in Discourse. > > Yes, I do. I read all Python-related mailing list via the Gmane gate. It > is convenient in case of large discussions, when I can read selected > branches and ignore others. The great advantage of NNTP is that it > provides access to past discussions. I can read Python-Dev discussions > back from 1999. Like Barry and Serhiy and perhaps others, I use gmane for all python lists I follow with a gmane mirror. At least with Thunderbird, I generally find it far superior to to the list interface: each list/group automatically goes is a separate directory; only subject lines are auto-downloaded*; I can choose to only see unread subject lines; I can set an auto-purge time. * I now download and read less than half of python-list and python-ideas. When I am done with a batch, shift-C marks the rest as 'read' and therefore invisible unless I choose to see all unpurged articles. When the gmane search page worked, it was much better than mailman's month-by-month search. Perhaps Discourse fixes this. >> We could probably figure something out with Gmane if there's interest. There definitely is, but ... > Would be nice. It would be even better if provide the own NNTP gate and > avoid depending on third-party services. Agreed. From steve.dower at python.org Sat Sep 29 14:38:15 2018 From: steve.dower at python.org (Steve Dower) Date: Sat, 29 Sep 2018 11:38:15 -0700 Subject: [python-committers] [PEP 8013] The External Council Governance Model In-Reply-To: References: <7f28da9c-a0f4-074d-9c49-38a0e64387e9@python.org> Message-ID: <28028bf4-9a5f-250e-47a6-bb1832475804@python.org> On 28Sep2018 0649, Nick Coghlan wrote: > If we did go down the "independent > advisory council" route, I'd actually prefer to see it used to > strengthen the BDFL-Delegate system rather than weaken it: the role of > the advisory council would only be to step in when there was a dispute > amongst the core developers as to whether or not there was a suitable > volunteer available to serve as BDFL-Delegate, or if there was a > proposal where nobody was volunteering to be the final decision maker, > but the council thought the prospective gains on offer were > sufficiently large to make it worthwhile to attempt to change that > state of affairs. Perhaps I need to clarify the text referring to this system (or provide an example?), but the way I see it working is that the council may choose to nominate a core developer to drive and approve the design by saying that they will veto the proposal unless that specific person approves of it. What I *don't* want to bake into the process is that the council has no further veto power after nominating a delegate, or that the council is *required* to nominate a delegate. The easiest way to do this is to (a) not allow complete delegation of final approval, and (b) not define the criteria required to obtain approval. Basically, the written process should not constrain those who we select to manage final decisions. The constraint is that the core developers have to approve of the people selected, which (in my mind, at least) implies some period of campaigning or investigation prior to the election. > The other aspects would pretty much remain the same as you suggest - > the advisory council would mainly be there to help BDFL-Delegates out > when it came time to end discussion of a proposal and make their > decision (whether for or against) stick. This paragraph makes me think you're on the same page and I just need to add an example for the above case. The members of the council can do or say whatever they like when a proposal is being discussed (but they don't have to), provided they also make an explicit approval/rejection when requested by a core developer. Cheers, Steve From steve.dower at python.org Sat Sep 29 19:59:56 2018 From: steve.dower at python.org (Steve Dower) Date: Sat, 29 Sep 2018 16:59:56 -0700 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <1083483d-7395-d56c-e543-f53bd279da91@udel.edu> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <1083483d-7395-d56c-e543-f53bd279da91@udel.edu> Message-ID: <17f3624c-2f02-08c1-2222-3f34ec3b1611@python.org> I just wanted to add that while I was not involved in the Discourse discussions at the sprint (and didn't realise there were "discussions" going on), and while I would have been opposed to such a drastic change, my first impressions of discuss.python.org are good. Things that I have configured to make it better for me: * secure password and 2FA with an authenticator app * my default landing page is "latest" not "categories" * muted the categories I'm not interested in * disabled direct messages (you can email me; if you don't know how, then please don't email me :) ) * disabled email notifications, except the once per week when I haven't logged in (we'll see whether I change that after a week...) Things that I just like: * like button, rather than +1 emails (and you can disable the notifications for this) * Ctrl+V to paste images into a message * good mobile layout - doesn't try to do fancy stuff that fails on phones * transitions between pages are smooth, and drafts are auto-saved (I haven't really wanted more than one tab open yet) * mentions (my email filtering rules prioritised the lists, so they never came direct - but I should notice actual mentions more quickly now) So I'm fairly happy to try it out for a while. I'm interested to see whether it works better for PEP discussions (oh I want Google Wave back so badly sometimes!) and if we can migrate things like the buildbot-status list (one thread per configuration might be nice). Not entirely comfortable with declaring the mailing list "dead" so quickly, but I know for infrastructure stuff it's sometimes hard to get community momentum without just doing it. Cheers, Steve From ncoghlan at gmail.com Sat Sep 29 22:22:32 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 30 Sep 2018 12:22:32 +1000 Subject: [python-committers] python-committers is dead, long live discuss.python.org In-Reply-To: <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> References: <72307253-96e7-7486-398d-5a702377a4fb@gmail.com> <3F11F17A-F04A-49D3-9821-4E94169EB068@langa.pl> <37728F30-53CA-430A-BEA5-EF81CC76F811@python.org> <341BC704-C924-4F9E-84FB-11BFBDCD7E0B@langa.pl> Message-ID: On Sat., 29 Sep. 2018, 7:40 pm ?ukasz Langa, wrote: > > On Sep 29, 2018, at 09:53, Nick Coghlan wrote: > > Especially on the eve of critical governance discussions that will heavily > impact the future of python-dev. > > > Ironically it's the very gravity of those upcoming discussions that made > us decide to move fast on this. > > Part of why we are in this mess in the first place is due to inadequate > moderation controls available on mailing lists and the way they invite > thundering herds of answers and the combinatorial explosion of posts in > trees of discussion. The PEP 572 process exercised this painfully well. > This is not a problem that applies to python-committers, since there are less than a hundred people on the planet with permission to post to it. > Discourse is a chance to address the problems that contributed to the BDFL > stepping down. > For the generally accessible mailing lists, I agree completely, and if this had been a post to core-workflow saying "We want to experiment with closing python-ideas and moving it to a Discourse forum", I would been an enthusiastic +1. The same goes for core-mentorship: I think we've given MM3 a fair go there, and my conclusion is that while it does improve several aspects of the moderation process over MM2, it's still much weaker on that front than Discourse. That isn't what happened: the *first* I heard about this idea was a peremptory *order* to say that I had to move *now*, which isn't how the system works. Even when Guido was BDFL he wouldn't have been able to declare "We're dropping the mailing lists and switching to web forums" and make it stick - we'd have told him to write a PEP and make his case, just like anyone else (akin to Mariatta's current excellent PEP laying out the pros and cons of switching to a different issue tracker). The closest equivalent I can think of would be when python-committers was split out from python-dev (so that subscribing to python-dev could be made optional), and even then most of the critical announcements continued to be cross-posted to python-dev, and the discussions themselves didn't move. > > arbitrary decision making > > ... > > insufficiently representative group > > ... > > without involving most of the people affected > > ... > > Hold on. Out of the 30-something committers active in the past two > releases, 20-something were at the sprint. (I can pull more detailed stats > but I'm on the phone now.) Setting up Discourse with the intent of > replacing the mailing lists met no opposition at the sprint. By all counts, > the group was *sufficiently* representative and involved *most* of the > people affected. > The governance discussions affect, and need to involve *all* committers, not just the currently active ones. One particular reason why I consider the group at in-person events to be inherently insufficiently representative is that I was a core developer for more than five years before I ever met another core dev in person, and during that time I felt fully included in the decision making process. I think that's less true now, and part of the reason for it is that more discussions are taking place in contexts where the only folks present are those in a position to devote several work days to CPython related travel. Accounting for the opinions, perspectives, and feelings of those that aren't present only happens through the deliberate effort of those that are in the room. >From 2011 to 2017, that "in the room" group pretty consistently included me, since Red Hat were very permissive when it came to allowing time for that kind of thing, and the PSF was willing to compensate for RH's reluctance to provide travel funding. But I never forgot what I'd needed to feel included in the process before that job change, so I constantly asked myself not "who's here?" but rather "Who *isn't* here?", and advocated for approaches that lessened the gap between those two groups (most importantly: in-person events being for high bandwidth discussions that would subsequently be summarised in writing, not final decisions that would be handed down with no further asynchronous online discussion to be entered into) > I would prefer for everybody to be there, of course. Some decided against > it, some could not be there even though they wanted to. This is > unfortunate. But if you have committer unanimity in mind, that's not > something that was feasible regardless of the forum. > No, it isn't about unanimity, it's about ensuring that folks have the opportunity to be heard, rather than being explicitly told "You weren't there at the time, so your point of view is irrelevant". Red Hat had a good phrase for this in their Open Decision Making [1] framework: affected associates may still be disappointed by an outcome, but they shouldn't be surprised by it. In this case I was surprised twice over: * a core workflow change was proposed and implemented without even being mentioned on the core-workflow mailing list * the first I heard about it on python-committers was this peremptory order to move, rather than an informational post describing the discussion that was had at the sprints, and the potential problems the proposal was aiming to solve Now, if folks working on governance PEPs want to receive feedback through a more structured forum than the python-committers mailing list offers, I think that's an entirely reasonable request, but the approach I would propose to tackle that is to add a section to PEP 8000 saying: - a cpython-governance subforum will be set up on discuss.python.org - a service account will be set up so all traffic in that subforum is mirrored to python-committers Actually posting to the discussions would require going to the forum site, but nothing would need to change if just reading them. That doesn't require changing the requirements for maintaining core commit access the way the proposal at the start of this thread does, while still avoiding the need to wrangle governance threads directly on the mailing list. Regards, Nick. [1] https://opensource.com/open-organization/resources/open-decision-framework > - ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: