From taleinat at gmail.com Tue Jul 3 05:35:47 2018 From: taleinat at gmail.com (Tal Einat) Date: Tue, 3 Jul 2018 12:35:47 +0300 Subject: [python-committers] How to Increase Triage and Code Review Activity? (was: Vote to promote Pablo Salingo Salgado as core developer) In-Reply-To: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: On Sat, Jun 16, 2018 at 1:37 AM, Eric Snow wrote: > The consequent question is how to get more people resolving open > tracker issues and giving PR reviews? Off-hand, I'm not sure. :/ > We've discussed this before and it's probably time to discuss it > again. Any ideas? In 2012 point Martin L?wis had a "5-for-1" review standing offer: anyone who reviewed five patches could get a review for a patch of their choosing. Maybe something of the sort could work? As a still-junior core-dev, having a way to get certain PRs I'd like to push be reviewed by experienced core-devs would be great. Requiring me to reduce the general review workload seems like a fair way to balance things out. Since I'm still not experienced enough for my review to carry very much weight, I'd be willing to try this on a 1-to-1 basis: review any PR or b.p.o. issue, and I'll review one of your choosing. - Tal From guido at python.org Fri Jul 6 14:49:50 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 6 Jul 2018 11:49:50 -0700 Subject: [python-committers] Please be patient Message-ID: I have been overwhelmed by the amount of feedback I've received on PEP 572. I can't possibly respond to everything, and some of the feedback just takes time. E.g. I am planning to do a revision of the PEP for clarity, but this will take some time, and I may not get to it until next week or the week after. There are also several minor TODOs in the PEP that need to be resolved. I will sort it all out, just please be patient. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sun Jul 8 03:45:43 2018 From: larry at hastings.org (Larry Hastings) Date: Sun, 8 Jul 2018 00:45:43 -0700 Subject: [python-committers] Time for 3.4.9 and 3.5.6 Message-ID: My six-month cadence means it's time for the next releases of 3.4 and 3.5.? There haven't been many changes since the last releases--two, to be exact.? These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown.? (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, and they also have no open "release blocker" or "deferred blocker" bugs.? It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I therefore propose to cut the RCs in a week and a half, and the finals two weeks later.? So: Wednesday? July 18 2018 - 3.4.9rc1 and 3.5.6rc1 Wednesday August 1 2018 - 3.4.9 final and 3.5.6 final If anybody needs more time I'm totally happy to accommodate them--you can probably have all the time you need.? I'm trying to keep to my rough six-month cadence, but honestly that's pretty arbitrary. Thanks to all of you who keep making 3.4 and 3.5 better, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Sun Jul 8 04:31:48 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Sun, 8 Jul 2018 11:31:48 +0300 Subject: [python-committers] Time for 3.4.9 and 3.5.6 In-Reply-To: References: Message-ID: 08.07.18 10:45, Larry Hastings ????: > My six-month cadence means it's time for the next releases of 3.4 and > 3.5.? There haven't been many changes since the last releases--two, to > be exact.? These two security fixes were backported to both 3.4 and 3.5: > > * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) > * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) > > 3.5 also got some doc-only changes related to the online "version > switcher" dropdown.? (They weren't backported to 3.4 because we don't > list 3.4 in the version switcher dropdown anymore.) > > > There are currently no PRs open for either 3.4 or 3.5, and they also > have no open "release blocker" or "deferred blocker" bugs.? It seems > things are pretty quiet in our two security-fixes-only branches--a good > way to be! I suggest to merge a 3.5 specific documentation fix for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were undocumented changes in 3.5, and third-party projects which implement interpreting or generating these opcodes do it incorrectly. The behavior change was subtle, simple tests will not catch it. https://bugs.python.org/issue33216 https://github.com/python/cpython/pull/6365 From larry at hastings.org Sun Jul 8 06:02:04 2018 From: larry at hastings.org (Larry Hastings) Date: Sun, 8 Jul 2018 03:02:04 -0700 Subject: [python-committers] Time for 3.4.9 and 3.5.6 In-Reply-To: References: Message-ID: On 07/08/2018 01:31 AM, Serhiy Storchaka wrote: > I suggest to merge a 3.5 specific documentation fix for > CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were > undocumented changes in 3.5, and third-party projects which implement > interpreting or generating these opcodes do it incorrectly. The > behavior change was subtle, simple tests will not catch it. > > https://bugs.python.org/issue33216 > https://github.com/python/cpython/pull/6365 I'm happy to consider documentation changes at any time.? As far as this change goes: if you look at the PR you'll see I'm the one who closed it.? While I acknowledge that the current documentation is imprecise, this PR made the docs inaccurate, and therefore, worse. I'm not sure these minor documentation changes need to be discussed on python-dev.? Perhaps you can take future comments back to bpo and GitHub? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Sun Jul 8 12:44:09 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Sun, 8 Jul 2018 19:44:09 +0300 Subject: [python-committers] Time for 3.4.9 and 3.5.6 In-Reply-To: References: Message-ID: 08.07.18 13:02, Larry Hastings ????: > On 07/08/2018 01:31 AM, Serhiy Storchaka wrote: >> I suggest to merge a 3.5 specific documentation fix for >> CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were >> undocumented changes in 3.5, and third-party projects which implement >> interpreting or generating these opcodes do it incorrectly. The >> behavior change was subtle, simple tests will not catch it. >> >> https://bugs.python.org/issue33216 >> https://github.com/python/cpython/pull/6365 > > I'm happy to consider documentation changes at any time.? As far as this > change goes: if you look at the PR you'll see I'm the one who closed > it.? While I acknowledge that the current documentation is imprecise, > this PR made the docs inaccurate, and therefore, worse. The current documentation is not just imprecise, it is wrong. My English is so bad that I don't understand what is wrong with the proposed PR. To me, it adds correct information. Would be nice if you or other native English speaker suggest better wording. This is not a minor documentation change, this is a fix of a single official documentation about CPython bytecode. I'm sorry for reminding about this issue. I thought you forgot about it. This issue was open for 3.5 and marked as "release blocker", but you have not mentioned it. From antoine at python.org Sun Jul 8 12:49:31 2018 From: antoine at python.org (Antoine Pitrou) Date: Sun, 8 Jul 2018 18:49:31 +0200 Subject: [python-committers] Time for 3.4.9 and 3.5.6 In-Reply-To: References: Message-ID: <547c2db8-1091-e123-62a6-fa2a43b9a71c@python.org> OTOH, we're talking about a doc fix for a very old version. Surely people who rely on the documented opcodes there have already fixed their software to deal with the discrepancy. Regards Antoine. Le 08/07/2018 ? 18:44, Serhiy Storchaka a ?crit?: > 08.07.18 13:02, Larry Hastings ????: >> On 07/08/2018 01:31 AM, Serhiy Storchaka wrote: >>> I suggest to merge a 3.5 specific documentation fix for >>> CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were >>> undocumented changes in 3.5, and third-party projects which implement >>> interpreting or generating these opcodes do it incorrectly. The >>> behavior change was subtle, simple tests will not catch it. >>> >>> https://bugs.python.org/issue33216 >>> https://github.com/python/cpython/pull/6365 >> >> I'm happy to consider documentation changes at any time.? As far as this >> change goes: if you look at the PR you'll see I'm the one who closed >> it.? While I acknowledge that the current documentation is imprecise, >> this PR made the docs inaccurate, and therefore, worse. > > The current documentation is not just imprecise, it is wrong. My English > is so bad that I don't understand what is wrong with the proposed PR. To > me, it adds correct information. Would be nice if you or other native > English speaker suggest better wording. This is not a minor > documentation change, this is a fix of a single official documentation > about CPython bytecode. > > I'm sorry for reminding about this issue. I thought you forgot about it. > This issue was open for 3.5 and marked as "release blocker", but you > have not mentioned it. > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > From mariatta.wijaya at gmail.com Wed Jul 11 12:25:57 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 11 Jul 2018 09:25:57 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> Message-ID: Sorry to bring up this old topic. I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok? Mariatta On Thu, Jun 28, 2018 at 4:34 AM Antoine Pitrou wrote: > > Le 28/06/2018 ? 13:04, Victor Stinner a ?crit : > > It seems like the PEP 572 discussions restarted on python-dev mailing > > list with more than 100 emails in one week. > > > > Stupid idea: we created a mailing list just to fix os.random(): PEP > > 522 and PEP 524, whereas these discussions were not the ones with the > > most emails. Why not creating a new pep572 mailing list for the ones > > who don't want to follow PEP 572 discussions? > > PEP 572 is a language-wide change. Presumably those who don't want to > follow discussions will still want to give their opinion (or informal > vote) at the end. Which will give rise to other discussions... > > What strikes me is that we have such long-lasting and intense discussion > about a feature which, whether approved or not, will not significantly > change Python's popularity or appeal or ability to solve real-world > problems. > > Perhaps this is a case where ? Nature abhors a vacuum ? : we're getting > focussed on whatever comes up to fill the narrative of Python's evolution. > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Wed Jul 11 13:31:25 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 11 Jul 2018 10:31:25 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> Message-ID: <5B463EED.7010409@stoneleaf.us> On 07/11/2018 09:25 AM, Mariatta Wijaya wrote: > Sorry to bring up this old topic. > > I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) > Are we all still content with posting to python-dev? > I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new > #pep581 stream. > Will that be ok? I think this will be a good test of Zulip, as well as incentive for folks to join. -- ~Ethan~ From brett at python.org Wed Jul 11 13:35:00 2018 From: brett at python.org (Brett Cannon) Date: Wed, 11 Jul 2018 10:35:00 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <5B463EED.7010409@stoneleaf.us> References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> <5B463EED.7010409@stoneleaf.us> Message-ID: On Wed, 11 Jul 2018 at 10:31 Ethan Furman wrote: > On 07/11/2018 09:25 AM, Mariatta Wijaya wrote: > > > Sorry to bring up this old topic. > > > > I'm trying to decide how to handle discussions for PEP 581, and I'm open > to try out new things :) > > Are we all still content with posting to python-dev? > > I was thinking in addition to a thread in python-dev, I want to allow > discussions to take place in zulip, under a new > > #pep581 stream. > > Will that be ok? > > I think this will be a good test of Zulip, as well as incentive for folks > to join. > Fine by me as well since we won't know if it will work until we try it. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Wed Jul 11 13:38:13 2018 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Jul 2018 10:38:13 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <5B463EED.7010409@stoneleaf.us> References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> <5B463EED.7010409@stoneleaf.us> Message-ID: I like the Zulip idea, though it'll be hard to get permalinks to past discussions. Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl). On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman wrote: > On 07/11/2018 09:25 AM, Mariatta Wijaya wrote: > > Sorry to bring up this old topic. >> >> I'm trying to decide how to handle discussions for PEP 581, and I'm open >> to try out new things :) >> Are we all still content with posting to python-dev? >> I was thinking in addition to a thread in python-dev, I want to allow >> discussions to take place in zulip, under a new >> #pep581 stream. >> Will that be ok? >> > > I think this will be a good test of Zulip, as well as incentive for folks > to join. > > -- > ~Ethan~ > > > _______________________________________________ > 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 mariatta.wijaya at gmail.com Wed Jul 11 14:22:28 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 11 Jul 2018 11:22:28 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> <5B463EED.7010409@stoneleaf.us> Message-ID: For permalink in zulip, the link from "Copy link to conversation" seems to be sufficient. I've created a stream ( https://python.zulipchat.com/#narrow/stream/130206-.23pep581/subject/hello/near/129486993) but it now has double ## ? and it seems I can't rename it to remove the extra "#" I've been waiting for the "excitement" surrounding PEP 572 to cool down before I want to merge PEP 581 (https://github.com/python/peps/pull/681/) I was hoping to bypass python-ideas since we've discussed at Python Language Summit :) but if really needed I can start a thread there. Mariatta On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum wrote: > I like the Zulip idea, though it'll be hard to get permalinks to past > discussions. > > Also, before going to python-dev it should probably be battle-tested in > python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, > and I'm still recovering from the resulting brawl). > > On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman wrote: > >> On 07/11/2018 09:25 AM, Mariatta Wijaya wrote: >> >> Sorry to bring up this old topic. >>> >>> I'm trying to decide how to handle discussions for PEP 581, and I'm open >>> to try out new things :) >>> Are we all still content with posting to python-dev? >>> I was thinking in addition to a thread in python-dev, I want to allow >>> discussions to take place in zulip, under a new >>> #pep581 stream. >>> Will that be ok? >>> >> >> I think this will be a good test of Zulip, as well as incentive for folks >> to join. >> >> -- >> ~Ethan~ >> >> >> _______________________________________________ >> 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) > _______________________________________________ > 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 Wed Jul 11 14:46:09 2018 From: brett at python.org (Brett Cannon) Date: Wed, 11 Jul 2018 11:46:09 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> <5B463EED.7010409@stoneleaf.us> Message-ID: I just renamed the stream so there's now just a single #. :) On Wed, 11 Jul 2018 at 11:22 Mariatta Wijaya wrote: > > For permalink in zulip, the link from "Copy link to conversation" seems to > be sufficient. > I've created a stream ( > https://python.zulipchat.com/#narrow/stream/130206-.23pep581/subject/hello/near/129486993) > but it now has double ## ? and it seems I can't rename it to remove the > extra "#" > > I've been waiting for the "excitement" surrounding PEP 572 to cool down > before I want to merge PEP 581 (https://github.com/python/peps/pull/681/) > > I was hoping to bypass python-ideas since we've discussed at Python > Language Summit :) but if really needed I can start a thread there. > > Mariatta > > > On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum > wrote: > >> I like the Zulip idea, though it'll be hard to get permalinks to past >> discussions. >> >> Also, before going to python-dev it should probably be battle-tested in >> python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, >> and I'm still recovering from the resulting brawl). >> >> On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman >> wrote: >> >>> On 07/11/2018 09:25 AM, Mariatta Wijaya wrote: >>> >>> Sorry to bring up this old topic. >>>> >>>> I'm trying to decide how to handle discussions for PEP 581, and I'm >>>> open to try out new things :) >>>> Are we all still content with posting to python-dev? >>>> I was thinking in addition to a thread in python-dev, I want to allow >>>> discussions to take place in zulip, under a new >>>> #pep581 stream. >>>> Will that be ok? >>>> >>> >>> I think this will be a good test of Zulip, as well as incentive for >>> folks to join. >>> >>> -- >>> ~Ethan~ >>> >>> >>> _______________________________________________ >>> 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) >> _______________________________________________ >> 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 guido at python.org Wed Jul 11 14:53:56 2018 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Jul 2018 11:53:56 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org> <5B463EED.7010409@stoneleaf.us> Message-ID: On Wed, Jul 11, 2018 at 11:22 AM, Mariatta Wijaya wrote: > > For permalink in zulip, the link from "Copy link to conversation" seems to > be sufficient. > I've created a stream (https://python.zulipchat.com/ > #narrow/stream/130206-.23pep581/subject/hello/near/129486993) but it now > has double ## ? and it seems I can't rename it to remove the extra "#" > > I've been waiting for the "excitement" surrounding PEP 572 to cool down > before I want to merge PEP 581 (https://github.com/python/peps/pull/681/) > I'm posting the acceptance later today. > I was hoping to bypass python-ideas since we've discussed at Python > Language Summit :) but if really needed I can start a thread there. > >From my reading of the summit, most people were okay with exploring this, but many had specific issues they thought needed to be researched and addressed in the PEP. And many core devs (the majority, actually, depending on how you count :-) were not at the summit. I guess since it's mostly the core devs that need to be convinced, announcing the Zulip channel here is good enough, unless we hear from people for whom Zulip doesn't work at all. So if you don't want to go to python-ideas, you have my blessing. > Mariatta > > > On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum > wrote: > >> I like the Zulip idea, though it'll be hard to get permalinks to past >> discussions. >> >> Also, before going to python-dev it should probably be battle-tested in >> python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, >> and I'm still recovering from the resulting brawl). >> >> On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman >> wrote: >> >>> On 07/11/2018 09:25 AM, Mariatta Wijaya wrote: >>> >>> Sorry to bring up this old topic. >>>> >>>> I'm trying to decide how to handle discussions for PEP 581, and I'm >>>> open to try out new things :) >>>> Are we all still content with posting to python-dev? >>>> I was thinking in addition to a thread in python-dev, I want to allow >>>> discussions to take place in zulip, under a new >>>> #pep581 stream. >>>> Will that be ok? >>>> >>> >>> I think this will be a good test of Zulip, as well as incentive for >>> folks to join. >>> >>> -- >>> ~Ethan~ >>> >>> >>> _______________________________________________ >>> 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) >> _______________________________________________ >> 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 guido at python.org Thu Jul 12 10:57:35 2018 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Jul 2018 07:57:35 -0700 Subject: [python-committers] Transfer of power Message-ID: Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions. I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.) I am not going to appoint a successor. So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation? I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been. The decisions that most matter are probably - How are PEPs decided - How are new core devs inducted We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves. Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC). Finally. A reminder that the archives of this list are public ( https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs). I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at python.org Thu Jul 12 11:55:41 2018 From: christian at python.org (Christian Heimes) Date: Thu, 12 Jul 2018 17:55:41 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> On 2018-07-12 16:57, Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for > a PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll > still be there for a while as an ordinary core dev, and I'll still be > available to mentor people -- possibly more available. But I'm basically > giving myself a permanent vacation from being BDFL, and you all will be > on your own. > > After all that's eventually going to happen regardless -- there's still > that bus lurking around the corner, and I'm not getting younger... (I'll > spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? Thanks for being our beloved BDFL for so many years! The mail doesn't come to an suprise, although I didn't think it would hit my inbox this year or next year. I've been pondering about possible succession for you for a while. In my opinion we need some trusted entity to have final say. Otherwise we are going to waste^H^H^H^H^H spend too much time in bike shedding. But I don't see one clear person to take your place as BDFL. How about a form of presbyterian polity in the form of a triumvirate or quintumvirate? (For those with a lucky childhood that didn't involve Latin and Greek: ruling of elders with three or five powerful individuals). It would spread the load and responsibilities between multiple core devs. I would consider (in alphabetical order) Barry, Brett, Mariatta, Mark, Nick, or Victor as potential members. Each persons has been a core dev for a long time and would brings a unique perspective into the quintumvirate. For example Mark Shannon has an academic background in language design. Regards, Christian From vstinner at redhat.com Thu Jul 12 11:55:25 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 12 Jul 2018 17:55:25 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: Hi, 2018-07-12 16:57 GMT+02:00 Guido van Rossum : > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. Thank you for having solved the long standing issue of the PEP 572: taking a decision was the only way to stop the flood of emails on mailing lists (python-dev for the latest one)! I'm sure that it was super hard and painful to take a decision on the PEP, especially the most unpopular decision... approving it! I'm not sure how it happened, but I started to like the new syntax :-) > I would like to remove myself entirely from the decision process. I'll still > be there for a while as an ordinary core dev, and I'll still be available to > mentor people -- possibly more available. But I'm basically giving myself a > permanent vacation from being BDFL, and you all will be on your own. Wow! That's huge! One day, Larry Hastings told me that Python is your project ("toy"? I don't recall), but sometimes you let us to play with it :-) Thank you for having let us to play with it! Thank you for your 25 years of service as a BDFL! > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted For PEPs, I already told you in private about the PHP process to take a decision on a RFC: vote where the majority wins. I like that. The vote is reserved to core developers. I would like to experiment that in Python. I expect that only some core developers would vote depending on the PEP, since we are no experts in everything. For example, I'm not following anything about distutils and I'm happy that Nick Coghlan and now Paul Moore handle these PEPs! https://twitter.com/ncoghlan_dev/status/1015420826177265665 Nick Coghlan?: "End of an era: after ~5 years, I decided that it's time to hand over the responsibilities of default Python packaging interoperability PEP approval. Paul Moore has graciously agreed to take on that task: https://mail.python.org/mm3/archives/list/distutils-sig at python.org/thread/QT7SKORCF6OKWO3OVP5KO6XNGU2AR6TU/ " I'm not sure what to do in case of equal number of votes. Maybe we need a dictator per PEP. Or at least per area of the code :-) We already have kind of experts per area. > I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. A well deserved break ;-) Victor From antoine at python.org Thu Jul 12 12:14:27 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 12 Jul 2018 18:14:27 +0200 Subject: [python-committers] Transfer of power In-Reply-To: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> References: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> Message-ID: <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org> I think it would be worth studying the governance structure (*) of a bunch of open source projects picked according to a set of criteria: - major project in # of users and contributors - non BDFL-governed - mostly volunteer-driven - with an established decision process for major enhancements (*) (e.g. as an informational PEP) Regards Antoine. Le 12/07/2018 ? 17:55, Christian Heimes a ?crit?: > On 2018-07-12 16:57, Guido van Rossum wrote: >> Now that PEP 572 is done, I don't ever want to have to fight so hard for >> a PEP and find that so many people despise my decisions. >> >> I would like to remove myself entirely from the decision process. I'll >> still be there for a while as an ordinary core dev, and I'll still be >> available to mentor people -- possibly more available. But I'm basically >> giving myself a permanent vacation from being BDFL, and you all will be >> on your own. >> >> After all that's eventually going to happen regardless -- there's still >> that bus lurking around the corner, and I'm not getting younger... (I'll >> spare you the list of medical issues.) >> >> I am not going to appoint a successor. >> >> So what are you all going to do? Create a democracy? Anarchy? A >> dictatorship? A federation? > > Thanks for being our beloved BDFL for so many years! > > The mail doesn't come to an suprise, although I didn't think it would > hit my inbox this year or next year. I've been pondering about possible > succession for you for a while. In my opinion we need some trusted > entity to have final say. Otherwise we are going to waste^H^H^H^H^H > spend too much time in bike shedding. But I don't see one clear person > to take your place as BDFL. > > How about a form of presbyterian polity in the form of a triumvirate or > quintumvirate? (For those with a lucky childhood that didn't involve > Latin and Greek: ruling of elders with three or five powerful > individuals). It would spread the load and responsibilities between > multiple core devs. > > I would consider (in alphabetical order) Barry, Brett, Mariatta, Mark, > Nick, or Victor as potential members. Each persons has been a core dev > for a long time and would brings a unique perspective into the > quintumvirate. For example Mark Shannon has an academic background in > language design. > > Regards, > Christian > _______________________________________________ > 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 hs at ox.cx Thu Jul 12 12:15:04 2018 From: hs at ox.cx (Hynek Schlawack) Date: Thu, 12 Jul 2018 18:15:04 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <5A72857F-8588-4BCF-BA30-B9BC83737FEC@ox.cx> Guido, > I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. Since you only announced it here so far, this also seems the only proper place to thank you for 27 years of service?and Python of course. :) > So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves. I believe none of us is an expert in *this* kind of problems so I?m positive it would be beneficial to a) look what others did and process it into a PEP(?), b) possibly even involve someone external who *is* an expert like PyCon US did with their CoC, and most importantly c) never, ever quote works of ESR. Enjoy your break! ?h From mark at hotpy.org Thu Jul 12 12:17:17 2018 From: mark at hotpy.org (Mark Shannon) Date: Thu, 12 Jul 2018 17:17:17 +0100 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On 12/07/18 15:57, Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for > a PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll > still be there for a while as an ordinary core dev, and I'll still be > available to mentor people -- possibly more available. But I'm basically > giving myself a permanent vacation from being BDFL, and you all will be > on your own. Thanks for all your work. You should be very proud of all you have achieved. I expect I am not alone on this list in saying that Python has changed my life, and mostly for the better :) > > After all that's eventually going to happen regardless -- there's still > that bus lurking around the corner, and I'm not getting younger... (I'll > spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or > on GitHub. Very rarely I get asked for an opinion, and usually it's not > actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe > those PEPs will form a kind of constitution). But here's the catch. I'm > going to try and let you all (the current committers) figure it out for > yourselves. > > Note that there's still the CoC -- if you don't like that document your > only option might be to leave this group voluntarily. Perhaps there are > issues to decide like when should someone be kicked out (this could be > banning people from python-dev or python-ideas too, since those are also > covered by the CoC). > > Finally. A reminder that the archives of this list are public > (https://mail.python.org/pipermail/python-committers/) although > membership is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out > for yourselves. I'm tired, and need a very long break. Enjoy your break. You deserve it. Cheers, Mark. From mark at hotpy.org Thu Jul 12 12:19:12 2018 From: mark at hotpy.org (Mark Shannon) Date: Thu, 12 Jul 2018 17:19:12 +0100 Subject: [python-committers] Transfer of power In-Reply-To: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> References: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> Message-ID: On 12/07/18 16:55, Christian Heimes wrote: > On 2018-07-12 16:57, Guido van Rossum wrote: >> Now that PEP 572 is done, I don't ever want to have to fight so hard for >> a PEP and find that so many people despise my decisions. >> >> I would like to remove myself entirely from the decision process. I'll >> still be there for a while as an ordinary core dev, and I'll still be >> available to mentor people -- possibly more available. But I'm basically >> giving myself a permanent vacation from being BDFL, and you all will be >> on your own. >> >> After all that's eventually going to happen regardless -- there's still >> that bus lurking around the corner, and I'm not getting younger... (I'll >> spare you the list of medical issues.) >> >> I am not going to appoint a successor. >> >> So what are you all going to do? Create a democracy? Anarchy? A >> dictatorship? A federation? > > Thanks for being our beloved BDFL for so many years! > > The mail doesn't come to an suprise, although I didn't think it would > hit my inbox this year or next year. I've been pondering about possible > succession for you for a while. In my opinion we need some trusted > entity to have final say. Otherwise we are going to waste^H^H^H^H^H > spend too much time in bike shedding. But I don't see one clear person > to take your place as BDFL. > > How about a form of presbyterian polity in the form of a triumvirate or > quintumvirate? (For those with a lucky childhood that didn't involve > Latin and Greek: ruling of elders with three or five powerful > individuals). It would spread the load and responsibilities between > multiple core devs. > > I would consider (in alphabetical order) Barry, Brett, Mariatta, Mark, > Nick, or Victor as potential members. Each persons has been a core dev > for a long time and would brings a unique perspective into the > quintumvirate. For example Mark Shannon has an academic background in > language design. Language *implementation* not design. It is much less controversial :) Thanks for your vote of confidence, but I think there are plenty of others better qualified. Cheers, Mark. From brett at python.org Thu Jul 12 12:48:47 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 09:48:47 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 07:58 Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll > still be there for a while as an ordinary core dev, and I'll still be > available to mentor people -- possibly more available. But I'm basically > giving myself a permanent vacation from being BDFL, and you all will be on > your own. > Like Christian, I was hoping we had a couple more years of your direct guidance, but I understand how the PEP 572 situation accelerated things. :( > > After all that's eventually going to happen regardless -- there's still > that bus lurking around the corner, and I'm not getting younger... (I'll > spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on > GitHub. Very rarely I get asked for an opinion, and usually it's not > actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those > PEPs will form a kind of constitution). But here's the catch. I'm going to > try and let you all (the current committers) figure it out for yourselves. > At this point I've seen proposed: - Christian's proposal for a triumvirate (and thanks for the vote of confidence, Christian, to be on said cabal/committee :) - Victor's proposal of voting for every PEP - Do essentially a literary review of how other projects handle this For me, I think a key asset that Guido has provided for us as a BDFL is consistency in design/taste. Design by committee through voting does not appeal to me at all as that can too easily lead to shifts in preferences and not have the nice cohesion we have with the language's overall design, especially considering that there will always be subjective choices to make (someone has to eventually choose the colour of the shed). People, including me, have also pointed out that by having Guido to look up to you we have had a very consistent view of how the community should behave and that too has been an asset. IOW I don't like Victor's proposal. ;) What that means is I think we should either have another BDFL or go with Christian's triumvirate suggestion in the name of general consistency and guidance (and I personally don't like the four-person suggestion simply because you can't break ties). There's also no objective way to choose any of this unfortunately, so I suspect this is going to be based on gut feel of what we think will work for a couple of decades (using the word "experiment" with our design governance model scares me since we are not talking about little decisions here like whether to backport a fix). If people still want to put into the time to research other approaches I can understand that I will personally listen with an open mind, but based on my personal reflections on this topic over the years in preparation of having to eventually deal with this inevitability, my choice is dictator or triumvirate. > > Note that there's still the CoC -- if you don't like that document your > only option might be to leave this group voluntarily. Perhaps there are > issues to decide like when should someone be kicked out (this could be > banning people from python-dev or python-ideas too, since those are also > covered by the CoC). > I joined the PSF's CoC committee in hopes of coming up with a proposal by the end of the year for fleshing out details of enforcement, etc., so my hope is this will eventually get resolved. -Brett > > Finally. A reminder that the archives of this list are public ( > https://mail.python.org/pipermail/python-committers/) although membership > is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. > > -- > --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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at sweetapp.com Thu Jul 12 12:53:55 2018 From: brian at sweetapp.com (Brian Quinlan) Date: Thu, 12 Jul 2018 09:53:55 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll > still be there for a while as an ordinary core dev, and I'll still be > available to mentor people -- possibly more available. But I'm basically > giving myself a permanent vacation from being BDFL, and you all will be on > your own. > Hey Guido, Thank you so much for creating Python and nurturing it for the last 25+ years. I, and many others on the list, have built our careers around Python and we own you a huge amount of gratitude. So thank you very much and I hope that your retirement goes better than it does for most dictators ;-) Cheers, Brian > > After all that's eventually going to happen regardless -- there's still > that bus lurking around the corner, and I'm not getting younger... (I'll > spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on > GitHub. Very rarely I get asked for an opinion, and usually it's not > actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those > PEPs will form a kind of constitution). But here's the catch. I'm going to > try and let you all (the current committers) figure it out for yourselves. > > Note that there's still the CoC -- if you don't like that document your > only option might be to leave this group voluntarily. Perhaps there are > issues to decide like when should someone be kicked out (this could be > banning people from python-dev or python-ideas too, since those are also > covered by the CoC). > > Finally. A reminder that the archives of this list are public ( > https://mail.python.org/pipermail/python-committers/) although membership > is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. > > -- > --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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Thu Jul 12 12:54:57 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 12 Jul 2018 12:54:57 -0400 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: Thank you, Guido. This is a sad day for me personally; I really hoped you'd lead Python for a few more years. On the other hand, Python is in good hands, you've built a large enough and diverse community around it! As for the new governing model, I imagine that we don't need to make any decisions *right now*. As Victor suggested, core devs can simply count +1/-1 on any language feature and we'll see how it goes. Or maybe the first such vote should be on the new governing model? :) I really hope that we won't have an excruciating debate on the mailing list about the governing model though; maybe we can discuss it on the upcoming core dev sprint. Yury On Thu, Jul 12, 2018 at 10:58 AM Guido van Rossum wrote: > > Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. > > After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves. > > Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC). > > Finally. A reminder that the archives of this list are public (https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break. > > -- > --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/ -- Yury From jdhardy at gmail.com Thu Jul 12 12:58:09 2018 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 12 Jul 2018 09:58:09 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 7:57 AM, Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll still > be there for a while as an ordinary core dev, and I'll still be available to > mentor people -- possibly more available. But I'm basically giving myself a > permanent vacation from being BDFL, and you all will be on your own. > > After all that's eventually going to happen regardless -- there's still that > bus lurking around the corner, and I'm not getting younger... (I'll spare > you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on > GitHub. Very rarely I get asked for an opinion, and usually it's not > actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those > PEPs will form a kind of constitution). But here's the catch. I'm going to > try and let you all (the current committers) figure it out for yourselves. > > Note that there's still the CoC -- if you don't like that document your only > option might be to leave this group voluntarily. Perhaps there are issues to > decide like when should someone be kicked out (this could be banning people > from python-dev or python-ideas too, since those are also covered by the > CoC). > > Finally. A reminder that the archives of this list are public > (https://mail.python.org/pipermail/python-committers/) although membership > is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. Thank you, Guido, for everything that you're done, and enjoy your well-deserved rest. - Jeff From antoine at python.org Thu Jul 12 12:58:19 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 12 Jul 2018 18:58:19 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: I'd like to point out that the N-virate idea doesn't handle a key issue: once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel there's a perpetual category they're locked out of)? Do you just wait for people to gently step down when required? One key point about Guido is that not only he's the founder of the project, but he's been consistently be there all the time, with almost no interruptions. I don't think any of us can claim such an uninterrupted presence, neither in the past, nor in the long future. The suggestion about studying other projects was not to do a "literary review" but simply to look at what works well for other projects. Regards Antoine. Le 12/07/2018 ? 18:48, Brett Cannon a ?crit?: > > > On Thu, 12 Jul 2018 at 07:58 Guido van Rossum > wrote: > > Now that PEP 572 is done, I don't ever want to have to fight so hard > for a PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. > I'll still be there for a while as an ordinary core dev, and I'll > still be available to mentor people -- possibly more available. But > I'm basically giving myself a permanent vacation from being BDFL, > and you all will be on your own. > > > Like Christian, I was hoping we had a couple more years of your direct > guidance, but I understand how the PEP 572 situation accelerated things. :( > ? > > > After all that's eventually going to happen regardless -- there's > still that bus lurking around the corner, and I'm not getting > younger... (I'll spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker > or on GitHub. Very rarely I get asked for an opinion, and usually > it's not actually important. So this can just be dealt with as it > has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe > those PEPs will form a kind of constitution). But here's the catch. > I'm going to try and let you all (the current committers) figure it > out for yourselves. > > > At this point I've seen proposed: > > - Christian's proposal for a triumvirate (and thanks for the vote of > confidence, Christian, to be on said cabal/committee :) > - Victor's proposal of voting for every PEP > - Do essentially a literary review of how other projects handle this > > For me, I think a key asset that Guido has provided for us as a BDFL is > consistency in design/taste. Design by committee through voting does not > appeal to me at all as that can too easily lead to shifts in preferences > and not have the nice cohesion we have with the language's overall > design, especially considering that there will always be subjective > choices to make (someone has to eventually choose the colour of the > shed). People, including me, have also pointed out that by having Guido > to look up to you we have had a very consistent view of how the > community should behave and that too has been an asset. IOW I don't like > Victor's proposal. ;) > > What that means is I think we should either have another BDFL or go with > Christian's triumvirate suggestion in the name of general consistency > and guidance (and I personally don't like the four-person suggestion > simply because you can't break ties). > > There's also no objective way to choose any of this unfortunately, so I > suspect this is going to be based on gut feel of what we think will work > for a couple of decades (using the word "experiment" with our design > governance model scares me since we are not talking about little > decisions here like whether to backport a fix). If people still want to > put into the time to research other approaches I can understand that I > will personally listen with an open mind, but based on my personal > reflections on this topic over the years in preparation of having to > eventually deal with this inevitability, my choice is dictator or > triumvirate. > ? > > > Note that there's still the CoC -- if you don't like that document > your only option might be to leave this group voluntarily. Perhaps > there are issues to decide like when should someone be kicked out > (this could be banning people from python-dev or python-ideas too, > since those are also covered by the CoC). > > > I joined the PSF's CoC committee in hopes of coming up with a proposal > by the end of the year for fleshing out details of enforcement, etc., so > my hope is this will eventually get resolved. > > -Brett > ? > > > Finally. A reminder that the archives of this list are public > (https://mail.python.org/pipermail/python-committers/) although > membership is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something > out for yourselves. I'm tired, and need a very long break. > > -- > --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/ > > > > _______________________________________________ > 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 Thu Jul 12 13:12:38 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Thu, 12 Jul 2018 10:12:38 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: Guido, Thank you for all you've done for Python. It is well deserved break. I'm sad, but I like to see this as an opportunity to further improve Python and this community. My first instinct is to suggest: instead of one successor, we will have several people as the new "leaders", perhaps a co-BDFL, or even 3-5 people as co-BDFLs/leaders. This is based on my experience with organizing meetup and conference (although these are not comparable to leading the community like Python). The benefit is to lessen the burden and responsibilities of one person, and they will have backups when they need to go on a break, vacation, take care of personal life. Another thing that came to my mind is, who is actually able (have the time and energy) to take on this role? Most of us in open source are volunteering on limited free time available. I'm aware some of you have employer support, but most don't. Will this limit the candidacy to certain people just because they have the employer support? What is the role of the successor(s)? Do we assume "whatever Guido did", or is this an opportunity to come up with a new process? One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8 The slides: https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf Some ideas from that talk: 1. identify critical roles (e.g. PEP decision making) 2. refactor large roles 3. mentor the new successor, shadow the previous leader 4. document all the things This might be selfish request, but I hope you can still assume power until we have new successor(s). Thanks. Mariatta On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll > still be there for a while as an ordinary core dev, and I'll still be > available to mentor people -- possibly more available. But I'm basically > giving myself a permanent vacation from being BDFL, and you all will be on > your own. > > After all that's eventually going to happen regardless -- there's still > that bus lurking around the corner, and I'm not getting younger... (I'll > spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on > GitHub. Very rarely I get asked for an opinion, and usually it's not > actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those > PEPs will form a kind of constitution). But here's the catch. I'm going to > try and let you all (the current committers) figure it out for yourselves. > > Note that there's still the CoC -- if you don't like that document your > only option might be to leave this group voluntarily. Perhaps there are > issues to decide like when should someone be kicked out (this could be > banning people from python-dev or python-ideas too, since those are also > covered by the CoC). > > Finally. A reminder that the archives of this list are public ( > https://mail.python.org/pipermail/python-committers/) although membership > is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. > > -- > --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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Thu Jul 12 13:12:52 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 12 Jul 2018 10:12:52 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <90e71d08-3ccf-5905-2457-13587533c5d4@python.org> On 12Jul2018 0958, Antoine Pitrou wrote: > > I'd like to point out that the N-virate idea doesn't handle a key issue: > once you have a N-virate, how do you evolve its composition according to > the implication and motivation of its members - but also to remarks or > frustation by non-virate contributors (especially new contributors who > will feel there's a perpetual category they're locked out of)? Do you > just wait for people to gently step down when required? One of the important things we will have to do is define the scope of any long-term appointees. For example, saying "we have an N-virate that decides on PEPs" is very different from saying "we have an N-virate that decides on the PEP approver (formerly BDFL-delegates)". The latter does not necessarily lock anyone out from being a critical part of Python's future, but it does avoid endless arguments about selecting who is responsible with deciding. I'm honestly not very sympathetic towards "locking out" new contributors from literally leading a project. As you say below, few of us can claim as long and as uninterrupted a presence in this project as Guido, but many of us can certainly claim more "right" to a say than some random person who probably ought to build a few of their own languages before deeming themselves worthy to significantly influence a well established one. > One key point about Guido is that not only he's the founder of the > project, but he's been consistently be there all the time, with almost > no interruptions. I don't think any of us can claim such an > uninterrupted presence, neither in the past, nor in the long future. This is the main reason for having more than one person be on the critical path for significant changes. It is easier to replace 33% of a group without losing continuity than to replace 100%. For me, I would like the release manager to also take on some of the responsibility for new features in their releases. Perhaps holding one position in an N-virate for the current RM (who continue rotating every two releases) is a good way to keep things fresh? Cheers, Steve From raymond.hettinger at gmail.com Thu Jul 12 13:18:28 2018 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Thu, 12 Jul 2018 19:18:28 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <8335669F-EF8C-4AE1-9A51-3D01D81C7F18@gmail.com> > On Jul 12, 2018, at 4:57 PM, Guido van Rossum wrote: > > I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. Sorry the PEP process was so painful. I hope your decision to have a permanent vacation will lift a great weight from your shoulders and that you will derive more joy from just being a far from ordinary core dev. Raymond From yselivanov.ml at gmail.com Thu Jul 12 13:29:21 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 12 Jul 2018 13:29:21 -0400 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou wrote: > > > I'd like to point out that the N-virate idea doesn't handle a key issue: > once you have a N-virate, how do you evolve its composition according to > the implication and motivation of its members - but also to remarks or > frustation by non-virate contributors (especially new contributors who > will feel there's a perpetual category they're locked out of)? Do you > just wait for people to gently step down when required? One way would be to re-elect them every 5 or so years. Essentially, an N-virate is a dictator-like entity for a few years. Yury From ericsnowcurrently at gmail.com Thu Jul 12 13:41:52 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Thu, 12 Jul 2018 11:41:52 -0600 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov wrote: > > Thank you, Guido. This is a sad day for me personally; I really hoped > you'd lead Python for a few more years. On the other hand, Python is > in good hands, you've built a large enough and diverse community > around it! +1 Thank you for putting so much time, effort, and care into both the language and its community! We cannot thank you enough. > As for the new governing model, I imagine that we don't need to make > any decisions *right now*. As Victor suggested, core devs can simply > count +1/-1 on any language feature and we'll see how it goes. Or > maybe the first such vote should be on the new governing model? :) I > really hope that we won't have an excruciating debate on the mailing > list about the governing model though; maybe we can discuss it on the > upcoming core dev sprint. In the short term we could appoint a *temporary* triumvirate to fill in as BDFL (with the intent to re-assess the situation in September if we haven't resolved on a permanent solution by then). That would allow us to maintain business-as-usual (and try out a triumvirate). If we go that route then I'd recommend Brett, Nick, and Barry. -eric From doug at doughellmann.com Thu Jul 12 13:49:02 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 12 Jul 2018 13:49:02 -0400 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <1531417396-sup-8296@lrrr.local> Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400: > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou wrote: > > > > > > I'd like to point out that the N-virate idea doesn't handle a key issue: > > once you have a N-virate, how do you evolve its composition according to > > the implication and motivation of its members - but also to remarks or > > frustation by non-virate contributors (especially new contributors who > > will feel there's a perpetual category they're locked out of)? Do you > > just wait for people to gently step down when required? > > One way would be to re-elect them every 5 or so years. Essentially, > an N-virate is a dictator-like entity for a few years. > > Yury We've had good luck in the OpenStack community tying leadership to release cycles. It causes elections more often (our cycles are 6 months long), but people tend to step up for several cycles in a row so that hasn't been a cause of excessive turnover. Having frequent opportunities for folks to step down gracefully when they need or want to also means no one feels like they are signing up for an indefinite time commitment. For a multi-person group, staggered elections where only a portion of the group is up for election at one time, also provides some consistency when there is turnover. Doug From brett at python.org Thu Jul 12 13:50:11 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 10:50:11 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 10:29 Yury Selivanov wrote: > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou > wrote: > > > > > > I'd like to point out that the N-virate idea doesn't handle a key issue: > > once you have a N-virate, how do you evolve its composition according to > > the implication and motivation of its members - but also to remarks or > > frustation by non-virate contributors (especially new contributors who > > will feel there's a perpetual category they're locked out of)? Do you > > just wait for people to gently step down when required? > That's what we had with Guido so I don't see why this needs to suddenly change. The BDFL role needs to not fear the "tyranny of the majority" (Alexis de Tocqueville). Otherwise we are sacrificing consistent/uniform design for design-by-committee/community. > > One way would be to re-elect them every 5 or so years. Essentially, > an N-virate is a dictator-like entity for a few years. > But that doesn't help deal with inconsistency since that just means we have consistency for 2 releases and then we start all over again. If you're suggesting someone forcibly rotates out every 5 years then that's different since that adds in some consistency thanks to the remaining two members. Remember the time scale we are talking about here. Python is 28 years old, so a 5 year scale means we would have swapped leaders 6 times at this point. Python 3.0 came out in 2008, so we're approaching 10 years, so a 5 year time scale we would not have had any consistency in just Python 3's lifetime. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Jul 12 13:55:24 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 10:55:24 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 10:42 Eric Snow wrote: > On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov > wrote: > > > > Thank you, Guido. This is a sad day for me personally; I really hoped > > you'd lead Python for a few more years. On the other hand, Python is > > in good hands, you've built a large enough and diverse community > > around it! > > +1 > > Thank you for putting so much time, effort, and care into both the > language and its community! We cannot thank you enough. > > > As for the new governing model, I imagine that we don't need to make > > any decisions *right now*. As Victor suggested, core devs can simply > > count +1/-1 on any language feature and we'll see how it goes. Or > > maybe the first such vote should be on the new governing model? :) I > > really hope that we won't have an excruciating debate on the mailing > > list about the governing model though; maybe we can discuss it on the > > upcoming core dev sprint. > > In the short term we could appoint a *temporary* triumvirate to fill > in as BDFL (with the intent to re-assess the situation in September if > we haven't resolved on a permanent solution by then). That would > allow us to maintain business-as-usual (and try out a triumvirate). > If we go that route then I'd recommend Brett, Nick, and Barry. > Thanks for the vote of confidence. :) One other idea if we go the BDFL or triumvirate route is we could ask Guido to choose (if he's willing). I think Guido's key point is he wants us to choose how we want to keep this team going, but that may not preclude us to essentially naming him BDFL-delegate in this instance. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericsnowcurrently at gmail.com Thu Jul 12 13:59:47 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Thu, 12 Jul 2018 11:59:47 -0600 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 11:55 AM Brett Cannon wrote: > One other idea if we go the BDFL or triumvirate route is we could ask Guido to choose (if he's willing). I think Guido's key point is he wants us to choose how we want to keep this team going, but that may not preclude us to essentially naming him BDFL-delegate in this instance. :) +1 -eric From nas-python at arctrix.com Thu Jul 12 13:55:40 2018 From: nas-python at arctrix.com (Neil Schemenauer) Date: Thu, 12 Jul 2018 11:55:40 -0600 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <20180712175540.fqlcsyqia6kktzvd@python.ca> On 2018-07-12, Yury Selivanov wrote: > One way would be to re-elect them every 5 or so years. Essentially, > an N-virate is a dictator-like entity for a few years. Modeling the body after a supreme court seems like a good idea. They don't have to make day-to-day decisions, only settle disputes that cannot be resolved by normal processes. Having an N-virate entity would diffuse some of the criticism they will almost certainly receive for their decisions. Having them serve for multiple years will provide more consistency of direction. Having multiple members will allow members to be replaced without too much disruption. The most important decision is what will we call this entity? ;-P I'm sure Barry will have a good idea. Is a "cabal" the correct term? Cheers, Neil From berker.peksag at gmail.com Thu Jul 12 14:02:08 2018 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Thu, 12 Jul 2018 21:02:08 +0300 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 8:41 PM, Eric Snow wrote: > Thank you for putting so much time, effort, and care into both the > language and its community! We cannot thank you enough. +1 > In the short term we could appoint a *temporary* triumvirate to fill > in as BDFL (with the intent to re-assess the situation in September if > we haven't resolved on a permanent solution by then). That would > allow us to maintain business-as-usual (and try out a triumvirate). > If we go that route then I'd recommend Brett, Nick, and Barry. I was going to recommend the same names :) --Berker From yselivanov.ml at gmail.com Thu Jul 12 14:02:27 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 12 Jul 2018 14:02:27 -0400 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon wrote: [..] >> One way would be to re-elect them every 5 or so years. Essentially, >> an N-virate is a dictator-like entity for a few years. > > > But that doesn't help deal with inconsistency since that just means we have consistency for 2 releases and then we start all over again. If you're suggesting someone forcibly rotates out every 5 years then that's different since that adds in some consistency thanks to the remaining two members. My worry is that not everybody can stick to to be with Python for a few decades like Guido. Ideally, there should be a mechanism for both leaving the N-virate and being appointed to it. Another worry -- Guido knows mostly everything about all aspects of Python design in all fields. To illustrate my point, I'm particularly worried about async/await, asyncio/trio/twisted ecosystem -- so far it seems that it's only Guido and I who've spent a huge chunk of their time maintaining (or caring about) it. We have many other critical fields besides async: general language design, packaging, scientific ecosystem, web (partially overlaps with async), performance, etc. Essentially we need to build our N-virate to have knowledgable representatives (formally known as BDFL-delegates) from all of those fields, otherwise the language can stop evolving in some important directions. IOW I don't see anyone (or some group of 3) who is as well-versed in everything on Guido's level. That can be solved if Guido agrees to join the permanent N-virate though :) Yury From brett at python.org Thu Jul 12 14:04:26 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 11:04:26 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 10:13 Mariatta Wijaya wrote: > Guido, > > Thank you for all you've done for Python. It is well deserved break. > > I'm sad, but I like to see this as an opportunity to further improve > Python and this community. > > My first instinct is to suggest: instead of one successor, we will have > several people as the new "leaders", perhaps a co-BDFL, or even 3-5 people > as co-BDFLs/leaders. > This is based on my experience with organizing meetup and conference > (although these are not comparable to leading the community like Python). > The benefit is to lessen the burden and responsibilities of one person, > and they will have backups when they need to go on a break, vacation, take > care of personal life. > > Another thing that came to my mind is, who is actually able (have the time > and energy) to take on this role? Most of us in open source are > volunteering on limited free time available. I'm aware some of you have > employer support, but most don't. Will this limit the candidacy to certain > people just because they have the employer support? > I think it will limit it to people who feel they are up for it. I'm not sure what Guido's time commitment was in the end pre-PEP 572, but outside of major PEP discussions I don't think the time commitment should be huge (and if you delegate a PEP then even less :) . So I don't think it necessitates work time, but you might want to check with your family if they are happy with your current engagement level. ;) > > What is the role of the successor(s)? Do we assume "whatever Guido did", > or is this an opportunity to come up with a new process? > That's why Guido is leaving it up to us. :) For me the key function Guido provided was tone and consistency in design. So whatever we replace Guido with should be something that will represent us in a way we are all proud to stand behind. And then from there the design consistency suggests a first line of yea/nay on PEPs and then delegation. I don't think we can just have a "delegation committee" which doesn't make initial rejections since that would then leave the over-arching design of the language unguided unless the "delegation chooser" consistently chose the same person, informally choosing a design dictator anyway. ;) > One useful resource is Vicky Brasseur's talk: Passing the Baton, > Succession planning for your project > https://www.youtube.com/watch?v=Jhkm2PA_Gf8 > The slides: > https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf > > Some ideas from that talk: > 1. identify critical roles (e.g. PEP decision making) > 2. refactor large roles > 3. mentor the new successor, shadow the previous leader > 4. document all the things > > This might be selfish request, but I hope you can still assume power until > we have new successor(s). > > Thanks. > > Mariatta > > > On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum wrote: > >> Now that PEP 572 is done, I don't ever want to have to fight so hard for >> a PEP and find that so many people despise my decisions. >> >> I would like to remove myself entirely from the decision process. I'll >> still be there for a while as an ordinary core dev, and I'll still be >> available to mentor people -- possibly more available. But I'm basically >> giving myself a permanent vacation from being BDFL, and you all will be on >> your own. >> >> After all that's eventually going to happen regardless -- there's still >> that bus lurking around the corner, and I'm not getting younger... (I'll >> spare you the list of medical issues.) >> >> I am not going to appoint a successor. >> >> So what are you all going to do? Create a democracy? Anarchy? A >> dictatorship? A federation? >> >> I'm not worried about the day to day decisions in the issue tracker or on >> GitHub. Very rarely I get asked for an opinion, and usually it's not >> actually important. So this can just be dealt with as it has always been. >> >> The decisions that most matter are probably >> - How are PEPs decided >> - How are new core devs inducted >> >> We may be able to write up processes for these things as PEPs (maybe >> those PEPs will form a kind of constitution). But here's the catch. I'm >> going to try and let you all (the current committers) figure it out for >> yourselves. >> >> Note that there's still the CoC -- if you don't like that document your >> only option might be to leave this group voluntarily. Perhaps there are >> issues to decide like when should someone be kicked out (this could be >> banning people from python-dev or python-ideas too, since those are also >> covered by the CoC). >> >> Finally. A reminder that the archives of this list are public ( >> https://mail.python.org/pipermail/python-committers/) although >> membership is closed (limited to core devs). >> >> I'll still be here, but I'm trying to let you all figure something out >> for yourselves. I'm tired, and need a very long break. >> >> -- >> --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/ >> > _______________________________________________ > 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 Jul 12 14:04:56 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 12 Jul 2018 20:04:56 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> Le 12/07/2018 ? 19:55, Brett Cannon a ?crit?: > > One other idea if we go the BDFL or triumvirate route is we could ask > Guido to choose (if he's willing). I think Guido's key point is he wants > us to choose how we want to keep this team going, but that may not > preclude us to essentially naming him BDFL-delegate in this instance. :) That might be a minority view, but I don't think anyone except Guido would be legitimate as a Python BDFL. Not even Tim or Barry ;-) Regards Antoine. From alexander.belopolsky at gmail.com Thu Jul 12 14:06:06 2018 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 12 Jul 2018 14:06:06 -0400 Subject: [python-committers] Transfer of power In-Reply-To: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> References: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> Message-ID: On Thu, Jul 12, 2018 at 2:04 PM Antoine Pitrou wrote: > > That might be a minority view, but I don't think anyone except Guido > would be legitimate as a Python BDFL. > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Jul 12 14:11:49 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 11:11:49 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 11:02 Yury Selivanov wrote: > On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon wrote: > [..] > >> One way would be to re-elect them every 5 or so years. Essentially, > >> an N-virate is a dictator-like entity for a few years. > > > > > > But that doesn't help deal with inconsistency since that just means we > have consistency for 2 releases and then we start all over again. If you're > suggesting someone forcibly rotates out every 5 years then that's different > since that adds in some consistency thanks to the remaining two members. > > My worry is that not everybody can stick to to be with Python for a > few decades like Guido. Ideally, there should be a mechanism for both > leaving the N-virate and being appointed to it. > I'm assuming that's what would be the next step if we decide this N-virate approach is agreed to. Like when you talk about every 5 years, can people stand back up and just consistently re-join, or is is 5 years and then you have to rotate out? > > Another worry -- Guido knows mostly everything about all aspects of > Python design in all fields. To illustrate my point, I'm particularly > worried about async/await, asyncio/trio/twisted ecosystem -- so far it > seems that it's only Guido and I who've spent a huge chunk of their > time maintaining (or caring about) it. We have many other critical > fields besides async: general language design, packaging, scientific > ecosystem, web (partially overlaps with async), performance, etc. > Essentially we need to build our N-virate to have knowledgable > representatives (formally known as BDFL-delegates) from all of those > fields, otherwise the language can stop evolving in some important > directions. > Yes, Guido has a unique skill set. Having said that, one would also hope that anyone chosen to do this would be up for learning a few new things. ;) This is also why Guido delegated to folks on occasion and talked to experts for opinions, something I expect people chosen to do this would > > IOW I don't see anyone (or some group of 3) who is as well-versed in > everything on Guido's level. That can be solved if Guido agrees to > join the permanent N-virate though :) > No one has suggested we haven't been extremely lucky for the past 28 years. :) I also don't think we will reach perfection in any solution anyway and this is somewhat of a "least bad" situation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Thu Jul 12 14:14:55 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 12 Jul 2018 11:14:55 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> References: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> Message-ID: On 12Jul2018 1104, Antoine Pitrou wrote: > > Le 12/07/2018 ? 19:55, Brett Cannon a ?crit?: >> >> One other idea if we go the BDFL or triumvirate route is we could ask >> Guido to choose (if he's willing). I think Guido's key point is he wants >> us to choose how we want to keep this team going, but that may not >> preclude us to essentially naming him BDFL-delegate in this instance. :) > > That might be a minority view, but I don't think anyone except Guido > would be legitimate as a Python BDFL. Not even Tim or Barry ;-) +1. If Guido had designated a successor, I'd be all for it, but I don't see any stable future if we try to select one person to fill that role. > Regards > > Antoine. From steve.dower at python.org Thu Jul 12 14:18:37 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 12 Jul 2018 11:18:37 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <9fe88c8f-16cd-0411-ff86-4720013c4456@python.org> On 12Jul2018 1102, Yury Selivanov wrote: > IOW I don't see anyone (or some group of 3) who is as well-versed in > everything on Guido's level. The actual solution is to ensure the members of the group are humble enough to admit this, and aware enough of the community to be able to identify and nominate the people who are well-versed enough for a particular subject. We should *always* be able to nominate a core committer to be the designated expert for a particular area (at least for long enough to approve a PEP). If we cannot, the problem is that we don't have anyone for that area, not that the triumvirate isn't well-versed enough themselves. Cheers, Steve From tim.peters at gmail.com Thu Jul 12 14:21:02 2018 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 12 Jul 2018 13:21:02 -0500 Subject: [python-committers] Transfer of power In-Reply-To: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> References: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> Message-ID: [Antoine Pitrou] > > That might be a minority view, but I don't think anyone except Guido > > would be legitimate as a Python BDFL. Not even Tim or Barry ;-) A majority view is probably an incorrect view anyway. If Barry had been BDFL all along, only features useful to Mailman would have gotten in ;-) If I had been, - generators would have been in the language years earlier - but `async` gimmicks still wouldn't be in - ternary `if` would not have been added (too little bang for the buck) - assignment expressions either (yup, I want them! but I wouldn't have had the guts to persevere against such intense community opposition) - etc etc etc The details don't matter. The point is that, at heart, Python is what it is because Guido is who he is. No matter what we do when he steps down, Python will change in a fundamental way. _Now_ is the time to spread FUD via republishing Stroustrup's essay on the Vasa ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Thu Jul 12 14:16:08 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 13 Jul 2018 04:16:08 +1000 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <20180712181608.GC7318@ando.pearwood.info> I'm sure I will have more (public) comments later, but for now I'd like to limit myself to one thing: On Thu, Jul 12, 2018 at 11:41:52AM -0600, Eric Snow wrote: > In the short term we could appoint a *temporary* triumvirate to fill > in as BDFL (with the intent to re-assess the situation in September if > we haven't resolved on a permanent solution by then). That would > allow us to maintain business-as-usual (and try out a triumvirate). > If we go that route then I'd recommend Brett, Nick, and Barry. https://www.python.org/dev/peps/pep-0401/ -- Steve From doug at doughellmann.com Thu Jul 12 14:22:26 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 12 Jul 2018 14:22:26 -0400 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <1531419654-sup-6867@lrrr.local> Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700: > On Thu, 12 Jul 2018 at 11:02 Yury Selivanov wrote: > > > > > IOW I don't see anyone (or some group of 3) who is as well-versed in > > everything on Guido's level. That can be solved if Guido agrees to > > join the permanent N-virate though :) > > > > No one has suggested we haven't been extremely lucky for the past 28 years. > :) I also don't think we will reach perfection in any solution anyway and > this is somewhat of a "least bad" situation. Are we looking for people who are skilled at language design, or who are skilled at building consensus through open decision-making processes? Because those are very different sorts of skills, and if this new body is intended to only be a final arbiter on decisions the former set of skills may be less important than the latter. Doug From antoine at python.org Thu Jul 12 14:27:57 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 12 Jul 2018 20:27:57 +0200 Subject: [python-committers] Transfer of power In-Reply-To: <1531419654-sup-6867@lrrr.local> References: <1531419654-sup-6867@lrrr.local> Message-ID: Le 12/07/2018 ? 20:22, Doug Hellmann a ?crit?: > Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700: >> On Thu, 12 Jul 2018 at 11:02 Yury Selivanov wrote: >> >>> >>> IOW I don't see anyone (or some group of 3) who is as well-versed in >>> everything on Guido's level. That can be solved if Guido agrees to >>> join the permanent N-virate though :) >>> >> >> No one has suggested we haven't been extremely lucky for the past 28 years. >> :) I also don't think we will reach perfection in any solution anyway and >> this is somewhat of a "least bad" situation. > > Are we looking for people who are skilled at language design, or who are > skilled at building consensus through open decision-making processes? > Because those are very different sorts of skills, and if this new body > is intended to only be a final arbiter on decisions the former set of > skills may be less important than the latter. IMHO the N-virate should primarily be responsible for delegation. Side note: I think we'll be talking less and less about language design, and instead about library and infrastructure design. Regards Antoine. From merwok at netwok.org Thu Jul 12 14:49:10 2018 From: merwok at netwok.org (=?UTF-8?Q?=c3=89ric_Araujo?=) Date: Thu, 12 Jul 2018 14:49:10 -0400 Subject: [python-committers] Transfer of power In-Reply-To: <20180712175540.fqlcsyqia6kktzvd@python.ca> References: <20180712175540.fqlcsyqia6kktzvd@python.ca> Message-ID: Hello, Le 2018-07-12 ? 13:55, Neil Schemenauer a ?crit?: > The most important decision is what will we call this entity? ;-P > I'm sure Barry will have a good idea. Is a "cabal" the correct > term? I fear the general public may not get the self-mocking humour here. A note about triumvirate: it means three men, not three people. Cheers From brett at python.org Thu Jul 12 14:50:44 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 11:50:44 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: <1531419654-sup-6867@lrrr.local> Message-ID: On Thu, 12 Jul 2018 at 11:28 Antoine Pitrou wrote: > > Le 12/07/2018 ? 20:22, Doug Hellmann a ?crit : > > Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700: > >> On Thu, 12 Jul 2018 at 11:02 Yury Selivanov > wrote: > >> > >>> > >>> IOW I don't see anyone (or some group of 3) who is as well-versed in > >>> everything on Guido's level. That can be solved if Guido agrees to > >>> join the permanent N-virate though :) > >>> > >> > >> No one has suggested we haven't been extremely lucky for the past 28 > years. > >> :) I also don't think we will reach perfection in any solution anyway > and > >> this is somewhat of a "least bad" situation. > > > > Are we looking for people who are skilled at language design, or who are > > skilled at building consensus through open decision-making processes? > > Because those are very different sorts of skills, and if this new body > > is intended to only be a final arbiter on decisions the former set of > > skills may be less important than the latter. > > IMHO the N-virate should primarily be responsible for delegation. > > Side note: I think we'll be talking less and less about language design, > and instead about library and infrastructure design. > Same here. I suspect this will make us much more conservative in accepting language changes compared to e.g. what our deprecation policy should be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at python.org Thu Jul 12 14:51:19 2018 From: christian at python.org (Christian Heimes) Date: Thu, 12 Jul 2018 20:51:19 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <8de5f476-0142-cd87-de90-0230e1f06ebf@python.org> On 2018-07-12 20:02, Yury Selivanov wrote: > Another worry -- Guido knows mostly everything about all aspects of > Python design in all fields. To illustrate my point, I'm particularly > worried about async/await, asyncio/trio/twisted ecosystem -- so far it > seems that it's only Guido and I who've spent a huge chunk of their > time maintaining (or caring about) it. We have many other critical > fields besides async: general language design, packaging, scientific > ecosystem, web (partially overlaps with async), performance, etc. > Essentially we need to build our N-virate to have knowledgable > representatives (formally known as BDFL-delegates) from all of those > fields, otherwise the language can stop evolving in some important > directions. I understand that you are worried. But you don't have to be member of an hypothetical N-virate in order to stir asyncio into the future. I assumme that the trusted and wise members of the N-virate will recognize you as domain expert for asyncio and listen to your advise. We already have the concept of BDFL delegate for PEPs and should adapt the idea. As Brett pointed out in one of his replies, N-virate should guarantee long-term stability and consistency of the language. It's not the job of the N-virate to control every little details. I envision the gremium a bit like SCOTUS. SCOP, Supreme Court of Python, has a nice ring. Christian From barry at python.org Thu Jul 12 14:53:18 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 12 Jul 2018 11:53:18 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Jul 12, 2018, at 07:57, Guido van Rossum wrote: > > I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. Leaving my emotions out of it for now, and with my heartfelt gratitude for everything you?ve done, I am absolutely certain that the community you?ve built is strong enough to carry on. I?m honored that a some of you think I can fill 1/3 of Guido?s shoes, although in all humility I have my doubts. Aside from that, it?s important to recognize that we have so many intelligent and compassionate contributors, that much of Python?s ongoing development can essentially carry on unchanged. Yury, for example worried about replacing Guido?s extensive knowledge across so much of Python, and there?s the concern that Guido?s unique authority as BDFL will be difficult to replicate. E.g even if you still absolutely hate PEP 572 (which I don?t), it is now unequivocally part of Python. It?s up to all of us to accept that, move on, and learn to use it tastefully. I think this change in governance will increase the importance of the BDFL-Delegate. We have trusted experts in many of the sub-topics of Python, and I have so much more confidence in letting them make the decisions relevant to those sub-topics. E.g. Nick, and now Paul for packaging, Yury et al for async, etc. I know that experts and BDFL-Delegates will make the right choices in these sub-topics, with the right intentions, and the best of their abilities. Even Guido recognizes that we?re all just trying to do our best. Where the BDFL role is most important is in those holistic decisions about global features, such as PEP 572. These things impact everyone and every corner of Python, so having a final arbiter(s) that is accepted by the community at large is critical. I?ve long said that if I had to choose a single person to fill that role, it would be Brett. He has the right mix of technical and social chops to make thoughtful, intelligent, compassionate decisions, and he has the advantage of being likely more than a decade away from Guido in hopeful retirement plans, unlike perhaps that FLUFL guy. :) That said, I think a triumvirate would work (Guido?s Unworthy Inherited Delegation Organization). Mostly, that group would identify and work with Delegates to make the final decisions on such PEPs, and most importantly, confidently back them up, even if those decisions are unpopular. For PEP 572-level language decisions, the group would be the final arbiters, so it would have to be an odd number. I agree with Brett that voting and rotation could be problematic due to the tyranny of the majority. Imagine that PEP 572 were put in front of this group, and after all the kerfuffle, the same decision were made. Put yourself in that place when you think about the governance of Python-the-language over the next 25 years. I personally value stability and certainty over popularity for such features. PEP 572 won?t destroy Python, and I predict most of us will appreciate it being there once in a while. There?s no rush to decide, and this would make for a fine discussion at the core sprint in September. 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 christian at cheimes.de Thu Jul 12 14:54:05 2018 From: christian at cheimes.de (Christian Heimes) Date: Thu, 12 Jul 2018 20:54:05 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: <1531419654-sup-6867@lrrr.local> Message-ID: <8f20179b-9314-4838-73fa-0b6b728bdf4e@cheimes.de> On 2018-07-12 20:50, Brett Cannon wrote: > IMHO the N-virate should primarily be responsible for delegation. > > Side note: I think we'll be talking less and less about language design, > and instead about library and infrastructure design. > > > Same here. I suspect this will make us much more conservative in > accepting language changes compared to e.g. what our deprecation policy > should be. +1 - Primary to delegate responsibilities to domain experts - Secondary to provide consistency and trust - Lastly to have final word in case of controversial bike shedding Christian From brett at python.org Thu Jul 12 15:16:49 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 12:16:49 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 11:53 Barry Warsaw wrote: > On Jul 12, 2018, at 07:57, Guido van Rossum wrote: > > > > I would like to remove myself entirely from the decision process. I'll > still be there for a while as an ordinary core dev, and I'll still be > available to mentor people -- possibly more available. But I'm basically > giving myself a permanent vacation from being BDFL, and you all will be on > your own. > > Leaving my emotions out of it for now, and with my heartfelt gratitude for > everything you?ve done, I am absolutely certain that the community you?ve > built is strong enough to carry on. > > I?m honored that a some of you think I can fill 1/3 of Guido?s shoes, > although in all humility I have my doubts. Aside from that, it?s important > to recognize that we have so many intelligent and compassionate > contributors, that much of Python?s ongoing development can essentially > carry on unchanged. Yury, for example worried about replacing Guido?s > extensive knowledge across so much of Python, and there?s the concern that > Guido?s unique authority as BDFL will be difficult to replicate. E.g even > if you still absolutely hate PEP 572 (which I don?t), it is now > unequivocally part of Python. It?s up to all of us to accept that, move > on, and learn to use it tastefully. > > I think this change in governance will increase the importance of the > BDFL-Delegate. We have trusted experts in many of the sub-topics of > Python, and I have so much more confidence in letting them make the > decisions relevant to those sub-topics. E.g. Nick, and now Paul for > packaging, Yury et al for async, etc. I know that experts and > BDFL-Delegates will make the right choices in these sub-topics, with the > right intentions, and the best of their abilities. Even Guido recognizes > that we?re all just trying to do our best. > > Where the BDFL role is most important is in those holistic decisions about > global features, such as PEP 572. These things impact everyone and every > corner of Python, so having a final arbiter(s) that is accepted by the > community at large is critical. I?ve long said that if I had to choose a > single person to fill that role, it would be Brett. He has the right mix > of technical and social chops to make thoughtful, intelligent, > compassionate decisions, and he has the advantage of being likely more than > a decade away from Guido in hopeful retirement plans, unlike perhaps that > FLUFL guy. :) > Thanks for the vote of confidence! And I haven't hit my mid-life crisis yet, let alone gotten to worry about choosing when to retire. ;) > > That said, I think a triumvirate would work (Guido?s Unworthy Inherited > Delegation Organization). Nice! "GUIDO decided ..." Totally going to mess with Guido's personal SEO, though. ;) > Mostly, that group would identify and work with Delegates to make the > final decisions on such PEPs, and most importantly, confidently back them > up, even if those decisions are unpopular. > > For PEP 572-level language decisions, the group would be the final > arbiters, so it would have to be an odd number. I agree with Brett that > voting and rotation could be problematic due to the tyranny of the > majority. Imagine that PEP 572 were put in front of this group, and after > all the kerfuffle, the same decision were made. Put yourself in that place > when you think about the governance of Python-the-language over the next 25 > years. I personally value stability and certainty over popularity for such > features. PEP 572 won?t destroy Python, and I predict most of us will > appreciate it being there once in a while. > Maybe another way to label this is design stewards? We seem to be suggesting a cabal of folks who steward the overall design while relying on experts as appropriate to handle finer details. > > > There?s no rush to decide, and this would make for a fine discussion at > the core sprint in September. > Oh, if this isn't settled by September then I expect there will be a lively discussion at the dev sprints. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Thu Jul 12 15:17:19 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 12 Jul 2018 15:17:19 -0400 Subject: [python-committers] Transfer of power In-Reply-To: <8f20179b-9314-4838-73fa-0b6b728bdf4e@cheimes.de> References: <1531419654-sup-6867@lrrr.local> <8f20179b-9314-4838-73fa-0b6b728bdf4e@cheimes.de> Message-ID: <1531422465-sup-9106@lrrr.local> Excerpts from Christian Heimes's message of 2018-07-12 20:54:05 +0200: > On 2018-07-12 20:50, Brett Cannon wrote: > > IMHO the N-virate should primarily be responsible for delegation. > > > > Side note: I think we'll be talking less and less about language design, > > and instead about library and infrastructure design. > > > > > > Same here. I suspect this will make us much more conservative in > > accepting language changes compared to e.g. what our deprecation policy > > should be. > > +1 > > - Primary to delegate responsibilities to domain experts > - Secondary to provide consistency and trust > - Lastly to have final word in case of controversial bike shedding > > Christian If the primary approach to decision making is to delegate unless an arbiter is absolutely necessary, then long-term consistency and stability comes less from finding individuals to commit to serving for very long terms on the N-virate as it does from everyone having a good understanding of the history of discussions and from a willingness to keep the status quo in situations where consensus isn't reached (note "consensus" rather than "unanimous agreement"). Building the system to support and encourage turnover, like we do with release managers, lowers the level of effort someone is signing up for when they agree to serve. Given the *many* discussions of burnout in the Python community and open source in general, that seems like an important feature. Doug From willingc at gmail.com Thu Jul 12 15:18:27 2018 From: willingc at gmail.com (Carol Willing) Date: Thu, 12 Jul 2018 12:18:27 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <0AB7B5F8-4224-4AB7-B406-D6EBF0A6B447@gmail.com> > On Jul 12, 2018, at 11:53 AM, Barry Warsaw > wrote: > > On Jul 12, 2018, at 07:57, Guido van Rossum > wrote: >> >> I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. > > Leaving my emotions out of it for now, and with my heartfelt gratitude for everything you?ve done, I am absolutely certain that the community you?ve built is strong enough to carry on. > Well said, Barry. > > That said, I think a triumvirate would work (Guido?s Unworthy Inherited Delegation Organization). > We'll likely all be asking ourselves often "What would Guido think/do in situation x, y, or z?" > > There?s no rush to decide, and this would make for a fine discussion at the core sprint in September. > Tim's reference to Stroustrup's article and the article's cautions are spot on. I agree with Barry there's no rush to decide. Taking our time to absorb the news and giving Guido the space to recharge and pursue things that rock his world (Python and beyond) would be two actions that we can take right now. Thank you Guido for everything. Wishing you all that you wish for us: https://neopythonic.blogspot.com/2016/04/kings-day-speech.html Warmly, Carol -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Jul 12 15:18:58 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 12 Jul 2018 12:18:58 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <20180712181608.GC7318@ando.pearwood.info> References: <20180712181608.GC7318@ando.pearwood.info> Message-ID: <57C64E16-4362-4192-B902-B3F500C4F830@python.org> On Jul 12, 2018, at 11:16, Steven D'Aprano wrote: > > https://www.python.org/dev/peps/pep-0401/ And of course, Uncle Timmy was the original FLUFL, before Guido and Brett did their nefarious edits. :) -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 Thu Jul 12 15:20:06 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 12 Jul 2018 21:20:06 +0200 Subject: [python-committers] Transfer of power In-Reply-To: <1531422465-sup-9106@lrrr.local> References: <1531419654-sup-6867@lrrr.local> <8f20179b-9314-4838-73fa-0b6b728bdf4e@cheimes.de> <1531422465-sup-9106@lrrr.local> Message-ID: Le 12/07/2018 ? 21:17, Doug Hellmann a ?crit?: > > If the primary approach to decision making is to delegate unless > an arbiter is absolutely necessary, then long-term consistency and > stability comes less from finding individuals to commit to serving > for very long terms on the N-virate as it does from everyone having > a good understanding of the history of discussions and from a > willingness to keep the status quo in situations where consensus > isn't reached (note "consensus" rather than "unanimous agreement"). > > Building the system to support and encourage turnover, like we do > with release managers, lowers the level of effort someone is signing > up for when they agree to serve. Given the *many* discussions of > burnout in the Python community and open source in general, that > seems like an important feature. +1. Ongoing consistency is achieved through a strong culture. Regards Antoine. From barry at python.org Thu Jul 12 15:20:58 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 12 Jul 2018 12:20:58 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org> Message-ID: On Jul 12, 2018, at 11:21, Tim Peters wrote: > > If Barry had been BDFL all along, only features useful to Mailman would have gotten in ;-) I would have stuck around just long enough to kill off != diamonds-are-a-flufl?s-best-friend-ly y?rs, -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 Thu Jul 12 15:28:09 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 12 Jul 2018 12:28:09 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Jul 12, 2018, at 12:16, Brett Cannon wrote: > > Maybe another way to label this is design stewards? We seem to be suggesting a cabal of folks who steward the overall design while relying on experts as appropriate to handle finer details. I like that distinction. -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 brett at python.org Thu Jul 12 15:29:00 2018 From: brett at python.org (Brett Cannon) Date: Thu, 12 Jul 2018 12:29:00 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, 12 Jul 2018 at 10:42 Eric Snow wrote: > On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov > wrote: > > > > Thank you, Guido. This is a sad day for me personally; I really hoped > > you'd lead Python for a few more years. On the other hand, Python is > > in good hands, you've built a large enough and diverse community > > around it! > > +1 > > Thank you for putting so much time, effort, and care into both the > language and its community! We cannot thank you enough. > > > As for the new governing model, I imagine that we don't need to make > > any decisions *right now*. As Victor suggested, core devs can simply > > count +1/-1 on any language feature and we'll see how it goes. Or > > maybe the first such vote should be on the new governing model? :) I > > really hope that we won't have an excruciating debate on the mailing > > list about the governing model though; maybe we can discuss it on the > > upcoming core dev sprint. > > In the short term we could appoint a *temporary* triumvirate to fill > in as BDFL (with the intent to re-assess the situation in September if > we haven't resolved on a permanent solution by then). That would > allow us to maintain business-as-usual (and try out a triumvirate). > If we go that route then I'd recommend Brett, Nick, and Barry. > I don't think we need a temporary solution while we digest this and figure out how we want to manage ourselves. Short of some horrible CoC catastrophe we can just hold off on making any final decisions on PEPs until a decision is made in how we want to handle PEPs going forward since Python 3.8 isn't hitting beta until May 2019 (and even if it was close we don't need to ever rush anything into a release as there's always the next release :) . -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericsnowcurrently at gmail.com Thu Jul 12 15:38:03 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Thu, 12 Jul 2018 13:38:03 -0600 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon wrote: > On Thu, 12 Jul 2018 at 10:42 Eric Snow wrote: >> In the short term we could appoint a *temporary* triumvirate to fill >> in as BDFL (with the intent to re-assess the situation in September if >> we haven't resolved on a permanent solution by then). That would >> allow us to maintain business-as-usual (and try out a triumvirate). >> If we go that route then I'd recommend Brett, Nick, and Barry. > > I don't think we need a temporary solution while we digest this and figure out how we want to manage ourselves. Short of some horrible CoC catastrophe we can just hold off on making any final decisions on PEPs until a decision is made in how we want to handle PEPs going forward since Python 3.8 isn't hitting beta until May 2019 (and even if it was close we don't need to ever rush anything into a release as there's always the next release :) . Agreed. I was hasty in posting that and don't foresee any issues where a temporary BDFL would matter. :) -eric From ethan at stoneleaf.us Thu Jul 12 16:27:18 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 12 Jul 2018 13:27:18 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <5B47B9A6.1020600@stoneleaf.us> Guido, Thank you for creating Python. Thank you for giving me a second chance when I mouthed off to you. Thank you for trusting us enough to leave this great project in our hands. Thank you. -- ~Ethan~ From raymond.hettinger at gmail.com Thu Jul 12 16:27:53 2018 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Thu, 12 Jul 2018 22:27:53 +0200 Subject: [python-committers] Transfer of power In-Reply-To: <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org> References: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org> Message-ID: <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com> > On Jul 12, 2018, at 6:14 PM, Antoine Pitrou wrote: > > I think it would be worth studying the governance structure (*) of a > bunch of open source projects picked according to a set of criteria: > > - major project in # of users and contributors > - non BDFL-governed > - mostly volunteer-driven > - with an established decision process for major enhancements > > (*) (e.g. as an informational PEP) That makes good sense. We would do well to learn from those who came before us :-) For the time being, I propose that we shift into low gear and defer major language changes for a while -- that will give us time to digest the changes already in motion and it will give the other implementations more of a chance to catch up (we've been out-running them for a while). For the smaller decisions, I suggest that for the most part we leave the final calls to the subject matter experts, original authors, and module maintainers when applicable (Yuri for async, Vinay for logging, Nick for functools, Brett for imports, Inada/Victor for the eval-loop and opcodes, Bob for JSON, etc.) The people who've invested the most time in a subject area are probably the best ones to be decision makers for those areas. But mostly, we should aim for consensus and only appeal to a decision maker when there is a major divergence about which way to go. For the bigger decisions (and there aren't many coming up), I have some suggestions on ways to improve the discussions so that the interested parties can have a more equal say in the outcome and so that the discussions can be more time efficient (it takes too much time to keep-up with long-running, active threads). Essentially the idea would be have a wiki/faq editable by all the participants. It would include the key examples, arguments for and against, and rebuttals which can be collected into a current-state-of-the-conversation. This would be somewhat different than the current PEP process because currently PEP authors dominate the conversation and others can get drowned out too easily. (This idea is modeled on the California Legislative Analyst Voters Guide which summarizes proposals and has statements and rebuttals from both proponents and opponents). Also, it would be nice to have the decisions made by someone other that the principal proponents. From my own experience with PEPs, I know that the psychological effects are powerful -- if you are the one spelling out all the details and defending the idea against all the slings and arrows, then it is only natural to come to identify with the PEP and come to believe that the only righteous outcome is for it to be accepted. Raymond From python at discontinuity.net Thu Jul 12 16:40:58 2018 From: python at discontinuity.net (Davin Potts) Date: Thu, 12 Jul 2018 15:40:58 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: Per Antoine's comment: > That might be a minority view, but I don't think anyone except Guido > would be legitimate as a Python BDFL. Not even Tim or Barry ;-) I think all agree that there simply is no replacing Guido, there is only succeeding Guido and demonstrating that what he has built and cultivated in this community and those on this mailing list is self-sustaining. Per Christian's comment, repeated by many: > How about a form of presbyterian polity in the form of a triumvirate +1 +1 +1 Per Brett's comment: > What that means is I think we should either have another BDFL or go > with Christian's triumvirate suggestion in the name of general > consistency and guidance Consistency, I suggest, outweighs many of our other valid concerns raised so far. I support the approach of sorting out over time how the composition of the triumvirate changes and when -- legislating how things work before we have a good sense of things will quickly become problematic. I have faith in the people we are choosing from for the first triumvirate. Per Raymond's comment: > Sorry the PEP process was so painful. I hope your decision to have a > permanent vacation will lift a great weight from your shoulders and that > you will derive more joy from just being a far from ordinary core dev. +1 Davin On Thu, Jul 12, 2018 at 2:38 PM, Eric Snow wrote: > On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon wrote: > > On Thu, 12 Jul 2018 at 10:42 Eric Snow > wrote: > >> In the short term we could appoint a *temporary* triumvirate to fill > >> in as BDFL (with the intent to re-assess the situation in September if > >> we haven't resolved on a permanent solution by then). That would > >> allow us to maintain business-as-usual (and try out a triumvirate). > >> If we go that route then I'd recommend Brett, Nick, and Barry. > > > > I don't think we need a temporary solution while we digest this and > figure out how we want to manage ourselves. Short of some horrible CoC > catastrophe we can just hold off on making any final decisions on PEPs > until a decision is made in how we want to handle PEPs going forward since > Python 3.8 isn't hitting beta until May 2019 (and even if it was close we > don't need to ever rush anything into a release as there's always the next > release :) . > > Agreed. I was hasty in posting that and don't foresee any issues > where a temporary BDFL would matter. :) > > -eric > _______________________________________________ > 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 Jul 12 16:55:30 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 12 Jul 2018 13:55:30 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <5B47C042.3060003@stoneleaf.us> On 07/12/2018 12:28 PM, Barry Warsaw wrote: > On Jul 12, 2018, at 12:16, Brett Cannon wrote: >> Maybe another way to label this is design stewards? We seem to be >> suggesting a cabal of folks who steward the overall design while >> relying on experts as appropriate to handle finer details. > > I like that distinction. As do I. My thoughts in more detail: - the number of stewards should be five to increase stability . the positions should be filled by majority vote of core-devs - the terms should be for life, with the acknowledgment that stepping down at any time for any reason is perfectly acceptable The stewards' duties: - appoint PEP delegates as needed (not every PEP needs a delegate) - decide PEPs that don't have delegates - decide on major issues (such as revision control systems, main discussion forums, etc.) As has been said already, there is no rush. -- ~Ethan~ From pablogsal at gmail.com Thu Jul 12 17:22:38 2018 From: pablogsal at gmail.com (Pablo Galindo Salgado) Date: Thu, 12 Jul 2018 22:22:38 +0100 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: Thank you so much for creating a language that is much bigger than itself and for your passion and commitment along all these years. I hope you enjoy this well-deserved vacation :) Paraphrasing [this]( http://neopythonic.blogspot.com/2013/10/letter-to-young-programmer.html) letter of yours: Thank you so much for have dreamed so big! Regards from cloudy London, Pablo Galindo Salgado -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at langa.pl Thu Jul 12 21:35:26 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Thu, 12 Jul 2018 19:35:26 -0600 Subject: [python-committers] Transfer of power In-Reply-To: <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com> References: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org> <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com> Message-ID: > On Jul 12, 2018, at 2:27 PM, Raymond Hettinger wrote: > > For the time being, I propose that we shift into low gear and defer major language changes for a while +1 Not only do I think our first major decision should be how we make decisions now, but as the release manager of the first versions of Python to ever be developed without a dictator at the helm, I feel responsible for them not to be viewed by future archeologists as the releases where the project went downhill ;-) The fact I'm midway through a 5 week coast-to-coast road trip doesn't help. Let's not rush anything at this point. This includes the release schedule which I think is wise to keep intact through this transition. See PEP 569 for 3.8. I'm +1 to an Informational PEP around the state of the art in project governance. -- ? From larry at hastings.org Thu Jul 12 23:41:28 2018 From: larry at hastings.org (Larry Hastings) Date: Thu, 12 Jul 2018 20:41:28 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <146c2d67-69f8-e328-dca5-77c58ee7f06a@hastings.org> On 07/12/2018 07:57 AM, Guido van Rossum wrote: > I'll still be here, but I'm trying to let you all figure something out > for yourselves. I'm tired, and need a very long break. Let me add my voice to the choir saying: * I'm sorry you had such a miserable experience. * I'm sad that you're retiring.? I was hoping we'd get a few more years out of you. * I wish you the very best in your retirement as BDFL. * I hope you have a pleasant experience as a core dev and stick around for a good long while! //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Fri Jul 13 00:30:56 2018 From: larry at hastings.org (Larry Hastings) Date: Thu, 12 Jul 2018 21:30:56 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: (separate reply to discuss the "what do we do now" topic) On 07/12/2018 07:57 AM, Guido van Rossum wrote: > I would like to remove myself entirely from the decision process. [...] > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? Although the timing is a surprise, the idea of Guido retiring isn't.? I remember shooting the breeze with Guido about it as far back as the Santa Clara PyCons--and I'm sure the topic goes even further back.? So we've had quite a while to think about it.? Here's my opinion, which I reached years ago and haven't appreciably changed since. First, there's no single person in the community who can take over as BDFL.? It's simply impossible.? The Guido we have today is who he is because he's been doing the BDFL job for more than twenty years. The job has shaped and taught him as he did it; as Python grew, so did Guido.? Literally anybody else we might appoint as BDFL would have to start fresh and grow into the job--and I don't think we can afford the growing pains. On the other hand, I also think that deciding PEPs by popular vote would be folly.? Python is mature enough to be simultaneously robust and fragile, and leaving its design up to popular vote seems like a recipe for chaos.? In my opinion, the final arbiters of Python's evolution should be experts, not the masses.? (Cue "Twitch Plays Pokemon" here.) I think the happy medium is a Council Of Elders.? Summarizing this approach: * The number of Elders on the Council should be an odd number greater than two.? It can't be one person, as that'd just be a BDFL.? And we want an odd number to prevent tie votes.? My instinct is that three would be fine. * For most PEPs the Elders should delegate, just as Guido has generally done in the last few years.? Although I expect the Elders to be seasoned Python core developers, they probably won't have domain-specific knowledge necessary to rule on most PEPs. * I'm not sure how to appoint the initial round of Elders. Maybe a popular vote? * However, once appointed, Elders are appointed is "for life". The only way to remove one would be for them to voluntarily step down--there would be no mechanism to remove one from office. (Perhaps this is too strong--perhaps one could be removed by a unanimous vote from all other Elders?)? I want the Council to be immune to popular opinion, to be empowered to do what they think is right without fear of anything beyond negative public opinion. * I'm not sure how we'd replace Elders.? Maybe they'd hold an internal-only election?? ("Jo has decided to step down, and we have elected Sam as Jo's replacement.") Your reaction to this might be "but running Python's evolution by committee will slow it down!"? I suspect that's right.? Not being Guido, I think the Council would be more cautious in approving changes to the language.? But I think that'd be appropriate anyway. Python's already a fine language, and I can live with it evolving more slowly in the future. Personally I'd nominate the following three Elders.? In alphabetical order: * Barry Warsaw (knows where the bodies are buried) * Benjamin Peterson (young enough that we'll get many years of service out of him) * Brett Cannon (the only candidate tall enough to be worth considering as BDFL replacement) I like this union of experience and personality.? My intuition is that they'd find the mixture of caution and let's-go-for-it spirit that we need to keep Python moving forward without making too many mistakes.? And we could call them "the B's" for short! Finally, I agree with Raymond's call for slow deliberation. Python's not going anywhere, there are no burning needs for changing the language that need to be addressed immediately.? We can all collectively sit and stew on this for a while. //arry /p.s. I know nobody is suggesting this, but I'll preemptively say it anyway: let's not simply appoint all the Release Managers as our initial Council Of Elders.? While that'd net us some very fine Elders indeed, you'd also wind up with me on the Council--an obvious mistake! // -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Fri Jul 13 01:55:20 2018 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 12 Jul 2018 22:55:20 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 7:57 AM, Guido van Rossum wrote: I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. > Thank you, Guido, for being the BDFL of Python. As the title goes, it is for Life. :-) I wouldn't worry about the governance process now. We will figure out something that will work. You have steered in the right direction with the right people. I hope, you will find rest and peace with the break you are taking. I heard it somewhere that there isn't a concept of retirement for artists. I am inclined to believe that it might be the same for certain programmers. Good luck with your happy break :-) Thank you! Senthil -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at robertcollins.net Fri Jul 13 01:55:34 2018 From: robertc at robertcollins.net (Robert Collins) Date: Fri, 13 Jul 2018 17:55:34 +1200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Fri., 13 Jul. 2018, 02:58 Guido van Rossum, wrote: > available. But I'm basically giving myself a permanent vacation from being > BDFL, and you all will be on your own. > Thank you for being here, benevolent, for so long . You've been a great example in our communities and it is much appreciated. Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Fri Jul 13 04:22:40 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 13 Jul 2018 09:22:40 +0100 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On 12 July 2018 at 15:57, Guido van Rossum wrote: > But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. I just want to echo everyone else's sentiments and say thank you for all the work you've done, and for the example you've set to all of us. Like many others here, my life would have been quite different without Python. Even though I've never met you in person, you've been a huge influence for me. Best wishes for the future. Paul From anthonybaxter at gmail.com Fri Jul 13 05:30:28 2018 From: anthonybaxter at gmail.com (Anthony Baxter) Date: Fri, 13 Jul 2018 19:30:28 +1000 Subject: [python-committers] Transfer of power In-Reply-To: <1531417396-sup-8296@lrrr.local> References: <1531417396-sup-8296@lrrr.local> Message-ID: As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable. Getting a release out is a heck of a lot of work, both the actually cutting the alphas, betas, &c, and also triaging issues that comes up and chasing people up for fixes. I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager. On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann wrote: > Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400: > > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou > wrote: > > > > > > > > > I'd like to point out that the N-virate idea doesn't handle a key > issue: > > > once you have a N-virate, how do you evolve its composition according > to > > > the implication and motivation of its members - but also to remarks or > > > frustation by non-virate contributors (especially new contributors who > > > will feel there's a perpetual category they're locked out of)? Do you > > > just wait for people to gently step down when required? > > > > One way would be to re-elect them every 5 or so years. Essentially, > > an N-virate is a dictator-like entity for a few years. > > > > Yury > > We've had good luck in the OpenStack community tying leadership to > release cycles. It causes elections more often (our cycles are 6 > months long), but people tend to step up for several cycles in a > row so that hasn't been a cause of excessive turnover. Having > frequent opportunities for folks to step down gracefully when they > need or want to also means no one feels like they are signing up > for an indefinite time commitment. > > For a multi-person group, staggered elections where only a portion > of the group is up for election at one time, also provides some > consistency when there is turnover. > > Doug > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Fri Jul 13 06:40:08 2018 From: vstinner at redhat.com (Victor Stinner) Date: Fri, 13 Jul 2018 12:40:08 +0200 Subject: [python-committers] Identify roles of the BDFL Message-ID: Hi, 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : > What is the role of the successor(s)? Do we assume "whatever Guido did", or > is this an opportunity to come up with a new process? > > One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession > planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8 > The slides: > https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf > > Some ideas from that talk: > 1. identify critical roles (e.g. PEP decision making) > 2. refactor large roles > 3. mentor the new successor, shadow the previous leader > 4. document all the things I liked this talk! (I attended it at FOSDEM) To be able to replace the BDFL, IMHO first we need to define what are the roles of the BDFL. I also think that it's an opportunity to split the big central BDFL role into sub-roles: delegate some roles to multiple people. Let me try to list roles of the BDFL: * Take a decision/PEP. For a Python change (usually a PEP), when they are two good solutions and we fail to find a consensus, the BDFL chooses his favorite solution. Usually, when the BDFL pronounces, everybody has to follow his choice. * PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL final decision only comes after weeks of discussions and when there is already a kind of consensus (usually in favor of the PEP, otherwise the PEP is abandonned earlier). For example, python-ideas list already works well to reject ideas which should obviously be rejected for whatever reason. Sometimes when the consensus is to reject the PEP, the BDFL officially rejects it. * Public Relations. The BDFL is our reference for the Public Relations. We like to ask our BDFL what is his vision for the next 5 years, even if he usually say that he doesn't know and he is usually not the one who propose new ideas :-) * Community? In case of conflict between two developers, sometimes the BDFL tries to solve the conflict. I'm not sure that it's an official role of the BDFL :-) * Community. (Here I will maybe speak for myself.) The BDFL is my reference for the right level of humour and right level of tone (on mailing lists and other medias). When the tone goes bad, sometimes the BDFL speaks up to cool down the discussion. * Language. The BDFL is our designer for the Python language. I would like to generalize this definition to the general "taste" of Python: the BDFL defines what is "pythonic" or not by blessing some coding styles and blessing some new syntaxes. It's wider than just the pure grammar of the language. * Diversity. Last years, the BDFL was a strong player to enhance the diversity of core developers and contributors by mentoring directly Mariatta Wijaya, and suggesting regularly to mentor more people from minorities whenever possible. He also likes to wear PyLadies t-shirt and support DjangoGirls ;-) Maybe it would also help if we list what the BDFL is not: * The BDFL is no longer the technical reference to review implementation changes. IMHO other people took this role somewhere between Python 1.0 and Python 3.7. As it has been said in the other thread, there are known experts in some areas of the Python which requires specific skills. For example, Yury Selivanov is my reference for asyncio. Well, that's a bad example, since Guido van Rossum ("as a developer, not as the BDFL") is my second reference here :-) * IMHO the BDFL is not the single one to decide to promote a contributor as a core developer. It seems like our process using a vote on python-committers works. I'm not sure that the process is perfect, but at least, I don't see the BDFL here as the central key to take a decision. These list are likely incomplete, don't hesitate to complete them :-) The question is now if a single people or a single small group of people should get all these roles? Or if we can distribute these roles to multiple people? Moreover, do all these tasks still need a BDFL? For example, do we need a diversity BDFL? IMHO the most critical roles of the BDFL is to design the language and take decisions on PEPs. To follow Vicky's talk, the second step is: "2. refactor large roles". Should we split the role "take the final decision on PEPs" into sub-roles for example? Do we need in advance to define BDFL-delegate for some kinds of PEPs? Or the BDFL should define per-PEP, which ones he doesn't want to handle and need a BDFL-delegate? In my experience, the BDFL delegation was done naturally, was not the source of conflict, and usually discussed directly with the BDFL. -- By the way, I already started to work on "1. identify critical roles (e.g. PEP decision making)" a few months ago, not directly for the BDFL roles, but more generally on "maintenance tasks" and what are the key responsibilities in Python: http://pythondev.readthedocs.io/maintenance_tasks.html Victor From njs at pobox.com Fri Jul 13 07:31:00 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 13 Jul 2018 04:31:00 -0700 Subject: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power) Message-ID: On Thu, Jul 12, 2018 at 6:35 PM, ?ukasz Langa wrote: > I'm +1 to an Informational PEP around the state of the art in project governance. I think this is a great idea. There's a lot of experience out there on different governance models, but of course any given project only uses one of them, so knowledge about what works and what doesn't is pretty fragmented across the F/OSS community. And this is a really important decision for us and our users, so we should do due diligence. For example, we should think this through at least as carefully as we thought through Github vs. Gitlab :-). A PEP is a good format to start doing that. I volunteer to co-author such a PEP. But I'm not up to doing it on my own. So... who else wants to be a co-author? (I'm not going to pressure anyone, but Brett, Mariatta, and Carol, please know that your names were the first ones that jumped to my mind when thinking about this :-).) What I'm thinking: - While this might eventually produce some recommendations, the immediate goal would just be to collect together different options and ideas and point out their trade-offs. I'm guessing most core devs aren't interested in becoming experts on open-source governance, so the goal here would be to help the broader community get up to speed and have a more informed discussion [1]. - As per the general PEP philosophy, I think this is best done by having some amount of general discussion on python-dev/python-committers, plus a small group of coauthors (say 2-4 people) who take responsibility for filtering ideas and organizing them in a coherent document. - Places where we'll want to look for ideas: - The thread already happening on python-committers - Whatever books / articles / blog posts / etc. we can find (e.g. I know Karl Fogel's Producing OSS book has some good discussion) - Other major projects in a similar position to CPython (e.g., node.js, Rust) -- what do they do, and what parts are they happy/not-happy about? - Large Python projects (e.g. Django) -- likewise If you have suggestions for particularly interesting projects or excellent writing on the topic, then this thread would be a good place to mention them. -n [1] The NumPy project has put a lot of energy into working through governance issues over the last few years, and one thing that definitely helped was coming up with some "assigned reading" ahead of the main sprint where we talked about this. NumPy's problems are/were pretty different from CPython's, but I'm imagining this PEP as filling a similar role. -- Nathaniel J. Smith -- https://vorpus.org From antoine at python.org Fri Jul 13 09:13:42 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 13 Jul 2018 15:13:42 +0200 Subject: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power) In-Reply-To: References: Message-ID: <6c36514e-a151-c14f-66b3-e34062fd9440@python.org> Le 13/07/2018 ? 13:31, Nathaniel Smith a ?crit?: > > I volunteer to co-author such a PEP. But I'm not up to doing it on my > own. So... who else wants to be a co-author? (I'm not going to > pressure anyone, but Brett, Mariatta, and Carol, please know that your > names were the first ones that jumped to my mind when thinking about > this :-).) I don't know how much time I'll be able to devote to it, but feel free to enlist me. > If you have suggestions for particularly interesting projects or > excellent writing on the topic, then this thread would be a good place > to mention them. Perhaps Apache httpd? (or some other major Apache project, since I /think/ they share similar governance structures... I happen to work on Apache Arrow, which is young and a bit on the small side compared to Python, but can ask the project leaders for feedback) Regards Antoine. > > What I'm thinking: > > - While this might eventually produce some recommendations, the > immediate goal would just be to collect together different options and > ideas and point out their trade-offs. I'm guessing most core devs > aren't interested in becoming experts on open-source governance, so > the goal here would be to help the broader community get up to speed > and have a more informed discussion [1]. > > - As per the general PEP philosophy, I think this is best done by > having some amount of general discussion on > python-dev/python-committers, plus a small group of coauthors (say 2-4 > people) who take responsibility for filtering ideas and organizing > them in a coherent document. > > - Places where we'll want to look for ideas: > - The thread already happening on python-committers > - Whatever books / articles / blog posts / etc. we can find (e.g. I > know Karl Fogel's Producing OSS book has some good discussion) > - Other major projects in a similar position to CPython (e.g., > node.js, Rust) -- what do they do, and what parts are they > happy/not-happy about? > - Large Python projects (e.g. Django) -- likewise > > > -n > > [1] The NumPy project has put a lot of energy into working through > governance issues over the last few years, and one thing that > definitely helped was coming up with some "assigned reading" ahead of > the main sprint where we talked about this. NumPy's problems are/were > pretty different from CPython's, but I'm imagining this PEP as filling > a similar role. > From doug at doughellmann.com Fri Jul 13 09:59:54 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 13 Jul 2018 09:59:54 -0400 Subject: [python-committers] Transfer of power In-Reply-To: References: <1531417396-sup-8296@lrrr.local> Message-ID: <6F78BB0C-0889-4240-8D7F-0164E07BBB05@doughellmann.com> Oh, yeah, I guess I wasn?t clear there. I am not suggesting that release managers add this new responsibility. I?m suggesting that a release cycle length is an amount of time the community is used to dealing with, and therefore might make a good cadence for elections or whatever other rotation mechanism is selected for the new group. Sorry for the confusion. Doug > On Jul 13, 2018, at 5:30 AM, Anthony Baxter wrote: > > As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable. > > Getting a release out is a heck of a lot of work, both the actually cutting the alphas, betas, &c, and also triaging issues that comes up and chasing people up for fixes. > > I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager. > > On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann > wrote: > Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400: > > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou > wrote: > > > > > > > > > I'd like to point out that the N-virate idea doesn't handle a key issue: > > > once you have a N-virate, how do you evolve its composition according to > > > the implication and motivation of its members - but also to remarks or > > > frustation by non-virate contributors (especially new contributors who > > > will feel there's a perpetual category they're locked out of)? Do you > > > just wait for people to gently step down when required? > > > > One way would be to re-elect them every 5 or so years. Essentially, > > an N-virate is a dictator-like entity for a few years. > > > > Yury > > We've had good luck in the OpenStack community tying leadership to > release cycles. It causes elections more often (our cycles are 6 > months long), but people tend to step up for several cycles in a > row so that hasn't been a cause of excessive turnover. Having > frequent opportunities for folks to step down gracefully when they > need or want to also means no one feels like they are signing up > for an indefinite time commitment. > > For a multi-person group, staggered elections where only a portion > of the group is up for election at one time, also provides some > consistency when there is turnover. > > Doug > _______________________________________________ > 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 doug at doughellmann.com Fri Jul 13 10:08:23 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 13 Jul 2018 10:08:23 -0400 Subject: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power) In-Reply-To: References: Message-ID: <1531490615-sup-6291@lrrr.local> Excerpts from Nathaniel Smith's message of 2018-07-13 04:31:00 -0700: > On Thu, Jul 12, 2018 at 6:35 PM, ?ukasz Langa wrote: > > I'm +1 to an Informational PEP around the state of the art in project governance. > > I think this is a great idea. There's a lot of experience out there on > different governance models, but of course any given project only uses > one of them, so knowledge about what works and what doesn't is pretty > fragmented across the F/OSS community. And this is a really important > decision for us and our users, so we should do due diligence. For > example, we should think this through at least as carefully as we > thought through Github vs. Gitlab :-). A PEP is a good format to start > doing that. > > I volunteer to co-author such a PEP. But I'm not up to doing it on my > own. So... who else wants to be a co-author? (I'm not going to > pressure anyone, but Brett, Mariatta, and Carol, please know that your > names were the first ones that jumped to my mind when thinking about > this :-).) > > What I'm thinking: > > - While this might eventually produce some recommendations, the > immediate goal would just be to collect together different options and > ideas and point out their trade-offs. I'm guessing most core devs > aren't interested in becoming experts on open-source governance, so > the goal here would be to help the broader community get up to speed > and have a more informed discussion [1]. > > - As per the general PEP philosophy, I think this is best done by > having some amount of general discussion on > python-dev/python-committers, plus a small group of coauthors (say 2-4 > people) who take responsibility for filtering ideas and organizing > them in a coherent document. > > - Places where we'll want to look for ideas: > - The thread already happening on python-committers > - Whatever books / articles / blog posts / etc. we can find (e.g. I > know Karl Fogel's Producing OSS book has some good discussion) > - Other major projects in a similar position to CPython (e.g., > node.js, Rust) -- what do they do, and what parts are they > happy/not-happy about? > - Large Python projects (e.g. Django) -- likewise > > If you have suggestions for particularly interesting projects or > excellent writing on the topic, then this thread would be a good place > to mention them. I would be happy to contribute based on the experiences we've had with different leadership models in OpenStack. Doug > > -n > > [1] The NumPy project has put a lot of energy into working through > governance issues over the last few years, and one thing that > definitely helped was coming up with some "assigned reading" ahead of > the main sprint where we talked about this. NumPy's problems are/were > pretty different from CPython's, but I'm imagining this PEP as filling > a similar role. > From vstinner at redhat.com Fri Jul 13 12:36:18 2018 From: vstinner at redhat.com (Victor Stinner) Date: Fri, 13 Jul 2018 18:36:18 +0200 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: References: Message-ID: 2018-07-13 12:40 GMT+02:00 Victor Stinner : > * Take a decision/PEP. For a Python change (usually a PEP), when they > are two good solutions and we fail to find a consensus, the BDFL > chooses his favorite solution. Usually, when the BDFL pronounces, > everybody has to follow his choice. > > * PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL > final decision only comes after weeks of discussions and when there is > already a kind of consensus (usually in favor of the PEP, otherwise > the PEP is abandonned earlier). For example, python-ideas list already > works well to reject ideas which should obviously be rejected for > whatever reason. Sometimes when the consensus is to reject the PEP, > the BDFL officially rejects it. Let me elaborate this part. One quality of the BDFL (Guido) is to take unpopular decision when he knows that it is the right choice. Some examples: * PEP 572: assignment expressions. * The PEP 446 "Make newly created file descriptors non-inheritable" was supposed to break the world... Well, it occurred and almost nobody noticed this Python 3.4 change... I like what Guido wrote on my PEP with humor: "We are aware of the code breakage this is likely to cause, and doing it anyway for the good of mankind." :-) * Yury mentioned async/await keywords. * Add your own example. Well, maybe this "responsibility" goes against my idea of voting on PEPs :-) ("popularity contest") Victor From antoine at python.org Fri Jul 13 13:57:43 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 13 Jul 2018 19:57:43 +0200 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: References: Message-ID: <56f12da1-f8e0-77e2-5e5c-440e4a323022@python.org> Le 13/07/2018 ? 18:36, Victor Stinner a ?crit?: > > Let me elaborate this part. One quality of the BDFL (Guido) is to take > unpopular decision when he knows that it is the right choice. > > Some examples: > > * PEP 572: assignment expressions. > > * The PEP 446 "Make newly created file descriptors non-inheritable" > was supposed to break the world... Well, it occurred and almost nobody > noticed this Python 3.4 change... I like what Guido wrote on my PEP > with humor: "We are aware of the code breakage this is likely to > cause, and doing it anyway for the good of mankind." :-) > > * Yury mentioned async/await keywords. > > * Add your own example. > > Well, maybe this "responsibility" goes against my idea of voting on > PEPs :-) ("popularity contest") Of the three you mention, only PEP 572 would have been controversial enough to fail a vote, IMO. Regards Antoine. From ethan at stoneleaf.us Fri Jul 13 14:21:57 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 13 Jul 2018 11:21:57 -0700 Subject: [python-committers] possible future PEP discussion format [was: Transfer of power] In-Reply-To: <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com> References: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org> <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com> Message-ID: <5B48EDC5.7030904@stoneleaf.us> On 07/12/2018 01:27 PM, Raymond Hettinger wrote: > For the bigger decisions (and there aren't many coming up), I have some > suggestions on ways to improve the discussions so that the interested > parties can have a more equal say in the outcome and so that the > discussions can be more time efficient (it takes too much time to keep-up > with long-running, active threads). > > Essentially the idea would be have a wiki/faq editable by all the > participants. It would include the key examples, arguments for and against, > and rebuttals which can be collected into a current-state-of-the-conversation. > This would be somewhat different than the current PEP process because > currently PEP authors dominate the conversation and others can get drowned > out too easily. (This idea is modeled on the California Legislative Analyst > Voters Guide which summarizes proposals and has statements and rebuttals from > both proponents and opponents). I really like this idea. I stopped reading the PEP 572 threads once it was painfully obvious that almost all new replies were just saying the same things over and over and over... -- ~Ethan~ From brett at python.org Fri Jul 13 14:26:26 2018 From: brett at python.org (Brett Cannon) Date: Fri, 13 Jul 2018 11:26:26 -0700 Subject: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power) In-Reply-To: References: Message-ID: On Fri, 13 Jul 2018 at 04:31 Nathaniel Smith wrote: > On Thu, Jul 12, 2018 at 6:35 PM, ?ukasz Langa wrote: > > I'm +1 to an Informational PEP around the state of the art in project > governance. > > I think this is a great idea. There's a lot of experience out there on > different governance models, but of course any given project only uses > one of them, so knowledge about what works and what doesn't is pretty > fragmented across the F/OSS community. And this is a really important > decision for us and our users, so we should do due diligence. For > example, we should think this through at least as carefully as we > thought through Github vs. Gitlab :-). A PEP is a good format to start > doing that. > > I volunteer to co-author such a PEP. But I'm not up to doing it on my > own. So... who else wants to be a co-author? (I'm not going to > pressure anyone, but Brett, Mariatta, and Carol, please know that your > names were the first ones that jumped to my mind when thinking about > this :-).) > Thanks for thinking of me, but I actually already have a governance model that I want to propose so I don't think I could be viewed as impartial when gathering details on other approaches. > > What I'm thinking: > > - While this might eventually produce some recommendations, the > immediate goal would just be to collect together different options and > ideas and point out their trade-offs. I'm guessing most core devs > aren't interested in becoming experts on open-source governance, so > the goal here would be to help the broader community get up to speed > and have a more informed discussion [1]. > > - As per the general PEP philosophy, I think this is best done by > having some amount of general discussion on > python-dev/python-committers, plus a small group of coauthors (say 2-4 > people) who take responsibility for filtering ideas and organizing > them in a coherent document. > > - Places where we'll want to look for ideas: > - The thread already happening on python-committers > - Whatever books / articles / blog posts / etc. we can find (e.g. I > know Karl Fogel's Producing OSS book has some good discussion) > - Other major projects in a similar position to CPython (e.g., > node.js, Rust) -- what do they do, and what parts are they > happy/not-happy about? > - Large Python projects (e.g. Django) -- likewise > So are you thinking an informational PEP that does a general survey of other projects and how they handle things? If so then I think that would be interesting to have even for other projects looking for this kind of information. My suspicion is when we all decide it's time to make a decision that we will have a call for PEPs on governance models and then we will choose from those. So in that situation I would view this initial PEP as information gathering for those that want an idea of what preexisting approaches there are before working towards a concrete proposal. That sounds about right? > > If you have suggestions for particularly interesting projects or > excellent writing on the topic, then this thread would be a good place > to mention them. > Someone privately suggested Kafka to me, but I think that's partially because Kafka is apparently about to propose a release and the person follows its development. -Brett > > -n > > [1] The NumPy project has put a lot of energy into working through > governance issues over the last few years, and one thing that > definitely helped was coming up with some "assigned reading" ahead of > the main sprint where we talked about this. NumPy's problems are/were > pretty different from CPython's, but I'm imagining this PEP as filling > a similar role. > > -- > Nathaniel J. Smith -- https://vorpus.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 ethan at stoneleaf.us Fri Jul 13 14:38:07 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 13 Jul 2018 11:38:07 -0700 Subject: [python-committers] possible future PEP discussion format [was: Transfer of power] Message-ID: <5B48F18F.5020805@stoneleaf.us> On 07/12/2018 01:27 PM, Raymond Hettinger wrote: > For the bigger decisions (and there aren't many coming up), I have some > suggestions on ways to improve the discussions so that the interested > parties can have a more equal say in the outcome and so that the > discussions can be more time efficient (it takes too much time to keep-up > with long-running, active threads). > > Essentially the idea would be have a wiki/faq editable by all the > participants. It would include the key examples, arguments for and against, > and rebuttals which can be collected into a current-state-of-the-conversation. > This would be somewhat different than the current PEP process because > currently PEP authors dominate the conversation and others can get drowned > out too easily. (This idea is modeled on the California Legislative Analyst > Voters Guide which summarizes proposals and has statements and rebuttals from > both proponents and opponents). I really like this idea. I stopped reading the PEP 572 threads once it was painfully obvious that almost all new replies were just saying the same things over and over and over... -- ~Ethan~ From brett at python.org Fri Jul 13 14:39:18 2018 From: brett at python.org (Brett Cannon) Date: Fri, 13 Jul 2018 11:39:18 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: References: Message-ID: On Fri, 13 Jul 2018 at 03:44 Victor Stinner wrote: > Hi, > > 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : > > What is the role of the successor(s)? Do we assume "whatever Guido did", > or > > is this an opportunity to come up with a new process? > > > > One useful resource is Vicky Brasseur's talk: Passing the Baton, > Succession > > planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8 > > The slides: > > > https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf > > > > Some ideas from that talk: > > 1. identify critical roles (e.g. PEP decision making) > > 2. refactor large roles > > 3. mentor the new successor, shadow the previous leader > > 4. document all the things > > I liked this talk! (I attended it at FOSDEM) > > To be able to replace the BDFL, IMHO first we need to define what are > the roles of the BDFL. I also think that it's an opportunity to split > the big central BDFL role into sub-roles: delegate some roles to > multiple people. > > Let me try to list roles of the BDFL: > > * Take a decision/PEP. For a Python change (usually a PEP), when they > are two good solutions and we fail to find a consensus, the BDFL > chooses his favorite solution. Usually, when the BDFL pronounces, > everybody has to follow his choice. > > * PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL > final decision only comes after weeks of discussions and when there is > already a kind of consensus (usually in favor of the PEP, otherwise > the PEP is abandonned earlier). For example, python-ideas list already > works well to reject ideas which should obviously be rejected for > whatever reason. Sometimes when the consensus is to reject the PEP, > the BDFL officially rejects it. > I view the first and second points as basically the same. This is the role of final arbiter of PEP acceptance. > > * Public Relations. The BDFL is our reference for the Public > Relations. We like to ask our BDFL what is his vision for the next 5 > years, even if he usually say that he doesn't know and he is usually > not the one who propose new ideas :-) > > * Community? In case of conflict between two developers, sometimes the > BDFL tries to solve the conflict. I'm not sure that it's an official > role of the BDFL :-) > > * Community. (Here I will maybe speak for myself.) The BDFL is my > reference for the right level of humour and right level of tone (on > mailing lists and other medias). When the tone goes bad, sometimes the > BDFL speaks up to cool down the discussion. > While Guido played this role, I don't think that necessarily plays into governance. I suspect, though, that if we choose some council structure then those people will act as the public face of the team overall to help project the tone we hope to set overall. IOW I don' think we can appointment the head of humour (although if we do I'm nominating Tim ;) . > > * Language. The BDFL is our designer for the Python language. I would > like to generalize this definition to the general "taste" of Python: > the BDFL defines what is "pythonic" or not by blessing some coding > styles and blessing some new syntaxes. It's wider than just the pure > grammar of the language. > This is the other key part of the BDFL. I have always viewed Guido's BDFL role on PEPs to be an initial yea/nay, and then either delegating with some guiding words to a person who has domain expertise for a technical PEP or to make a pronouncement for a design-related PEP that isn't technical (e.g. function expressions). > > * Diversity. Last years, the BDFL was a strong player to enhance the > diversity of core developers and contributors by mentoring directly > Mariatta Wijaya, and suggesting regularly to mentor more people from > minorities whenever possible. He also likes to wear PyLadies t-shirt > and support DjangoGirls ;-) > I lump this into the community and PR bucket as I don't know if we need to be worrying about appointing a head of diversity right now as that doesn't tie into governance. If, once this is all over, we want to take our diversity efforts to another level then a diversity SIG could be formed, but I don't see this as a BDFL thing and more of a team thing that someone choose to spearhead. -Brett > > Maybe it would also help if we list what the BDFL is not: > > * The BDFL is no longer the technical reference to review > implementation changes. IMHO other people took this role somewhere > between Python 1.0 and Python 3.7. As it has been said in the other > thread, there are known experts in some areas of the Python which > requires specific skills. For example, Yury Selivanov is my reference > for asyncio. Well, that's a bad example, since Guido van Rossum ("as a > developer, not as the BDFL") is my second reference here :-) > > * IMHO the BDFL is not the single one to decide to promote a > contributor as a core developer. It seems like our process using a > vote on python-committers works. I'm not sure that the process is > perfect, but at least, I don't see the BDFL here as the central key to > take a decision. > > > These list are likely incomplete, don't hesitate to complete them :-) > > > The question is now if a single people or a single small group of > people should get all these roles? Or if we can distribute these roles > to multiple people? Moreover, do all these tasks still need a BDFL? > For example, do we need a diversity BDFL? > > IMHO the most critical roles of the BDFL is to design the language and > take decisions on PEPs. > > > To follow Vicky's talk, the second step is: "2. refactor large roles". > > Should we split the role "take the final decision on PEPs" into > sub-roles for example? Do we need in advance to define BDFL-delegate > for some kinds of PEPs? Or the BDFL should define per-PEP, which ones > he doesn't want to handle and need a BDFL-delegate? In my experience, > the BDFL delegation was done naturally, was not the source of > conflict, and usually discussed directly with the BDFL. > > -- > > By the way, I already started to work on "1. identify critical roles > (e.g. PEP decision making)" a few months ago, not directly for the > BDFL roles, but more generally on "maintenance tasks" and what are the > key responsibilities in Python: > > http://pythondev.readthedocs.io/maintenance_tasks.html > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Fri Jul 13 14:42:56 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 13 Jul 2018 11:42:56 -0700 Subject: [python-committers] possible future PEP discussion format [was: Transfer of power] In-Reply-To: <5B48EDC5.7030904@stoneleaf.us> References: <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org> <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org> <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com> <5B48EDC5.7030904@stoneleaf.us> Message-ID: <5B48F2B0.70408@stoneleaf.us> On 07/13/2018 11:21 AM, Ethan Furman wrote: [...] Sorry, was trying to generate a new thread. Please respond to that one instead. -- ~Ethan~ From nas-python at arctrix.com Fri Jul 13 16:14:13 2018 From: nas-python at arctrix.com (Neil Schemenauer) Date: Fri, 13 Jul 2018 14:14:13 -0600 Subject: [python-committers] possible future PEP discussion format [was: Transfer of power] In-Reply-To: <5B48F18F.5020805@stoneleaf.us> References: <5B48F18F.5020805@stoneleaf.us> Message-ID: <20180713201413.dria37yjaeoffd5p@python.ca> On 2018-07-13, Ethan Furman wrote: > I stopped reading the PEP 572 threads once it was painfully > obvious that almost all new replies were just saying the same > things over and over and over... Perhaps this can be seen as a kind of economic problem. What is the cost of posting to a PEP discussion thread vs the cost of everyone reading that post? Or, what is the value of the comment vs what is cost for everyone to read it? With the current discussion method, the costs are often disproportionate. You have hundreds of people reading the thread. So that cost is pretty high. Posting a half-baked comment is too easy. Starting a new thread with a new subject line is too easy. One idea is to have a list dedicated to PEP discussions. We could establish a set of rules (cultural norms) for discussion on that list. E.g. - do your background research before posting: read PEP in its entirety, read complete PEP discussion thread - make high quality posts: ensure your points are truly bringing new ideas forth, present them clearly and succinctly - lay down rules for subject lines of posts, when you can start a new thread. Off topic discussion should go back to python-ideas. python-ideas can remain a free-wheeling wild west. Make the PEP discussion list a formal discussion forum. If people don't follow the rules, warn them and ultimately ban them from the list. Thinking about subject line rules, it would be helpful to organize threads by PEP, by topic and sub-topic. E.g. PEP 572: R: informal educator feedback PEP 572: S: comprehension scope PEP 572: S: operator precedence of := Possible topic abbreviations: R: Rationale S: Syntax and semantics E: Examples Regards, Neil From jack.jansen at cwi.nl Fri Jul 13 18:11:26 2018 From: jack.jansen at cwi.nl (Jack Jansen) Date: Sat, 14 Jul 2018 00:11:26 +0200 Subject: [python-committers] Transfer of power In-Reply-To: <20180712175540.fqlcsyqia6kktzvd@python.ca> References: <20180712175540.fqlcsyqia6kktzvd@python.ca> Message-ID: <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> A wild idea: How about a triumvirate (or trium*ate if ?vir? is seen as too male-centric, and actually the ?3? isn?t important either) where unanimity is required for language changes (i.e. basically for accepting a PEP)? A unanimity requirement will inevitably lead to more conservative decisions, but that may be a good thing... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Fri Jul 13 18:30:40 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Jul 2018 15:30:40 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> References: <20180712175540.fqlcsyqia6kktzvd@python.ca> <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> Message-ID: <8EA3BD07-A5BF-4489-9181-F5B22CDB7FB5@python.org> On Jul 13, 2018, at 15:11, Jack Jansen wrote: > > How about a triumvirate (or trium*ate if ?vir? is seen as too male-centric, and actually the ?3? isn?t important either) where unanimity is required for language changes (i.e. basically for accepting a PEP)? Possibly, but even if unanimity can?t be achieved, I feel strongly that any decision coming from the GUIDO/Cabal/Council should be give as a single party. E.g. if Alice and Bob +1 PEP 801 and Carol -1?s it, I don?t think any purpose is served by breaking that out into individual votes. I would hope that the council members support each other and the body?s decision even if it doesn?t go an individual?s way. 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 Jul 13 18:37:27 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Jul 2018 15:37:27 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: <1531417396-sup-8296@lrrr.local> Message-ID: <677B9C14-CC36-402A-9980-4FC0BD4F02C9@python.org> On Jul 13, 2018, at 02:30, Anthony Baxter wrote: > > As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable. > > I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager. My thinking is that the current RM can serve a useful role on the Council, but not in a voting capacity. Some possible scenarios: * A Council member wants to author a PEP. They probably shouldn?t also get to vote on the PEP?s acceptance, so the RM can serve as a replacement vote for that one PEP. (Maybe only for Standard Track PEPs). * If a Council member is temporarily unavailable, the RM can serve in their place during that period. * The RM can give valuable insight that may influence Council members votes. Maybe the PEP?s implementation is too difficult for the current release, and recommends deferral. * If the Council also decides on the ?PEP-worthiness? of an idea, the RM can weigh in based on their unique perspective on the release cycle. * The RM can provide an independent oversight role on the Council, kind of like an ombudsman (or maybe that should be a separate role, although I suspect it will be rarely invoked in practice). I would propose that the RM be involved with Council communications, but does not get a vote. 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 larry at hastings.org Fri Jul 13 19:00:39 2018 From: larry at hastings.org (Larry Hastings) Date: Fri, 13 Jul 2018 16:00:39 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <8EA3BD07-A5BF-4489-9181-F5B22CDB7FB5@python.org> References: <20180712175540.fqlcsyqia6kktzvd@python.ca> <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> <8EA3BD07-A5BF-4489-9181-F5B22CDB7FB5@python.org> Message-ID: <16865e94-34a8-86d3-b2ae-5c7b63ad255d@hastings.org> On 07/13/2018 03:30 PM, Barry Warsaw wrote: > On Jul 13, 2018, at 15:11, Jack Jansen wrote: >> How about a triumvirate (or trium*ate if ?vir? is seen as too male-centric, and actually the ?3? isn?t important either) where unanimity is required for language changes (i.e. basically for accepting a PEP)? > Possibly, but even if unanimity can?t be achieved, I feel strongly that any decision coming from the GUIDO/Cabal/Council should be give as a single party. E.g. if Alice and Bob +1 PEP 801 and Carol -1?s it, I don?t think any purpose is served by breaking that out into individual votes. I would hope that the council members support each other and the body?s decision even if it doesn?t go an individual?s way. I disagree.? My proposal for Python's Council Of Elders is partially based on the Supreme Court Of The United States.? For example, SCOTUS judges are appointed for life, and I think PCOE members should be too. When SCOTUS renders a decision: * the deliberation is held in private, but then * the judges cast their votes, * the "winning" side writes up the official decision, called "the Court's opinion", * and any member may contribute their own individual opinion, concurring /or/ dissenting, and finally * all votes and opinions contributed to the decision are made public. This seems like a sensible approach for the PCOE to me too.? I prefer more transparency in governance generally, and as a member of the community governed by this body I'd prefer more rather than less insight into the process and the thinking that went into the decision.? I don't think it's a requirement for the PCOE to present as a unified front or to work in secret for them to be supportive of each other and of the body's decision. Sunlight, not darkness, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Fri Jul 13 19:20:55 2018 From: steve.dower at python.org (Steve Dower) Date: Fri, 13 Jul 2018 16:20:55 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <16865e94-34a8-86d3-b2ae-5c7b63ad255d@hastings.org> References: <20180712175540.fqlcsyqia6kktzvd@python.ca> <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> <8EA3BD07-A5BF-4489-9181-F5B22CDB7FB5@python.org> <16865e94-34a8-86d3-b2ae-5c7b63ad255d@hastings.org> Message-ID: On 13Jul2018 1600, Larry Hastings wrote: > I disagree.? My proposal for Python's Council Of Elders is partially > based on the Supreme Court Of The United States.? For example, SCOTUS > judges are appointed for life, and I think PCOE members should be too. > > When SCOTUS renders a decision: > > * the deliberation is held in private, but then > * the judges cast their votes, > * the "winning" side writes up the official decision, called "the > Court's opinion", > * and any member may contribute their own individual opinion, > concurring /or/ dissenting, and finally > * all votes and opinions contributed to the decision are made public. > > This seems like a sensible approach for the PCOE to me too.? I prefer > more transparency in governance generally, and as a member of the > community governed by this body I'd prefer more rather than less insight > into the process and the thinking that went into the decision.? I don't > think it's a requirement for the PCOE to present as a unified front or > to work in secret for them to be supportive of each other and of the > body's decision. > > Sunlight, not darkness I agree with Larry, at least until the point at which we see "the public" aggressively idolising or demonising those members of the Council with whom they agree/disagree. Then I'll change my mind :) (For those who are unfamiliar with the phenomenon I'm referencing, wait for SCOTUS to decide _anything_ and then go look at American Twitter.) Cheers, Steve From barry at python.org Fri Jul 13 20:09:31 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Jul 2018 17:09:31 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: References: Message-ID: <66913909-F4DA-4E34-897D-EDACDC452AD0@python.org> On Jul 13, 2018, at 03:40, Victor Stinner wrote: > Should we split the role "take the final decision on PEPs" into > sub-roles for example? Do we need in advance to define BDFL-delegate > for some kinds of PEPs? Or the BDFL should define per-PEP, which ones > he doesn't want to handle and need a BDFL-delegate? In my experience, > the BDFL delegation was done naturally, was not the source of > conflict, and usually discussed directly with the BDFL. I don?t think we need to be so formal about delegation. As you say, it should generally happen naturally. I actually think delegation will be more common, leaving mostly the language-level Standards Track PEPs for the BDFL (Benevolent Design Faction Lifers - okay, still playing with names :). One tricky thing with delegation will be when a natural delegate is also the author of the PEP. For example, if Yury proposed some changes to async, he wouldn?t also be able to pronounce on it. OTOH, Guido is of course still a developer and could be a delegate for such PEPs if he wants. Just something to be aware of. It?s possible that more decisions that have previously been informal will be best served by the PEP process. For example, the pronouncement that dictionaries officially preserve insertion order would likely be handled as a succinct PEP. One of the roles of the council would be to decide whether a change is PEP-worthy or not. It?s possible that ideas that only show up on the tracker for example, need to be promoted into a PEP, and it would be up to the developer community to help identify those potential changes. 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 willingc at gmail.com Fri Jul 13 20:11:51 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 13 Jul 2018 17:11:51 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: References: Message-ID: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> > On Jul 13, 2018, at 11:39 AM, Brett Cannon > wrote: > > > > On Fri, 13 Jul 2018 at 03:44 Victor Stinner > wrote: > Hi, > > 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya >: > > > * Diversity. Last years, the BDFL was a strong player to enhance the > diversity of core developers and contributors by mentoring directly > Mariatta Wijaya, and suggesting regularly to mentor more people from > minorities whenever possible. He also likes to wear PyLadies t-shirt > and support DjangoGirls ;-) > > I lump this into the community and PR bucket as I don't know if we need to be worrying about appointing a head of diversity right now as that doesn't tie into governance. If, once this is all over, we want to take our diversity efforts to another level then a diversity SIG could be formed, but I don't see this as a BDFL thing and more of a team thing that someone choose to spearhead. > Brett, I'm wondering if prematurely placing this in the community and PR bucket gives mentoring and inclusion among the core developer enviroment enough strategic importance. Knowing how gracious you are, I suspect that you personally are viewing it as such. Yet, I'm not sure that by removing this as a role that Guido has played is best for the language or the developer community. If I look at the many important roles that Guido has played, I personally believe that he has been someone who encouraged many women (and I'm sure others as well) and most importantly provided a safe place to share ideas. If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we should not overlook this role as growth and improvements still need to happen here. I believe that improving the overall communication and professionalism on mailing lists and PEPs is important to continuously improve the culture and discourse. While this may help improve inclusion (and is a step in the right direction), I would encourage everyone to reflect on Mariatta's talks and consider whether improvement will happen if members of GUIDO/elders/triumvirate/kittens of entropy and anarchy/pick your governance/etc. don't believe, embrace, and make this a priority in stewarding the future of the Python language. tldr; We don't need a head of diversity. What we need is leadership that embraces inclusion and will steward the vision for improvements. Thanks, Carol -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Fri Jul 13 20:15:02 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Jul 2018 17:15:02 -0700 Subject: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power) In-Reply-To: References: Message-ID: <5A00D362-56DC-4F18-97C9-4DC19FD7B792@python.org> On Jul 13, 2018, at 04:31, Nathaniel Smith wrote: > > I volunteer to co-author such a PEP. But I'm not up to doing it on my > own. So... who else wants to be a co-author? (I'm not going to > pressure anyone, but Brett, Mariatta, and Carol, please know that your > names were the first ones that jumped to my mind when thinking about > this :-).) Count me in. Procedurally, I think an informational PEP numbered in sequence is a good place for the ?design? of our governance. Once we?ve settled on a plan, we would capture the operational procedures in a new process PEP (I propose PEP 2), which would be our working document moving forward. I think it?s pretty much a certainty that whatever we come up with initially will undergo changes as time goes on and we gain experience. PEP 2 would then be the living document for our language governance process. -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 Jul 13 20:25:28 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Jul 2018 17:25:28 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> References: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> Message-ID: <05FB5893-307C-4FCA-B18F-1C3659625A8C@python.org> On Jul 13, 2018, at 17:11, Carol Willing wrote: > If I look at the many important roles that Guido has played, I personally believe that he has been someone who encouraged many women (and I'm sure others as well) and most importantly provided a safe place to share ideas. If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we should not overlook this role as growth and improvements still need to happen here. Maybe we refactor this particular role of the BDFL? It may be that given Guido?s passion for this topic, he would still want to be active. If so, he would certainly still have the stature, respect, and voice to continue to promote this within the community. Of course, we don?t know whether that?ll be the case or not. It?s a good question though: should the Council primarily concern itself with technical details of language evolution, or take on more of the other roles that Guido traditional performed? Or do you see more of an overlap there (other than through the person embodying that role)? -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 Fri Jul 13 20:28:47 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 13 Jul 2018 17:28:47 -0700 Subject: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power) In-Reply-To: <5A00D362-56DC-4F18-97C9-4DC19FD7B792@python.org> References: <5A00D362-56DC-4F18-97C9-4DC19FD7B792@python.org> Message-ID: > On Jul 13, 2018, at 5:15 PM, Barry Warsaw wrote: > > On Jul 13, 2018, at 04:31, Nathaniel Smith wrote: >> >> I volunteer to co-author such a PEP. But I'm not up to doing it on my >> own. So... who else wants to be a co-author? (I'm not going to >> pressure anyone, but Brett, Mariatta, and Carol, please know that your >> names were the first ones that jumped to my mind when thinking about >> this :-).) > > Count me in. Me too. > > Procedurally, I think an informational PEP numbered in sequence is a good place for the ?design? of our governance. I've been debating all day how to respond to this informational PEP re: governance. While I think it's great to cull good practices from other communities, I'm not sure that Python really fits into any existing governance that other projects use. IMHO Python is one of the healthiest language/community in the open source world. There's a reason that the saying "I came for the language and stayed for the community" exists. There's also a reason the Zen of Python has been so popular for so long. It works. While this may be an unconventional idea, I would love to look at governance through the lens of these 2 universally held beliefs as we begin to "design" our goverance (Thank you Barry for phrasing so well). > Once we?ve settled on a plan, we would capture the operational procedures in a new process PEP (I propose PEP 2), which would be our working document moving forward. I think it?s pretty much a certainty that whatever we come up with initially will undergo changes as time goes on and we gain experience. PEP 2 would then be the living document for our language governance process. Sounds great. > > -Barry > From willingc at gmail.com Fri Jul 13 20:38:17 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 13 Jul 2018 17:38:17 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: <05FB5893-307C-4FCA-B18F-1C3659625A8C@python.org> References: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> <05FB5893-307C-4FCA-B18F-1C3659625A8C@python.org> Message-ID: <0D1F507E-1BB0-48D6-9060-14AA2FC891DB@gmail.com> > > On Jul 13, 2018, at 5:25 PM, Barry Warsaw wrote: > > On Jul 13, 2018, at 17:11, Carol Willing wrote: > >> If I look at the many important roles that Guido has played, I personally believe that he has been someone who encouraged many women (and I'm sure others as well) and most importantly provided a safe place to share ideas. If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we should not overlook this role as growth and improvements still need to happen here. > > Maybe we refactor this particular role of the BDFL? It may be that given Guido?s passion for this topic, he would still want to be active. If so, he would certainly still have the stature, respect, and voice to continue to promote this within the community. Of course, we don?t know whether that?ll be the case or not. Make sense, and I have no object to refactoring. I sincerely hope that is the case, but mostly I want Guido to do whatever rocks his world. > It?s a good question though: should the Council primarily concern itself with technical details of language evolution, or take on more of the other roles that Guido traditional performed? Or do you see more of an overlap there (other than through the person embodying that role)? Our messages crossed from a different post so I'm going to repost it here: > [Barry] Procedurally, I think an informational PEP numbered in sequence is a good place for the ?design? of our governance. [Carol] I've been debating all day how to respond to this informational PEP re: governance. While I think it's great to cull good practices from other communities, I'm not sure that Python really fits into any existing governance that other projects use. IMHO Python is one of the healthiest language/community in the open source world. There's a reason that the saying "I came for the language and stayed for the community" exists. There's also a reason the Zen of Python has been so popular for so long. It works. While this may be an unconventional idea, I would love to look at governance through the lens of these 2 universally held beliefs as we begin to "design" our goverance (Thank you Barry for phrasing so well). --- tldr; If what evolves embraces the Zen of Python and "I came for the language and stayed for the community", I am confident that the language will benefit technically. Encouraging people to work together even through disagreement and to respect that more than one solution is possible (it doesn't have to be one is great and the other stinks). > > -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 larry at hastings.org Fri Jul 13 20:59:38 2018 From: larry at hastings.org (Larry Hastings) Date: Fri, 13 Jul 2018 17:59:38 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: <20180712175540.fqlcsyqia6kktzvd@python.ca> <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> <8EA3BD07-A5BF-4489-9181-F5B22CDB7FB5@python.org> <16865e94-34a8-86d3-b2ae-5c7b63ad255d@hastings.org> Message-ID: On 07/13/2018 04:20 PM, Steve Dower wrote: > On 13Jul2018 1600, Larry Hastings wrote: >> I disagree.? My proposal for Python's Council Of Elders is partially >> based on the Supreme Court Of The United States.? For example, SCOTUS >> judges are appointed for life, and I think PCOE members should be too. >> >> When SCOTUS renders a decision: >> >> ? * the deliberation is held in private, but then >> ? * the judges cast their votes, >> ? * the "winning" side writes up the official decision, called "the >> ??? Court's opinion", >> ? * and any member may contribute their own individual opinion, >> ??? concurring /or/ dissenting, and finally >> ? * all votes and opinions contributed to the decision are made public. > > I agree with Larry, at least until the point at which we see "the > public" aggressively idolising or demonising those members of the > Council with whom they agree/disagree. Then I'll change my mind :) Despite the smiley etc, this is a reasonable point.? But!? I think it's inevitable.? As the BDFL Guido received more than his fair share of idolatry and demonization (cf. the PEP 572 discussion). It's a natural consequence of having identifiable people in charge of a project as popular as Python.? Having the PCOE keep its votes / dissent private wouldn't eliminate the consequences of fame for its members--all I'd expect is that it'd be more evenly distributed. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Fri Jul 13 21:54:24 2018 From: tim.peters at gmail.com (Tim Peters) Date: Fri, 13 Jul 2018 20:54:24 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Larry Hastings] ... > > - However, once appointed, Elders are appointed is "for life". The > only way to remove one would be for them to voluntarily step down--there > would be no mechanism to remove one from office. (Perhaps this is too > strong--perhaps one could be removed by a unanimous vote from all other > Elders?) I want the Council to be immune to popular opinion, to be > empowered to do what they think is right without fear of anything beyond > negative public opinion. > > At the time the US"s founders drafted the Constitution, mean US life expectancy was about 35 years A Federal judge only had to maintain "good behavior" to keep their job, but I imagine they expected most judges would die within a decade or two regardless. I really don't think they'd be happy with how the Supreme Court turned out - political ideologues wielding near-absolute power for decades on end. So: term limits! Say, 12 years. If there are 3 Elders, replace one every 12/3 = 4 years. At the start we can use the `secrets` module to pick which Elders get the first 4, 8, and 12-year terms ;-) Fresh blood is a good thing in all areas. > - I'm not sure how we'd replace Elders. Maybe they'd hold an > internal-only election? ("Jo has decided to step down, and we have elected > Sam as Jo's replacement.") > > Obviously, an Elder would be nominated by the President and confirmed with the advice and consent of the Senate ;-) Or, short of that, by an approval vote of the Fellows (whatever it is we call for-real PSF members these days). And I'd propose to let the Fellows remove an Elder by a 2/3rd supermajority vote (akin to the bar for impeachment of a US President). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Fri Jul 13 22:33:21 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Fri, 13 Jul 2018 19:33:21 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <5B4960F1.1020004@stoneleaf.us> On 07/13/2018 06:54 PM, Tim Peters wrote: > Or, short of that, by an approval vote of the Fellows (whatever it is we call for-real PSF members these days). Forgive my ignorance, but how does one become a PSF member? -- ~Ethan~ From njs at pobox.com Fri Jul 13 22:34:48 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 13 Jul 2018 19:34:48 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Fri, Jul 13, 2018 at 6:54 PM, Tim Peters wrote: > [Larry Hastings] > ... >> >> However, once appointed, Elders are appointed is "for life". The only way >> to remove one would be for them to voluntarily step down--there would be no >> mechanism to remove one from office. (Perhaps this is too strong--perhaps >> one could be removed by a unanimous vote from all other Elders?) I want the >> Council to be immune to popular opinion, to be empowered to do what they >> think is right without fear of anything beyond negative public opinion. > > At the time the US"s founders drafted the Constitution, mean US life > expectancy was about 35 years A Federal judge only had to maintain "good > behavior" to keep their job, but I imagine they expected most judges would > die within a decade or two regardless. That's not really true -- life expectancy *at birth* was ~35 years, but mostly because so many people died as infants/children. If you survived long enough to get nominated for a judgeship, then by that point your life expectancy wasn't too different from what we're used to today: https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html But I think there are a lot of differences between a 21st-century F/OSS project and an 18th-century federal government, so probably not the most relevant model in any case. And of course it's always tempting to start inventing neat rules and procedures, but IME those details are actually the least important part of project governance (compared to things like, having a healthy discussion culture, tools for building consensus, etc. -- by the time you're voting on something you've already failed). So debating the pros and cons of term limits seems a bit premature to me right now :-). -n -- Nathaniel J. Smith -- https://vorpus.org From tim.peters at gmail.com Fri Jul 13 22:36:32 2018 From: tim.peters at gmail.com (Tim Peters) Date: Fri, 13 Jul 2018 21:36:32 -0500 Subject: [python-committers] Transfer of power In-Reply-To: <5B4960F1.1020004@stoneleaf.us> References: <5B4960F1.1020004@stoneleaf.us> Message-ID: [Tim] > > Or, short of that, by an approval vote of the Fellows (whatever it is we > call for-real PSF members these days). > [Ethan Furman] > Forgive my ignorance, but how does one become a PSF member? That depends on which year you ask ;-) The current rules are here: https://www.python.org/psf/membership/ That also defines what I meant by "Fellows". -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Fri Jul 13 23:22:00 2018 From: larry at hastings.org (Larry Hastings) Date: Fri, 13 Jul 2018 20:22:00 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On 07/13/2018 06:54 PM, Tim Peters wrote: > So:? term limits!? Say, 12 years.? If there are 3 Elders, replace one > every 12/3 = 4 years.? At the start we can use the `secrets` module to > pick which Elders get the first 4, 8, and 12-year terms ;-) > > Fresh blood is a good thing in all areas. Can I get you to clarify what you mean by "term limits"?? Do you solely mean "Elders would not be appointed for life, but rather would need to be re-elected every N years"?? Or do you additionally mean "No Elder can serve more than N terms in their lifetime?"? As an admittedly-feeble attempt at disambiguation, I'd call the former "limited terms" and the latter "term limits".? (I would welcome better terms ;-) I'm most familiar with the term "term limits" from American politics, where it definitely means the latter: a person can only serve N times, and are simply ineligible to serve in that same role an N+1th time.? As an example, after FDR was elected President four times (!), the American Congress passed the 22nd Amendment which limits any particular person to no more than two terms as President. Using my terminology above, at the moment I'm open-minded about whether or not the Council members should have "limited terms".? But I'm less upbeat about "term limits".? Personally I've always found this concept of "term limits" a bit silly--the electorate could simply decline to re-elect the incumbent.? The fact that Americans re-elect the incumbent so frequently, and /also/ vote for term limits, seems to distill down to the attitude "Throw the bums out!... except for /my/ guy, he's good." //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Fri Jul 13 23:22:09 2018 From: tim.peters at gmail.com (Tim Peters) Date: Fri, 13 Jul 2018 22:22:09 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Nathaniel Smith ] > That's not really true -- life expectancy *at birth* was ~35 years, > but mostly because so many people died as infants/children. If you > survived long enough to get nominated for a judgeship, then by that > point your life expectancy wasn't too different from what we're used > to today: > https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html But that's just anecdotal, apparently cherry-picking the oldest people of the time the author could find, and misleadingly saying "George Washington was a young 67 [at death]", implying that was exceptionally young. A better account is here, which shows a bell-like curve for _all_ the Founders' death ages, peaking in the 60s (Washington did not die exceptionally young - except by _contemporary_ standards): https://en.wikipedia.org/wiki/Founding_Fathers_of_the_United_States#Youth_and_longevity I happily grant that the vast bulk of mean expectancy increase is due to surviving early childhood, but it's not true either that life expectancy at (say) age 30 hasn't also increased. But I think there are a lot of differences between a 21st-century > F/OSS project and an 18th-century federal government, so probably not > the most relevant model in any case. And of course it's always > tempting to start inventing neat rules and procedures, but IME those > details are actually the least important part of project governance > (compared to things like, having a healthy discussion culture, tools > for building consensus, etc. -- by the time you're voting on something > you've already failed). So debating the pros and cons of term limits > seems a bit premature to me right now :-). > The subject "Transfer of power" is a pretty good clue that building tools (etc) isn't the primary topic of this thread ;-) We're looking to fill the void left by an Absolute Dictator for Life stepping down. It's important to get that part right too, because "by the time you're voting on something you're already failed" is a thing that will happen, and repeatedly. Guido has been the last, best resort in such cases. The US Supreme Court is the closest thing to a dictatorial institution the US has (lifetime appointments, answerable to nobody, and against which there is no appeal), so it's a natural model to consider when replacing a dictator. Maybe people don't want a dictatorial court of last resort at all. That would be germane too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Fri Jul 13 23:47:25 2018 From: tim.peters at gmail.com (Tim Peters) Date: Fri, 13 Jul 2018 22:47:25 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Tim] > So: term limits! Say, 12 years. If there are 3 Elders, replace one > every 12/3 = 4 years. At the start we can use the `secrets` module to pick > which Elders get the first 4, 8, and 12-year terms ;-) > > Fresh blood is a good thing in all areas. > > [Larry] > Can I get you to clarify what you mean by "term limits"? Do you solely > mean "Elders would not be appointed for life, but rather would need to be > re-elected every N years"? Or do you additionally mean "No Elder can serve > more than N terms in their lifetime?" As an admittedly-feeble attempt at > disambiguation, I'd call the former "limited terms" and the latter "term > limits". (I would welcome better terms ;-) > It would mean whatever we said it means ;-) I had in mind that an Elder would be limited to one 12-year term. You do your dozen and you're out. The only ways to get out are to serve your 12 years, quit. die, or get impeached. Then that's it - you can't be a Python Elder again. > I'm most familiar with the term "term limits" from American politics, > where it definitely means the latter: a person can only serve N times, and > are simply ineligible to serve in that same role an N+1th time. As an > example, after FDR was elected President four times (!), the American > Congress passed the 22nd Amendment which limits any particular person to no > more than two terms as President. > In the context of hypothetical US Supreme Court term limits, legal thinking has been in line with my meaning above, although (a single) 18-year term has been most often discussed in that context: https://en.wikipedia.org/wiki/Term_limits_in_the_United_States#Supreme_Court However, the articles I read most recently talked about 12 years instead, and I like that better for Python. The Supremes get a salary, but Elders don't. 12 years is a looooong commitment to do something "in spare time". Using my terminology above, at the moment I'm open-minded about whether or > not the Council members should have "limited terms". But I'm less upbeat > about "term limits". Personally I've always found this concept of "term > limits" a bit silly--the electorate could simply decline to re-elect the > incumbent. The fact that Americans re-elect the incumbent so frequently, > and *also* vote for term limits, seems to distill down to the attitude > "Throw the bums out!... except for *my* guy, he's good." > Of course a limit on the number of terms a Congress Critter can serve is intended to force the _other_ side's bums out. The passion for the prospect of being able to do that clouds seeing that it will also throw your side's bums out too ;-) BTW, we both know that the US founders deliberately did _not_ want Federal judges to be elected. They had little use for democracy at the Federal level. But without a Prez and a Congress to "do the right thing" in the peoples' best interest, I figured it's good enough to let PSF Fellows do the voting (in the best interests of the PSF's much broader membership). -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Sat Jul 14 00:42:31 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 13 Jul 2018 21:42:31 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Fri, Jul 13, 2018 at 8:22 PM, Tim Peters wrote: > [Nathaniel Smith ] >> >> That's not really true -- life expectancy *at birth* was ~35 years, >> but mostly because so many people died as infants/children. If you >> survived long enough to get nominated for a judgeship, then by that >> point your life expectancy wasn't too different from what we're used >> to today: >> https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html > > But that's just anecdotal, [...] Yeah, it's an off-topic digression anyway so I was simplifying and didn't spend much time looking for the perfect link. Looking a bit it seems like in ~1790 a 20-year old white male in the US could expect to live another ~45 years, and today that's up to ~55 years, and then the numbers get closer together as the ages increase. Which is about what I had in mind for "not too different". >> But I think there are a lot of differences between a 21st-century >> F/OSS project and an 18th-century federal government, so probably not >> the most relevant model in any case. And of course it's always >> tempting to start inventing neat rules and procedures, but IME those >> details are actually the least important part of project governance >> (compared to things like, having a healthy discussion culture, tools >> for building consensus, etc. -- by the time you're voting on something >> you've already failed). So debating the pros and cons of term limits >> seems a bit premature to me right now :-). > > > The subject "Transfer of power" is a pretty good clue that building tools > (etc) isn't the primary topic of this thread ;-) We're looking to fill the > void left by an Absolute Dictator for Life stepping down. It's important to > get that part right too, because "by the time you're voting on something > you're already failed" is a thing that will happen, and repeatedly. Guido > has been the last, best resort in such cases. Well, sure, we can try to come up with something to slot into the space Guido is leaving, while keeping everything else the same, that's one option. But I doubt it's the best one. Guido is, quite literally, irreplaceable. > The US Supreme Court is the closest thing to a dictatorial institution the > US has (lifetime appointments, answerable to nobody, and against which there > is no appeal), so it's a natural model to consider when replacing a > dictator. Yeah, I get why it comes to mind for USians here, but there are also, like... lots of actual open-source projects that have transitioned from a BDFL model to something else, and they're probably even more natural models ;-). -n -- Nathaniel J. Smith -- https://vorpus.org From tim.peters at gmail.com Sat Jul 14 01:18:11 2018 From: tim.peters at gmail.com (Tim Peters) Date: Sat, 14 Jul 2018 00:18:11 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Nathaniel Smith] > ... > Well, sure, we can try to come up with something to slot into the > space Guido is leaving, while keeping everything else the same, that's > one option. There are already differences between "a Guido" and what Larry suggested. > But I doubt it's the best one. Then please suggest something specific you think is better. > Guido is, quite literally, irreplaceable. > Yet the roles he played are not self-evidently dispensable either. > > The US Supreme Court is the closest thing to a dictatorial institution > the > > US has (lifetime appointments, answerable to nobody, and against which > there > > is no appeal), so it's a natural model to consider when replacing a > > dictator. > > Yeah, I get why it comes to mind for USians here, but there are also, > like... lots of actual open-source projects that have transitioned > from a BDFL model to something else, and they're probably even more > natural models ;-). Then spell out what they did and how that worked for them? I'm not familiar with any such. The closest match to Python's development process I know of was Perl's, but Larry Wall is still (AFAIK) dictator-for-life in Perl world. On the face of it, sure, I'd rather look at a successful transition in an open source software project than at the centuries-old experiment that brought us American politics ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleax at google.com Sat Jul 14 01:33:34 2018 From: aleax at google.com (Alex Martelli) Date: Fri, 13 Jul 2018 22:33:34 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> References: <20180712175540.fqlcsyqia6kktzvd@python.ca> <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl> Message-ID: > > > How about a triumvirate (or trium*ate if ?vir? is seen as too male-centric, > The root "vir" in appropriate contexts (though clearly not in all, e.g in `virile`) has long been divorced from its original "male" denotation. The best example is probably in the word "virtus" (in English, "virtue") and further derivatives (e.g "virtuoso", an Italian word which has also been adopted in English), where nobody perceives a denotation of "maleness" any more (even though a long time ago the word was coined to refer to "a male's positive traits" such as courage and strength). I contend that "triumvir" today has no more denotation of maleness than "virtue" does -- e.g, Merriam-Webster defines it as "one of a commission or ruling body of three" (appropriately gender-neutral) and I think they're spot-on about this. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at krypto.org Sat Jul 14 02:09:22 2018 From: greg at krypto.org (Gregory P. Smith) Date: Fri, 13 Jul 2018 23:09:22 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 12:17 PM Brett Cannon wrote: > On Thu, 12 Jul 2018 at 11:53 Barry Warsaw wrote: > >> >> That said, I think a triumvirate would work (Guido?s Unworthy Inherited >> Delegation Organization). > > > Nice! "GUIDO decided ..." Totally going to mess with Guido's personal SEO, > though. ;) > +1 Whatever we wind up with, the name has already been decided. Lets keep GUIDO as the name unless the ex-BDFL rejects it! =) I *assumed* someone else would've long suggested we act as an autonomous collective organized as an anarcho-syndicalist commune in honor of https://youtu.be/Yx_pDo9B0NY by now given the in person conversations where the Holy Grail quoting of came up. :P (in case it isn't obvious: *don't take that seriously*) In all seriousness, we already have a BDFL delegate system for PEPs that makes sense. At a minimum, how to choose the delegate, or early reject a PEP so it doesn't need one, is the thing we'll decide within the next year. I also liked some of Raymond H's suggestions around adjusting the PEP section authorship and potentially final decision acceptance process. But those types of changes are likely best kept separate from choosing how BDFL delegates are agreed on. (ie: lets decide how we would even declare the decision of such changes first) -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Jul 14 02:32:27 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 14 Jul 2018 16:32:27 +1000 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On 13 July 2018 at 00:57, Guido van Rossum wrote: > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll still > be there for a while as an ordinary core dev, and I'll still be available to > mentor people -- possibly more available. But I'm basically giving myself a > permanent vacation from being BDFL, and you all will be on your own. Guido, thank you for the immense amount of time and energy you've devoted to both designing and developing Python-the-language, and also to building and supporting python-dev-the-collaborative-community. I know I'd be a different person without the years of freely shared experience, knowledge, and advice that I've benefited from by being part of this group. > I'll still be here, but I'm trying to let you all figure something out for > yourselves. I'm tired, and need a very long break. Take all the time you need - you've built a strong design community here, and hopefully we can arrange things in away that allows you to rediscover the fun parts of contributing without the burden of always needing to be the ultimately responsible decision maker :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Sat Jul 14 03:05:32 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 14 Jul 2018 17:05:32 +1000 Subject: [python-committers] PEP stewardship delegation: the minimal change approach Message-ID: Hi folks, While I think the threads suggesting that we treat Guido's retirement as an opportunity to conduct a critical self-review of our community governance structures and practices are an excellent idea, I also want to note that there's only a relatively minimal change required to PEP 1 to permit changes to proceed in areas that would likely previously have been handled by a BDFL-Delegate anyway. The gist is that both PEP 1 and the derived process I set up for PyPA allow for folks to *volunteer* as BDFL-Delegates for a PEP, rather than waiting for Guido (or the default BDFL-Delegate in the PyPA case) to pick someone. (The unwritten addendum to both these clauses is that PEP authors may also ask core devs with suitable experience to consider volunteering as BDFL-Delegate) Quoting the relevant paragraph from PEP 1 [1]: ===================== The final authority for PEP approval is the BDFL. However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. This process happens most frequently with PEPs where the BDFL has granted in principle approval for something to be done, but there are details that need to be worked out before the PEP can be accepted. ===================== And the relevant section from the PyPA process documentation [2]: ===================== Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL?s delegate (or ?PEP czar?) for that PEP. If their self-nomination is accepted by the other PyPA core reviewers, the lead PyPI maintainer and the default BDFL delegate for package distribution metadata PEPs, then they will have the authority to approve (or reject) that PEP. Otherwise, the default BDFL-Delegate depends on the area the PEP affects. - Package Distribution Metadata PEPs: Paul Moore - Package Index Interface PEPs: Donald Stufft For Package Distribution Metadata, the default BDFL-Delegate was originally appointed directly by Guido van Rossum as Python?s BDFL (hence the use of the term BDFL-Delegate), but is now nominated by the previous default BDFL-Delegate (and the transfer of delegation approved by Guido). For Package Index Interfaces, the default responsible decision maker is the lead maintainer for the Python Package Index. ===================== So stealing Brett's excellent suggestion of "Design Steward" as a BDFL-independent term for the current BDFL-Delegate role, a potential PEP 1 amendment for the appointment process would be: ===================== Whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the "Design Steward" for that PEP. If their self-nomination is accepted by the other core developers, then they will have the authority to approve (or reject) that PEP. ===================== This is similar to the "any core developer can approve a commit, any other core developer can subsequently ask for that commit to be reverted" principle that applies for smaller changes, just applied in advance to more complex design reviews and decisions. The PyPA amendment would be similar - replacing "BDFL-Delegate" with "Design Steward", and removing any references to Guido's previously priviliged role in the process. There are some proposals where I wouldn't expect this simple modification to be sufficient (e.g. PEP 505's proposal for new None-aware operators, or PEP 572's assignment expressions), due to a lack of core developers that would consider themselves suitably experienced to be solely responsible for language level design decisions of that magnitude. However, I'd expect it to be sufficient in cases where the main motivation for requiring a PEP is due to a generally supported change's design complexity, rather than due to it being a particularly controversial decision on whether or not to do anything at all. Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0001/#pep-review-resolution [2] https://www.pypa.io/en/latest/specifications/#proposing-new-specifications -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From lukasz at langa.pl Sat Jul 14 03:16:23 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Sat, 14 Jul 2018 01:16:23 -0600 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: > On Jul 13, 2018, at 7:54 PM, Tim Peters wrote: > > If there are 3 Elders [snip] It looks like the number 3 is popular in this context. What makes it so attractive? I see a bunch of problems with such a low number, like the ability for a single corporation to take over the design process of Python by employing just two of the three members (consistently voting over the third one). 3 also has high likelihood of ties if one of the members abstains. And so on. Taking a step back, before we talk names, term limits and even numbers of council members, Python needs a "constitution" which will codify what the council is and how it functions. Barry calls it PEP 2 but I'd like to understand who is supposed to author it and who is supposed to accept it. Any committer is in a position to suggest parts of or the entirety of such a document. Otherwise we create a fractal problem of who and how decides on who shouId be writing it. Ultimately we are volunteers, the ones who step up and do the work. Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers? -- ? From p.f.moore at gmail.com Sat Jul 14 05:36:46 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 14 Jul 2018 10:36:46 +0100 Subject: [python-committers] PEP stewardship delegation: the minimal change approach In-Reply-To: References: Message-ID: On 14 July 2018 at 08:05, Nick Coghlan wrote: > So stealing Brett's excellent suggestion of "Design Steward" as a > BDFL-independent term for the current BDFL-Delegate role, a potential > PEP 1 amendment for the appointment process would be: I've only got one peripheral point to make here, but can we keep the term "BDFL" and its derived terms? Even if we no longer have a BDFL (although the "FL" means that Guido is still our BDFL, even if he has stood down from the actual day to day responsibilities), Carol made the important point that Python is about community as much as it is about a programming language, and that community is built around the BDFL. I think it's important for the community that we continue to acknowledge the place of the BDFL in that role, even if it's now a notional position. As a British person, I suppose I think in terms of the royal family. No actual function in terms of government, but important in what many people (both within and outside Britain) consider being "British" to mean (apologies to any republicans out there). Paul From g.rodola at gmail.com Sat Jul 14 07:48:25 2018 From: g.rodola at gmail.com (Giampaolo Rodola') Date: Sat, 14 Jul 2018 13:48:25 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Thu, Jul 12, 2018 at 4:58 PM Guido van Rossum wrote: > > Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions. > > I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. > > After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.) > > I am not going to appoint a successor. > > So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation? > > I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been. > > The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted > > We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves. > > Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC). > > Finally. A reminder that the archives of this list are public (https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs). > > I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break. > > -- > --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/ I owe my entire career to you. Your creation has influenced my life and decision making in a very profound way. I cannot tell you how grateful I am for what you did throughout all these years. I am sincerely sad to see you resigning from your role. -- Giampaolo - http://grodola.blogspot.com From tim.peters at gmail.com Sat Jul 14 14:36:35 2018 From: tim.peters at gmail.com (Tim Peters) Date: Sat, 14 Jul 2018 13:36:35 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Tim] > > If there are 3 Elders [snip] > [?ukasz Langa] > It looks like the number 3 is popular in this context. What makes it so > attractive? > Likely because it was the first specific non-insane number someone mentioned. It helps to be concrete, but I don't know that anyone is wedded to 3. > I see a bunch of problems with such a low number, like the ability for a > single corporation to take over the design process of Python by employing > just two of the three members (consistently voting over the third one). Perhaps then you don't want a "supreme court" at all. We've been living for decades with the possibility that a single corporation could buy off Guido. Would it really help to change 3 to 5? Then Evil Corp only needs to buy off 3 - but the larger the number, the more likely Evil Corp will get some votes in its favor without needing to pay. If semi-dictators are part of the New Order at all, they need to be trusted a whole lot (although I suggested a mechanism for impeachment too). > 3 also has high likelihood of ties if one of the members abstains. I don't care about that. How often did Guido abstain? it's an Elder's _job_ to make potentially unpopular decisions. If one abstained without extraordinarily solid reason, I'd move to impeach them - they're not doing the job in that case. If they tied, that's fine too. Ties favor the status quo (same as if the proposed change had been rejected). For that reason, I'm not even wedded to an odd number. > And so on. > Likewise in the other direction. For example, how many "extremely trusted" people can we even get to volunteer for a contentious, long-term, non-paying job? I don't know. "3" probably started with the first person here who suggested specific names and could only come up with 3 ;-) Taking a step back, before we talk names, term limits and even numbers of > council members, Python needs a "constitution" which will codify what the > council is and how it functions. "Feedback loops" - all decisions feed into each other, in all directions. For example, the number of people on the council has real effects on what it's _possible_ for it do, and on how it functions. It doesn't hurt to think about everything at once ;-) Barry calls it PEP 2 but I'd like to understand who is supposed to author > it and who is supposed to accept it. > Any committer is in a position to suggest parts of or the entirety of such > a document. Otherwise we create a fractal problem of who and how decides on > who shouId be writing it. Ultimately we are volunteers, the ones who step > up and do the work. > Sure! Ideally Guido would accept the PEP but I'm not sure if he is willing to. His initial message here seemed very clear that he wants us to "figure something out for yourselves". He's tired of the battles, and perhaps you have to be as old as him (as I was 4 years ago) to grasp what "bone weary" really means ;-) > If that is indeed the case then how should this be done so that the > document is universally accepted by all committers? > Perhaps it won't be - after all, much of the point to a dictator-workalike is that universal acceptance is a rare thing in real life. Guido left us with an interesting puzzle to solve :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Jul 14 15:07:12 2018 From: brett at python.org (Brett Cannon) Date: Sat, 14 Jul 2018 12:07:12 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sat, 14 Jul 2018 at 00:16 ?ukasz Langa wrote: > > > On Jul 13, 2018, at 7:54 PM, Tim Peters wrote: > > > > If there are 3 Elders [snip] > > > It looks like the number 3 is popular in this context. What makes it so > attractive? > I think because it's small enough to be manageable and have consistency in outcomes (which is what I would want if these folks are the design stewards). IOW it prevents design-by-committee scenarios. > > I see a bunch of problems with such a low number, like the ability for a > single corporation to take over the design process of Python by employing > just two of the three members (consistently voting over the third one). 3 > also has high likelihood of ties if one of the members abstains. And so on. > > I'm personally not worried about the single corporation issue as we've basically had that under Guido since the beginning. :) I would also hope that anyone who ends up in this position is trusted enough to put Python above any potential pressure from their employer. While I prefer 3, I can see 5 working. Basically I think the number should be small enough that you can have a casual conversation with everyone involved and not feel like it's a committee meeting. > > Taking a step back, before we talk names, term limits and even numbers of > council members, Python needs a "constitution" which will codify what the > council is and how it functions. Barry calls it PEP 2 but I'd like to > understand who is supposed to author it and who is supposed to accept it. > Any committer is in a position to suggest parts of or the entirety of such > a document. Otherwise we create a fractal problem of who and how decides on > who shouId be writing it. Ultimately we are volunteers, the ones who step > up and do the work. > Ideally Guido would accept the PEP but I'm not sure if he is willing to. > If that is indeed the case then how should this be done so that the > document is universally accepted by all committers? > In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Jul 14 18:56:43 2018 From: brett at python.org (Brett Cannon) Date: Sat, 14 Jul 2018 15:56:43 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> References: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> Message-ID: On Fri, Jul 13, 2018, 17:11 Carol Willing, wrote: > On Jul 13, 2018, at 11:39 AM, Brett Cannon wrote: > > On Fri, 13 Jul 2018 at 03:44 Victor Stinner wrote: > >> Hi, >> >> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : >> >> >> * Diversity. Last years, the BDFL was a strong player to enhance the >> diversity of core developers and contributors by mentoring directly >> Mariatta Wijaya, and suggesting regularly to mentor more people from >> minorities whenever possible. He also likes to wear PyLadies t-shirt >> and support DjangoGirls ;-) >> > > I lump this into the community and PR bucket as I don't know if we need to > be worrying about appointing a head of diversity right now as that doesn't > tie into governance. If, once this is all over, we want to take our > diversity efforts to another level then a diversity SIG could be formed, > but I don't see this as a BDFL thing and more of a team thing that someone > choose to spearhead. > > > Brett, > > I'm wondering if prematurely placing this in the community and PR bucket > gives mentoring and inclusion among the core developer enviroment enough > strategic importance. Knowing how gracious you are, I suspect that you > personally are viewing it as such. Yet, I'm not sure that by removing this > as a role that Guido has played is best for the language or the developer > community. > > If I look at the many important roles that Guido has played, I personally > believe that he has been someone who encouraged many women (and I'm sure > others as well) and most importantly provided a safe place to share ideas. > If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we > should not overlook this role as growth and improvements still need to > happen here. > > I believe that improving the overall communication and professionalism on > mailing lists and PEPs is important to continuously improve the culture and > discourse. While this may help improve inclusion (and is a step in the > right direction), I would encourage everyone to reflect on Mariatta's talks > and consider whether improvement will happen if members of > GUIDO/elders/triumvirate/kittens of entropy and anarchy/pick your > governance/etc. don't believe, embrace, and make this a priority in > stewarding the future of the Python language. > > tldr; We don't need a head of diversity. What we need is leadership that > embraces inclusion and will steward the vision for improvements. > Yes, and I'm assuming no one would end up on any council who doesn't hold these views. My poorly made point is I don't know if we want to lump all of this together such that this council is expected to lead all of these points explicitly. IOW if I were to make a PSF comparison this is like the council being the board and they would be expected to support a diversity SIG/WG. -Brett > Thanks, > Carol > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Jul 14 18:59:11 2018 From: brett at python.org (Brett Cannon) Date: Sat, 14 Jul 2018 15:59:11 -0700 Subject: [python-committers] possible future PEP discussion format [was: Transfer of power] In-Reply-To: <20180713201413.dria37yjaeoffd5p@python.ca> References: <5B48F18F.5020805@stoneleaf.us> <20180713201413.dria37yjaeoffd5p@python.ca> Message-ID: On Fri, Jul 13, 2018, 13:14 Neil Schemenauer, wrote: > On 2018-07-13, Ethan Furman wrote: > > I stopped reading the PEP 572 threads once it was painfully > > obvious that almost all new replies were just saying the same > > things over and over and over... > > Perhaps this can be seen as a kind of economic problem. What is the > cost of posting to a PEP discussion thread vs the cost of everyone > reading that post? Or, what is the value of the comment vs what is > cost for everyone to read it? > > With the current discussion method, the costs are often > disproportionate. You have hundreds of people reading the thread. > So that cost is pretty high. Posting a half-baked comment is too > easy. Starting a new thread with a new subject line is too easy. > While I'm not ready to start talking about a tweaked PEP process, I will say that this disproportionate cost is definitely an issue from my perspective. -Brett > One idea is to have a list dedicated to PEP discussions. We could > establish a set of rules (cultural norms) for discussion on that > list. E.g. > > - do your background research before posting: read PEP in its > entirety, read complete PEP discussion thread > > - make high quality posts: ensure your points are truly bringing new > ideas forth, present them clearly and succinctly > > - lay down rules for subject lines of posts, when you can start a > new thread. Off topic discussion should go back to python-ideas. > > python-ideas can remain a free-wheeling wild west. Make the PEP > discussion list a formal discussion forum. If people don't follow > the rules, warn them and ultimately ban them from the list. > > Thinking about subject line rules, it would be helpful to organize > threads by PEP, by topic and sub-topic. E.g. > > PEP 572: R: informal educator feedback > PEP 572: S: comprehension scope > PEP 572: S: operator precedence of := > > Possible topic abbreviations: > > R: Rationale > S: Syntax and semantics > E: Examples > > Regards, > > Neil > _______________________________________________ > 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 Sat Jul 14 20:08:48 2018 From: brett at python.org (Brett Cannon) Date: Sat, 14 Jul 2018 17:08:48 -0700 Subject: [python-committers] Identify roles of the BDFL In-Reply-To: References: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com> Message-ID: On Sat, Jul 14, 2018, 15:56 Brett Cannon, wrote: > > > On Fri, Jul 13, 2018, 17:11 Carol Willing, wrote: > >> On Jul 13, 2018, at 11:39 AM, Brett Cannon wrote: >> >> On Fri, 13 Jul 2018 at 03:44 Victor Stinner wrote: >> >>> Hi, >>> >>> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : >>> >>> >>> * Diversity. Last years, the BDFL was a strong player to enhance the >>> diversity of core developers and contributors by mentoring directly >>> Mariatta Wijaya, and suggesting regularly to mentor more people from >>> minorities whenever possible. He also likes to wear PyLadies t-shirt >>> and support DjangoGirls ;-) >>> >> >> I lump this into the community and PR bucket as I don't know if we need >> to be worrying about appointing a head of diversity right now as that >> doesn't tie into governance. If, once this is all over, we want to take our >> diversity efforts to another level then a diversity SIG could be formed, >> but I don't see this as a BDFL thing and more of a team thing that someone >> choose to spearhead. >> >> >> Brett, >> >> I'm wondering if prematurely placing this in the community and PR bucket >> gives mentoring and inclusion among the core developer enviroment enough >> strategic importance. Knowing how gracious you are, I suspect that you >> personally are viewing it as such. Yet, I'm not sure that by removing this >> as a role that Guido has played is best for the language or the developer >> community. >> >> If I look at the many important roles that Guido has played, I personally >> believe that he has been someone who encouraged many women (and I'm sure >> others as well) and most importantly provided a safe place to share ideas. >> If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we >> should not overlook this role as growth and improvements still need to >> happen here. >> >> I believe that improving the overall communication and professionalism on >> mailing lists and PEPs is important to continuously improve the culture and >> discourse. While this may help improve inclusion (and is a step in the >> right direction), I would encourage everyone to reflect on Mariatta's talks >> and consider whether improvement will happen if members of >> GUIDO/elders/triumvirate/kittens of entropy and anarchy/pick your >> governance/etc. don't believe, embrace, and make this a priority in >> stewarding the future of the Python language. >> >> tldr; We don't need a head of diversity. What we need is leadership that >> embraces inclusion and will steward the vision for improvements. >> > > Yes, and I'm assuming no one would end up on any council who doesn't hold > these views. My poorly made point is I don't know if we want to lump all of > this together such that this council is expected to lead all of these > points explicitly. IOW if I were to make a PSF comparison this is like the > council being the board and they would be expected to support a diversity > SIG/WG. > And after sending this I realized the council -> board analogy might suggest more power than the council will probably have. Anyway, my key point is I'm trying to avoid burnout for anyone ending up on this council by making them directly responsible for too much while still expecting them to be good representatives of the team (like I would hope we all strive to be). > -Brett > > >> Thanks, >> Carol >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sun Jul 15 00:11:58 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 15 Jul 2018 14:11:58 +1000 Subject: [python-committers] PEP stewardship delegation: the minimal change approach In-Reply-To: References: Message-ID: On 14 July 2018 at 19:36, Paul Moore wrote: > On 14 July 2018 at 08:05, Nick Coghlan wrote: >> So stealing Brett's excellent suggestion of "Design Steward" as a >> BDFL-independent term for the current BDFL-Delegate role, a potential >> PEP 1 amendment for the appointment process would be: > > I've only got one peripheral point to make here, but can we keep the > term "BDFL" and its derived terms? Even if we no longer have a BDFL > (although the "FL" means that Guido is still our BDFL, even if he has > stood down from the actual day to day responsibilities), Carol made > the important point that Python is about community as much as it is > about a programming language, and that community is built around the > BDFL. I think it's important for the community that we continue to > acknowledge the place of the BDFL in that role, even if it's now a > notional position. Yes, the even-more-minimal change would be to leave the terminology alone (which has the additional benefit of avoiding any bikeshedding over a new name for the role), and just note that Guido now has the same role in the process as any other core developer, rather than needing to explicitly assent to any BDFL-Delegate nomination. ===================== Whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the "BDFL-Delegate" for that PEP. If their self-nomination is accepted by the other active core developers, then they will have the authority to approve (or reject) that PEP. (We retain the "BDFL-Delegate" term for this role, even though delegates are no longer directly appointed or accepted by the BDFL - while Guido still participates in the BDFL-Delegate appointment process, he participates in the same capacity as any other core developer) ===================== Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From yselivanov.ml at gmail.com Sun Jul 15 02:53:42 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Sun, 15 Jul 2018 09:53:42 +0300 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon wrote: [..] >> Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers? > > > In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2. That would be indeed the ideal scenario, legitimizing the whole thing. Yury From barry at python.org Sun Jul 15 14:49:18 2018 From: barry at python.org (Barry Warsaw) Date: Sun, 15 Jul 2018 11:49:18 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <08710656-C7E7-4287-85C7-6773C5C5E167@python.org> On Jul 14, 2018, at 00:16, ?ukasz Langa wrote: > Taking a step back, before we talk names, term limits and even numbers of council members, Python needs a "constitution" which will codify what the council is and how it functions. Barry calls it PEP 2 but I'd like to understand who is supposed to author it and who is supposed to accept it. Yes, I?ve been thinking the same thing. PEP 2 would serve as the Python development constitution. -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 thomas at python.org Sun Jul 15 16:01:02 2018 From: thomas at python.org (Thomas Wouters) Date: Sun, 15 Jul 2018 22:01:02 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov wrote: > On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon wrote: > [..] > >> Ideally Guido would accept the PEP but I'm not sure if he is willing > to. If that is indeed the case then how should this be done so that the > document is universally accepted by all committers? > > > > > > In my ideal scenario, people write up PEPs proposing a governance model > and Guido chooses one, making it PEP 2. > > > That would be indeed the ideal scenario, legitimizing the whole thing. > I don't know how to read these comments... Are you afraid Guido wouldn't accept the proposed arrangement, or are people really doubting that Guido is still involved in this decision? I've seen the latter idea expressed by non-core-developers, but to me, Guido's use of "try" (twice) and "we" in his original email makes it clear that he's still involved; he just doesn't want to (or can't) dictate what he'll be replaced by. If people feel like Guido's participation in this is in doubt, should we just ask him to confirm one way or the other? (You don't have to wait for an answer to that question, Guido :) -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sun Jul 15 16:37:06 2018 From: brett at python.org (Brett Cannon) Date: Sun, 15 Jul 2018 13:37:06 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018, 13:01 Thomas Wouters, wrote: > On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov > wrote: > >> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon wrote: >> [..] >> >> Ideally Guido would accept the PEP but I'm not sure if he is willing >> to. If that is indeed the case then how should this be done so that the >> document is universally accepted by all committers? >> > >> > >> > In my ideal scenario, people write up PEPs proposing a governance model >> and Guido chooses one, making it PEP 2. >> >> >> That would be indeed the ideal scenario, legitimizing the whole thing. >> > > I don't know how to read these comments... Are you afraid Guido wouldn't > accept the proposed arrangement, or are people really doubting that Guido > is still involved in this decision? I've seen the latter idea expressed by > non-core-developers, but to me, Guido's use of "try" (twice) and "we" in > his original email makes it clear that he's still involved; he just doesn't > want to (or can't) dictate what he'll be replaced by. If people feel like > Guido's participation in this is in doubt, should we just ask him to > confirm one way or the other? (You don't have to wait for an answer to that > question, Guido :) > For me, Guido's participation just hasn't been agreed to by him yet ?. I have viewed the retirement email as saying "you all have to decide how you want things to be as I'm not going to force something upon you" and not a mic drop of "I ain't participating". But Guido hasn't spoken up yet as I think he's still processing all of this. So I'm just hedging my phrasing in case he takes a pass. -Brett > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > _______________________________________________ > 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 guido at python.org Sun Jul 15 16:43:24 2018 From: guido at python.org (Guido van Rossum) Date: Sun, 15 Jul 2018 13:43:24 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: I?m still here, but I would like to be out of the debate and out of the decision loop. I?m also still President of the PSF. But this is not for the PSF to decide. You all are doing fine. ?Guido On Sun, Jul 15, 2018 at 1:37 PM Brett Cannon wrote: > > > On Sun, Jul 15, 2018, 13:01 Thomas Wouters, wrote: > >> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov >> wrote: >> >>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon wrote: >>> [..] >>> >> Ideally Guido would accept the PEP but I'm not sure if he is willing >>> to. If that is indeed the case then how should this be done so that the >>> document is universally accepted by all committers? >>> > >>> > >>> > In my ideal scenario, people write up PEPs proposing a governance >>> model and Guido chooses one, making it PEP 2. >>> >>> >>> That would be indeed the ideal scenario, legitimizing the whole thing. >>> >> >> I don't know how to read these comments... Are you afraid Guido wouldn't >> accept the proposed arrangement, or are people really doubting that Guido >> is still involved in this decision? I've seen the latter idea expressed by >> non-core-developers, but to me, Guido's use of "try" (twice) and "we" in >> his original email makes it clear that he's still involved; he just doesn't >> want to (or can't) dictate what he'll be replaced by. If people feel like >> Guido's participation in this is in doubt, should we just ask him to >> confirm one way or the other? (You don't have to wait for an answer to that >> question, Guido :) >> > > > For me, Guido's participation just hasn't been agreed to by him yet ?. I > have viewed the retirement email as saying "you all have to decide how you > want things to be as I'm not going to force something upon you" and not a > mic drop of "I ain't participating". But Guido hasn't spoken up yet as I > think he's still processing all of this. So I'm just hedging my phrasing in > case he takes a pass. > > -Brett > > >> -- >> Thomas Wouters >> >> Hi! I'm an email virus! Think twice before sending your email to help me >> spread! >> _______________________________________________ >> 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/ > -- --Guido (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at gmail.com Sun Jul 15 20:23:38 2018 From: willingc at gmail.com (Carol Willing) Date: Sun, 15 Jul 2018 17:23:38 -0700 Subject: [python-committers] Summarizing our discussion about Governance Message-ID: Hi folks, There have been lots of good comments the past few days. For those who are interested, I've compiled a Markdown document that pulls out and summarizes many comments. The document builds around the questions/issues that Guido posed in his message. We've been using Hackmd for collaborative writing for Project Jupyter for a while. It's similar to etherpad but with some additional versioning - if you have a GitHub account you can authenticate to make edits. This is a working document so please feel free to make edits. If you are adding content, please keep it brief and try to avoid personal names or attributions to yourself or others. As this is a gathering of information, the source of the information is less important than the information itself. https://hackmd.io/s/BJPaxUFX7 To view: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?view To edit: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?edit Note: I got about 80% through the messages on python-committers, but need to travel now. Will add the rest tomorrow or others please feel free to do so (I left off with Barry's July 12 14:53:18 message. Carol ?Carol Willing? Research Software Engineer Project Jupyter at Cal Poly State University, San Luis Obispo @willingc on GitHub and @willingcarol on Twitter Signature Strengths Empathy - Relator - Ideation - Strategic - Learner -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sun Jul 15 21:07:36 2018 From: brett at python.org (Brett Cannon) Date: Sun, 15 Jul 2018 18:07:36 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sat, 14 Jul 2018 at 11:37 Tim Peters wrote: > [Tim] > >> > If there are 3 Elders [snip] >> > > [?ukasz Langa] > > It looks like the number 3 is popular in this context. What makes it so >> attractive? >> > > Likely because it was the first specific non-insane number someone > mentioned. It helps to be concrete, but I don't know that anyone is wedded > to 3. > > >> I see a bunch of problems with such a low number, like the ability for a >> single corporation to take over the design process of Python by employing >> just two of the three members (consistently voting over the third one). > > > Perhaps then you don't want a "supreme court" at all. We've been living > for decades with the possibility that a single corporation could buy off > Guido. Would it really help to change 3 to 5? Then Evil Corp only needs > to buy off 3 - but the larger the number, the more likely Evil Corp will > get some votes in its favor without needing to pay. > > If semi-dictators are part of the New Order at all, they need to be > trusted a whole lot (although I suggested a mechanism for impeachment too). > > > >> 3 also has high likelihood of ties if one of the members abstains. > > > I don't care about that. How often did Guido abstain? it's an Elder's > _job_ to make potentially unpopular decisions. If one abstained without > extraordinarily solid reason, I'd move to impeach them - they're not doing > the job in that case. > > If they tied, that's fine too. Ties favor the status quo (same as if the > proposed change had been rejected). For that reason, I'm not even wedded > to an odd number. > That's a good point. Since this is typically going to be a yes/no question instead of an A/B question, ties that go in favour of the status quo aren't a stalemate issue. -Brett > > > >> And so on. >> > > Likewise in the other direction. For example, how many "extremely > trusted" people can we even get to volunteer for a contentious, long-term, > non-paying job? I don't know. "3" probably started with the first person > here who suggested specific names and could only come up with 3 ;-) > > > Taking a step back, before we talk names, term limits and even numbers of >> council members, Python needs a "constitution" which will codify what the >> council is and how it functions. > > > "Feedback loops" - all decisions feed into each other, in all directions. > For example, the number of people on the council has real effects on what > it's _possible_ for it do, and on how it functions. It doesn't hurt to > think about everything at once ;-) > > > Barry calls it PEP 2 but I'd like to understand who is supposed to author >> it and who is supposed to accept it. > > >> Any committer is in a position to suggest parts of or the entirety of >> such a document. Otherwise we create a fractal problem of who and how >> decides on who shouId be writing it. Ultimately we are volunteers, the ones >> who step up and do the work. >> > > Sure! > > Ideally Guido would accept the PEP but I'm not sure if he is willing to. > > > His initial message here seemed very clear that he wants us to "figure > something out for yourselves". He's tired of the battles, and perhaps you > have to be as old as him (as I was 4 years ago) to grasp what "bone weary" > really means ;-) > > >> If that is indeed the case then how should this be done so that the >> document is universally accepted by all committers? >> > > Perhaps it won't be - after all, much of the point to a dictator-workalike > is that universal acceptance is a rare thing in real life. Guido left us > with an interesting puzzle to solve :-) > > _______________________________________________ > 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 tim.peters at gmail.com Sun Jul 15 22:38:30 2018 From: tim.peters at gmail.com (Tim Peters) Date: Sun, 15 Jul 2018 21:38:30 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Tim] > If they tied, that's fine too. Ties favor the status quo (same as if the >> proposed change had been rejected). For that reason, I'm not even wedded >> to an odd number. >> > [Brett Cannon] > That's a good point. Since this is typically going to be a yes/no question > instead of an A/B question, ties that go in favour of the status quo aren't > a stalemate issue. > Thanks for reading my mind :-) I certainly didn't spell it out. Predictably contentious A/B issues, like how to allocate limited resources (how much do we spend on grants vs sponsoring conferences?), are mostly in the PSF's court. Likewise A/B decisions with legal consequences (now that the DPRK has ruled the PSF license counterrevolutionary, which license should we use there instead?). Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns. But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters. Those "small" pronouncements typically go by with little notice except by those shut down, but may well be crucial in keeping productive discussion going at all. And they need to be timely to do any good. Whoever makes such decisions needs to be down in the mud, wrestling with the issues while they're hot topics, not judging at leisure weeks (or even days) later. I'm not sure "a committee" can do that at all. Then again, there seems to be consensus that the current PEP discussion process is sometimes broken anyway, even with a BDFL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.jerdonek at gmail.com Mon Jul 16 01:26:10 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Sun, 15 Jul 2018 22:26:10 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018 at 6:07 PM Brett Cannon wrote: > On Sat, 14 Jul 2018 at 11:37 Tim Peters wrote: > >> [Tim] >> >>> > If there are 3 Elders [snip] >>> >> >> [?ukasz Langa] >> >> It looks like the number 3 is popular in this context. What makes it so >>> attractive? >>> >> >> Likely because it was the first specific non-insane number someone >> mentioned. It helps to be concrete, but I don't know that anyone is wedded >> to 3. >> >> >>> I see a bunch of problems with such a low number, like the ability for a >>> single corporation to take over the design process of Python by employing >>> just two of the three members (consistently voting over the third one). >> >> >> Perhaps then you don't want a "supreme court" at all. We've been living >> for decades with the possibility that a single corporation could buy off >> Guido. Would it really help to change 3 to 5? Then Evil Corp only needs >> to buy off 3 - but the larger the number, the more likely Evil Corp will >> get some votes in its favor without needing to pay. >> >> If semi-dictators are part of the New Order at all, they need to be >> trusted a whole lot (although I suggested a mechanism for impeachment too). >> >> >> >>> 3 also has high likelihood of ties if one of the members abstains. >> >> >> I don't care about that. How often did Guido abstain? it's an Elder's >> _job_ to make potentially unpopular decisions. If one abstained without >> extraordinarily solid reason, I'd move to impeach them - they're not doing >> the job in that case. >> >> If they tied, that's fine too. Ties favor the status quo (same as if the >> proposed change had been rejected). For that reason, I'm not even wedded >> to an odd number. >> > > That's a good point. Since this is typically going to be a yes/no question > instead of an A/B question, ties that go in favour of the status quo aren't > a stalemate issue. > I don?t think we should assume that a stalemate would be okay in all cases. There may be cases in which a decision has to be made (e.g. if nothing changes, bad things will happen). I think one of the most important roles a BDFL serves is to provide a mechanism of last resort to resolve such stalemates should they ever arise. If the replacement we come up with can itself stalemate, I think there will be a problem. ?Chris > -Brett > > >> >> >> >>> And so on. >>> >> >> Likewise in the other direction. For example, how many "extremely >> trusted" people can we even get to volunteer for a contentious, long-term, >> non-paying job? I don't know. "3" probably started with the first person >> here who suggested specific names and could only come up with 3 ;-) >> >> >> Taking a step back, before we talk names, term limits and even numbers of >>> council members, Python needs a "constitution" which will codify what the >>> council is and how it functions. >> >> >> "Feedback loops" - all decisions feed into each other, in all >> directions. For example, the number of people on the council has real >> effects on what it's _possible_ for it do, and on how it functions. It >> doesn't hurt to think about everything at once ;-) >> >> >> Barry calls it PEP 2 but I'd like to understand who is supposed to >>> author it and who is supposed to accept it. >> >> >>> Any committer is in a position to suggest parts of or the entirety of >>> such a document. Otherwise we create a fractal problem of who and how >>> decides on who shouId be writing it. Ultimately we are volunteers, the ones >>> who step up and do the work. >>> >> >> Sure! >> >> Ideally Guido would accept the PEP but I'm not sure if he is willing to. >> >> >> His initial message here seemed very clear that he wants us to "figure >> something out for yourselves". He's tired of the battles, and perhaps you >> have to be as old as him (as I was 4 years ago) to grasp what "bone weary" >> really means ;-) >> >> >>> If that is indeed the case then how should this be done so that the >>> document is universally accepted by all committers? >>> >> >> Perhaps it won't be - after all, much of the point to a >> dictator-workalike is that universal acceptance is a rare thing in real >> life. Guido left us with an interesting puzzle to solve :-) >> >> _______________________________________________ >> 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 tim.peters at gmail.com Mon Jul 16 02:31:12 2018 From: tim.peters at gmail.com (Tim Peters) Date: Mon, 16 Jul 2018 01:31:12 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Chris Jerdonek] > I don?t think we should assume that a stalemate would be okay in all > cases. There may be cases in which a decision has to be made (e.g. if > nothing changes, bad things will happen). I think one of the most important > roles a BDFL serves is to provide a mechanism of last resort to resolve > such stalemates should they ever arise. If the replacement we come up with > can itself stalemate, I think there will be a problem. > Can you flesh that out with a plausible example? If "bad things can happen" relates to finances or legal issues, the problem is almost certainly the PSF's headache to resolve. If they don't relate to finances or legal issues, I'm unclear on what "bad" could mean. Guido's BDFL pronouncements were mostly about language and library design issues. The only total stalemate I can recall happened when complex numbers were added to Python. Should the suffix used to denote imaginary literals be "i" or "j"? After long argumentation, nothing anywhere near consensus was reached, in large part because there really isn't a _compelling_ argument for or against either one. Just observations justifying personal tastes, sometimes disguised as "arguments" (whether "i looks too much like the digit 1" or "j is rarely used by mathematicians"). Guido picked "j". The world wouldn't really be significantly different if he had picked "i". If the Elders childishly refused to compromise, then print(random.choice("ij')) could settle it ;-) Here's a hypothetical: suppose Larry removes the GIL but it slows down single-threaded code by a factor of 1.2. Should the default CPython provided by the PSF enable that or not? That could plausibly become a contentious issue with no community consensus. If the Elders tied, the "no change" (maintain the status quo) outcome would still be _a_ resolution. If you want to make a rule that the Elders cannot tie, the only way to do that is to say they'll all be impeached and replaced if they ever tie (as already noted by ?ukasz, having an odd number of Elders doesn't prevent one from abstaining). And we'll keep replacing them until they stop tying. But we'll probably run out of volunteers after the first round of impeachments. Sneakier: add a rule that if the Elders tie, then the choice has to be made by the President of the PSF. Which, by sheer coincidence, is Guido :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.jerdonek at gmail.com Mon Jul 16 03:17:22 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Mon, 16 Jul 2018 00:17:22 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters wrote: > [Chris Jerdonek] >> >> I don?t think we should assume that a stalemate would be okay in all >> cases. There may be cases in which a decision has to be made (e.g. if >> nothing changes, bad things will happen). I think one of the most important >> roles a BDFL serves is to provide a mechanism of last resort to resolve such >> stalemates should they ever arise. If the replacement we come up with can >> itself stalemate, I think there will be a problem. > > Can you flesh that out with a plausible example? If "bad things can happen" > relates to finances or legal issues, the problem is almost certainly the > PSF's headache to resolve. If they don't relate to finances or legal > issues, I'm unclear on what "bad" could mean. Guido's BDFL pronouncements > were mostly about language and library design issues. I only had in mind technical things. Non-technical things didn't cross my mind. The types of cases I had in mind were (in the abstract) (1) a feature is rolled out which later turns out to have a severe defect, and so it needs to be fixed somehow, and people are divided on how it should be fixed; (2) something changes outside of Python (e.g. something OS related), which is or will cause a severe defect for Python users, and people can't agree on how it should be fixed; and (3) (a case you mentioned) there is a feature that everyone wants to add, but people are split on some bike shed issue. It's true that a stalemate for (3) wouldn't be so bad, but it would prevent something that everybody wants. For (1) and (2), I'm probably not the best person to provide an example. But one case in the back of my mind that may have prompted my reply and that might qualify was when there was a randomness-related security issue in the summer of 2016. I believe this is the thread that kicked it off (subject line: "BDFL ruling request: should we block forever waiting for high-quality random bits?"): https://mail.python.org/pipermail/python-dev/2016-June/144939.html Things got so contentious on python-dev that, IIRC, at least one core developer quit or was threatening to quit, and it prompted the creation of a new mailing list (Security-SIG) due to the volume of emails. See the number of emails the thread above spurred alone: https://mail.python.org/pipermail/python-dev/2016-June/thread.html To resolve the split, Guido ultimately chose PEP 524 over PEP 522. > If you want to make a rule that the Elders cannot tie, the only way to do > that is to say they'll all be impeached and replaced if they ever tie (as > already noted by ?ukasz, having an odd number of Elders doesn't prevent one > from abstaining). There's another alternative. You can make a rule that they're not allowed to abstain (or some variant, like you have to choose someone else if you need to recuse yourself). I'm a member of such a body in fact (the San Francisco Elections Commission). If a member wants to abstain, a member has to request it, and then the Commission has to pass a majority vote to let the person to abstain. But we wouldn't even have to have that extra provision. --Chris > And we'll keep replacing them until they stop tying. But > we'll probably run out of volunteers after the first round of impeachments. > > Sneakier: add a rule that if the Elders tie, then the choice has to be made > by the President of the PSF. Which, by sheer coincidence, is Guido :-) > From antoine at python.org Mon Jul 16 05:23:12 2018 From: antoine at python.org (Antoine Pitrou) Date: Mon, 16 Jul 2018 11:23:12 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org> Le 16/07/2018 ? 04:38, Tim Peters a ?crit?: > > But I'm not sure it's fully appreciated just how active Guido has been > in those at times.? The "accepted/rejected" at the end of major PEPs is > just a small part of that.? Along the way, e.g., it's been pretty common > to see a "Save your breath.? That's not going to happen." from Guido to > end a distracting alternative (sub)proposal persistently promoted by one > (or a few) very active and/or loquacious posters. I think that only happens on python-ideas. We've long had a problem with that mailing-list (but at least it allows to avoid such discussions on python-dev). Regards Antoine. From tim.peters at gmail.com Mon Jul 16 14:05:08 2018 From: tim.peters at gmail.com (Tim Peters) Date: Mon, 16 Jul 2018 13:05:08 -0500 Subject: [python-committers] Transfer of power In-Reply-To: <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org> References: <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org> Message-ID: [Tim] > > But I'm not sure it's fully appreciated just how active Guido has been > > in those at times. The "accepted/rejected" at the end of major PEPs is > > just a small part of that. Along the way, e.g., it's been pretty common > > to see a "Save your breath. That's not going to happen." from Guido to > > end a distracting alternative (sub)proposal persistently promoted by one > > (or a few) very active and/or loquacious posters. > [Antoine] > I think that only happens on python-ideas. We've long had a problem > with that mailing-list (but at least it allows to avoid such discussions > on python-dev). > I'm unclear on whether you view that as opposing or confirming my point ;-) I view it as confirming: yes, the BDFL has played this role mostly on python-ideas, where the dirty work of developing general PEPs is intended to take place, while they're still at best half-baked. If someone only follows python-dev, they're unaware of most of these BDFL pronouncements. The latter may think "oh, big deal - a PEP is posted to python-dev, and then Guido has weeks to make up his mind about whether to accept or reject it". They're only seeing the end of a sometimes very messy process. Most things on python-ideas never make it to python-dev at all. PEP 572 was (IMO, and Guido's, and a whole bunch of others) posted to python-dev prematurely, so anyone who doesn't follow python-ideas should know that the firestorm on python-dev was just a hint of what python-ideas can be like routinely ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Mon Jul 16 14:15:59 2018 From: antoine at python.org (Antoine Pitrou) Date: Mon, 16 Jul 2018 20:15:59 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org> Message-ID: Le 16/07/2018 ? 20:05, Tim Peters a ?crit?: > [Tim] > > > But I'm not sure it's fully appreciated just how active Guido has been > > in those at times.? The "accepted/rejected" at the end of major > PEPs is > > just a small part of that.? Along the way, e.g., it's been pretty > common > > to see a "Save your breath.? That's not going to happen." from > Guido to > > end a distracting alternative (sub)proposal persistently promoted > by one > > (or a few) very active and/or loquacious posters. > > [Antoine] > > I think that only happens on python-ideas.? We've long had a problem > with that mailing-list (but at least it allows to avoid such discussions > on python-dev). > > I'm unclear on whether you view that as opposing or confirming my point > ;-)? I view it as confirming:? yes, the BDFL has played this role mostly > on python-ideas, where the dirty work of developing general PEPs is > intended to take place, while they're still at best half-baked.? If > someone only follows python-dev, they're unaware of most of these BDFL > pronouncements. > > The latter may think "oh, big deal - a PEP is posted to python-dev, and > then Guido has weeks to make up his mind about whether to accept or > reject it".? They're only seeing the end of a sometimes very messy > process.? Most things on python-ideas never make it to python-dev at all. > > PEP 572 was (IMO, and Guido's, and a whole bunch of others) posted to > python-dev prematurely, so anyone who doesn't follow python-ideas should > know that the firestorm on python-dev was just a hint of what > python-ideas can be like routinely ;-)? I know what python-ideas can be like routinely (I do read it at times). I think the general idea of my comment is that the signal-to-noise ratio on python-ideas is so low that, whether or not Guido had remained BDFL, we would still have a productivity problem to solve there. Regards Antoine. From brett at python.org Mon Jul 16 15:35:22 2018 From: brett at python.org (Brett Cannon) Date: Mon, 16 Jul 2018 12:35:22 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Mon, 16 Jul 2018 at 00:17 Chris Jerdonek wrote: > On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters wrote: > > [Chris Jerdonek] > >> > >> I don?t think we should assume that a stalemate would be okay in all > >> cases. There may be cases in which a decision has to be made (e.g. if > >> nothing changes, bad things will happen). I think one of the most > important > >> roles a BDFL serves is to provide a mechanism of last resort to resolve > such > >> stalemates should they ever arise. If the replacement we come up with > can > >> itself stalemate, I think there will be a problem. > > > > Can you flesh that out with a plausible example? If "bad things can > happen" > > relates to finances or legal issues, the problem is almost certainly the > > PSF's headache to resolve. If they don't relate to finances or legal > > issues, I'm unclear on what "bad" could mean. Guido's BDFL > pronouncements > > were mostly about language and library design issues. > > I only had in mind technical things. Non-technical things didn't cross > my mind. The types of cases I had in mind were (in the abstract) (1) a > feature is rolled out which later turns out to have a severe defect, > and so it needs to be fixed somehow, and people are divided on how it > should be fixed; (2) something changes outside of Python (e.g. > something OS related), which is or will cause a severe defect for > Python users, and people can't agree on how it should be fixed; and > (3) (a case you mentioned) there is a feature that everyone wants to > add, but people are split on some bike shed issue. It's true that a > stalemate for (3) wouldn't be so bad, but it would prevent something > that everybody wants. > > For (1) and (2), I'm probably not the best person to provide an > example. But one case in the back of my mind that may have prompted my > reply and that might qualify was when there was a randomness-related > security issue in the summer of 2016. I believe this is the thread > that kicked it off (subject line: "BDFL ruling request: should we > block forever waiting for high-quality random bits?"): > https://mail.python.org/pipermail/python-dev/2016-June/144939.html > > Things got so contentious on python-dev that, IIRC, at least one core > developer quit or was threatening to quit, and it prompted the > creation of a new mailing list (Security-SIG) due to the volume of > emails. See the number of emails the thread above spurred alone: > https://mail.python.org/pipermail/python-dev/2016-June/thread.html > > To resolve the split, Guido ultimately chose PEP 524 over PEP 522. > But that's an extremely rare case. And even then, I would assume the council would have picked a BDFL delegate who would have made the utlimate decision. So even in a stalemate there's a way out by the council saying "not it" and pointing at someone else. -Brett > > > If you want to make a rule that the Elders cannot tie, the only way to do > > that is to say they'll all be impeached and replaced if they ever tie (as > > already noted by ?ukasz, having an odd number of Elders doesn't prevent > one > > from abstaining). > > There's another alternative. You can make a rule that they're not > allowed to abstain (or some variant, like you have to choose someone > else if you need to recuse yourself). I'm a member of such a body in > fact (the San Francisco Elections Commission). If a member wants to > abstain, a member has to request it, and then the Commission has to > pass a majority vote to let the person to abstain. But we wouldn't > even have to have that extra provision. > > --Chris > > > > And we'll keep replacing them until they stop tying. But > > we'll probably run out of volunteers after the first round of > impeachments. > > > > Sneakier: add a rule that if the Elders tie, then the choice has to be > made > > by the President of the PSF. Which, by sheer coincidence, is Guido :-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Jul 16 15:38:44 2018 From: brett at python.org (Brett Cannon) Date: Mon, 16 Jul 2018 12:38:44 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: On Sun, 15 Jul 2018 at 19:38 Tim Peters wrote: > [Tim] > >> If they tied, that's fine too. Ties favor the status quo (same as if the >>> proposed change had been rejected). For that reason, I'm not even wedded >>> to an odd number. >>> >> > [Brett Cannon] > >> That's a good point. Since this is typically going to be a yes/no >> question instead of an A/B question, ties that go in favour of the status >> quo aren't a stalemate issue. >> > > Thanks for reading my mind :-) I certainly didn't spell it out. > Just glad I still have the knack for it on occasion. :) > > Predictably contentious A/B issues, like how to allocate limited resources > (how much do we spend on grants vs sponsoring conferences?), are mostly in > the PSF's court. Likewise A/B decisions with legal consequences (now that > the DPRK has ruled the PSF license counterrevolutionary, which license > should we use there instead?). > > Guido's most visible (well, to us committers) BDFL role has been in > "yes/no", "go/nogo" language/library design questions, which don't even > overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a > few) very active and/or loquacious posters. > IOW the design guidance he provided as the discussion progressed and his thoughts evolved/formed on the topic. > > Those "small" pronouncements typically go by with little notice except by > those shut down, but may well be crucial in keeping productive discussion > going at all. And they need to be timely to do any good. Whoever makes > such decisions needs to be down in the mud, wrestling with the issues while > they're hot topics, not judging at leisure weeks (or even days) later. > > I'm not sure "a committee" can do that at all. Then again, there seems to > be consensus that the current PEP discussion process is sometimes broken > anyway, even with a BDFL. > There are definitely perks to having a BDFL such as timely shutdown of side threads, consistency/guidance in design, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Mon Jul 16 16:12:32 2018 From: tim.peters at gmail.com (Tim Peters) Date: Mon, 16 Jul 2018 15:12:32 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: [Chris Jerdonek] > ... But one case in the back of my mind that may have prompted my reply and that might qualify was when there was a randomness-related >> security issue in the summer of 2016. I believe this is the thread >> that kicked it off (subject line: "BDFL ruling request: should we >> block forever waiting for high-quality random bits?"): >> https://mail.python.org/pipermail/python-dev/2016-June/144939.html >> >> Things got so contentious on python-dev that, IIRC, at least one core >> developer quit or was threatening to quit, and it prompted the >> creation of a new mailing list (Security-SIG) due to the volume of >> emails. See the number of emails the thread above spurred alone: >> https://mail.python.org/pipermail/python-dev/2016-June/thread.html >> >> To resolve the split, Guido ultimately chose PEP 524 over PEP 522. > > [Brett Cannon] > But that's an extremely rare case. And even then, I would assume the > council would have picked a BDFL delegate who would have made the utlimate > decision. So even in a stalemate there's a way out by the council saying > "not it" and pointing at someone else. In the original message of that thread, the release manager had already made a decision, but was getting so much opposition to his position that he appealed to Guido. But the RM already had authority to make the decision. Highly contentious decisions will always be appealed to the full height of whatever bureaucracy exists ;-) It turned out Guido agreed with the RM in this case. The PEPs came later, and were much less contentious than the original under-time-pressure decision. Regardless, I agree with Chris that it would be good to spell out what to do if the Ultimate Authority can't, or won't, reach a decision on their own. Indeed, that's the exact position Guido just left us in ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Mon Jul 16 16:38:33 2018 From: tim.peters at gmail.com (Tim Peters) Date: Mon, 16 Jul 2018 15:38:33 -0500 Subject: [python-committers] Transfer of power In-Reply-To: References: <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org> Message-ID: [Antoine] > I know what python-ideas can be like routinely (I do read it at times). > > I think the general idea of my comment is that the signal-to-noise ratio > on python-ideas is so low that, whether or not Guido had remained BDFL, > we would still have a productivity problem to solve there. > I'm much more focused here on the underappreciated roles Guido played in the process than the medium in which the process occurred. Regardless of whether it occurs on a high or low S/N mailing list, a wiki, a Github issue, ... a PEP proceeds from freewheeling brainstorming to python-dev-worthy perfection ;-) incrementally, and along the way "yes, this idea is definitely in - stop arguing about it' and "no, that idea is dead - stop repeating it" pronouncements need to be made. When that doesn't happen by universal consensus, it needs to be forced by _some_ mechanism. If the people involved vote on what they do and don't like, then we have design by committee. I'd much rather have a BDFL-workalike. But in that case, they need to be involved and responsive, not just sit back waiting for "a crisis" to rise to their rarefied level. The latter is indeed important for a BDFL-workalike too, but the point here has been that Guido did much more than _just_ put out raging fires, via the multitude of largely unheralded little pronouncements he routinely made to help PEPs-in-progress continue making progress. And to kill PEPs before they were written when he knew he'd never accept the core idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack.jansen at cwi.nl Mon Jul 16 18:21:43 2018 From: jack.jansen at cwi.nl (Jack Jansen) Date: Tue, 17 Jul 2018 00:21:43 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: Message-ID: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> > On 16-Jul-2018, at 04:38 , Tim Peters wrote: > > Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters. This is a very good point. And it is a role that is not ?formally encoded? anywhere, and one that I think cannot be formally encoded. And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn?t going to happen. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Jul 16 18:59:11 2018 From: brett at python.org (Brett Cannon) Date: Mon, 16 Jul 2018 15:59:11 -0700 Subject: [python-committers] Transfer of power In-Reply-To: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> References: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> Message-ID: On Mon, 16 Jul 2018 at 15:21 Jack Jansen wrote: > > > On 16-Jul-2018, at 04:38 , Tim Peters wrote: > > Guido's most visible (well, to us committers) BDFL role has been in > "yes/no", "go/nogo" language/library design questions, which don't even > overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a > few) very active and/or loquacious posters. > > > This is a very good point. And it is a role that is not ?formally encoded? > anywhere, and one that I think cannot be formally encoded. > > And actually I wonder whether this role could be fulfilled by any > person/committee/procedure other than Guido himself. Which means that in > future we should prepare for doing without this role. Which will lead to > more contentious issues being put in front of the > whatever-body-replaces-the-bdfl, because the early weeding out isn?t going > to happen. > I'm not sure if I agree with that in this case. In terms of this specific case of quickly shutting down dead-end discussions, that comes down to time and dedication and maybe a decently broad knowledge base to grasp a concept quickly enough or ability to learn on their feet. But those are not magical traits of Guido's. To me the question is whether we can replace Guido's design sensibilities. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Mon Jul 16 20:02:13 2018 From: tim.peters at gmail.com (Tim Peters) Date: Mon, 16 Jul 2018 19:02:13 -0500 Subject: [python-committers] Transfer of power In-Reply-To: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> References: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> Message-ID: [Tim] > Guido's most visible (well, to us committers) BDFL role has been in > "yes/no", "go/nogo" language/library design questions, which don't even > overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a > few) very active and/or loquacious posters. > > [Jack Jansen] > This is a very good point. And it is a role that is not ?formally encoded? > anywhere, and one that I think cannot be formally encoded. > > And actually I wonder whether this role could be fulfilled by any > person/committee/procedure other than Guido himself. Which means that in > future we should prepare for doing without this role. Which will lead to > more contentious issues being put in front of the > whatever-body-replaces-the-bdfl, because the early weeding out isn?t going > to happen. > > > I'm not quite as hopeless ;-) Most notions on python-ideas are dropped voluntarily, after it's clear that they generate little interest - or massive hostility ;-) For one that proceeds to a preliminary PEP, I think it would be wise for the Elders (whatever it's called) to appoint a BDFL-workalike for that specific PEP. Which may or may not be an Elder. That person would need to commit to staying current with the PEP's progress, and would have final "yes/no", "this/that", ... authority on all the design decisions on the way to polishing the PEP. But not the final accept/reject decision (if the PEP survives that long). That would do more than "just" provide a BDFL-workalike for the PEP, it would also provide a kind of mentor for PEP writers sometimes pretty clueless about what the community expects from a PEP. It wouldn't provide a consistent design vision _across_ PEPs, but would at least leave each PEP coherent on its own in _some_ experienced developer's mind. Leaving the final accept/reject to someone else is, in part, a nod to that even a self-coherent PEP may be best rejected for clashing with a broader vision. With a bit of luck, PEP authors and their BDFL-workalikes will come to despise each other so swiftly that no PEP will ever finish again ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Jul 16 22:07:16 2018 From: brett at python.org (Brett Cannon) Date: Mon, 16 Jul 2018 19:07:16 -0700 Subject: [python-committers] Transfer of power In-Reply-To: References: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> Message-ID: On Mon, Jul 16, 2018, 17:02 Tim Peters, wrote: > [Tim] > >> Guido's most visible (well, to us committers) BDFL role has been in >> "yes/no", "go/nogo" language/library design questions, which don't even >> overlap with the PSF's proper concerns. >> >> But I'm not sure it's fully appreciated just how active Guido has been in >> those at times. The "accepted/rejected" at the end of major PEPs is just a >> small part of that. Along the way, e.g., it's been pretty common to see a >> "Save your breath. That's not going to happen." from Guido to end a >> distracting alternative (sub)proposal persistently promoted by one (or a >> few) very active and/or loquacious posters. >> >> [Jack Jansen] > > >> This is a very good point. And it is a role that is not ?formally >> encoded? anywhere, and one that I think cannot be formally encoded. >> >> And actually I wonder whether this role could be fulfilled by any >> person/committee/procedure other than Guido himself. Which means that in >> future we should prepare for doing without this role. Which will lead to >> more contentious issues being put in front of the >> whatever-body-replaces-the-bdfl, because the early weeding out isn?t going >> to happen. >> >> >> I'm not quite as hopeless ;-) Most notions on python-ideas are dropped > voluntarily, after it's clear that they generate little interest - or > massive hostility ;-) > > For one that proceeds to a preliminary PEP, I think it would be wise for > the Elders (whatever it's called) to appoint a BDFL-workalike for that > specific PEP. Which may or may not be an Elder. That person would need to > commit to staying current with the PEP's progress, and would have final > "yes/no", "this/that", ... authority on all the design decisions on the > way to polishing the PEP. But not the final accept/reject decision (if the > PEP survives that long). > > That would do more than "just" provide a BDFL-workalike for the PEP, it > would also provide a kind of mentor for PEP writers sometimes pretty > clueless about what the community expects from a PEP. > > It wouldn't provide a consistent design vision _across_ PEPs, but would at > least leave each PEP coherent on its own in _some_ experienced developer's > mind. Leaving the final accept/reject to someone else is, in part, a nod > to that even a self-coherent PEP may be best rejected for clashing with a > broader vision. > This ties into the core dev sponsor idea that got floated where all inexperienced PEP authors need someone to sign up to shepherd them through the process. That way everything is more structured and, with this idea, also more uniform. -Brett > With a bit of luck, PEP authors and their BDFL-workalikes will come to > despise each other so swiftly that no PEP will ever finish again ;-) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Jul 17 03:36:32 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 17 Jul 2018 09:36:32 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> Message-ID: <4b495c90-817a-2ecb-7a3c-7a2182d690d1@python.org> Le 17/07/2018 ? 04:07, Brett Cannon a ?crit?: > > This ties into the core dev sponsor idea that got floated where all > inexperienced PEP authors need someone to sign up to shepherd them > through the process. That way everything is more structured and, with > this idea, also more uniform. This sounds like a reasonable policy. We could stipulate that a non-core developer can't get a PEP examined if they didn't go through the shepherding process (which implies there exists a core developer motivated enough to shepherd them, which may help weed out the silliest ideas). Regards Antoine. From jack.jansen at cwi.nl Tue Jul 17 05:33:22 2018 From: jack.jansen at cwi.nl (Jack Jansen) Date: Tue, 17 Jul 2018 11:33:22 +0200 Subject: [python-committers] Transfer of power In-Reply-To: References: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> Message-ID: <3BE02932-AEA8-4B29-8ACA-B5CFD1330AA6@cwi.nl> > On 17 Jul 2018, at 02:02, Tim Peters wrote: > > [Tim] >> Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns. >> >> But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters. > [Jack Jansen] > >> This is a very good point. And it is a role that is not ?formally encoded? anywhere, and one that I think cannot be formally encoded. >> >> And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn?t going to happen. >> > I'm not quite as hopeless ;-) Most notions on python-ideas are dropped voluntarily, after it's clear that they generate little interest - or massive hostility ;-) > > For one that proceeds to a preliminary PEP, I think it would be wise for the Elders (whatever it's called) to appoint a BDFL-workalike for that specific PEP. Which may or may not be an Elder. That person would need to commit to staying current with the PEP's progress, and would have final "yes/no", "this/that", ... authority on all the design decisions on the way to polishing the PEP. But not the final accept/reject decision (if the PEP survives that long). I?m not hopeless either:-) But the point I was trying to make is that Guido has a standing _within the wider community_ that will cause people to sit and ponder his replies, in stead of quickly replying and going into the defensive. The Elders will probably miss that standing in the community at large, at least for the time being. So I think we should prepare for more and longer heated discussions, and make sure that the procedures for the eventual decision are such that people can generally live with the outcome and don?t turn their back on the community. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From doug at doughellmann.com Tue Jul 17 08:50:01 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 17 Jul 2018 08:50:01 -0400 Subject: [python-committers] Transfer of power In-Reply-To: <3BE02932-AEA8-4B29-8ACA-B5CFD1330AA6@cwi.nl> References: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl> <3BE02932-AEA8-4B29-8ACA-B5CFD1330AA6@cwi.nl> Message-ID: <1531831551-sup-1177@lrrr.local> Excerpts from Jack Jansen's message of 2018-07-17 11:33:22 +0200: > > > On 17 Jul 2018, at 02:02, Tim Peters wrote: > > > > [Tim] > >> Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns. > >> > >> But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters. > > [Jack Jansen] > > > >> This is a very good point. And it is a role that is not ?formally encoded? anywhere, and one that I think cannot be formally encoded. > >> > >> And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn?t going to happen. > >> > > I'm not quite as hopeless ;-) Most notions on python-ideas are dropped voluntarily, after it's clear that they generate little interest - or massive hostility ;-) > > > > For one that proceeds to a preliminary PEP, I think it would be wise for the Elders (whatever it's called) to appoint a BDFL-workalike for that specific PEP. Which may or may not be an Elder. That person would need to commit to staying current with the PEP's progress, and would have final "yes/no", "this/that", ... authority on all the design decisions on the way to polishing the PEP. But not the final accept/reject decision (if the PEP survives that long). > > I?m not hopeless either:-) > > But the point I was trying to make is that Guido has a standing _within the wider community_ that will cause people to sit and ponder his replies, in stead of quickly replying and going into the defensive. The Elders will probably miss that standing in the community at large, at least for the time being. So I think we should prepare for more and longer heated discussions, and make sure that the procedures for the eventual decision are such that people can generally live with the outcome and don?t turn their back on the community. I agree that having a consensus-based process that everyone agrees to use and abide by is important. Perhaps we can also take change the process to start eliminating the culture that leads to so much heat in the first place. Healthy debate is all well and good, but it seems like we've had a couple of examples of things getting out of hand recently. Doug From barry at python.org Tue Jul 17 22:02:46 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 17 Jul 2018 19:02:46 -0700 Subject: [python-committers] An alternative governance model Message-ID: I?d like to propose an alternative model, and with it a succession plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it proposes to not actually change that much! TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you?ll have to read on for the big reveal. Why keep a singular BDFL? I think it?s clear that no one can completely replace Guido, and neither should we try, nor do we need to. The discussion to date has explored refactoring many of the roles that the BDFL has, and that?s all excellent, especially to reduce the burden and burnout factor of the NBDFL. But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term. A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language? ?Bob Smith, on Behalf of the GUIDO? is IMHO less obviously and unquestionably authoritative than ?Alice Jones, BDFL?. This also comes into play for shutting down discussions early. With a committee, it?s possible that you?ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python?s evolution. Alice Jones may say ?No, that?s not gonna happen? only to be overruled or undermined by Bob Smith?s ?That?s a good idea?. Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention. I also think a council will be much more risk adverse than a singular BDFL, and that?s not necessarily a good thing. While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. I hope Guido won?t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding. The question for any new leader is: What is your vision for Python? This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades. Yes, Python is a mature language, but it?s far from stagnant. Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn?t or couldn?t always clearly articulate them. The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that?s okay! A strong vision is better than no vision. Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment. As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo? Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance position, to actually move the language and its primary implementation forward? I?m not so sure. For these reasons I propose that we retain a singular BDFL. The formation of a formal Council is still a good idea! I just think that it shouldn?t be the ultimate arbiter of decisions for Python. So what would the Council do? - It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn?t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power. - The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They?d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL. - The council would serve as trusted advisors to the NBDFL. The BDFL won?t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions. We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It?s just that the roles and responsibilities would differ. The COA wouldn?t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors. I definitely have my own thoughts on an initial make-up of said council, but I?ll reserve that for later. If you?ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be? (drum roll)? Brett Cannon I?ve long said ? somewhat in jest, since I never expected Guido to actually ever retire! ? that Brett would be my choice for the next BDFL. I think he?s the perfect candidate, and he?s already demonstrated qualities that I think make him a fantastic leader. He?s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he?s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He?s not afraid to say what?s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn?t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He?ll be able to delegate where appropriate, and make definitive pronouncements where needed. Before you ask, yes I did check with Brett before making this proposal and he didn?t shoot it down. He may have specific requirements for accepting the position, but I?ll let him articulate those. I?m confident they would come across as completely reasonable. :) To summarize: * We retain a singular BDFL to lead Python * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL. That?s it in a nutshell. Thanks for listening. 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 eric at trueblade.com Tue Jul 17 22:15:34 2018 From: eric at trueblade.com (Eric V. Smith) Date: Tue, 17 Jul 2018 22:15:34 -0400 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On 7/17/2018 10:02 PM, Barry Warsaw wrote: > I?d like to propose an alternative model, and with it a succession plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it proposes to not actually change that much! > > TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you?ll have to read on for the big reveal. I've come to this same conclusion. I think Brett would be a good choice, and I'd support him, but I think the more important part is that it be a single person. And I think the succession plan is important, too. I think ?ukasz was alluding to this earlier (or maybe I'm projecting): who's to say that the next BDFL is legitimate? If we put together a plan, and Guido blesses it, that makes the plan legitimate, and then the plan gets executed and makes NBDFL legitimate. Eric > > Why keep a singular BDFL? I think it?s clear that no one can completely replace Guido, and neither should we try, nor do we need to. The discussion to date has explored refactoring many of the roles that the BDFL has, and that?s all excellent, especially to reduce the burden and burnout factor of the NBDFL. But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term. > > A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language? ?Bob Smith, on Behalf of the GUIDO? is IMHO less obviously and unquestionably authoritative than ?Alice Jones, BDFL?. > > This also comes into play for shutting down discussions early. With a committee, it?s possible that you?ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python?s evolution. Alice Jones may say ?No, that?s not gonna happen? only to be overruled or undermined by Bob Smith?s ?That?s a good idea?. > > Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention. > > I also think a council will be much more risk adverse than a singular BDFL, and that?s not necessarily a good thing. While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. > > I hope Guido won?t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding. The question for any new leader is: > > What is your vision for Python? > > This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades. Yes, Python is a mature language, but it?s far from stagnant. Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn?t or couldn?t always clearly articulate them. The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that?s okay! A strong vision is better than no vision. Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment. As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo? > > Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance position, to actually move the language and its primary implementation forward? I?m not so sure. > > For these reasons I propose that we retain a singular BDFL. > > The formation of a formal Council is still a good idea! I just think that it shouldn?t be the ultimate arbiter of decisions for Python. So what would the Council do? > > - It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn?t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power. > > - The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They?d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL. > > - The council would serve as trusted advisors to the NBDFL. The BDFL won?t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions. > > We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It?s just that the roles and responsibilities would differ. The COA wouldn?t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors. > > I definitely have my own thoughts on an initial make-up of said council, but I?ll reserve that for later. > > If you?ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be? (drum roll)? > > Brett Cannon > > I?ve long said ? somewhat in jest, since I never expected Guido to actually ever retire! ? that Brett would be my choice for the next BDFL. I think he?s the perfect candidate, and he?s already demonstrated qualities that I think make him a fantastic leader. He?s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he?s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He?s not afraid to say what?s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn?t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He?ll be able to delegate where appropriate, and make definitive pronouncements where needed. > > Before you ask, yes I did check with Brett before making this proposal and he didn?t shoot it down. He may have specific requirements for accepting the position, but I?ll let him articulate those. I?m confident they would come across as completely reasonable. :) > > To summarize: > > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL. > > That?s it in a nutshell. Thanks for listening. > > 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 nad at python.org Tue Jul 17 22:38:34 2018 From: nad at python.org (Ned Deily) Date: Tue, 17 Jul 2018 22:38:34 -0400 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: <19714581-A3B1-4473-B362-F70F34C575A8@python.org> On Jul 17, 2018, at 22:15, Eric V. Smith wrote: > On 7/17/2018 10:02 PM, Barry Warsaw wrote: >> I?d like to propose an alternative model, and with it a succession plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it proposes to not actually change that much! >> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you?ll have to read on for the big reveal. > I've come to this same conclusion. I think Brett would be a good choice, and I'd support him, but I think the more important part is that it be a single person. +100. I think Python owes much of its success to both Guido's ongoing vision *and* his clear role as leader. Up to now, we have not had much experience governing by committee or council and I think it may be a mistake to try to implement that now (although we *do* have some successful experience with informal council of advisors models, for instance, in the release management area). While it wouldn't necessarily be a good choice for many (most?) open-source projects, I think the NBDFL-plus-advisors model would work well in the relatively congenial and respectful environment of the current Python committers community. That's not to say that we won't collectively decide down the road that we want to try something different but trying to keep this really important transition (i.e. from Guido) as simple as possible initially would be a really smart thing to do. > And I think the succession plan is important, too. I think ?ukasz was alluding to this earlier (or maybe I'm projecting): who's to say that the next BDFL is legitimate? If we put together a plan, and Guido blesses it, that makes the plan legitimate, and then the plan gets executed and makes NBDFL legitimate. That, too. -- Ned Deily nad at python.org -- [] From willingc at gmail.com Tue Jul 17 23:20:23 2018 From: willingc at gmail.com (Carol Willing) Date: Tue, 17 Jul 2018 20:20:23 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <19714581-A3B1-4473-B362-F70F34C575A8@python.org> References: <19714581-A3B1-4473-B362-F70F34C575A8@python.org> Message-ID: I wholeheartedly agree with Barry's suggestion. It offers a single person who can communicate the design vision. While the support of a council will help spread out the work and provides a great way to grow future leaders and a smooth transition if for any reason (family, work, health, etc.) the new BDFL has to take a break. On Tue, Jul 17, 2018, 7:38 PM Ned Deily wrote: > On Jul 17, 2018, at 22:15, Eric V. Smith wrote: > > On 7/17/2018 10:02 PM, Barry Warsaw wrote: > >> I?d like to propose an alternative model, and with it a succession > plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in > that it proposes to not actually change that much! > >> TL;DR: I propose keeping a singular BDFL and adding a Council of > Advisors that helps the BDFL in various capacities, with additional > responsibilities. I also have someone specific in mind for the NBDFL, but > you?ll have to read on for the big reveal. > > I've come to this same conclusion. I think Brett would be a good choice, > and I'd support him, but I think the more important part is that it be a > single person. > > +100. I think Python owes much of its success to both Guido's ongoing > vision *and* his clear role as leader. Up to now, we have not had much > experience governing by committee or council and I think it may be a > mistake to try to implement that now (although we *do* have some successful > experience with informal council of advisors models, for instance, in the > release management area). While it wouldn't necessarily be a good choice > for many (most?) open-source projects, I think the NBDFL-plus-advisors > model would work well in the relatively congenial and respectful > environment of the current Python committers community. That's not to say > that we won't collectively decide down the road that we want to try > something different but trying to keep this really important transition > (i.e. from Guido) as simple as possible initially would be a really smart > thing to do. > > > And I think the succession plan is important, too. I think ?ukasz was > alluding to this earlier (or maybe I'm projecting): who's to say that the > next BDFL is legitimate? If we put together a plan, and Guido blesses it, > that makes the plan legitimate, and then the plan gets executed and makes > NBDFL legitimate. > > That, too. > > -- > Ned Deily > nad at python.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 aleax at google.com Tue Jul 17 23:33:58 2018 From: aleax at google.com (Alex Martelli) Date: Tue, 17 Jul 2018 20:33:58 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: Barry, you offer truly compelling arguments for a new BDFL as GvR's successor -- FWIW, you've convinced me. And Brett would be an absolutely outstanding pick as that "new BDFL" -- on this, I need no convincing. Alex On Tue, Jul 17, 2018 at 7:08 PM Barry Warsaw wrote: > I?d like to propose an alternative model, and with it a succession plan, > that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it > proposes to not actually change that much! > > TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors > that helps the BDFL in various capacities, with additional > responsibilities. I also have someone specific in mind for the NBDFL, but > you?ll have to read on for the big reveal. > > Why keep a singular BDFL? I think it?s clear that no one can completely > replace Guido, and neither should we try, nor do we need to. The > discussion to date has explored refactoring many of the roles that the BDFL > has, and that?s all excellent, especially to reduce the burden and burnout > factor of the NBDFL. But I think having a singular BDFL making the tough > decisions, with the support and help of the community, is in the best > interests of Python over the long term. > > A singular BDFL provides clear leadership. With a council of elders, it > will be more difficult to communicate both to the Python community, and to > the larger, more peripheral user base, that any particular individual has > the authority to make decisions. Regardless of size, there would > ultimately be some one person communicating any council decision. There > will inevitably be ambiguity as to the authority of said decision. How > will folks, especially on the periphery, know that Alice Jones or Bob Smith > are members of the council and can speak authoritatively on decisions for > the language? ?Bob Smith, on Behalf of the GUIDO? is IMHO less obviously > and unquestionably authoritative than ?Alice Jones, BDFL?. > > This also comes into play for shutting down discussions early. With a > committee, it?s possible that you?ll have some disagreement among the > members as to whether a discussion is fruitful or not, whether it rehashes > settled questions, or whether the change fits into the overall direction > for Python?s evolution. Alice Jones may say ?No, that?s not gonna happen? > only to be overruled or undermined by Bob Smith?s ?That?s a good idea?. > > Taken together, these fall under the umbrella of having one voice for the > decision making process. It may be possible for consensus within the > council to come across as a single voice, but I think it will generally be > harder. A council also opens the door for more back-channel lobbying of a > sympathetic member. Yes, such lobbying is possible with a BDFL, but at > least there should be less contention. > > I also think a council will be much more risk adverse than a singular > BDFL, and that?s not necessarily a good thing. While moratoriums and a > more conservative approach to change may be appropriate at times, I would > prefer those to be deliberate decisions for a specific purpose, rather than > the unintended outcome of groupthink or lack of consensus. A singular BDFL > with support from the community will have more authority to make decisions > which probably will never be universally accepted, and much less prone to > vapor lock due to lack of consensus or internal bickering. > > I hope Guido won?t mind me relating a comment of his that has really > resonated with me over the last few days, and for which I think a singular > BDFL will be much more adept at communicating and shepherding. The > question for any new leader is: > > What is your vision for Python? > > This question keeps coming to mind as I think about how the evolution of > the language will be governed over the next few years or decades. Yes, > Python is a mature language, but it?s far from stagnant. Guido always had > a very clear vision of what Python should be, where it should go, and how > new proposed features (or other changes to the Python ecosystem) fit into > that vision, even if he didn?t or couldn?t always clearly articulate them. > The NBDFL will necessarily have a different vision than Guido, and I think > even he would agree that that?s okay! A strong vision is better than no > vision. Python must continue to grow and evolve if it is to stay relevant > in a rapidly change technology environment. As an almost 30 year old > language, Python is already facing challenges; how will that vision address > those challenges, even if to explicitly choose the status quo? > > Will a council be able to articular, express, communicate, adapt, and > follow through on that vision? Will a council be able to evaluate a > proposed change as it supports or detracts from that vision? Will a > council be able to break out of a primarily maintenance position, to > actually move the language and its primary implementation forward? I?m not > so sure. > > For these reasons I propose that we retain a singular BDFL. > > The formation of a formal Council is still a good idea! I just think that > it shouldn?t be the ultimate arbiter of decisions for Python. So what > would the Council do? > > - It would serve as a check on the BDFL. If Bob Smith were one day > employed by Evil Corp. and started making decisions that were directly > detrimental to Python, the council should be able to effectively impeach. > There should be checks and balances on this power, the BDFL shouldn?t > continuously fear a coup, and impeachment will hopefully never be invoked, > but the council can serve as the voice of the community for when the BDFL > is abusing their power. > > - The council would select the next BDFL if and when that time comes. No > one will serve forever, so a clear succession plan should be in place. To > avoid the tyranny of the majority, the council would serve similarly to a > board of directors. They?d search for candidates, match them against well > defined criteria, conduct interviews, serve as the voice of the community, > and eventually select the N+1BDFL. > > - The council would serve as trusted advisors to the NBDFL. The BDFL > won?t be out there all alone! The council will provide advice when > requested, and back up the BDFL when needed. The council helps legitimize > the BDFL and their decisions. > > We can debate how the initial council is selected, its make up, number of > members, term limits, etc. I think much of the current discussion about a > BDFL-like council would satisfy the requirements for a Council of > Advisors. It?s just that the roles and responsibilities would differ. The > COA wouldn?t make the decisions, but it would help the BDFL make the best > decisions possible, and have their back against any detractors. > > I definitely have my own thoughts on an initial make-up of said council, > but I?ll reserve that for later. > > If you?ve read this far - thank you! Now for the big reveal. I think the > Next BDFL should be? (drum roll)? > > Brett Cannon > > I?ve long said ? somewhat in jest, since I never expected Guido to > actually ever retire! ? that Brett would be my choice for the next BDFL. I > think he?s the perfect candidate, and he?s already demonstrated qualities > that I think make him a fantastic leader. He?s smart, compassionate, > passionate, respectful, young, tall, and has the right mix of technical > excellence and social skills. He believes deeply in diversity and > community. As he?s shown with the decisions to move first to Mercurial, > then to git/GitLab, he isn't afraid to make difficult decisions that he > knows not everyone will agree with (and I say that having advocated the > losing choice more than once :). He?s not afraid to say what?s on his > mind. I think he can clearly articulate a Vision. He shares many of these > same qualities with Guido, while being a different person with different > sensibilities. And that is not only fine, but IMHO a *good* thing. We can > trust his stewardship, and he already has legitimacy as a senior decision > maker in the Python ecosystem. He has a wide technical knowledge of Python > and its C implementation, and yet he knows what he doesn?t know. He has > good relationships with most core devs, and is a well-known voice within > the wider community. He?ll be able to delegate where appropriate, and make > definitive pronouncements where needed. > > Before you ask, yes I did check with Brett before making this proposal and > he didn?t shoot it down. He may have specific requirements for accepting > the position, but I?ll let him articulate those. I?m confident they would > come across as completely reasonable. :) > > To summarize: > > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection > committee for succession, and a check against the BDFL. > > That?s it in a nutshell. Thanks for listening. > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.jerdonek at gmail.com Wed Jul 18 01:23:32 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Tue, 17 Jul 2018 22:23:32 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: I apologize if this has already been mentioned on a different thread, but something else I like about the BDFL model is that it avoids "design by committee." I think Python owes a lot of its success to its coherence as a language, which is in large part due to Guido's vision, as well as making the hard decisions along the way. Of course, it will be hard to fill his shoes, but fortunately we have many good people to choose from. The BDFL is in some ways the human embodiment of the Zen of Python, in that they're the last line of defense to ensure Python remains true to its Zen. --Chris On Tue, Jul 17, 2018 at 8:33 PM, Alex Martelli via python-committers wrote: > Barry, you offer truly compelling arguments for a new BDFL as GvR's > successor -- FWIW, you've convinced me. > > And Brett would be an absolutely outstanding pick as that "new BDFL" -- on > this, I need no convincing. > > > Alex > > On Tue, Jul 17, 2018 at 7:08 PM Barry Warsaw wrote: >> >> I?d like to propose an alternative model, and with it a succession plan, >> that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it >> proposes to not actually change that much! >> >> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors >> that helps the BDFL in various capacities, with additional responsibilities. >> I also have someone specific in mind for the NBDFL, but you?ll have to read >> on for the big reveal. >> >> Why keep a singular BDFL? I think it?s clear that no one can completely >> replace Guido, and neither should we try, nor do we need to. The discussion >> to date has explored refactoring many of the roles that the BDFL has, and >> that?s all excellent, especially to reduce the burden and burnout factor of >> the NBDFL. But I think having a singular BDFL making the tough decisions, >> with the support and help of the community, is in the best interests of >> Python over the long term. >> >> A singular BDFL provides clear leadership. With a council of elders, it >> will be more difficult to communicate both to the Python community, and to >> the larger, more peripheral user base, that any particular individual has >> the authority to make decisions. Regardless of size, there would ultimately >> be some one person communicating any council decision. There will >> inevitably be ambiguity as to the authority of said decision. How will >> folks, especially on the periphery, know that Alice Jones or Bob Smith are >> members of the council and can speak authoritatively on decisions for the >> language? ?Bob Smith, on Behalf of the GUIDO? is IMHO less obviously and >> unquestionably authoritative than ?Alice Jones, BDFL?. >> >> This also comes into play for shutting down discussions early. With a >> committee, it?s possible that you?ll have some disagreement among the >> members as to whether a discussion is fruitful or not, whether it rehashes >> settled questions, or whether the change fits into the overall direction for >> Python?s evolution. Alice Jones may say ?No, that?s not gonna happen? only >> to be overruled or undermined by Bob Smith?s ?That?s a good idea?. >> >> Taken together, these fall under the umbrella of having one voice for the >> decision making process. It may be possible for consensus within the >> council to come across as a single voice, but I think it will generally be >> harder. A council also opens the door for more back-channel lobbying of a >> sympathetic member. Yes, such lobbying is possible with a BDFL, but at >> least there should be less contention. >> >> I also think a council will be much more risk adverse than a singular >> BDFL, and that?s not necessarily a good thing. While moratoriums and a more >> conservative approach to change may be appropriate at times, I would prefer >> those to be deliberate decisions for a specific purpose, rather than the >> unintended outcome of groupthink or lack of consensus. A singular BDFL with >> support from the community will have more authority to make decisions which >> probably will never be universally accepted, and much less prone to vapor >> lock due to lack of consensus or internal bickering. >> >> I hope Guido won?t mind me relating a comment of his that has really >> resonated with me over the last few days, and for which I think a singular >> BDFL will be much more adept at communicating and shepherding. The question >> for any new leader is: >> >> What is your vision for Python? >> >> This question keeps coming to mind as I think about how the evolution of >> the language will be governed over the next few years or decades. Yes, >> Python is a mature language, but it?s far from stagnant. Guido always had a >> very clear vision of what Python should be, where it should go, and how new >> proposed features (or other changes to the Python ecosystem) fit into that >> vision, even if he didn?t or couldn?t always clearly articulate them. The >> NBDFL will necessarily have a different vision than Guido, and I think even >> he would agree that that?s okay! A strong vision is better than no vision. >> Python must continue to grow and evolve if it is to stay relevant in a >> rapidly change technology environment. As an almost 30 year old language, >> Python is already facing challenges; how will that vision address those >> challenges, even if to explicitly choose the status quo? >> >> Will a council be able to articular, express, communicate, adapt, and >> follow through on that vision? Will a council be able to evaluate a >> proposed change as it supports or detracts from that vision? Will a council >> be able to break out of a primarily maintenance position, to actually move >> the language and its primary implementation forward? I?m not so sure. >> >> For these reasons I propose that we retain a singular BDFL. >> >> The formation of a formal Council is still a good idea! I just think that >> it shouldn?t be the ultimate arbiter of decisions for Python. So what would >> the Council do? >> >> - It would serve as a check on the BDFL. If Bob Smith were one day >> employed by Evil Corp. and started making decisions that were directly >> detrimental to Python, the council should be able to effectively impeach. >> There should be checks and balances on this power, the BDFL shouldn?t >> continuously fear a coup, and impeachment will hopefully never be invoked, >> but the council can serve as the voice of the community for when the BDFL is >> abusing their power. >> >> - The council would select the next BDFL if and when that time comes. No >> one will serve forever, so a clear succession plan should be in place. To >> avoid the tyranny of the majority, the council would serve similarly to a >> board of directors. They?d search for candidates, match them against well >> defined criteria, conduct interviews, serve as the voice of the community, >> and eventually select the N+1BDFL. >> >> - The council would serve as trusted advisors to the NBDFL. The BDFL >> won?t be out there all alone! The council will provide advice when >> requested, and back up the BDFL when needed. The council helps legitimize >> the BDFL and their decisions. >> >> We can debate how the initial council is selected, its make up, number of >> members, term limits, etc. I think much of the current discussion about a >> BDFL-like council would satisfy the requirements for a Council of Advisors. >> It?s just that the roles and responsibilities would differ. The COA >> wouldn?t make the decisions, but it would help the BDFL make the best >> decisions possible, and have their back against any detractors. >> >> I definitely have my own thoughts on an initial make-up of said council, >> but I?ll reserve that for later. >> >> If you?ve read this far - thank you! Now for the big reveal. I think the >> Next BDFL should be? (drum roll)? >> >> Brett Cannon >> >> I?ve long said ? somewhat in jest, since I never expected Guido to >> actually ever retire! ? that Brett would be my choice for the next BDFL. I >> think he?s the perfect candidate, and he?s already demonstrated qualities >> that I think make him a fantastic leader. He?s smart, compassionate, >> passionate, respectful, young, tall, and has the right mix of technical >> excellence and social skills. He believes deeply in diversity and >> community. As he?s shown with the decisions to move first to Mercurial, >> then to git/GitLab, he isn't afraid to make difficult decisions that he >> knows not everyone will agree with (and I say that having advocated the >> losing choice more than once :). He?s not afraid to say what?s on his mind. >> I think he can clearly articulate a Vision. He shares many of these same >> qualities with Guido, while being a different person with different >> sensibilities. And that is not only fine, but IMHO a *good* thing. We can >> trust his stewardship, and he already has legitimacy as a senior decision >> maker in the Python ecosystem. He has a wide technical knowledge of Python >> and its C implementation, and yet he knows what he doesn?t know. He has >> good relationships with most core devs, and is a well-known voice within the >> wider community. He?ll be able to delegate where appropriate, and make >> definitive pronouncements where needed. >> >> Before you ask, yes I did check with Brett before making this proposal and >> he didn?t shoot it down. He may have specific requirements for accepting >> the position, but I?ll let him articulate those. I?m confident they would >> come across as completely reasonable. :) >> >> To summarize: >> >> * We retain a singular BDFL to lead Python >> * A Council is selected to serve as advisors to the BDFL, a selection >> committee for succession, and a check against the BDFL. >> >> That?s it in a nutshell. Thanks for listening. >> >> 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 senthil at uthcode.com Wed Jul 18 01:37:18 2018 From: senthil at uthcode.com (Senthil Kumaran) Date: Tue, 17 Jul 2018 22:37:18 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Tue, Jul 17, 2018 at 7:02 PM, Barry Warsaw wrote: > > If you?ve read this far - thank you! Now for the big reveal. I think the > Next BDFL should be? (drum roll)? > > Brett Cannon > > To summarize: > > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection > committee for succession, and a check against the BDFL. > I will register my +1 to this suggestion, and +1 to Brett's name. a) A singular vision is highly beneficial. Personally, just as a nitpick, I'd like to reserve the term BDFL to Guido, and choose a different term to signify the ultimate authority of the new leader. b) Yes, council and its resposibilities sounds a good new idea. > No one will serve forever, so a clear succession plan should be in place. I support this idea too, and the details should be well defined. Thank you, Senthil -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Wed Jul 18 01:46:48 2018 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 18 Jul 2018 00:46:48 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: [Barry Warsaw] > ... > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection > committee for succession, and a check against the BDFL. > You made a fine case for that a single dictator is the best possible approach, for much the same reasons Emacs is the best possible editor. +1 Brett Cannon Not my first choice, but ... yup, I got the email back. Kim Jong Un is too busy providing field guidance to potato farms and trolley manufacturers this year :-( So that leaves Brett! However, to secure my full enthusiastic support he'll first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL priority. Since a committee or a (ugh!) democracy would never do that, it would prove he has the pigheadedness required to be an effective dictator ;-) [1] https://en.wikipedia.org/wiki/Red_Star_OS -------------- next part -------------- An HTML attachment was scrubbed... URL: From kushaldas at gmail.com Wed Jul 18 01:55:44 2018 From: kushaldas at gmail.com (Kushal Das) Date: Wed, 18 Jul 2018 11:25:44 +0530 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Wed, Jul 18, 2018 at 11:17 AM Tim Peters wrote: > > > [Barry Warsaw] >> >> ... >> >> * We retain a singular BDFL to lead Python >> * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL. > > +1 to this idea including Brett as BDFL. Though I am wondering if anyone asked Brett about it? > You made a fine case for that a single dictator is the best possible approach, for much the same reasons Emacs is the best possible editor. +1 > >> Brett Cannon > > > Not my first choice, but ... yup, I got the email back. Kim Jong Un is too busy providing field guidance to potato farms and trolley manufacturers this year :-( > > So that leaves Brett! However, to secure my full enthusiastic support he'll first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL priority. Since a committee or a (ugh!) democracy would never do that, it would prove he has the pigheadedness required to be an effective dictator ;-) > Red Star OS has Python in it iirc :) Means less work for Brett. Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in From chris.jerdonek at gmail.com Wed Jul 18 02:42:21 2018 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Tue, 17 Jul 2018 23:42:21 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: I agree a name other than BDFL should be chosen, especially since (as I understand it) Guido is still BDFL but just taking a permanent vacation, and the name implies there should only be one. Also, if we're considering particular people, I think Nick should also be considered. Should the position be decided before starting to decide who should fill it, though, or should it be decided with a particular person in mind? I feel like doing the former might be better, because that way we can also come up with the process for choosing the person, which we'll need at some point anyways. --Chris On Tue, Jul 17, 2018 at 10:55 PM, Kushal Das wrote: > On Wed, Jul 18, 2018 at 11:17 AM Tim Peters wrote: >> >> >> [Barry Warsaw] >>> >>> ... >>> >>> * We retain a singular BDFL to lead Python >>> * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL. >> >> > +1 to this idea including Brett as BDFL. Though I am wondering if > anyone asked Brett about it? > >> You made a fine case for that a single dictator is the best possible approach, for much the same reasons Emacs is the best possible editor. +1 >> >>> Brett Cannon >> >> >> Not my first choice, but ... yup, I got the email back. Kim Jong Un is too busy providing field guidance to potato farms and trolley manufacturers this year :-( >> >> So that leaves Brett! However, to secure my full enthusiastic support he'll first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL priority. Since a committee or a (ugh!) democracy would never do that, it would prove he has the pigheadedness required to be an effective dictator ;-) >> > > Red Star OS has Python in it iirc :) Means less work for Brett. > > > Kushal > -- > Staff, Freedom of the Press Foundation > CPython Core Developer > Director, Python Software Foundation > https://kushaldas.in > _______________________________________________ > 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 Wed Jul 18 04:05:23 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 18 Jul 2018 09:05:23 +0100 Subject: [python-committers] An alternative governance model In-Reply-To: References: <19714581-A3B1-4473-B362-F70F34C575A8@python.org> Message-ID: I also agree 100% with Barry's proposal. I think he's absolutely right that one of the important features of Python (both the language and the community) is the single focus and vision of the BDFL, and reading Barry's mail crystallised for me the unease I felt about the proposals around a Council, which is precisely that they wouldn't provide that unified vision. Having a council acting as support for the NBDFL gives the best of both worlds. Strong +1 all round. I too would love to hear Brett's thoughts, but he definitely has my support if he feels able to take on the role. Paul On 18 July 2018 at 04:20, Carol Willing wrote: > I wholeheartedly agree with Barry's suggestion. > > It offers a single person who can communicate the design vision. While the > support of a council will help spread out the work and provides a great way > to grow future leaders and a smooth transition if for any reason (family, > work, health, etc.) the new BDFL has to take a break. > > On Tue, Jul 17, 2018, 7:38 PM Ned Deily wrote: >> >> On Jul 17, 2018, at 22:15, Eric V. Smith wrote: >> > On 7/17/2018 10:02 PM, Barry Warsaw wrote: >> >> I?d like to propose an alternative model, and with it a succession >> >> plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in >> >> that it proposes to not actually change that much! >> >> TL;DR: I propose keeping a singular BDFL and adding a Council of >> >> Advisors that helps the BDFL in various capacities, with additional >> >> responsibilities. I also have someone specific in mind for the NBDFL, but >> >> you?ll have to read on for the big reveal. >> > I've come to this same conclusion. I think Brett would be a good choice, >> > and I'd support him, but I think the more important part is that it be a >> > single person. >> >> +100. I think Python owes much of its success to both Guido's ongoing >> vision *and* his clear role as leader. Up to now, we have not had much >> experience governing by committee or council and I think it may be a mistake >> to try to implement that now (although we *do* have some successful >> experience with informal council of advisors models, for instance, in the >> release management area). While it wouldn't necessarily be a good choice >> for many (most?) open-source projects, I think the NBDFL-plus-advisors model >> would work well in the relatively congenial and respectful environment of >> the current Python committers community. That's not to say that we won't >> collectively decide down the road that we want to try something different >> but trying to keep this really important transition (i.e. from Guido) as >> simple as possible initially would be a really smart thing to do. >> >> > And I think the succession plan is important, too. I think ?ukasz was >> > alluding to this earlier (or maybe I'm projecting): who's to say that the >> > next BDFL is legitimate? If we put together a plan, and Guido blesses it, >> > that makes the plan legitimate, and then the plan gets executed and makes >> > NBDFL legitimate. >> >> That, too. >> >> -- >> Ned Deily >> nad at python.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 antoine at python.org Wed Jul 18 04:43:47 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 18 Jul 2018 10:43:47 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> Hi Barry, Le 18/07/2018 ? 04:02, Barry Warsaw a ?crit?: > > A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. Why do you think non-BDFL projects have a problem with """ambiguity as to the authority of said decision"""? What is your basis for that assertion? I'm worried that you seem to be descending into magical thought, believing for some reason that nothing else than monarchy could ever work for a software project. > If you?ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be? (drum roll)? > > Brett Cannon Since you're opening this can of worms, I'll say it: - I'm -1 on a new dictator-for-life (*) - I'm -1 on Brett Cannon as a new dictator-for-life You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors. (*) (I'm leaving the "benevolent" part out, since clearly it was only tied to Guido's personality, not to any inherent statutory limitations) > I?ve long said ? somewhat in jest, since I never expected Guido to actually ever retire! ? that Brett would be my choice for the next BDFL. I think he?s the perfect candidate, and he?s already demonstrated qualities that I think make him a fantastic leader. I bed to disagree, Barry. Brett is a good contributor, that doesn't make him legitimate as a dictator. Only Guido could be, and he has stepped down. The amount of cheerleading here ("""smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills""") is embarrassing. What if we don't subscribe to your views of Brett's qualities: do you expect us to publicly criticize Brett so as to justify our opposition? Your proposal is turning this discussion into some kind of Napoleonic plebiscite. This is frankly unpleasant :-/ Regards Antoine. From ethan at stoneleaf.us Wed Jul 18 05:49:34 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 02:49:34 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> Message-ID: <5B4F0D2E.80702@stoneleaf.us> On 07/18/2018 01:43 AM, Antoine Pitrou wrote: > Le 18/07/2018 ? 04:02, Barry Warsaw a ?crit : >> If you?ve read this far - thank you! Now for the big reveal. I think the >> Next BDFL should be? (drum roll)? >> >> Brett Cannon > > Since you're opening this can of worms, I'll say it: > > - I'm -1 on a new dictator-for-life (*) > - I'm -1 on Brett Cannon as a new dictator-for-life > > You're creating a huge problem here. Whatever dictator you come up > with, not everyone will be ok with that choice. What are they supposed > to do? If one doesn't think X is legitimate as a dictator, how does one > keep contributing to the project? In other words, you are threatening > to exclude people, perhaps seasoned contributors. I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought foolish accepted? If we go with a committee are we threatening to exclude those who think design-by-committee is not a legitamate method, or don't think it's members are legitimate choices? No, we are not threatening anybody. The core-devs will make their choice, and those who don't like the result can leave or go as they will. > (*) (I'm leaving the "benevolent" part out, since clearly it was only > tied to Guido's personality, not to any inherent statutory limitations) I think that's a mistake. Clearly, the "benevolent" part is a major criteria for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is not the only benevolent core-dev we have. >> I?ve long said ? somewhat in jest, since I never expected Guido to actually >> ever retire! ? that Brett would be my choice for the next BDFL. I think he?s >> the perfect candidate, and he?s already demonstrated qualities that I think >> make him a fantastic leader. > > I beg to disagree, Barry. Brett is a good contributor, that doesn't > make him legitimate as a dictator. Only Guido could be, and he has > stepped down. I agree: being a good contributor does not ipso facto make for a good benevolent dictator. I disagree that only Guido could be a good BDFL. I do agree that good BDFLs are rare. > The amount of cheerleading here ("""smart, compassionate, passionate, > respectful, young, tall, and has the right mix of technical excellence > and social skills""") is embarrassing. What if we don't subscribe to > your views of Brett's qualities: do you expect us to publicly criticize > Brett so as to justify our opposition? I think one can oppose the NBDFL model without criticizing the proposed candidate. After all, if the model is rejected it doesn't matter who the candidates were. If the model is accepted, then I think a simple "I disagree with your assessment" would suffice, and you could nominate someone you felt was more qualified. -- ~Ethan~ From antoine at python.org Wed Jul 18 06:04:26 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 18 Jul 2018 12:04:26 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: <5B4F0D2E.80702@stoneleaf.us> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> Message-ID: Hi Ethan, Le 18/07/2018 ? 11:49, Ethan Furman a ?crit?: >> >> You're creating a huge problem here. Whatever dictator you come up >> with, not everyone will be ok with that choice. What are they supposed >> to do? If one doesn't think X is legitimate as a dictator, how does one >> keep contributing to the project? In other words, you are threatening >> to exclude people, perhaps seasoned contributors. > > I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought > foolish accepted? I'm not sure what you mean? I may disagree with my governement's decisions without wanting to overthrow the whole regime (or, conversely, I may agree with some of a despot's decisions without finding him legitimate to make those decisions). Disagreeing with a PEP has nothing to do with this discussion, has it? > If we go with a committee are we threatening to exclude those who think design-by-committee is not a > legitamate method, or don't think it's members are legitimate choices? If we're talking about a dictator (this is Barry's proposal), we're not talking about someone that just makes language design decisions, as Victor pointed out. Or if it is what we're talking about, the name is ill-chosen :-) Regards Antoine. From ethan at stoneleaf.us Wed Jul 18 06:31:34 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 03:31:34 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: <5B4F1706.5040309@stoneleaf.us> On 07/17/2018 07:02 PM, Barry Warsaw wrote: > TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors > that helps the BDFL in various capacities, with additional responsibilities. Having a singular BDFL certainly has its advantages, and from my interactions with Brett I certainly would have no qualms about supporting him in that role. More in-line devil's advocate comments below. > A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, > and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there > would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. > How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on > decisions for the language? ?Bob Smith, on Behalf of the GUIDO? is IMHO less obviously and unquestionably authoritative than ?Alice Jones, BDFL?. If the council appointments are for life, it shouldn't take too long to figure out. > This also comes into play for shutting down discussions early. With a committee, it?s possible that you?ll have some disagreement among the > members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall > direction for Python?s evolution. Alice Jones may say ?No, that?s not gonna happen? only to be overruled or undermined by Bob Smith?s ?That?s > a good idea?. I suspect that will occasionally happen -- I don't know that it's a big enough issue to make the NBDFL model the obvious choice. > Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the > council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying > of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention. I think this is the crux of the argument: getting a group of people, even a small one, to agree on a singular vision can be very difficult. > I also think a council will be much more risk adverse than a singular BDFL, and that?s not necessarily a good thing. While moratoriums and a more > conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than > the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make > decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. Community support can be mercurial, and should not be relied upon as an underpinning of our governance model. > Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed > change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance position, to actually move the > language and its primary implementation forward? I?m not so sure. I am sure that those questions will be difficult for a BDFL, a council, a membership majority, or whatever system we choose. > The formation of a formal Council is still a good idea! I just think that it shouldn?t be the ultimate arbiter of decisions for Python. So what > would the Council do? > > - It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental > to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn?t continuously fear > a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their > power. In other words, a more complicated tyranny of the majority. > - The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. > To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They?d search for candidates, match them against > well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL. Why should the council have that power? If the core-devs are selecting the NBDFL now, I see no reason why we shouldn't in the future as well. > - The council would serve as trusted advisors to the NBDFL. The BDFL won?t be out there all alone! The council will provide advice when requested, > and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions. This doesn't sound significantly different from just a council without a BDFL. Besides which, whichever model we choose, the fact that we chose it should be legitimizing enough. > To summarize: > > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL. I think an NBDFL model could work, but I find the supplemental CoA unnecessary. If we are worried about Evil Corp subverting our BDFL, then we could go with NBDF10years (or something) instead (with possible/probable reinstatement). Thank you, Barry, for taking the time to put your thoughts into words! -- ~Ethan~ From ericsnowcurrently at gmail.com Wed Jul 18 09:51:06 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 18 Jul 2018 07:51:06 -0600 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Tue, Jul 17, 2018 at 8:15 PM Eric V. Smith wrote: > On 7/17/2018 10:02 PM, Barry Warsaw wrote: > > I?d like to propose an alternative model, and with it a succession plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it proposes to not actually change that much! > > > > TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you?ll have to read on for the big reveal. > > I've come to this same conclusion. I think Brett would be a good choice, > and I'd support him, but I think the more important part is that it be a > single person. +1 IMHO, if we can have someone we can trust then a BDFL is the best option. Brett definitely fits that criteria for me. (Plus Canadians are "Benevolent" by definition, right?) Barry's proposal to have the council supporting (and guarding against) the BDFL gives the proposal better stability in the face of the unknown future. -eric From ethan at stoneleaf.us Wed Jul 18 11:58:54 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 08:58:54 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> Message-ID: <5B4F63BE.6090300@stoneleaf.us> On 07/18/2018 03:04 AM, Antoine Pitrou wrote: > > Hi Ethan, > > Le 18/07/2018 ? 11:49, Ethan Furman a ?crit : >>> >>> You're creating a huge problem here. Whatever dictator you come up >>> with, not everyone will be ok with that choice. What are they supposed >>> to do? If one doesn't think X is legitimate as a dictator, how does one >>> keep contributing to the project? In other words, you are threatening >>> to exclude people, perhaps seasoned contributors. >> >> I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought >> foolish accepted? > > I'm not sure what you mean? I may disagree with my governement's > decisions without wanting to overthrow the whole regime (or, conversely, > I may agree with some of a despot's decisions without finding him > legitimate to make those decisions). Disagreeing with a PEP has nothing > to do with this discussion, has it? If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate. >> If we go with a committee are we threatening to exclude those who >> think design-by-committee is not a legitamate method, or don't think >> it's members are legitimate choices? > > If we're talking about a dictator (this is Barry's proposal), we're not > talking about someone that just makes language design decisions, I was asking about how objecting to the currently chosen dictator would be any different from objecting to the currently chosen council members. > as Victor pointed out. Where did he point this out? I don't see an email, although I might just be missing it. -- ~Ethan~ From antoine at python.org Wed Jul 18 12:10:31 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 18 Jul 2018 18:10:31 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: <5B4F63BE.6090300@stoneleaf.us> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> Message-ID: Le 18/07/2018 ? 17:58, Ethan Furman a ?crit?: > > If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by > majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice > illegitimate. At this point we are not talking about a majority vote. All I see is a rushed plebiscite on a single governance model and a single person. Regards Antoine. From stefan at bytereef.org Wed Jul 18 12:11:56 2018 From: stefan at bytereef.org (Stefan Krah) Date: Wed, 18 Jul 2018 18:11:56 +0200 Subject: [python-committers] Language moratorium Message-ID: <20180718161156.GA5506@bytereef.org> Hi, if I remember correctly, we had a moratorium for language changes around versions 3.2-3.3. I think during that time relatively few BDFL-level decisions were required. Perhaps we could have one again, say for 12 months so we can figure things out. Other Python implementations may welcome the moratorium so they can catch up. During that time we could just informally listen very closely to Guido if anything requires a decision and he happens to be around. But there may be no decisions at all. And yes, I guess we can successfully attempt to be nice, especially to him (thanks for this wonderful language!). Stefan Krah From lukasz at langa.pl Wed Jul 18 12:23:52 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 11:23:52 -0500 Subject: [python-committers] Language moratorium In-Reply-To: <20180718161156.GA5506@bytereef.org> References: <20180718161156.GA5506@bytereef.org> Message-ID: There is a de facto moratorium for the time being until a new governance model is chosen. Let's not formalize anything beyond that. -- Best regards, ?ukasz Langa > On Jul 18, 2018, at 11:11 AM, Stefan Krah wrote: > > > Hi, > > if I remember correctly, we had a moratorium for language changes around > versions 3.2-3.3. I think during that time relatively few BDFL-level > decisions were required. > > Perhaps we could have one again, say for 12 months so we can figure things > out. Other Python implementations may welcome the moratorium so they can > catch up. > > > During that time we could just informally listen very closely to Guido if > anything requires a decision and he happens to be around. But there may be > no decisions at all. > > And yes, I guess we can successfully attempt to be nice, especially to him > (thanks for this wonderful language!). > > > > Stefan Krah > > > > _______________________________________________ > 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 Wed Jul 18 12:32:24 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 18 Jul 2018 09:32:24 -0700 Subject: [python-committers] Language moratorium In-Reply-To: References: <20180718161156.GA5506@bytereef.org> Message-ID: > > There is a de facto moratorium for the time being until a new governance > model is chosen. Let's not formalize anything beyond that. I agree. Mariatta On Wed, Jul 18, 2018 at 9:24 AM ?ukasz Langa wrote: > There is a de facto moratorium for the time being until a new governance > model is chosen. Let's not formalize anything beyond that. > > -- > Best regards, > ?ukasz Langa > > > On Jul 18, 2018, at 11:11 AM, Stefan Krah wrote: > > > > > > Hi, > > > > if I remember correctly, we had a moratorium for language changes around > > versions 3.2-3.3. I think during that time relatively few BDFL-level > > decisions were required. > > > > Perhaps we could have one again, say for 12 months so we can figure > things > > out. Other Python implementations may welcome the moratorium so they can > > catch up. > > > > > > During that time we could just informally listen very closely to Guido if > > anything requires a decision and he happens to be around. But there may > be > > no decisions at all. > > > > And yes, I guess we can successfully attempt to be nice, especially to > him > > (thanks for this wonderful language!). > > > > > > > > Stefan Krah > > > > > > > > _______________________________________________ > > 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 lukasz at langa.pl Wed Jul 18 12:36:21 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 11:36:21 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: <5B4F63BE.6090300@stoneleaf.us> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> Message-ID: <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> > On Jul 18, 2018, at 10:58 AM, Ethan Furman wrote: > > If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate. A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice. - ? From antoine at python.org Wed Jul 18 12:38:14 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 18 Jul 2018 18:38:14 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> Message-ID: <452b9b71-b329-5486-1b67-c883cb9760c0@python.org> Le 18/07/2018 ? 18:36, ?ukasz Langa a ?crit?: > >> On Jul 18, 2018, at 10:58 AM, Ethan Furman wrote: >> >> If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate. > > A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice. Thanks for saying this better than I could :-) Regards Antoine. From steve.dower at python.org Wed Jul 18 12:44:34 2018 From: steve.dower at python.org (Steve Dower) Date: Wed, 18 Jul 2018 09:44:34 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> Message-ID: <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org> On 18Jul2018 0910, Antoine Pitrou wrote: > > Le 18/07/2018 ? 17:58, Ethan Furman a ?crit?: >> >> If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by >> majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice >> illegitimate. > > At this point we are not talking about a majority vote. All I see is a > rushed plebiscite on a single governance model and a single person. The "plebiscite" is really about the question "should we *consider* appointing someone as NBDFL" - Barry's very first line of his email reads: > I?d like to propose an alternative model, and with it a succession plan, that IMHO hasn?t gotten enough discussion. It?s fairly radical in that it proposes to not actually change that much! The only thing I see happening now is sounding out opinions on the model. No decision is being taken yet. Right now, I imagine Barry is testing the waters to see whether it's worth his time writing this up as a proposed PEP 2. Other people seem to be interested in also proposing alternative PEP 2s, and eventually we as a group will have to select one of them, no doubt by majority vote. And while Barry's long service to this group certainly adds weight to his opinion, it's also likely that we can filibuster for long enough until he retires and then ignore him completely :) Your contributions to this part of the discussion are also very useful - we need to know what concerns people have, and often those concerns may not have occurred to those of us who approach it with a more idealistic idea of how everything will work out. Nobody has really disputed the idea of codifying our new model as PEP 2. Until we have an actual text of PEP 2, I see no reason for concern that we are rushing anything. Cheers, Steve From ethan at stoneleaf.us Wed Jul 18 12:54:43 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 09:54:43 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> Message-ID: <5B4F70D3.6050301@stoneleaf.us> On 07/18/2018 09:36 AM, ?ukasz Langa wrote: >> On Jul 18, 2018, at 10:58 AM, Ethan Furman wrote: >> If we, by majority vote, pick a governance model (dictator, council, or >> whatever), then that legitimizes it. If we, by majority vote, pick the >> new BDFL, then that legitimizes it. Being unhappy with the choice does >> not make the choice illegitimate. > > A simple majority vote is wildly insufficient for this case. Python is a > large project with many contributors and alienating maybe tens of them is > not acceptable, especially if we are talking about a "for life" choice. Are you saying that we should use some method besides voting, or that a higher percentage of yea votes is required? If the latter, I have no problem with 66% or 75%. -- ~Ethan~ From tim.peters at gmail.com Wed Jul 18 12:55:41 2018 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 18 Jul 2018 11:55:41 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> Message-ID: [Antoine Pitrou] > At this point we are not talking about a majority vote. All I see is a > rushed plebiscite on a single governance model and a single person. > I view this as the "freewheeling brainstorming" initial part of the process. We've barely even mentioned who the plebes may be - is it just committers who have a say? If so, is that by definition precisely the members of this mailing list, or some broader or narrower definition? Or also some subset of the 5 classes of PSF membership? Etc. And regardless of how someone wants to answer that, who decides on who gets to "vote" to begin with? Under what authority? IOW, we're several universes away from reaching a credible resolution. In the meantime, a "+1" or "-1" from me really just means "let's keep this idea on the table" or "let's drop this one", respectively. Which carries no actual weight at all. It's valuable to push back against ideas you don't like, and I'm glad you are! -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Wed Jul 18 12:57:52 2018 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 18 Jul 2018 09:57:52 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <452b9b71-b329-5486-1b67-c883cb9760c0@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <452b9b71-b329-5486-1b67-c883cb9760c0@python.org> Message-ID: On Wed, Jul 18, 2018 at 9:38 AM, Antoine Pitrou wrote: > > Le 18/07/2018 ? 18:36, ?ukasz Langa a ?crit : > > > > > > A simple majority vote is wildly insufficient for this case. Python is a > large project with many contributors and alienating maybe tens of them is > not acceptable, especially if we are talking about a "for life" choice. > > Thanks for saying this better than I could :-) > I supported Barry's proposal. I can definitely understand ?ukasz's and Antoine's stance here. One of the important part of Barry's proposal was removal of "for life" part. Most of us are volunteers contributing to python. A leader with ultimate say on language design, governance burden to steer the comittee is going to be challenging and stressful for "anyone" in this model proposed by Barry. Thank you, Senthil -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Wed Jul 18 13:03:43 2018 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 18 Jul 2018 12:03:43 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: [Senthil Kumaran ] > ... Personally, just as a nitpick, I'd like to reserve the term BDFL to Guido, > and choose a different term to signify the ultimate authority of the new > leader. > Finally - an important issue ;-) I submit instead that Monty Python would _certainly_ have kept the BDFL title. The irony of having at least two living BDFLs is just too exquisite to resist :-) But we can learn from other dictatorships too. For example, one of Kim Il Sung's many titles was "President". It was important for his son to get fancy titles too when he took over, so he was also called "President". And it was Kim Il Sung's title that changed, to "Eternal President". That gave him even more prestige. If there can be only one BDFL, then Guido's title should change to EBDFL. On his resume he can explain that means "Emeritus BDFL", but we'll all know it means "Eternal BDFL" :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Wed Jul 18 13:07:40 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 10:07:40 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: <2266A334-5A8D-4868-83A7-21D27562B393@python.org> On Jul 17, 2018, at 22:55, Kushal Das wrote: > +1 to this idea including Brett as BDFL. Though I am wondering if > anyone asked Brett about it? I know my email was long, so easy to overlook, but I did ask Brett and he didn?t immediately say no. :) -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 mal at egenix.com Wed Jul 18 13:06:12 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 18 Jul 2018 19:06:12 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> Message-ID: <6bf938b2-b002-f930-0a06-535c2ae57bfe@egenix.com> I find this discussion really interesting from a social perspective. Let's keep it going for a while without jumping to any conclusions. It's too early to head down into one particular rabbit hole yet ;-) There's no rush and if things crystallize only in a year's time, that's perfectly fine. (And even better: We have Tim back with us for all that time to entertain us :-)) Cheers. On 18.07.2018 18:55, Tim Peters wrote: > [Antoine Pitrou] > >> At this point we are not talking about a majority vote. All I see is a >> rushed plebiscite on a single governance model and a single person. >> > > I view this as the "freewheeling brainstorming" initial part of the > process. We've barely even mentioned who the plebes may be - is it just > committers who have a say? If so, is that by definition precisely the > members of this mailing list, or some broader or narrower definition? Or > also some subset of the 5 classes of PSF membership? Etc. And regardless > of how someone wants to answer that, who decides on who gets to "vote" to > begin with? Under what authority? > > IOW, we're several universes away from reaching a credible resolution. > > In the meantime, a "+1" or "-1" from me really just means "let's keep this > idea on the table" or "let's drop this one", respectively. Which carries > no actual weight at all. > > It's valuable to push back against ideas you don't like, and I'm glad you > are! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jul 18 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 ericsnowcurrently at gmail.com Wed Jul 18 13:13:46 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 18 Jul 2018 11:13:46 -0600 Subject: [python-committers] An alternative governance model In-Reply-To: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> Message-ID: On Wed, Jul 18, 2018 at 2:43 AM Antoine Pitrou wrote: > Le 18/07/2018 ? 04:02, Barry Warsaw a ?crit : > > A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. > > Why do you think non-BDFL projects have a problem with """ambiguity as > to the authority of said decision"""? What is your basis for that > assertion? > > I'm worried that you seem to be descending into magical thought, > believing for some reason that nothing else than monarchy could ever > work for a software project. tl;dr We worry too much :) While I do not feel quite the same way on your point, Antoine, I'm glad you brought this up. A blanket policy of monarchy would be a serious problem at the point that a BDFL goes "rogue". However, a blanket opposition to monarchy leads to its own problems. Relative to the BDFL's power, context is significant here. There is apparently a lot of support (mine included) for Barry's proposal. However, we might be blinded, now and in general, to the possibility of a rogue BDFL by the availability of good candidates (that "clearly" would not go rogue) in the present and struggle to imagine a time that there isn't such a candidate or that we were wrong about them. In fact, IIUC some reputable core devs do not feel like there's any such candidate now (no disrespect, Brett), based on what they expect a BDFL to be. We need to respect that and consider that viewpoint. Regardless of when it happens (if ever), what will happen in the future when we don't have anyone suitable? One danger is that we will install someone un-suitable because "we've always had a BDFL". But what is that "danger"? What impact could a rogue BDFL have? Before diving in to that, consider that change has a directly proportional relationship with disruption. Disruption to any organization has a pretty high cost, so the effect should be carefully considered before deciding to make changes (which is what we're doing, hopefully). In our case, figuring out how to proceed post-Guido-as-BDFL, we should make sure there's a good reason to change our "governance model". [Really quick: python-dev is rather ad-hoc as an org, so calling it a "governance model" is a bit misleading.] We've been operating (successfully) for decades with a BDFL. As others have indicated, Python greatly owes its success to having a BDFL. Assuming we find a suitable replacement (I think we can), why otherwise disrupt things? "this is our chance to change so we should" is an extremely weak argument on its own (and a dangerous one), as is "monarchs are always bad". There needs to be a stronger reason (one that applies concretely to us). Otherwise, at the least "status quo wins a stalemate" here. Arguably the best course of action would be to change as little as possible. All that said, I strongly affirm that we should not dismiss concerns and differing opinions. We need to consider them and be respectful. We must resist the temptation to say "let's be real, that isn't something we need to worry about". That's why I'm glad you said what you did, Antoine. It made me think about a few aspects of the status quo that may be worth addressing sooner rather than later. Along those lines, I consider the following questions to be significant. I'll address them a little, but not conclusively. 1. what makes a good BDFL? 2. what do we do when we can't find a suitable candidate? 3. what negative impact can a BDFL have? 4. how do we mitigate that impact? how do we deal with a "bad" BDFL? In my mind the key question is #3 (see my comments below). ---------- 1. what makes a good BDFL? This is already being discussed in other threads, e.g. about the "roles" of the BDFL. I'll add that the BDFL is someone we trust to lead Python into the future, even when it's hard and even when we strongly disagree with them. As a core team we rely on the BDFL to help us make hard technical decisions. However, I supposed I hadn't considered it before, but the BDFL has a much more significant role. The Python community is in many ways a reflection of Guido and a result of his leadership (much more than technical leadership). Consequently, a new BDFL must be someone who reflects where we want the community to be. 2. what do we do when we can't find a suitable candidate? This is worth figuring out. It isn't something we've discussed much. I expect most folks feel like it will never be an issue. I suppose they're right. At the point there isn't a suitable candidate, we have larger problems to address. :) 3. what negative impact can a BDFL have? I was primarily thinking about a "rogue" BDFL, rather that about mistakes an otherwise good one might make. The big question is what does it mean for the BDFL to go "rogue". It definitely isn't "making a decision the people don't agree with" as Guido has done that plenty of times (to our benefit). :) In my mind, the main bad that the BDFL can do is to hurt the community. Their possible negative technical impact is small and highly recoverable. As the leader of Python, the BDFL is in a position to hurt the project; by offending the Python community, by making Python less appealing to new users, by alienating existing contributors, and by discouraging new contributors. While the BDFL has the final say in changes to the language (through the PEP process), this isn't something easily abused nor hard to repair. Furthermore, the BDFL is otherwise already quite limited in authority and power. For instance, relative to the code they have no special standing; they are one among many committers. 4. how do we mitigate that impact? how do we deal with a "bad" BDFL? People make mistakes. We should expect the BDFL to make them too. We should also expect them to care deeply about Python (as well as align relatively closely with the community). We can deal with their mistakes. :) However, if the BDFL turns out to be not as capable as we expected (no judgement, Brett) or appears to be purposefully hurting Python then we'd need to act. On the one hand we'd need to deal with the BDFL directly, likely replacing them or more broadly restructuring. On the other had we'd have to deal with the community consequences (the four listed in point #3). The latter is the one with deeper consequences. TBH, the same is true of any structure we apply (e.g. council, majority rule). I suppose the most we could plan for would be quickly removing a rogue BDFL (but without such a plan hanging over a good BDFL's head). I'd consider Barry's proposal of advisers to be in the right direction. That said, as with #2 this is probably not something that will ever come up. (Other approaches to project governance might also help mitigate the equivalent effect of a rogue BDFL on the community. However, they make the technical decision-making side of things worse. There are serious trade-offs when more people are involved in the decision-making. I consider sticking with a BDFL worth it.) ---------- > You're creating a huge problem here. Whatever dictator you come up > with, not everyone will be ok with that choice. What are they supposed > to do? If one doesn't think X is legitimate as a dictator, how does one > keep contributing to the project? In other words, you are threatening > to exclude people, perhaps seasoned contributors. This is a real issue we need to solve. I'm not sure what we can do though. Not everyone will be happy with any approach we take. That's frustrating because I highly doubt anyone here wants anyone else to feel excluded. I challenge all of us to make this a priority as we consider an approach for replacing Guido. (Hopefully my other comments reflect this priority!) > (*) (I'm leaving the "benevolent" part out, since clearly it was only > tied to Guido's personality, not to any inherent statutory limitations) The "benevolent" part is critical though. Without it none of the rest would work for us. Perhaps I've misunderstood your point? FWIW, the word "dictator" has a lot of negative connotation that does not match our usage in BDFL. I don't mean to suggest that's the only concern here, but would it help to use a different name than BDFL? IIRC, it's either a clever Monty Python reference or a tongue-in-cheek expression from Barry 20 years ago that stuck. > What if we don't subscribe to > your views of Brett's qualities: do you expect us to publicly criticize > Brett so as to justify our opposition? Fair enough. I don't mean to put Barry or Brett in an uncomfortable position here, but at the point where we're discussing potential BDFL candidates, we need to be just as open and honest about concerns as about qualifications. However, perhaps we're premature in discussing candidates (before we've decided to stick with a BDFL). While I too would support Brett, I agree that tying Brett to the BDFL proposal makes the discussion harder when there is opposition, which obviously there is. So we should probably focus just on the BDFL proposal itself and then move on to the candidates once (if) that's settled. > Your proposal is turning this discussion into some kind of Napoleonic > plebiscite. This is frankly unpleasant :-/ :( We definitely need to be honest (and respectful) here so thanks for expressing that. I'm hopeful we can all work together to find a solution that will benefit Python going forward. Let's take this as an opportunity to understand each other's viewpoints and get on the same page. Let's build on the basis that we have in common. In summary, we're a relatively as-hoc, unorganized group without much structure to bind us down. This has worked because we've had an effective BDFL. Even if we get things wrong now by changing minimally, there is no real blocker to fixing things later (except *maybe* momentum). However if we add a bunch of structure there's a risk that we'll find it hard to undo. Ultimately, we should be careful about premature optimization. -eric From ericsnowcurrently at gmail.com Wed Jul 18 13:15:35 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 18 Jul 2018 11:15:35 -0600 Subject: [python-committers] An alternative governance model In-Reply-To: <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> Message-ID: On Wed, Jul 18, 2018 at 10:36 AM ?ukasz Langa wrote: > A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice. +1 -eric From ericsnowcurrently at gmail.com Wed Jul 18 13:19:36 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 18 Jul 2018 11:19:36 -0600 Subject: [python-committers] An alternative governance model In-Reply-To: <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org> Message-ID: On Wed, Jul 18, 2018 at 10:44 AM Steve Dower wrote: > Your contributions to this part of the discussion are also very useful - > we need to know what concerns people have, and often those concerns may > not have occurred to those of us who approach it with a more idealistic > idea of how everything will work out. This is a critical point, especially as we are without a BDFL to rely on for this discussion and decision. :) We need all the viewpoints, mutual respect, and patience. -eric From barry at python.org Wed Jul 18 13:51:40 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 10:51:40 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> Message-ID: <3E916CE1-9E84-4E50-8008-D98BA7A635EB@python.org> On Jul 18, 2018, at 01:43, Antoine Pitrou wrote: > > Why do you think non-BDFL projects have a problem with """ambiguity as > to the authority of said decision"""? What is your basis for that > assertion? With more people empowered to make a binding decision as part of a Supreme Council, there will be more uncertainty in the authority of the person pronouncing. Part of that will be because the pronouncement can come from any of the member of the Council, and part may come from more turnover in the Council membership. I?m not at all concerned about *us* accepting that authoritative decision because we are are deeply invested in Python?s governance. But I claim that the vast majority of Python users are not, so while they recognize Guido?s name as the (former) leader, I question whether they will be able to have the same certainty in the authority of a decision coming from 3 or 5 people who?s names they are not familiar with. With a singular leader, it will be easier to communicate the authority of that leader. So yeah, maybe it?s a PR problem, but it?s still important nonetheless. > I'm worried that you seem to be descending into magical thought, > believing for some reason that nothing else than monarchy could ever > work for a software project. We?re not talking about software project governance in general, we?re talking about Python specifically. And Python has had a strong singular leader with a clear vision for its entire nearly 30 year life. Yes, I personally question whether a Supreme Council will work for Python. > Since you're opening this can of worms, I'll say it: > > - I'm -1 on a new dictator-for-life (*) Let me be clear: ?BDFL? is a convenient term with a well-known meaning. In fact, I believe *we* coined that term that?s now often used in other open source projects. But as Guido has eloquently demonstrated, the ?For Life? part really means ?For As Long As They Want To Do It?. In other words, it?s just a title for the job. In my proposal, it really means ?For As Long As They Want To Do It And They Don?t Do Something Evil Enough To Get Impeached?. I?m spelling that title with the initialism ?BDFL? :) > - I'm -1 on Brett Cannon as a new dictator-for-life Of one thing I have absolutely no doubt: no decision in Python will ever be unanimous! That kind of proves my point as to why a singular leader is necessary. :) > You're creating a huge problem here. Whatever dictator you come up > with, not everyone will be ok with that choice. What are they supposed > to do? If one doesn't think X is legitimate as a dictator, how does one > keep contributing to the project? In other words, you are threatening > to exclude people, perhaps seasoned contributors. How is that any different with a Supreme Council rather than a singular leader? Whatever makeup of the Council we come up with, not everyone will be okay with those choices. What are they supposed to do? Ultimately you?re right. There are zillions of reasons not to contribute to Python, so having no confidence in its leadership is just one more. Fortunately, only you get to decide whether your reasons not to contribute outweigh your reasons to contribute. And further, it?s open source, so you are *always* welcome to fork. Look at Devuan . >> I?ve long said ? somewhat in jest, since I never expected Guido to actually ever retire! ? that Brett would be my choice for the next BDFL. I think he?s the perfect candidate, and he?s already demonstrated qualities that I think make him a fantastic leader. > > I bed to disagree, Barry. Brett is a good contributor, that doesn't > make him legitimate as a dictator. Only Guido could be, and he has > stepped down. > > The amount of cheerleading here ("""smart, compassionate, passionate, > respectful, young, tall, and has the right mix of technical excellence > and social skills""") is embarrassing. What if we don't subscribe to > your views of Brett's qualities: do you expect us to publicly criticize > Brett so as to justify our opposition? Also fortunately, I don?t get to unilaterally decide this! I get to propose a plan, make my arguments, try to persuade, and cast my one vote ? hopefully, depending on the criteria. Just like all of you. :) (Maybe we don?t count anybody who has more hair on his chin now than his head when he first started using Python, in which case, I?m definitely forking what I?ll call UncleTimmython). 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 Wed Jul 18 13:53:42 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 10:53:42 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <5B4F0D2E.80702@stoneleaf.us> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> Message-ID: <4D0B9A70-A079-4C55-B2AA-6B182912F010@python.org> On Jul 18, 2018, at 02:49, Ethan Furman wrote: >> (*) (I'm leaving the "benevolent" part out, since clearly it was only >> tied to Guido's personality, not to any inherent statutory limitations) > > I think that's a mistake. Clearly, the "benevolent" part is a major criteria for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is not the only benevolent core-dev we have. +1 - completely agree. ?Benevolence? is critical IMHO. -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 Wed Jul 18 13:56:33 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 10:56:33 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> Message-ID: On Jul 18, 2018, at 03:04, Antoine Pitrou wrote: > > If we're talking about a dictator (this is Barry's proposal), we're not > talking about someone that just makes language design decisions, as > Victor pointed out. I?m talking about a singular leader who has the responsibility and vision to direct Python for as long as they are able and want to. Just as Guido left tons of decisions to others (including this one :), so will the next BDFL. Exactly what that mix of delegation will look like is, in my proposal, up to the NBDFL. -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 Wed Jul 18 14:02:58 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 11:02:58 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <5B4F1706.5040309@stoneleaf.us> References: <5B4F1706.5040309@stoneleaf.us> Message-ID: <15B6DD76-4A6E-4190-85B7-C37A38B97610@python.org> On Jul 18, 2018, at 03:31, Ethan Furman wrote: > > I think this is the crux of the argument: getting a group of people, even a small one, to agree on a singular vision can be very difficult. Yep. >> I also think a council will be much more risk adverse than a singular BDFL, and that?s not necessarily a good thing. While moratoriums and a more > > conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than > > the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make > > decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. > > Community support can be mercurial, and should not be relied upon as an underpinning of our governance model. No? I think it?s critical. Here?s a thought experiment: Pretend that PEP 572 were in front of the Supreme Council. How do you think the discussions would go? Would your opinion for or against be weighed with sufficient deliberation? Would the PEP have undergone the rewrites it did in order to address the concerns early on? Would you have confidence in the decision of the Council, whether it went your way or not? If you lost the argument, how would you react? How would any of that be different with a singular leader? Would it matter to you if that leader was not Guido? 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 Wed Jul 18 14:05:29 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 11:05:29 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> Message-ID: <33C6F50B-84C9-4650-A792-F4A7602017A4@python.org> On Jul 18, 2018, at 09:10, Antoine Pitrou wrote: > At this point we are not talking about a majority vote. All I see is a > rushed plebiscite on a single governance model and a single person. Antoine, there?s nothing rushed about this. I made a proposal, and there?s a healthy debate going on. We don?t even know how the decisions will be made, or by whom yet. 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 Wed Jul 18 14:06:53 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 11:06:53 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org> Message-ID: On Jul 18, 2018, at 09:44, Steve Dower wrote: > Right now, I imagine Barry is testing the waters to see whether it's worth his time writing this up as a proposed PEP 2. Other people seem to be interested in also proposing alternative PEP 2s, and eventually we as a group will have to select one of them, no doubt by majority vote. And while Barry's long service to this group certainly adds weight to his opinion, it's also likely that we can filibuster for long enough until he retires and then ignore him completely :) One can only hope! :) 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 lukasz at langa.pl Wed Jul 18 14:07:17 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 13:07:17 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: <5B4F70D3.6050301@stoneleaf.us> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> Message-ID: > On Jul 18, 2018, at 11:54 AM, Ethan Furman wrote: > > Are you saying that we should use some method besides voting, or that a higher percentage of yea votes is required? If the latter, I have no problem with 66% or 75%. The cleanest way would be for Guido to choose but he already said he wants to stay out of the process. With that in mind, one alternative is for the President of the PSF to choose ;-) ...so realistically the only alternative is a vote. Given the gravity of the situation (a decision on how future decisions are made; long-term consequences), I propose: 1. Define a committer as anybody with GitHub privileges. While not everybody on this mailing list decided to get GitHub credentials, they can do it at any point. At the same time, by defining the committer set as GitHub contributors, we solve the issue of inactive contributors. And this is important because... 2. Require 90% participation for the vote to be valid. 3. Require 90% votes in favor for the proposal to pass. If 2. or 3. fail, back to the drawing board. I'd lower those requirements only after a few consecutive votes fail. - ? From aleax at google.com Wed Jul 18 14:23:52 2018 From: aleax at google.com (Alex Martelli) Date: Wed, 18 Jul 2018 11:23:52 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> Message-ID: Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted. In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session. As https://en.wikipedia.org/wiki/Liberum_veto puts it, "Many historians hold that the liberum veto was a major cause of the deterioration of the Commonwealth political system" all the way to the partitions of Poland. Let's steer well clear of this: those who cannot remember the past, etc, etc... Alex On Wed, Jul 18, 2018 at 11:07 AM ?ukasz Langa wrote: > > > On Jul 18, 2018, at 11:54 AM, Ethan Furman wrote: > > > > Are you saying that we should use some method besides voting, or that a > higher percentage of yea votes is required? If the latter, I have no > problem with 66% or 75%. > > The cleanest way would be for Guido to choose but he already said he wants > to stay out of the process. > > With that in mind, one alternative is for the President of the PSF to > choose ;-) > > ...so realistically the only alternative is a vote. Given the gravity of > the situation (a decision on how future decisions are made; long-term > consequences), I propose: > > 1. Define a committer as anybody with GitHub privileges. While not > everybody on this mailing list decided to get GitHub credentials, they can > do it at any point. At the same time, by defining the committer set as > GitHub contributors, we solve the issue of inactive contributors. And this > is important because... > > 2. Require 90% participation for the vote to be valid. > > 3. Require 90% votes in favor for the proposal to pass. > > If 2. or 3. fail, back to the drawing board. I'd lower those requirements > only after a few consecutive votes fail. > > - ? > _______________________________________________ > 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 barry at python.org Wed Jul 18 14:39:31 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 11:39:31 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> Message-ID: <9706D627-344A-4487-81B6-CFB8A33ADB78@python.org> On Jul 18, 2018, at 10:13, Eric Snow wrote: > Regardless of when it happens (if ever), what will happen > in the future when we don't have anyone suitable? One danger is that > we will install someone un-suitable because "we've always had a BDFL". > But what is that "danger"? What impact could a rogue BDFL have? I?m not concerned about that, and not just because I?m secretly wishing for a filibuster until I get to join Guido on the Isle of Former Pythonistas Who Know Prefer To Sip Margaritas In Peace and Quiet and No Internet. Grooming suitable future leaders is critical to the relevance of Python for the next 30 years. I?m confident that when the time comes, there will be obvious choices, just as there has been for Release Managers. And if there really isn?t then future archeologists will point to this thread and say ?maybe now we can experiment with a Supreme Council?. > 1. what makes a good BDFL? > 2. what do we do when we can't find a suitable candidate? > 3. what negative impact can a BDFL have? > 4. how do we mitigate that impact? how do we deal with a "bad" BDFL? I?d like to add: how do we ensure that we will have many suitable candidates if and when the time comes to choose the N+1BDFL? > However, I supposed I hadn't considered it before, but the BDFL has a > much more significant role. The Python community is in many ways a > reflection of Guido and a result of his leadership (much more than > technical leadership). Consequently, a new BDFL must be someone who > reflects where we want the community to be. To me, that?s the ?vision? question, but I think the BDFL doesn?t just reflect the communities wishes, because ?the community? will never agree 100% on anything. Which, FTR, I think is okay. The BDFL uses their intuition, compassion, and experience to move Python forward according to their vision for what the language should be, deeply informed by ?but not subservient to? the opinions of all its users and developers, because that?s essentially impossible. > 2. what do we do when we can't find a suitable candidate? > > This is worth figuring out. It isn't something we've discussed much. > I expect most folks feel like it will never be an issue. I suppose > they're right. At the point there isn't a suitable candidate, we have > larger problems to address. :) Indeed. I?d say that we should be proactive so that we never get into that position, by beginning to groom future NBDFLs now. > 3. what negative impact can a BDFL have? > > I was primarily thinking about a "rogue" BDFL, rather that about > mistakes an otherwise good one might make. The big question is what > does it mean for the BDFL to go "rogue". It definitely isn't "making > a decision the people don't agree with" as Guido has done that plenty > of times (to our benefit). :) In my mind, the main bad that the BDFL > can do is to hurt the community. Their possible negative technical > impact is small and highly recoverable. That?s a good point, except that there is usually a window of practical recoverability. For example, once Python 3.8 is released, PEP 572 will be very very difficult to undo. > 4. how do we mitigate that impact? how do we deal with a "bad" BDFL? > > People make mistakes. We should expect the BDFL to make them too. We > should also expect them to care deeply about Python (as well as align > relatively closely with the community). We can deal with their > mistakes. :) > > However, if the BDFL turns out to be not as capable as we expected (no > judgement, Brett) or appears to be purposefully hurting Python then > we'd need to act. On the one hand we'd need to deal with the BDFL > directly, likely replacing them or more broadly restructuring. On the > other had we'd have to deal with the community consequences (the four > listed in point #3). The latter is the one with deeper consequences. > TBH, the same is true of any structure we apply (e.g. council, > majority rule). > > I suppose the most we could plan for would be quickly removing a rogue > BDFL (but without such a plan hanging over a good BDFL's head). I'd > consider Barry's proposal of advisers to be in the right direction. > That said, as with #2 this is probably not something that will ever > come up. Thanks Eric, these are good points to consider. > The "benevolent" part is critical though. Without it none of the rest > would work for us. Perhaps I've misunderstood your point? FWIW, the > word "dictator" has a lot of negative connotation that does not match > our usage in BDFL. I don't mean to suggest that's the only concern > here, but would it help to use a different name than BDFL? IIRC, it's > either a clever Monty Python reference or a tongue-in-cheek expression > from Barry 20 years ago that stuck. I?d put my money on Uncle Timmy coining that term, but maybe you?re on to something here. Okay, let?s call our leader ?Dinsdale?. As in, who will be the Next Dinsdale? > Fair enough. I don't mean to put Barry or Brett in an uncomfortable > position here, but at the point where we're discussing potential BDFL > candidates, we need to be just as open and honest about concerns as > about qualifications. However, perhaps we're premature in discussing > candidates (before we've decided to stick with a BDFL). While I too > would support Brett, I agree that tying Brett to the BDFL proposal > makes the discussion harder when there is opposition, which obviously > there is. So we should probably focus just on the BDFL proposal > itself and then move on to the candidates once (if) that's settled. FWIW, I would not expect PEP 2 to name a Next Dinsdale, er BDFL, er? I have been thinking that PEP 3 would serve as the Historical Record of Past And Future Leaders. > We definitely need to be honest (and respectful) here so thanks for > expressing that. I'm hopeful we can all work together to find a > solution that will benefit Python going forward. Let's take this as > an opportunity to understand each other's viewpoints and get on the > same page. Let's build on the basis that we have in common. > > In summary, we're a relatively as-hoc, unorganized group without much > structure to bind us down. This has worked because we've had an > effective BDFL. Even if we get things wrong now by changing > minimally, there is no real blocker to fixing things later (except > *maybe* momentum). However if we add a bunch of structure there's a > risk that we'll find it hard to undo. Ultimately, we should be > careful about premature optimization. Well put! I?d also caution against excessive pessimism. :) 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 antoine at python.org Wed Jul 18 14:41:02 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 18 Jul 2018 20:41:02 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: <3E916CE1-9E84-4E50-8008-D98BA7A635EB@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <3E916CE1-9E84-4E50-8008-D98BA7A635EB@python.org> Message-ID: Le 18/07/2018 ? 19:51, Barry Warsaw a ?crit?: > On Jul 18, 2018, at 01:43, Antoine Pitrou wrote: >> >> Why do you think non-BDFL projects have a problem with """ambiguity as >> to the authority of said decision"""? What is your basis for that >> assertion? > > With more people empowered to make a binding decision as part of a Supreme Council, there will be more uncertainty in the authority of the person pronouncing. I don't really follow you. If you have a collegial body (a Council), it's the Council as a whole that has the authority to pronounce. Not any singular member of the Council (unless the Council functions as a miniature monarchy, that is). So the "person pronouncing" is the Council. (Imagine a parliamentary regime: when a parliament decides on a law, it's the parliament's authority that makes the law valid in the eyes of every citizen. It does not matter which representatives exactly voted on a given piece of law.) > Of one thing I have absolutely no doubt: no decision in Python will ever be unanimous! That kind of proves my point as to why a singular leader is necessary. :) That doesn't prove anything. A dictator is not needed to make up for the lack of unanimity (fortunately! otherwise we would all live under dictatorships...). >> You're creating a huge problem here. Whatever dictator you come up >> with, not everyone will be ok with that choice. What are they supposed >> to do? If one doesn't think X is legitimate as a dictator, how does one >> keep contributing to the project? In other words, you are threatening >> to exclude people, perhaps seasoned contributors. > > How is that any different with a Supreme Council rather than a singular leader? Whatever makeup of the Council we come up with, not everyone will be okay with those choices. What are they supposed to do? Well, there is a large difference between a dictator-for-life and, for example, a collegial body that gets renewed from time to time. The latter is probably easier to compromise with, even for those who don't like its makeup. Regards Antoine. From barry at python.org Wed Jul 18 14:47:22 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 11:47:22 -0700 Subject: [python-committers] Language moratorium In-Reply-To: <20180718161156.GA5506@bytereef.org> References: <20180718161156.GA5506@bytereef.org> Message-ID: <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> On Jul 18, 2018, at 09:11, Stefan Krah wrote: > if I remember correctly, we had a moratorium for language changes around > versions 3.2-3.3. I think during that time relatively few BDFL-level > decisions were required. > > Perhaps we could have one again, say for 12 months so we can figure things > out. Other Python implementations may welcome the moratorium so they can > catch up. I agree that we?ll effectively have language moratorium until we have a new governance structure. But let me ask, what do you propose to do about PEP 572? That?s already been accepted, but not yet implemented. Would it be exempt from the moratorium or scoot in under the wire? 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 antoine at python.org Wed Jul 18 14:52:33 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 18 Jul 2018 20:52:33 +0200 Subject: [python-committers] Language moratorium In-Reply-To: <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> References: <20180718161156.GA5506@bytereef.org> <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> Message-ID: Le 18/07/2018 ? 20:47, Barry Warsaw a ?crit?: > On Jul 18, 2018, at 09:11, Stefan Krah wrote: > >> if I remember correctly, we had a moratorium for language changes around >> versions 3.2-3.3. I think during that time relatively few BDFL-level >> decisions were required. >> >> Perhaps we could have one again, say for 12 months so we can figure things >> out. Other Python implementations may welcome the moratorium so they can >> catch up. > > I agree that we?ll effectively have language moratorium until we have a new governance structure. But let me ask, what do you propose to do about PEP 572? That?s already been accepted, but not yet implemented. Would it be exempt from the moratorium or scoot in under the wire? Since it's accepted, the implementation is just a matter of code review and doesn't require (AFAICT) the intervention of an ultimate authority. As much as I dislike PEP 572... Regards Antoine. From christian at python.org Wed Jul 18 14:56:42 2018 From: christian at python.org (Christian Heimes) Date: Wed, 18 Jul 2018 20:56:42 +0200 Subject: [python-committers] Language moratorium In-Reply-To: <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> References: <20180718161156.GA5506@bytereef.org> <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> Message-ID: <2b6d3df4-8b04-ca9d-5bf2-14ebf2d2ab61@python.org> On 2018-07-18 20:47, Barry Warsaw wrote: > On Jul 18, 2018, at 09:11, Stefan Krah wrote: > >> if I remember correctly, we had a moratorium for language changes around >> versions 3.2-3.3. I think during that time relatively few BDFL-level >> decisions were required. >> >> Perhaps we could have one again, say for 12 months so we can figure things >> out. Other Python implementations may welcome the moratorium so they can >> catch up. > > I agree that we?ll effectively have language moratorium until we have a new governance structure. But let me ask, what do you propose to do about PEP 572? That?s already been accepted, but not yet implemented. Would it be exempt from the moratorium or scoot in under the wire? It's the last will of our beloved dictator. To quote my favorite Marvel villain: The first order of the new BDFL cannot undo the last will of the previous BDFL. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From tim.peters at gmail.com Wed Jul 18 15:08:43 2018 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 18 Jul 2018 14:08:43 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: <9706D627-344A-4487-81B6-CFB8A33ADB78@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <9706D627-344A-4487-81B6-CFB8A33ADB78@python.org> Message-ID: [Barry Warsaw, on the origin of BDFL] > I?d put my money on Uncle Timmy coining that term, Don't be insulting, Barry. I have no patience - let alone love - for frivolous wordplay. It wasn't me, but Guido doesn't remember either. Here's his best guess: https://www.artima.com/weblogs/viewpost.jsp?thread=235725 Short course: BDFL first appeared in a 1995 email sent by Ken Manheimer summarizing a PSA meeting. Guido was apparently named at that meeting as *First Interim Benevolent Dicator* [sic]* for Life* and While I can't prove my title (with or without the First Interim prefix) was > never used before, I'm pretty certain that it originated in this meeting. > Given what I know of how their minds work, it was most likely invented by > Ken Manheimer or Barry Warsaw, though it may well have been a joint > invention by all present. Some titles just _fit_. Like Kim Jong Il's Great Man, Who Is a Man of Deeds and Dear Leader, who is a perfect incarnation of the appearance that a leader should have More inspiring ideas where those came from: https://en.wikipedia.org/wiki/List_of_Kim_Jong-il%27s_titles -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Wed Jul 18 15:10:40 2018 From: stefan at bytereef.org (Stefan Krah) Date: Wed, 18 Jul 2018 21:10:40 +0200 Subject: [python-committers] Language moratorium In-Reply-To: <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> References: <20180718161156.GA5506@bytereef.org> <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> Message-ID: <20180718191040.GA8038@bytereef.org> On Wed, Jul 18, 2018 at 11:47:22AM -0700, Barry Warsaw wrote: > On Jul 18, 2018, at 09:11, Stefan Krah wrote: > > > if I remember correctly, we had a moratorium for language changes around > > versions 3.2-3.3. I think during that time relatively few BDFL-level > > decisions were required. > > > > Perhaps we could have one again, say for 12 months so we can figure things > > out. Other Python implementations may welcome the moratorium so they can > > catch up. > > I agree that we?ll effectively have language moratorium until we have a new governance structure. But let me ask, what do you propose to do about PEP 572? That?s already been accepted, but not yet implemented. Would it be exempt from the moratorium or scoot in under the wire? That is a tough question. :) I meant a moratorium for new decisions and subsequent changes, so I kind of assumed PEP 572 would go in. Stefan Krah From lukasz at langa.pl Wed Jul 18 17:04:32 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 16:04:32 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> Message-ID: <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> > On Jul 18, 2018, at 1:23 PM, Alex Martelli wrote: > > Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted. This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting for us to base our rules on a papal conclave. If we do, then it looks like 2/3 it is. However, historically cardinal participation rates were really high so I'd like to keep the 90% participation rule there. I do find it a bit problematic that a papal conclave doesn't vote "yes/no" but rather just places names for a predefined position using predefined rules. > In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session. Oh, you know how to hit close to home! However, there's a big difference between one vote vetoing the ruling and ten (as there's 100+ GitHub committers now IIRC). But yeah, if the Vatican is fine with two thirds, it sounds like we could, too. By the way, if we're already studying Polish parliamentary rules, 2/3 agreement is needed to make constitution changes. - ? From mariatta.wijaya at gmail.com Wed Jul 18 17:14:03 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 18 Jul 2018 14:14:03 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote. Barry made one proposal, that's all. Last week someone suggested doing research of other governance models. We should still do that before we even start voting on anything. Mariatta On Wed, Jul 18, 2018 at 2:04 PM ?ukasz Langa wrote: > > > On Jul 18, 2018, at 1:23 PM, Alex Martelli wrote: > > > > Since 1179 (and with a few very minor exceptions in the centuries right > after then -- none since 1612), the Catholic Church requires a > super-majority of 2/3 to elect a new Pope. I don't see how the choice of a > BDFL is so much more important to the Python community, than the choice of > a Pope is to the Catholic Church; thus, requiring 90% rather than "just" > 2/3 seems unwarranted. > > This is a good point. Moreover, I'm sure Monty Python-wise it's only > fitting for us to base our rules on a papal conclave. > > If we do, then it looks like 2/3 it is. However, historically cardinal > participation rates were really high so I'd like to keep the 90% > participation rule there. > > I do find it a bit problematic that a papal conclave doesn't vote "yes/no" > but rather just places names for a predefined position using predefined > rules. > > > In fact, a 90% requirement gets dangerously close to a requirement for > unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and > thus end the session and nullify every decision made in the session. > > Oh, you know how to hit close to home! However, there's a big difference > between one vote vetoing the ruling and ten (as there's 100+ GitHub > committers now IIRC). > > But yeah, if the Vatican is fine with two thirds, it sounds like we could, > too. By the way, if we're already studying Polish parliamentary rules, 2/3 > agreement is needed to make constitution changes. > > - ? > _______________________________________________ > 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 jack.jansen at cwi.nl Wed Jul 18 17:29:05 2018 From: jack.jansen at cwi.nl (Jack Jansen) Date: Wed, 18 Jul 2018 23:29:05 +0200 Subject: [python-committers] An alternative governance model In-Reply-To: <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: Is it necessary to put exact percentages here? I think a BDFL-replacement should have the support of a large majority of the community. I would expect anyone who would be considered as BDFL in the first place would voluntarily step down once this is no longer the case. I don?t think it is necessary to clearly define what ?large majority? means, nor what ?community? means. If the Python community ever gets to the level infighting of Borgia popes versus de Medici popes I think things have deteriorated to a level that it won?t make much difference anyways. I?m not 100% convinced I like Barry?s idea of a formal Council as the board of the community, but on the other hand I don?t have a good alternative (except for the anarchist village shouting match, but that has serious issues). Jack > On 18-Jul-2018, at 23:04 , ?ukasz Langa wrote: > > >> On Jul 18, 2018, at 1:23 PM, Alex Martelli wrote: >> >> Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted. > > This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting for us to base our rules on a papal conclave. > > If we do, then it looks like 2/3 it is. However, historically cardinal participation rates were really high so I'd like to keep the 90% participation rule there. > > I do find it a bit problematic that a papal conclave doesn't vote "yes/no" but rather just places names for a predefined position using predefined rules. > >> In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session. > > Oh, you know how to hit close to home! However, there's a big difference between one vote vetoing the ruling and ten (as there's 100+ GitHub committers now IIRC). > > But yeah, if the Vatican is fine with two thirds, it sounds like we could, too. By the way, if we're already studying Polish parliamentary rules, 2/3 agreement is needed to make constitution changes. > > - ? > _______________________________________________ > 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/ -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 18 17:56:34 2018 From: brett at python.org (Brett Cannon) Date: Wed, 18 Jul 2018 14:56:34 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: [starting a new thread] On Wed, 18 Jul 2018 at 14:04 ?ukasz Langa wrote: > > > On Jul 18, 2018, at 1:23 PM, Alex Martelli wrote: > > > > Since 1179 (and with a few very minor exceptions in the centuries right > after then -- none since 1612), the Catholic Church requires a > super-majority of 2/3 to elect a new Pope. I don't see how the choice of a > BDFL is so much more important to the Python community, than the choice of > a Pope is to the Catholic Church; thus, requiring 90% rather than "just" > 2/3 seems unwarranted. > > This is a good point. Moreover, I'm sure Monty Python-wise it's only > fitting for us to base our rules on a papal conclave. > > If we do, then it looks like 2/3 it is. However, historically cardinal > participation rates were really high so I'd like to keep the 90% > participation rule there. > To put hard numbers to this, there are 91 people with commit rights ATM and 171 potential people based on the bugs.python.org committers list. So that means we will require anywhere from 82 to 154 people to vote. To me that seems unreachable on either end of the scale. While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). -Brett > I do find it a bit problematic that a papal conclave doesn't vote "yes/no" > but rather just places names for a predefined position using predefined > rules. > > > In fact, a 90% requirement gets dangerously close to a requirement for > unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and > thus end the session and nullify every decision made in the session. > > Oh, you know how to hit close to home! However, there's a big difference > between one vote vetoing the ruling and ten (as there's 100+ GitHub > committers now IIRC). > > But yeah, if the Vatican is fine with two thirds, it sounds like we could, > too. By the way, if we're already studying Polish parliamentary rules, 2/3 > agreement is needed to make constitution changes. > > - ? > _______________________________________________ > 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 Wed Jul 18 18:01:42 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 17:01:42 -0500 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: > On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya wrote: > > Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote. I don't understand what you mean. Before we get to vote on a variant of PEP 2, we need to decide how we are supposed to perform that vote. This needs to be decided before we discuss councils, dictators, and so on because it's all moot if there is no accepted way to agree which governance model we want. > Last week someone suggested doing research of other governance models. We should still do that before we even start voting on anything. Yes, agreed, absolutely! But these are two separate concerns. I'm interested in establishing how we decide which model fits us. - ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at langa.pl Wed Jul 18 18:18:58 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 17:18:58 -0500 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: > On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: > > While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory. Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support: - this makes the decision authoritative ("the committers have spoken"); - this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote"). If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team. - ? From antoine at python.org Wed Jul 18 18:26:27 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 00:26:27 +0200 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> By the way, should the vote be public or secret? For such an important (and sensitive) matter, perhaps it would be wise for it to be secret. Regards Antoine. Le 19/07/2018 ? 00:18, ?ukasz Langa a ?crit?: > >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: >> >> While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). > > It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory. > > Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support: > - this makes the decision authoritative ("the committers have spoken"); > - this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote"). > > If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team. > > - ? > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > From vstinner at redhat.com Wed Jul 18 18:29:08 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 19 Jul 2018 00:29:08 +0200 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> Message-ID: I hate cabals. I prefer to keep everything open and transparent, as this mailing list is public (even if only core developers are allowed to post). Which drawback do you see of making the votes public? Victor 2018-07-19 0:26 GMT+02:00 Antoine Pitrou : > > By the way, should the vote be public or secret? > For such an important (and sensitive) matter, perhaps it would be wise > for it to be secret. > > Regards > > Antoine. > > > Le 19/07/2018 ? 00:18, ?ukasz Langa a ?crit : >> >>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: >>> >>> While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). >> >> It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory. >> >> Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support: >> - this makes the decision authoritative ("the committers have spoken"); >> - this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote"). >> >> If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team. >> >> - ? >> _______________________________________________ >> 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 Wed Jul 18 18:31:40 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 17:31:40 -0500 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> Message-ID: The PSF uses a good voting system where votes are secret. I see no reason not to reuse this infra. -- Best regards, ?ukasz Langa > On Jul 18, 2018, at 5:26 PM, Antoine Pitrou wrote: > > > By the way, should the vote be public or secret? > For such an important (and sensitive) matter, perhaps it would be wise > for it to be secret. > > Regards > > Antoine. > > >> Le 19/07/2018 ? 00:18, ?ukasz Langa a ?crit : >> >>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: >>> >>> While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). >> >> It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory. >> >> Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support: >> - this makes the decision authoritative ("the committers have spoken"); >> - this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote"). >> >> If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team. >> >> - ? >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From antoine at python.org Wed Jul 18 18:36:35 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 00:36:35 +0200 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> Message-ID: Le 19/07/2018 ? 00:29, Victor Stinner a ?crit?: > I hate cabals. I prefer to keep everything open and transparent, as > this mailing list is public (even if only core developers are allowed > to post). Even if posting is public, you won't know whether there is a cabal or not (unless you are part of the cabal -- I hope you aren't, are you? ;-)). > Which drawback do you see of making the votes public? Let's say I'm being asked if X should be a ? next BDFL ? (or Council member, etc.) and I vote no publicly. What is my position if X is elected? How will my vote be interpreted? Will I get discriminated against (even unconsciously) just because I didn't choose that person? There are all kinds of pressures (or self-censorship phenomena) that can occur with public voting. (votes by elected representatives, conversely, are public, because being elected it's important for the electors to know what the representatives truly stand for) Regards Antoine. > > Victor > > 2018-07-19 0:26 GMT+02:00 Antoine Pitrou : >> >> By the way, should the vote be public or secret? >> For such an important (and sensitive) matter, perhaps it would be wise >> for it to be secret. >> >> Regards >> >> Antoine. >> >> >> Le 19/07/2018 ? 00:18, ?ukasz Langa a ?crit : >>> >>>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: >>>> >>>> While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). >>> >>> It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory. >>> >>> Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support: >>> - this makes the decision authoritative ("the committers have spoken"); >>> - this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote"). >>> >>> If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team. >>> >>> - ? >>> _______________________________________________ >>> python-committers mailing list >>> python-committers at python.org >>> https://mail.python.org/mailman/listinfo/python-committers >>> Code of Conduct: https://www.python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ From antoine at python.org Wed Jul 18 18:37:54 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 00:37:54 +0200 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> Message-ID: <019b10ec-47d3-1e41-0e78-f98fef515b8e@python.org> Le 19/07/2018 ? 00:36, Antoine Pitrou a ?crit?: > > Le 19/07/2018 ? 00:29, Victor Stinner a ?crit?: >> I hate cabals. I prefer to keep everything open and transparent, as >> this mailing list is public (even if only core developers are allowed >> to post). > > Even if posting is public, you won't know whether there is a cabal or > not (unless you are part of the cabal -- I hope you aren't, are you? ;-)). Sorry: s/posting/voting/ From donald at stufft.io Wed Jul 18 18:46:30 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 18 Jul 2018 18:46:30 -0400 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa wrote: > > >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: >> >> While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote). > > It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory. Given that we don?t have a lot of levers in our tool chest to compel voting, what would you propose we do if we get only a 35% participation rate? We can?t drag people to the polls, the most we can really do is either keep running elections and hope you hit whatever threshold you decide on, or you start removing people who can vote until you?ve removed enough people that the people who are participating now make up whatever your target participation rate is. The first choice there strikes me as unrealistic. Hope is not a strategy, and I fail to see why repeatedly offering the same vote multiple times is likely to increase the participation rate. In fact, I think it?s likely to decease it as people get tired of having to do it over again and just start giving up and viewing it as noise. The second choice seems? dishonest to me? You?re not really increasing the participation of the vote, you?re just juicing the numbers to make the participation rate higher. It?s selectively defining who is eligible to vote to make the numbers look better. Is there another option I?m missing to compel people to vote? > > Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support: > - this makes the decision authoritative ("the committers have spoken?); I think this is largely a non-issue. In the US we do not have mandatory elections, and I don?t see very many people challenging the authority of said elections due to the large percentage of non-voters. The most I generally see if people scolding those who don?t vote. > - this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote?). Unless you require 100% voting participation, it doesn?t ensure this, it just makes it less likely. If you target 90%, then a full 10% of the people could have been excluded due to poor timing. I don?t think it?s possible to fully eliminate this risk, but I think the best possible way of handling it is to advertise the vote well in advance, and allow the vote itself to take place over a reasonable amount of time. The more advance notice, and the larger the window of time is to actually vote in, the less likely timing becomes an issue. Just to pluck some random times out of the air, if you advertise the voting for 3 months and allow voting to happen any time in a months time, that gives people a full 4 months they will have to be completely unavailable to have no idea the voting is happening, and be unable to access a computer for a handful of minutes to actually do the vote at all in a month. > > If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team. > From fred at fdrake.net Wed Jul 18 19:06:56 2018 From: fred at fdrake.net (Fred Drake) Date: Wed, 18 Jul 2018 19:06:56 -0400 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: > On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya wrote: > Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote. On Wed, Jul 18, 2018 at 6:03 PM ?ukasz Langa wrote: > I don't understand what you mean. Before we get to vote on a variant of PEP 2, we need to decide how we are supposed to perform that vote. This needs to be decided before we discuss councils, dictators, and so on because it's all moot if there is no accepted way to agree which governance model we want. Humans do so love to argue! Both the decision-making process and the candidate decisions are reasonable to discuss; there's no intrinsic ordering constraint for reasonable discussion. We need to decide on the decision-making mechanism before the decision can be made, but that's it. PEP 2 is (currently) the "Procedure for Adding New Modules". Though superseded, recycling the PEP number seems out of character with the RFC process from which we derived the PEP process. Let's be cautious about recycling like that; integers are cheap. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein From donald at stufft.io Wed Jul 18 19:13:05 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 18 Jul 2018 19:13:05 -0400 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: > On Jul 18, 2018, at 7:06 PM, Fred Drake wrote: > > PEP 2 is (currently) the "Procedure for Adding New Modules". Though > superseded, recycling the PEP number seems out of character with the > RFC process from which we derived the PEP process. Let's be cautious > about recycling like that; integers are cheap. Amusingly, I went through the low numbered PEPs as a result of this, and found https://www.python.org/dev/peps/pep-0010/ . -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Wed Jul 18 19:14:29 2018 From: barry at python.org (Barry Warsaw) Date: Wed, 18 Jul 2018 16:14:29 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org> On Jul 18, 2018, at 16:06, Fred Drake wrote: > PEP 2 is (currently) the "Procedure for Adding New Modules". Though > superseded, recycling the PEP number seems out of character with the > RFC process from which we derived the PEP process. Let's be cautious > about recycling like that; integers are cheap. Dang, so it is. :( I don?t want to recycle numbers, so we?ll likely end up taking the next available low ones. 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 mariatta.wijaya at gmail.com Wed Jul 18 19:16:07 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 18 Jul 2018 16:16:07 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org> Message-ID: Next available is PEP lucky number 13 ? Mariatta On Wed, Jul 18, 2018 at 4:14 PM Barry Warsaw wrote: > On Jul 18, 2018, at 16:06, Fred Drake wrote: > > > PEP 2 is (currently) the "Procedure for Adding New Modules". Though > > superseded, recycling the PEP number seems out of character with the > > RFC process from which we derived the PEP process. Let's be cautious > > about recycling like that; integers are cheap. > > Dang, so it is. :( > > I don?t want to recycle numbers, so we?ll likely end up taking the next > available low ones. > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Wed Jul 18 19:17:33 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 19 Jul 2018 01:17:33 +0200 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> Message-ID: 2018-07-19 0:36 GMT+02:00 Antoine Pitrou : > Let's say I'm being asked if X should be a ? next BDFL ? (or Council > member, etc.) and I vote no publicly. What is my position if X is > elected? How will my vote be interpreted? Will I get discriminated > against (even unconsciously) just because I didn't choose that person? I see. I understood that we were more discussing the governance model than voting for a specific BDFL: I'm not convinced yet that we need a BDFL :-) Victor From brett at python.org Wed Jul 18 19:21:07 2018 From: brett at python.org (Brett Cannon) Date: Wed, 18 Jul 2018 16:21:07 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> Message-ID: On Wed, 18 Jul 2018 at 15:46 Donald Stufft wrote: > > > > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa wrote: > > > > > >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: > >> > >> While I am totally fine with a super-majority of votes for something to > be accepted, I don't think the minimum participation requirement will work. > If people simply choose not to vote then they choose not to (we have no way > to really compel people to vote). > > > > It could be easily added to the list of things expected from a core > contributor. It's not like this is a laborious chore, neither is it > happening often. There are countries where voting is mandatory. > > Given that we don?t have a lot of levers in our tool chest to compel > voting, what would you propose we do if we get only a 35% participation > rate? We can?t drag people to the polls, the most we can really do is > either keep running elections and hope you hit whatever threshold you > decide on, or you start removing people who can vote until you?ve removed > enough people that the people who are participating now make up whatever > your target participation rate is. > > The first choice there strikes me as unrealistic. Hope is not a strategy, > and I fail to see why repeatedly offering the same vote multiple times is > likely to increase the participation rate. In fact, I think it?s likely to > decease it as people get tired of having to do it over again and just start > giving up and viewing it as noise. > > The second choice seems? dishonest to me? You?re not really increasing the > participation of the vote, you?re just juicing the numbers to make the > participation rate higher. It?s selectively defining who is eligible to > vote to make the numbers look better. > > Is there another option I?m missing to compel people to vote? > > > > > Taking a step back, there are two reasons I stress the importance of > (almost) everybody voicing their support: > > - this makes the decision authoritative ("the committers have spoken?); > > I think this is largely a non-issue. In the US we do not have mandatory > elections, and I don?t see very many people challenging the authority of > said elections due to the large percentage of non-voters. The most I > generally see if people scolding those who don?t vote. > > > - this ensures that we haven't omitted somebody due to poor timing ("I > was on a sabbatical and couldn't vote?). > > Unless you require 100% voting participation, it doesn?t ensure this, it > just makes it less likely. If you target 90%, then a full 10% of the people > could have been excluded due to poor timing. > > I don?t think it?s possible to fully eliminate this risk, but I think the > best possible way of handling it is to advertise the vote well in advance, > and allow the vote itself to take place over a reasonable amount of time. > The more advance notice, and the larger the window of time is to actually > vote in, the less likely timing becomes an issue. Just to pluck some random > times out of the air, if you advertise the voting for 3 months and allow > voting to happen any time in a months time, that gives people a full 4 > months they will have to be completely unavailable to have no idea the > voting is happening, and be unable to access a computer for a handful of > minutes to actually do the vote at all in a month. > I think this is a reasonable way to deal with the situation. We will also need to see how many proposals we have and how similar they are, else we might have to talk about ranked ballot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Wed Jul 18 19:34:39 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 18 Jul 2018 19:34:39 -0400 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org> Message-ID: <1531956677-sup-3846@lrrr.local> Excerpts from ?ukasz Langa's message of 2018-07-18 17:31:40 -0500: > The PSF uses a good voting system where votes are secret. I see no reason not to reuse this infra. > > -- > Best regards, > ?ukasz Langa This feels like a case where a consensus-based voting system may be better than one that depends on amassing raw votes. https://civs.cs.cornell.edu is a hosted version of Condorcet that is reliable, easy to use, and allows for public review of the ballots (without associating them with the person casting them). Doug From fred at fdrake.net Wed Jul 18 19:36:46 2018 From: fred at fdrake.net (Fred Drake) Date: Wed, 18 Jul 2018 19:36:46 -0400 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org> Message-ID: On Wed, Jul 18, 2018 at 7:16 PM Mariatta Wijaya wrote: > Next available is PEP lucky number 13 ? > As an integer, it has no known problems. What could possibly go wrong? ;-) To bad safe, make sure it lands on a Friday. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleax at google.com Wed Jul 18 20:28:30 2018 From: aleax at google.com (Alex Martelli) Date: Wed, 18 Jul 2018 17:28:30 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> Message-ID: There are plenty of precedents for mandatory voting, but the enforcement mechanisms (if any) appear not to be applicable to our case. Note the "if any": several countries declare voting a citizen's duty (in their Constitution or otherwise) but don't actually enforce this duty in any way. For example, that's the case in the United States: if you apply for naturalization you will be quizzed on many things, including "what are the duties of a citizen", and one of the latter is "participate in the democratic process" which includes voting -- but if you don't, no enforcement action is taken against you. In contrast, if you get a jury summons (jury duty being another of those citizen duties) and repeatedly fail to show up, you may end up in jail -- now THAT is enforcement of the duty (and no Python community organism has, nor should have, such power of enforcement. In Italy, where voting is declared to be a duty in the Constitution, at the start of the Republic you'd get (until next election) a stamp of "non ha votato" ("did not vote") in your publicly accessible judiciary record (it would come up in any background search -- and, in a country where firing employees was notoriously hard, some opined that such a flaw might be grounds for dismissal if the employer so wished, although I've never heard of it happening). That was abolished 25 years ago, in part because it was randomly/capriciously enforced (many judicial districts were too otherwise-busy to go through voting records and apply/remove the stamp!-). So, now, Italy is in the vast camp of countries declaring voting a duty (Italy's constitution was not changed on this subject) but not enforcing the "duty" at all (indeed, failing to show up to vote is now often advocated by adversaries of referendums, which have a 50% minimum participation threshold to be valid and may well be easier to defeat by getting people to just not show up -- since many others won't anyway for other reasons -- than by getting them to vote against). Since I originally brought up a parallel between "which BDFL" voting, and a Papal conclave, I would be remiss to fail to mention that since 1274 the Cardinals are locked up "with a key" ("cum clave") until a Pope does get elected -- usually a good-enough incentive to vote (though once the citizens of the town where the conclave was held had to decide after a few failed votes to only send in bread and water -- and later, said citizens removed the roof of the palace where the Cardinals were locked up, hoping that rain may speed up the proceedings). Colorful, but, again, not really applicable in our case. What's left? The "public naming and shaming" Italy used until a quarter century ago might work -- just make a little site listing the committers who, while having a right to vote, haven't voted (yet). A VERY long voting period might also help -- amendments to the US Constitution originally had unlimited times for ratification (the 27th amendment, originally the 2nd one proposed in 1789, was ratified 202 years after proposal), though these days 7 years is a more customary time limit for ratification. Not sure if these are good ideas. Another possibility is to avoid having separate thresholds for participation and approval (US constitution amendments work that way -- with the specifics being a threshold only for approval out of all States, not how many States have voted for or against). I.e, if we decide 2/3 is OK, a proposal might be approved if 2/3 of *eligible* voters have voted for it -- no matter how many of the remaining 1/3 have voted against, or not (yet?) voted at all (since, if 100% of eligible voters could be bothered to vote, once the proposal gets 2/3 of the votes in favor, it does not matter whether the remaining 1/3 vote against, abstain, or whatever). This is not mutually exclusive with other ideas (of which, out of what I've mentioned, the viable ones -- though not necessarily wise! -- would be "public naming" of non-voters, and VERY long voting periods). Lastly, I suspect two votes should be separated: (1) what model we adopt (BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO is going to serve (as BDFL, as triumvirate member, and so on)... Alex On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft wrote: > > > > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa wrote: > > > > > >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: > >> > >> While I am totally fine with a super-majority of votes for something to > be accepted, I don't think the minimum participation requirement will work. > If people simply choose not to vote then they choose not to (we have no way > to really compel people to vote). > > > > It could be easily added to the list of things expected from a core > contributor. It's not like this is a laborious chore, neither is it > happening often. There are countries where voting is mandatory. > > Given that we don?t have a lot of levers in our tool chest to compel > voting, what would you propose we do if we get only a 35% participation > rate? We can?t drag people to the polls, the most we can really do is > either keep running elections and hope you hit whatever threshold you > decide on, or you start removing people who can vote until you?ve removed > enough people that the people who are participating now make up whatever > your target participation rate is. > > The first choice there strikes me as unrealistic. Hope is not a strategy, > and I fail to see why repeatedly offering the same vote multiple times is > likely to increase the participation rate. In fact, I think it?s likely to > decease it as people get tired of having to do it over again and just start > giving up and viewing it as noise. > > The second choice seems? dishonest to me? You?re not really increasing the > participation of the vote, you?re just juicing the numbers to make the > participation rate higher. It?s selectively defining who is eligible to > vote to make the numbers look better. > > Is there another option I?m missing to compel people to vote? > > > > > Taking a step back, there are two reasons I stress the importance of > (almost) everybody voicing their support: > > - this makes the decision authoritative ("the committers have spoken?); > > I think this is largely a non-issue. In the US we do not have mandatory > elections, and I don?t see very many people challenging the authority of > said elections due to the large percentage of non-voters. The most I > generally see if people scolding those who don?t vote. > > > - this ensures that we haven't omitted somebody due to poor timing ("I > was on a sabbatical and couldn't vote?). > > Unless you require 100% voting participation, it doesn?t ensure this, it > just makes it less likely. If you target 90%, then a full 10% of the people > could have been excluded due to poor timing. > > I don?t think it?s possible to fully eliminate this risk, but I think the > best possible way of handling it is to advertise the vote well in advance, > and allow the vote itself to take place over a reasonable amount of time. > The more advance notice, and the larger the window of time is to actually > vote in, the less likely timing becomes an issue. Just to pluck some random > times out of the air, if you advertise the voting for 3 months and allow > voting to happen any time in a months time, that gives people a full 4 > months they will have to be completely unavailable to have no idea the > voting is happening, and be unable to access a computer for a handful of > minutes to actually do the vote at all in a month. > > > > > If you feel like this is unrealistic because most of our committers > aren't currently active, I hear you. But what I like even less is claiming > that "we, the core team" made a decision when, say, just 35% of us voted. > In such case it would be easier for those of us who disagree to claim the > decision doesn't really represent the views of the greater core team. > > > > > > _______________________________________________ > 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 aleax at google.com Wed Jul 18 20:31:18 2018 From: aleax at google.com (Alex Martelli) Date: Wed, 18 Jul 2018 17:31:18 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: On Wed, Jul 18, 2018 at 4:09 PM Fred Drake wrote: > > On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya > wrote: > > Let's be clear that we're not yet at the stage where we can vote for > anything, let alone how to vote. > > On Wed, Jul 18, 2018 at 6:03 PM ?ukasz Langa wrote: > > I don't understand what you mean. Before we get to vote on a variant of > PEP 2, we need to decide how we are supposed to perform that vote. This > needs to be decided before we discuss councils, dictators, and so on > because it's all moot if there is no accepted way to agree which governance > model we want. > > Humans do so love to argue! > No we don't! (cfr http://www.montypython.net/scripts/argument.php)... Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 18 20:50:49 2018 From: brett at python.org (Brett Cannon) Date: Wed, 18 Jul 2018 17:50:49 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> Message-ID: [can I just say how much I've missed having both you and Tim around, Alex? ?] On Wed, Jul 18, 2018, 17:28 Alex Martelli via python-committers, < python-committers at python.org> wrote: > There are plenty of precedents for mandatory voting, but the enforcement > mechanisms (if any) appear not to be applicable to our case. Note the "if > any": several countries declare voting a citizen's duty (in their > Constitution or otherwise) but don't actually enforce this duty in any way. > For example, that's the case in the United States: if you apply for > naturalization you will be quizzed on many things, including "what are the > duties of a citizen", and one of the latter is "participate in the > democratic process" which includes voting -- but if you don't, no > enforcement action is taken against you. In contrast, if you get a jury > summons (jury duty being another of those citizen duties) and repeatedly > fail to show up, you may end up in jail -- now THAT is enforcement of the > duty (and no Python community organism has, nor should have, such power of > enforcement. > And that lack of enforcement power is what makes me worry about mandatory participation to make a vote considered legitimate. > In Italy, where voting is declared to be a duty in the Constitution, at > the start of the Republic you'd get (until next election) a stamp of "non > ha votato" ("did not vote") in your publicly accessible judiciary record > (it would come up in any background search -- and, in a country where > firing employees was notoriously hard, some opined that such a flaw might > be grounds for dismissal if the employer so wished, although I've never > heard of it happening). That was abolished 25 years ago, in part because it > was randomly/capriciously enforced (many judicial districts were too > otherwise-busy to go through voting records and apply/remove the stamp!-). > So, now, Italy is in the vast camp of countries declaring voting a duty > (Italy's constitution was not changed on this subject) but not enforcing > the "duty" at all (indeed, failing to show up to vote is now often > advocated by adversaries of referendums, which have a 50% minimum > participation threshold to be valid and may well be easier to defeat by > getting people to just not show up -- since many others won't anyway for > other reasons -- than by getting them to vote against). > > Since I originally brought up a parallel between "which BDFL" voting, and > a Papal conclave, I would be remiss to fail to mention that since 1274 the > Cardinals are locked up "with a key" ("cum clave") until a Pope does get > elected -- usually a good-enough incentive to vote (though once the > citizens of the town where the conclave was held had to decide after a few > failed votes to only send in bread and water -- and later, said citizens > removed the roof of the palace where the Cardinals were locked up, hoping > that rain may speed up the proceedings). Colorful, but, again, not really > applicable in our case. > > What's left? The "public naming and shaming" Italy used until a quarter > century ago might work -- just make a little site listing the committers > who, while having a right to vote, haven't voted (yet). A VERY long voting > period might also help -- amendments to the US Constitution originally had > unlimited times for ratification (the 27th amendment, originally the 2nd > one proposed in 1789, was ratified 202 years after proposal), though these > days 7 years is a more customary time limit for ratification. Not sure if > these are good ideas. > > Another possibility is to avoid having separate thresholds for > participation and approval (US constitution amendments work that way -- > with the specifics being a threshold only for approval out of all States, > not how many States have voted for or against). I.e, if we decide 2/3 is > OK, a proposal might be approved if 2/3 of *eligible* voters have voted > for it -- no matter how many of the remaining 1/3 have voted against, or > not (yet?) voted at all (since, if 100% of eligible voters could be > bothered to vote, once the proposal gets 2/3 of the votes in favor, it does > not matter whether the remaining 1/3 vote against, abstain, or whatever). > This is not mutually exclusive with other ideas (of which, out of what I've > mentioned, the viable ones -- though not necessarily wise! -- would be > "public naming" of non-voters, and VERY long voting periods). > That is a good point of clarification. If we did super-majority, is it of all counted *votes* or all possible *voters*? We might be surprised by the participation levels, or we might be disappointed. So we might have to go on what we think is reasonable, try it, and if there's a threshold requirement then be prepared to have to vote again (and again ...) until the threshold is met (or we lower the threshold ?). Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) to have made a commit you have look back 7 years of commit history (that will include non-core folks and those who don't have privileges anymore). > Lastly, I suspect two votes should be separated: (1) what model we adopt > (BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO > is going to serve (as BDFL, as triumvirate member, and so on)... > I'm assuming that's how we will want to structure it as probably any of these proposals will specify how someone(s) will be chosen. -Brett > > Alex > > On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft wrote: > >> >> >> > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa wrote: >> > >> > >> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote: >> >> >> >> While I am totally fine with a super-majority of votes for something >> to be accepted, I don't think the minimum participation requirement will >> work. If people simply choose not to vote then they choose not to (we have >> no way to really compel people to vote). >> > >> > It could be easily added to the list of things expected from a core >> contributor. It's not like this is a laborious chore, neither is it >> happening often. There are countries where voting is mandatory. >> >> Given that we don?t have a lot of levers in our tool chest to compel >> voting, what would you propose we do if we get only a 35% participation >> rate? We can?t drag people to the polls, the most we can really do is >> either keep running elections and hope you hit whatever threshold you >> decide on, or you start removing people who can vote until you?ve removed >> enough people that the people who are participating now make up whatever >> your target participation rate is. >> >> The first choice there strikes me as unrealistic. Hope is not a strategy, >> and I fail to see why repeatedly offering the same vote multiple times is >> likely to increase the participation rate. In fact, I think it?s likely to >> decease it as people get tired of having to do it over again and just start >> giving up and viewing it as noise. >> >> The second choice seems? dishonest to me? You?re not really increasing >> the participation of the vote, you?re just juicing the numbers to make the >> participation rate higher. It?s selectively defining who is eligible to >> vote to make the numbers look better. >> >> Is there another option I?m missing to compel people to vote? >> >> > >> > Taking a step back, there are two reasons I stress the importance of >> (almost) everybody voicing their support: >> > - this makes the decision authoritative ("the committers have spoken?); >> >> I think this is largely a non-issue. In the US we do not have mandatory >> elections, and I don?t see very many people challenging the authority of >> said elections due to the large percentage of non-voters. The most I >> generally see if people scolding those who don?t vote. >> >> > - this ensures that we haven't omitted somebody due to poor timing ("I >> was on a sabbatical and couldn't vote?). >> >> Unless you require 100% voting participation, it doesn?t ensure this, it >> just makes it less likely. If you target 90%, then a full 10% of the people >> could have been excluded due to poor timing. >> >> I don?t think it?s possible to fully eliminate this risk, but I think the >> best possible way of handling it is to advertise the vote well in advance, >> and allow the vote itself to take place over a reasonable amount of time. >> The more advance notice, and the larger the window of time is to actually >> vote in, the less likely timing becomes an issue. Just to pluck some random >> times out of the air, if you advertise the voting for 3 months and allow >> voting to happen any time in a months time, that gives people a full 4 >> months they will have to be completely unavailable to have no idea the >> voting is happening, and be unable to access a computer for a handful of >> minutes to actually do the vote at all in a month. >> >> > >> > If you feel like this is unrealistic because most of our committers >> aren't currently active, I hear you. But what I like even less is claiming >> that "we, the core team" made a decision when, say, just 35% of us voted. >> In such case it would be easier for those of us who disagree to claim the >> decision doesn't really represent the views of the greater core team. >> > >> >> >> >> _______________________________________________ >> 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 aleax at google.com Wed Jul 18 21:08:48 2018 From: aleax at google.com (Alex Martelli) Date: Wed, 18 Jul 2018 18:08:48 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> Message-ID: Hi Brett, On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon wrote: > [can I just say how much I've missed having both you and Tim around, Alex? > ?] Heh, good to hear!-) Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) > Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 (at least not in the US with our `Imperial` system; does it work any differently in Canada with Metric?-)... Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 18 21:49:19 2018 From: brett at python.org (Brett Cannon) Date: Wed, 18 Jul 2018 18:49:19 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> Message-ID: On Wed, Jul 18, 2018, 18:09 Alex Martelli, wrote: > Hi Brett, > > On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon wrote: > >> [can I just say how much I've missed having both you and Tim around, >> Alex? ?] > > > Heh, good to hear!-) > > Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) >> > > Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce > on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 > (at least not in the US with our `Imperial` system; does it work any > differently in Canada with Metric?-)... > Sorry, the 82 in my head was from when Lukasz proposed 90%. That's what I get for replying to emails on the bus after a very stressful day at work. -Brett > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 18 21:53:51 2018 From: brett at python.org (Brett Cannon) Date: Wed, 18 Jul 2018 18:53:51 -0700 Subject: [python-committers] Proposal on how to vote (was: An alternative governance model) In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io> Message-ID: On Wed, Jul 18, 2018, 18:49 Brett Cannon, wrote: > > > On Wed, Jul 18, 2018, 18:09 Alex Martelli, wrote: > >> Hi Brett, >> >> On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon wrote: >> >>> [can I just say how much I've missed having both you and Tim around, >>> Alex? ?] >> >> >> Heh, good to hear!-) >> >> Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) >>> >> >> Uh, sorry, but -- even were you to become BDFL, you don't get to >> Pronounce on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near >> "roughly" 84 (at least not in the US with our `Imperial` system; does it >> work any differently in Canada with Metric?-)... >> > > Sorry, the 82 in my head was from when Lukasz proposed 90%. That's what I > get for replying to emails on the bus after a very stressful day at work. > And I just checked with the proper number and it goes back about 4 years to 2014. -Brett > -Brett > > >> Alex >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 18 21:56:06 2018 From: brett at python.org (Brett Cannon) Date: Wed, 18 Jul 2018 18:56:06 -0700 Subject: [python-committers] Language moratorium In-Reply-To: References: <20180718161156.GA5506@bytereef.org> Message-ID: On Wed, Jul 18, 2018, 09:32 Mariatta Wijaya, wrote: > There is a de facto moratorium for the time being until a new governance >> model is chosen. Let's not formalize anything beyond that. > > > I agree. > Same here. -Brett > Mariatta > > > On Wed, Jul 18, 2018 at 9:24 AM ?ukasz Langa wrote: > >> There is a de facto moratorium for the time being until a new governance >> model is chosen. Let's not formalize anything beyond that. >> >> -- >> Best regards, >> ?ukasz Langa >> >> > On Jul 18, 2018, at 11:11 AM, Stefan Krah wrote: >> > >> > >> > Hi, >> > >> > if I remember correctly, we had a moratorium for language changes around >> > versions 3.2-3.3. I think during that time relatively few BDFL-level >> > decisions were required. >> > >> > Perhaps we could have one again, say for 12 months so we can figure >> things >> > out. Other Python implementations may welcome the moratorium so they can >> > catch up. >> > >> > >> > During that time we could just informally listen very closely to Guido >> if >> > anything requires a decision and he happens to be around. But there may >> be >> > no decisions at all. >> > >> > And yes, I guess we can successfully attempt to be nice, especially to >> him >> > (thanks for this wonderful language!). >> > >> > >> > >> > Stefan Krah >> > >> > >> > >> > _______________________________________________ >> > 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 tim.peters at gmail.com Wed Jul 18 22:23:47 2018 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 18 Jul 2018 21:23:47 -0500 Subject: [python-committers] Language moratorium In-Reply-To: <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> References: <20180718161156.GA5506@bytereef.org> <81438D53-3E3A-4CD1-807F-4D06112BFE1C@python.org> Message-ID: [Barry] > I agree that we?ll effectively have language moratorium until we have a > new governance structure. Unsure! Governance is needed to resolve conflict. When there's broad agreement, "leaders" aren't really needed. For example, there's been a bit of talk on python-ideas about adding a new `intmath` module capturing some frequently reinvented functions for which decent implementations are known but non-obvious (e.g., for generating the primes). Nobody could sanely fight to death against something like that. Even whining about it would appear petty ;-) But let me ask, what do you propose to do about PEP 572? That?s already > been accepted, but not yet implemented. Would it be exempt from the > moratorium or scoot in under the wire? Unless "accepted" has a meaning with which I'm unfamiliar, "exempt" is the obvious answer. Changing to such an unfamiliar meaning would require the very governance structure whose present existence is denied by the case hypothesis ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Wed Jul 18 22:36:35 2018 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 18 Jul 2018 19:36:35 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions Message-ID: [tl;dr: We need some ground rules, because uncertainty makes it hard to think straight. But if we get sucked into a complicated meta-debate about the ground rules then that defeats the purpose. My proposal for a Minimum Viable Ground Rule: let's all agree not to finalize any governance decisions before October 1.] We're in a constitutional crisis, and that's scary. There's no map and none of us know what to expect. It feels like anything could happen. You look at the mailing list and see people making big proposals -- is one of them going to suddenly be adopted? If I look away for a few days, will I come back and find out that something's been decided? What are we even talking about? Do I need to jump into that thread RIGHT NOW? It's scary. People don't do their best work when scared. When we're scared it's harder to listen and build up common ground with others -- but that's exactly what we'll need to do to get through this. And also, like... being scared sucks. I would prefer to be less scared. So: can we do anything to make this less scary? One thing that would help is if we had some ground-rules for how the decision itself will be made. Knowing what to expect makes things less scary. There's another thread going on right now trying to do that (subject "Proposal on how to vote"). But... if you look at that thread, it turns out deciding on how to vote is itself an important decision with lots of subtle issues, where we probably want to give people time to think, brainstorm, critique. Heck, in the end we might decide a vote isn't even the best approach. So I'm not saying we shouldn't be having that discussion, we definitely should, but... it's also giving me a new source of anxiety: that we'll all be so eager to get *some* certainty here that we'll end up trying to force a decision prematurely. Kind of a catch-22: the decision about how to make complex decisions is itself a complex decision, which is what we don't know how to do yet. Is there some way to avoid this loop? Can we come up with some ground rules simple enough that we can agree on them without a big debate? Well, there's one thing I am pretty sure of: this is a big decision, there's a lot to think about and talk about, and that we won't regret taking some time some time to do that. And besides, trying to force it to happen faster will make people more scared and dig in their heels. So here's my proposal for an initial, Minimum Viable Ground Rule: we should set a date and promise that no actual decisions will be finalized before that. Until then we are just talking and brainstorming and gradually converging on points of consensus. (And to be clear, the point of this is to give us breathing room, not set a deadline -- we shouldn't dawdle, but if we get there and it turns out we need more time, then that's OK.) What would be a good date? The core sprint is coming up Sept. 10-14, and this seems to be a likely topic of conversation there. And then after the sprint, those who aren't present will need time to catch up with any discussions that happened at the sprint. So to make things concrete, I propose: no governance decisions finalized before October 1, 2018. Probably this is what will end up happening anyway, but if we make it explicit in advance and tell everyone, then at least we'll all know that it's OK to stop refreshing our email constantly and redirect that energy in more useful directions. What do you all think? -n -- Nathaniel J. Smith -- https://vorpus.org From robertc at robertcollins.net Wed Jul 18 22:47:18 2018 From: robertc at robertcollins.net (Robert Collins) Date: Thu, 19 Jul 2018 14:47:18 +1200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: So, I'm fine with this, but FWIW I'm also fine with anything we come up with: I trust us, our intentions individually and in aggregate, and I can't imagine a poor outcome. -Rob On 19 July 2018 at 14:36, Nathaniel Smith wrote: > [tl;dr: We need some ground rules, because uncertainty makes it hard > to think straight. But if we get sucked into a complicated meta-debate > about the ground rules then that defeats the purpose. My proposal for > a Minimum Viable Ground Rule: let's all agree not to finalize any > governance decisions before October 1.] From ethan at stoneleaf.us Wed Jul 18 22:55:09 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 19:55:09 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: <5B4FFD8D.3090604@stoneleaf.us> On 07/18/2018 07:36 PM, Nathaniel Smith wrote: > [tl;dr: We need some ground rules, because uncertainty makes it hard > to think straight. But if we get sucked into a complicated meta-debate > about the ground rules then that defeats the purpose. My proposal for > a Minimum Viable Ground Rule: let's all agree not to finalize any > governance decisions before October 1.] +1 -- ~Ethan~ From zachary.ware+pydev at gmail.com Wed Jul 18 23:05:18 2018 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Wed, 18 Jul 2018 22:05:18 -0500 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <5B4FFD8D.3090604@stoneleaf.us> References: <5B4FFD8D.3090604@stoneleaf.us> Message-ID: +1 -- Zach (On a phone) On Wed, Jul 18, 2018, 21:54 Ethan Furman wrote: > On 07/18/2018 07:36 PM, Nathaniel Smith wrote: > > > [tl;dr: We need some ground rules, because uncertainty makes it hard > > to think straight. But if we get sucked into a complicated meta-debate > > about the ground rules then that defeats the purpose. My proposal for > > a Minimum Viable Ground Rule: let's all agree not to finalize any > > governance decisions before October 1.] > > +1 > > -- > ~Ethan~ > > _______________________________________________ > 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 aleax at google.com Wed Jul 18 23:31:12 2018 From: aleax at google.com (Alex Martelli) Date: Wed, 18 Jul 2018 20:31:12 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: FWIW, +1. Alex On Wed, Jul 18, 2018 at 7:36 PM Nathaniel Smith wrote: > [tl;dr: We need some ground rules, because uncertainty makes it hard > to think straight. But if we get sucked into a complicated meta-debate > about the ground rules then that defeats the purpose. My proposal for > a Minimum Viable Ground Rule: let's all agree not to finalize any > governance decisions before October 1.] > > We're in a constitutional crisis, and that's scary. There's no map and > none of us know what to expect. It feels like anything could happen. > You look at the mailing list and see people making big proposals -- is > one of them going to suddenly be adopted? If I look away for a few > days, will I come back and find out that something's been decided? > What are we even talking about? Do I need to jump into that thread > RIGHT NOW? It's scary. > > People don't do their best work when scared. When we're scared it's > harder to listen and build up common ground with others -- but that's > exactly what we'll need to do to get through this. And also, like... > being scared sucks. I would prefer to be less scared. > > So: can we do anything to make this less scary? > > One thing that would help is if we had some ground-rules for how the > decision itself will be made. Knowing what to expect makes things less > scary. There's another thread going on right now trying to do that > (subject "Proposal on how to vote"). But... if you look at that > thread, it turns out deciding on how to vote is itself an important > decision with lots of subtle issues, where we probably want to give > people time to think, brainstorm, critique. Heck, in the end we might > decide a vote isn't even the best approach. So I'm not saying we > shouldn't be having that discussion, we definitely should, but... it's > also giving me a new source of anxiety: that we'll all be so eager to > get *some* certainty here that we'll end up trying to force a decision > prematurely. Kind of a catch-22: the decision about how to make > complex decisions is itself a complex decision, which is what we don't > know how to do yet. > > Is there some way to avoid this loop? Can we come up with some ground > rules simple enough that we can agree on them without a big debate? > Well, there's one thing I am pretty sure of: this is a big decision, > there's a lot to think about and talk about, and that we won't regret > taking some time some time to do that. And besides, trying to force it > to happen faster will make people more scared and dig in their heels. > > So here's my proposal for an initial, Minimum Viable Ground Rule: we > should set a date and promise that no actual decisions will be > finalized before that. Until then we are just talking and > brainstorming and gradually converging on points of consensus. (And to > be clear, the point of this is to give us breathing room, not set a > deadline -- we shouldn't dawdle, but if we get there and it turns out > we need more time, then that's OK.) > > What would be a good date? The core sprint is coming up Sept. 10-14, > and this seems to be a likely topic of conversation there. And then > after the sprint, those who aren't present will need time to catch up > with any discussions that happened at the sprint. So to make things > concrete, I propose: no governance decisions finalized before October > 1, 2018. > > Probably this is what will end up happening anyway, but if we make it > explicit in advance and tell everyone, then at least we'll all know > that it's OK to stop refreshing our email constantly and redirect that > energy in more useful directions. > > What do you all think? > > -n > > -- > Nathaniel J. Smith -- https://vorpus.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 lukasz at langa.pl Wed Jul 18 23:45:33 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 18 Jul 2018 22:45:33 -0500 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: > On Jul 18, 2018, at 9:36 PM, Nathaniel Smith wrote: > > I propose: no governance decisions finalized before October > 1, 2018. +1 but it's okay and expected that discussions here will continue in the interim. - ? From ethan at stoneleaf.us Wed Jul 18 23:55:17 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 20:55:17 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: <5B500BA5.5010802@stoneleaf.us> On 07/18/2018 08:45 PM, ?ukasz Langa wrote:> >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith wrote: >> >> I propose: no governance decisions finalized before October >> 1, 2018. > > +1 but it's okay and expected that discussions here will continue in the interim. Absolutely! Without continuing discussion we'll have nothing to vote on come October! ;-) -- ~Ethan~ From mariatta.wijaya at gmail.com Thu Jul 19 00:14:52 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 18 Jul 2018 21:14:52 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <5B500BA5.5010802@stoneleaf.us> References: <5B500BA5.5010802@stoneleaf.us> Message-ID: +1 On Wed, Jul 18, 2018, 8:54 PM Ethan Furman wrote: > On 07/18/2018 08:45 PM, ?ukasz Langa wrote:> > >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith wrote: > >> > >> I propose: no governance decisions finalized before October > >> 1, 2018. > > > > +1 but it's okay and expected that discussions here will continue in > the interim. > > Absolutely! Without continuing discussion we'll have nothing to vote on > come October! ;-) > > -- > ~Ethan~ > > _______________________________________________ > 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 willingc at gmail.com Thu Jul 19 00:40:08 2018 From: willingc at gmail.com (Carol Willing) Date: Wed, 18 Jul 2018 21:40:08 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> Message-ID: I am in favor of a time limit. Yet, October 1 seems a bit too long for the initial governance decision (i.e. how to decide how to decide). My perspective, based on transitions in non-profits and the corporate world, is that the longer an organization let's it draw out then fear, uncertainty, and doubt creep in. We have PEP 10 in place for a strawperson vote. It seems as good as anything to use to determine how to make a decision. Perhaps set a 30 day deadline to submit decision process recommendations. Then take a strawperson poll on each and at the core sprint create a time window for specific proposals on structure be submitted before October 1. My concern if we leave how to decide until at least Oct 1 that the likelihood of completing this year is fairly low. On Wed, Jul 18, 2018, 9:15 PM Mariatta Wijaya wrote: > +1 > > > On Wed, Jul 18, 2018, 8:54 PM Ethan Furman wrote: > >> On 07/18/2018 08:45 PM, ?ukasz Langa wrote:> >> >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith wrote: >> >> >> >> I propose: no governance decisions finalized before October >> >> 1, 2018. >> > >> > +1 but it's okay and expected that discussions here will continue in >> the interim. >> >> Absolutely! Without continuing discussion we'll have nothing to vote on >> come October! ;-) >> >> -- >> ~Ethan~ >> >> _______________________________________________ >> 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 Jul 19 01:19:24 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 18 Jul 2018 22:19:24 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> Message-ID: <5B501F5C.3090401@stoneleaf.us> On 07/18/2018 09:40 PM, Carol Willing wrote: > I am in favor of a time limit. Yet, October 1 seems a bit too long for the initial governance decision (i.e. how to > decide how to decide). My perspective, based on transitions in non-profits and the corporate world, is that the longer > an organization let's it draw out then fear, uncertainty, and doubt creep in. > > We have PEP 10 in place for a strawperson vote. It seems as good as anything to use to determine how to make a decision. > Perhaps set a 30 day deadline to submit decision process recommendations. Then take a strawperson poll on each and at > the core sprint create a time window for specific proposals on structure be submitted before October 1. > > My concern if we leave how to decide until at least Oct 1 that the likelihood of completing this year is fairly low. My understanding is that, between now and Oct 1, we'll all get our proposals together for both how to decide, and what to decide. Then we have the first vote to decide how to decide, then maybe a week or two later we use that mechanism to decide on a governance model. -- ~Ethan~ From willingc at gmail.com Thu Jul 19 01:32:15 2018 From: willingc at gmail.com (Carol Willing) Date: Wed, 18 Jul 2018 22:32:15 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <5B501F5C.3090401@stoneleaf.us> References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> Message-ID: Thanks Ethan for clarifying. Totally cool if that is the case. On Wed, Jul 18, 2018, 10:19 PM Ethan Furman wrote: > On 07/18/2018 09:40 PM, Carol Willing wrote: > > I am in favor of a time limit. Yet, October 1 seems a bit too long for > the initial governance decision (i.e. how to > > decide how to decide). My perspective, based on transitions in > non-profits and the corporate world, is that the longer > > an organization let's it draw out then fear, uncertainty, and doubt > creep in. > > > > We have PEP 10 in place for a strawperson vote. It seems as good as > anything to use to determine how to make a decision. > > Perhaps set a 30 day deadline to submit decision process > recommendations. Then take a strawperson poll on each and at > > the core sprint create a time window for specific proposals on structure > be submitted before October 1. > > > > My concern if we leave how to decide until at least Oct 1 that the > likelihood of completing this year is fairly low. > > My understanding is that, between now and Oct 1, we'll all get our > proposals together for both how to decide, and what > to decide. Then we have the first vote to decide how to decide, then > maybe a week or two later we use that mechanism to > decide on a governance model. > > -- > ~Ethan~ > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Thu Jul 19 02:05:17 2018 From: steve.dower at python.org (Steve Dower) Date: Wed, 18 Jul 2018 23:05:17 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: I?ll be a little disappointed to not have anything in place by the sprints, as most of my planned work was to get my PEPs accepted, but it seems we have a fairly sizable split within the group between the ~3 proposals so far (NBDFL, Council, delay), so under the circumstances I think it?s most fair to let those in the third group have time to think through. (I haven?t been counting or keeping track of names, but it seems like different people are +1-ing this thread than were doing it on the others.) Consider this a +0. Cheers, Steve Top-posted from my Windows 10 phone From: Nathaniel Smith Sent: Wednesday, 18 July 2018 19:37 To: python-committers Subject: [python-committers] Proposal: an explicit,time-limited moratorium on finalizing any governance decisions [tl;dr: We need some ground rules, because uncertainty makes it hard to think straight. But if we get sucked into a complicated meta-debate about the ground rules then that defeats the purpose. My proposal for a Minimum Viable Ground Rule: let's all agree not to finalize any governance decisions before October 1.] We're in a constitutional crisis, and that's scary. There's no map and none of us know what to expect. It feels like anything could happen. You look at the mailing list and see people making big proposals -- is one of them going to suddenly be adopted? If I look away for a few days, will I come back and find out that something's been decided? What are we even talking about? Do I need to jump into that thread RIGHT NOW? It's scary. People don't do their best work when scared. When we're scared it's harder to listen and build up common ground with others -- but that's exactly what we'll need to do to get through this. And also, like... being scared sucks. I would prefer to be less scared. So: can we do anything to make this less scary? One thing that would help is if we had some ground-rules for how the decision itself will be made. Knowing what to expect makes things less scary. There's another thread going on right now trying to do that (subject "Proposal on how to vote"). But... if you look at that thread, it turns out deciding on how to vote is itself an important decision with lots of subtle issues, where we probably want to give people time to think, brainstorm, critique. Heck, in the end we might decide a vote isn't even the best approach. So I'm not saying we shouldn't be having that discussion, we definitely should, but... it's also giving me a new source of anxiety: that we'll all be so eager to get *some* certainty here that we'll end up trying to force a decision prematurely. Kind of a catch-22: the decision about how to make complex decisions is itself a complex decision, which is what we don't know how to do yet. Is there some way to avoid this loop? Can we come up with some ground rules simple enough that we can agree on them without a big debate? Well, there's one thing I am pretty sure of: this is a big decision, there's a lot to think about and talk about, and that we won't regret taking some time some time to do that. And besides, trying to force it to happen faster will make people more scared and dig in their heels. So here's my proposal for an initial, Minimum Viable Ground Rule: we should set a date and promise that no actual decisions will be finalized before that. Until then we are just talking and brainstorming and gradually converging on points of consensus. (And to be clear, the point of this is to give us breathing room, not set a deadline -- we shouldn't dawdle, but if we get there and it turns out we need more time, then that's OK.) What would be a good date? The core sprint is coming up Sept. 10-14, and this seems to be a likely topic of conversation there. And then after the sprint, those who aren't present will need time to catch up with any discussions that happened at the sprint. So to make things concrete, I propose: no governance decisions finalized before October 1, 2018. Probably this is what will end up happening anyway, but if we make it explicit in advance and tell everyone, then at least we'll all know that it's OK to stop refreshing our email constantly and redirect that energy in more useful directions. What do you all think? -n -- Nathaniel J. Smith -- https://vorpus.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 Jul 19 03:33:25 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 09:33:25 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: <2d496893-c63e-458c-087f-4d516d213644@python.org> Le 19/07/2018 ? 04:36, Nathaniel Smith a ?crit?: > [tl;dr: We need some ground rules, because uncertainty makes it hard > to think straight. But if we get sucked into a complicated meta-debate > about the ground rules then that defeats the purpose. My proposal for > a Minimum Viable Ground Rule: let's all agree not to finalize any > governance decisions before October 1.] +1 from me. Thank you. Regards Antoine. From yselivanov.ml at gmail.com Thu Jul 19 04:09:19 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 19 Jul 2018 11:09:19 +0300 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 5:36 AM Nathaniel Smith wrote: > What would be a good date? The core sprint is coming up Sept. 10-14, > and this seems to be a likely topic of conversation there. And then > after the sprint, those who aren't present will need time to catch up > with any discussions that happened at the sprint. So to make things > concrete, I propose: no governance decisions finalized before October > 1, 2018. > +1. Yury From vstinner at redhat.com Thu Jul 19 04:24:17 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 19 Jul 2018 10:24:17 +0200 Subject: [python-committers] Language moratorium In-Reply-To: <20180718161156.GA5506@bytereef.org> References: <20180718161156.GA5506@bytereef.org> Message-ID: Hi, 2018-07-18 18:11 GMT+02:00 Stefan Krah : > Perhaps we could have one again, say for 12 months so we can figure things > out. Other Python implementations may welcome the moratorium so they can > catch up. Python 3.8 has a new syntax for assignment expressions (PEP 572). A moratorium of 12 months in practice means no other syntax changes for Python 3.8. I strongly prefer to introduce syntax changes early in the development cycle, rather than late, to give time to third party modules to be updated (ex: linters like flake8 or pylint). I am unable to decide if a moratorium is a good idea. For example, I was (strongly) against f-string at the beginning, and wrote that it was possible to write the same thing without f-string. You can say the same for PEP 572 which is "more or less" pure syntax sugar. But Python 3.6 also got a simple change to allow underscore in numbers for readability (PEP 515) and I now really love that feature. On the side, I would like to slow down syntax changes. On the other side, I started to really love latest syntax changes... What about other syntax changes like async and await which became real keywords? IMHO it's also a major enhancement for asyncio, even if they were more or less already keywords :-) When I look back at syntax changes since Python 3.4, it's really hard for me to say that I prefer to stay at Python 3.4 (syntax) forever and never use Python 3.5, 3.6 and 3.7 new syntaxes... When I can use them, I started to strongly prefer f-string over str % args (which now kind of look as "legacy" compared to f-string) or its verbose brother str.format(args). On of the reason which motivated Facebook and Instagram to migrate from Python 2.7 directly to 3.5 was to get the new async and await keywords. So new syntaxes can be the new "killer feature" of a specific Python release, at least for some use cases. Victor From p.f.moore at gmail.com Thu Jul 19 04:43:31 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 19 Jul 2018 09:43:31 +0100 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <2d496893-c63e-458c-087f-4d516d213644@python.org> References: <2d496893-c63e-458c-087f-4d516d213644@python.org> Message-ID: On 19 July 2018 at 08:33, Antoine Pitrou wrote: > > Le 19/07/2018 ? 04:36, Nathaniel Smith a ?crit : >> [tl;dr: We need some ground rules, because uncertainty makes it hard >> to think straight. But if we get sucked into a complicated meta-debate >> about the ground rules then that defeats the purpose. My proposal for >> a Minimum Viable Ground Rule: let's all agree not to finalize any >> governance decisions before October 1.] > > +1 from me. Thank you. +1 from me too. You make very good points (particularly regarding the "fear of something happening while I'm not watching" factor). Paul From mark at hotpy.org Thu Jul 19 05:04:50 2018 From: mark at hotpy.org (Mark Shannon) Date: Thu, 19 Jul 2018 10:04:50 +0100 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: Message-ID: On 19/07/18 03:36, Nathaniel Smith wrote: > [tl;dr: We need some ground rules, because uncertainty makes it hard > to think straight. But if we get sucked into a complicated meta-debate > about the ground rules then that defeats the purpose. My proposal for > a Minimum Viable Ground Rule: let's all agree not to finalize any > governance decisions before October 1.] +1 Cheers, Mark. From larry at hastings.org Thu Jul 19 08:50:46 2018 From: larry at hastings.org (Larry Hastings) Date: Thu, 19 Jul 2018 05:50:46 -0700 Subject: [python-committers] 3.4.9rc1 and 3.5.6rc1 slipping by one day to Thursday July 19 2018 Message-ID: I was working with Serhiy on fixing the documentation for some bytecodes in 3.5 (GH-8338) and time got away from me.? They'll both be out later today, Thursday July 19 2018. *yawn,* //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Jul 19 11:41:36 2018 From: brett at python.org (Brett Cannon) Date: Thu, 19 Jul 2018 08:41:36 -0700 Subject: [python-committers] Language moratorium In-Reply-To: References: <20180718161156.GA5506@bytereef.org> Message-ID: On Thu, Jul 19, 2018, 01:24 Victor Stinner, wrote: > Hi, > > 2018-07-18 18:11 GMT+02:00 Stefan Krah : > > Perhaps we could have one again, say for 12 months so we can figure > things > > out. Other Python implementations may welcome the moratorium so they can > > catch up. > > Python 3.8 has a new syntax for assignment expressions (PEP 572). A > moratorium of 12 months in practice means no other syntax changes for > Python 3.8. I strongly prefer to introduce syntax changes early in the > development cycle, rather than late, to give time to third party > modules to be updated (ex: linters like flake8 or pylint). > > I am unable to decide if a moratorium is a good idea. For example, I > was (strongly) against f-string at the beginning, and wrote that it > was possible to write the same thing without f-string. You can say the > same for PEP 572 which is "more or less" pure syntax sugar. But Python > 3.6 also got a simple change to allow underscore in numbers for > readability (PEP 515) and I now really love that feature. > > On the side, I would like to slow down syntax changes. On the other > side, I started to really love latest syntax changes... > > What about other syntax changes like async and await which became real > keywords? IMHO it's also a major enhancement for asyncio, even if they > were more or less already keywords :-) > > When I look back at syntax changes since Python 3.4, it's really hard > for me to say that I prefer to stay at Python 3.4 (syntax) forever and > never use Python 3.5, 3.6 and 3.7 new syntaxes... When I can use them, > I started to strongly prefer f-string over str % args (which now kind > of look as "legacy" compared to f-string) or its verbose brother > str.format(args). > > On of the reason which motivated Facebook and Instagram to migrate > from Python 2.7 directly to 3.5 was to get the new async and await > keywords. So new syntaxes can be the new "killer feature" of a > specific Python release, at least for some use cases. > Then we would have to solve our governance problem sooner rather than later. But i don't think every Python release has to make a huge splash. -Brett > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Jul 19 11:59:29 2018 From: brett at python.org (Brett Cannon) Date: Thu, 19 Jul 2018 08:59:29 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> Message-ID: On Wed, Jul 18, 2018, 22:32 Carol Willing, wrote: > Thanks Ethan for clarifying. Totally cool if that is the case. > > On Wed, Jul 18, 2018, 10:19 PM Ethan Furman wrote: > >> On 07/18/2018 09:40 PM, Carol Willing wrote: >> > I am in favor of a time limit. Yet, October 1 seems a bit too long for >> the initial governance decision (i.e. how to >> > decide how to decide). My perspective, based on transitions in >> non-profits and the corporate world, is that the longer >> > an organization let's it draw out then fear, uncertainty, and doubt >> creep in. >> > >> > We have PEP 10 in place for a strawperson vote. It seems as good as >> anything to use to determine how to make a decision. >> > Perhaps set a 30 day deadline to submit decision process >> recommendations. Then take a strawperson poll on each and at >> > the core sprint create a time window for specific proposals on >> structure be submitted before October 1. >> > >> > My concern if we leave how to decide until at least Oct 1 that the >> likelihood of completing this year is fairly low. >> >> My understanding is that, between now and Oct 1, we'll all get our >> proposals together for both how to decide, and what >> to decide. Then we have the first vote to decide how to decide, then >> maybe a week or two later we use that mechanism to >> decide on a governance model. >> > I had Carol's same worry that while it's great to have a "no sooner than" date, we also can't let this drag on and we have no "settle by" date, else we risk losing the faith of the community in our ability to come together and make decisions (e.g. if I heard it took a year for a project to resolve this then I would think there was some major divisiveness on the team). So could we go with Nathaniel's idea of no decision before October, but any proposals to be ready by then as well as Ethan suggested? I would also propose we have a goal of at least choosing the governance model by the end of the year (and a stretch goal to even have people placed into created positions by then as well). I have no problem with sooner, but I think it might be good to try to put _some_ upper bound on this. -Brett >> -- >> ~Ethan~ >> >> _______________________________________________ >> 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 mariatta.wijaya at gmail.com Thu Jul 19 13:10:26 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Thu, 19 Jul 2018 10:10:26 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> Message-ID: On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon wrote: > > I had Carol's same worry that while it's great to have a "no sooner than" > date, we also can't let this drag on and we have no "settle by" date, else > we risk losing the faith of the community in our ability to come together > and make decisions (e.g. if I heard it took a year for a project to resolve > this then I would think there was some major divisiveness on the team). > > So could we go with Nathaniel's idea of no decision before October, but > any proposals to be ready by then as well as Ethan suggested? > > I would also propose we have a goal of at least choosing the governance > model by the end of the year (and a stretch goal to even have people placed > into created positions by then as well). I have no problem with sooner, but > I think it might be good to try to put _some_ upper bound on this. > > -Brett > > Sounds good. So what about the following timelines: Oct 1: Deadline for people to come up with proposals of governance model, candidates, and how to vote Dec 1: Deadline to choose a governance model, (and if possible, we choose the new leader(s) too) Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Thu Jul 19 13:19:23 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 19 Jul 2018 13:19:23 -0400 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> Message-ID: <4f26cd3d-edaa-f5c2-d503-9c6af6746ab1@udel.edu> On 7/19/2018 1:10 PM, Mariatta Wijaya wrote: > > > On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > wrote: > > > I had Carol's same worry that while it's great to have a "no sooner > than" date, we also can't let this drag on and we have no "settle > by" date, else we risk losing the faith of the community in our > ability to come together and make decisions (e.g. if I heard it took > a year for a project to resolve this then I would think there was > some major divisiveness on the team). > > So could we go with Nathaniel's idea of no decision before October, > but any proposals to be ready by then as well as Ethan suggested? > > I would also propose we have a goal of at least choosing the > governance model by the end of the year (and a stretch goal to even > have people placed into created positions by then as well). I have > no problem with sooner, but I think it might be good to try to put > _some_ upper bound on this. > > -Brett > > > Sounds good. > So what about the following timelines: > Oct 1: Deadline for people to come up with proposals of governance > model, candidates, and how to vote > Dec 1: Deadline to choose a governance model, (and if possible, we > choose the new leader(s) too) Why not Nov 1, leaving a month to decide on proposals? > Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1. From willingc at gmail.com Thu Jul 19 13:26:24 2018 From: willingc at gmail.com (Carol Willing) Date: Thu, 19 Jul 2018 10:26:24 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> Message-ID: Would it be possible to have all proposals: - How to determine the governance structure (PEP 10 or other approval process) - The suggested governance structure submitted by AOE August 31, 2018? That would give everyone 40ish days to get their proposals in for either topic. That would give everyone a full 30 day review period before the emerging October 1 decision moratorium. Perhaps we can post the timeline as an informational PEP by the end of July. Suggested timeline: July 31 AOE - Informational PEP on this timeline or emails to python-committers, python-dev as a less formal notification of timeline August 31 AOE - Submissions due for proposals on governance decision making and governance structure. Proposals should be posted as PRs on either the PEP repo or a TBD repo. Sept 1 - 30 Review period for all submissions by committers and community. Oct 1 - Earliest possible decision on any proposals (perhaps a strawperson poll begins on Oct 1 and ends by Oct 7, if needed re: PEP 10, on all decision making proposals. Oct 15 - 21 Strawperson poll on all governance structures, if needed. Nov 15 - Target date for formalizing names to roles I'm happy to write up the Information PEP for the timeline or draft an email message. In addition, I am happy to assist in editing any proposals that folks wish to submit. > On Jul 19, 2018, at 8:59 AM, Brett Cannon > wrote: > > > > On Wed, Jul 18, 2018, 22:32 Carol Willing, > wrote: > Thanks Ethan for clarifying. Totally cool if that is the case. > > On Wed, Jul 18, 2018, 10:19 PM Ethan Furman > wrote: > On 07/18/2018 09:40 PM, Carol Willing wrote: > > I am in favor of a time limit. Yet, October 1 seems a bit too long for the initial governance decision (i.e. how to > > decide how to decide). My perspective, based on transitions in non-profits and the corporate world, is that the longer > > an organization let's it draw out then fear, uncertainty, and doubt creep in. > > > > We have PEP 10 in place for a strawperson vote. It seems as good as anything to use to determine how to make a decision. > > Perhaps set a 30 day deadline to submit decision process recommendations. Then take a strawperson poll on each and at > > the core sprint create a time window for specific proposals on structure be submitted before October 1. > > > > My concern if we leave how to decide until at least Oct 1 that the likelihood of completing this year is fairly low. > > My understanding is that, between now and Oct 1, we'll all get our proposals together for both how to decide, and what > to decide. Then we have the first vote to decide how to decide, then maybe a week or two later we use that mechanism to > decide on a governance model. > > I had Carol's same worry that while it's great to have a "no sooner than" date, we also can't let this drag on and we have no "settle by" date, else we risk losing the faith of the community in our ability to come together and make decisions (e.g. if I heard it took a year for a project to resolve this then I would think there was some major divisiveness on the team). > > So could we go with Nathaniel's idea of no decision before October, but any proposals to be ready by then as well as Ethan suggested? > > I would also propose we have a goal of at least choosing the governance model by the end of the year (and a stretch goal to even have people placed into created positions by then as well). I have no problem with sooner, but I think it might be good to try to put _some_ upper bound on this. > > -Brett > > > > -- > ~Ethan~ > > _______________________________________________ > 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 Jul 19 13:36:36 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 19:36:36 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> Message-ID: <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> Le 19/07/2018 ? 19:26, Carol Willing a ?crit?: > Would it be possible to have all proposals: > > - How to determine the governance structure (PEP 10 or other approval > process) > - The suggested governance structure > > submitted by AOE August 31, 2018? > > That would give everyone 40ish days to get their proposals in for either > topic. Much too short IMHO. We are all volunteers, plus July-August is often an extended leave (holiday) period in European countries (not for me, but I imagine for other people perhaps). This is a serious decision to take, I don't think we gain anything in hasting things. Plus we are talking about a situation that seems to have taken everyone by surprise, given what I can read of the various e-mails. Let's let people think and elaborate at a calm pace. Regards Antoine. From barry at python.org Thu Jul 19 13:53:00 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 19 Jul 2018 10:53:00 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <4f26cd3d-edaa-f5c2-d503-9c6af6746ab1@udel.edu> References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <4f26cd3d-edaa-f5c2-d503-9c6af6746ab1@udel.edu> Message-ID: On Jul 19, 2018, at 10:19, Terry Reedy wrote: > > On 7/19/2018 1:10 PM, Mariatta Wijaya wrote: >> On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > wrote: >> So what about the following timelines: >> Oct 1: Deadline for people to come up with proposals of governance model, candidates, and how to vote >> Dec 1: Deadline to choose a governance model, (and if possible, we choose the new leader(s) too) > > Why not Nov 1, leaving a month to decide on proposals? > >> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1. I like the Nov 1 schedule. I?m +1 with giving plenty of time to process, but I share the concern about letting things drag on too long. IMHO, ideally we?d have the new governance structure and its office holders in place by EOY18. That has to account for various holidays, including Thanksgiving in the US and Christmas to New Years. 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 willingc at gmail.com Thu Jul 19 14:00:23 2018 From: willingc at gmail.com (Carol Willing) Date: Thu, 19 Jul 2018 11:00:23 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> Message-ID: I appreciate and respect the importance of these decisions. The dates that I suggested, and I am not anchored to any of them, were not selected to rush or be hasty. Instead, it was respect for our time together (at least some of us) at the September sprint and to have all proposals on the table by that time. You make a good point about European holidays. I am not opposed to delaying a couple of weeks (due date for proposals by the September sprint start). My biggest concern is that dragging this on into the new year will result in more bikeshedding, more uncertainty, and less confidence in the developer community decision making ability. Hoping we can compromise on a happy medium on a timeline. On Thu, Jul 19, 2018, 10:36 AM Antoine Pitrou wrote: > > Le 19/07/2018 ? 19:26, Carol Willing a ?crit : > > Would it be possible to have all proposals: > > > > - How to determine the governance structure (PEP 10 or other approval > > process) > > - The suggested governance structure > > > > submitted by AOE August 31, 2018? > > > > That would give everyone 40ish days to get their proposals in for either > > topic. > > Much too short IMHO. We are all volunteers, plus July-August is often > an extended leave (holiday) period in European countries (not for me, > but I imagine for other people perhaps). > > This is a serious decision to take, I don't think we gain anything in > hasting things. Plus we are talking about a situation that seems to > have taken everyone by surprise, given what I can read of the various > e-mails. > > Let's let people think and elaborate at a calm pace. > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Jul 19 14:03:51 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 19 Jul 2018 11:03:51 -0700 Subject: [python-committers] Language moratorium In-Reply-To: References: <20180718161156.GA5506@bytereef.org> Message-ID: <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org> On Jul 19, 2018, at 08:41, Brett Cannon wrote: > > Then we would have to solve our governance problem sooner rather than later. But i don't think every Python release has to make a huge splash. The other option of course is to push the release date of Python 3.8 back to accommodate the new governance structure. > On Jul 18, 2018, at 19:23, Tim Peters wrote: > Unsure! Governance is needed to resolve conflict. When there's broad agreement, "leaders" aren't really needed. For example, there's been a bit of talk on python-ideas about adding a new `intmath` module capturing some frequently reinvented functions for which decent implementations are known but non-obvious (e.g., for generating the primes). Nobody could sanely fight to death against something like that. Even whining about it would appear petty ;-) I don?t necessarily include new modules, other stdlib changes, build or performance improvements, and other such ?normal development? work (i.e. bug fixing) to be affected by a language moratorium. PEP 572-level decisions would very definitely fall under that rubric. We have plenty of experts still in place that can make more minor decisions. In fact, perhaps we should largely operate as if our BDFL were just on a long vacation and not pronouncing on PEPs. That?s never frozen Python development before, and shouldn?t now. If PEP 572 were the only new syntax for 3.8, then so be it. 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 antoine at python.org Thu Jul 19 14:07:41 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 20:07:41 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> Message-ID: Le 19/07/2018 ? 20:00, Carol Willing a ?crit?: > I appreciate and respect the importance of these decisions. The dates > that I suggested, and I am not anchored to any of them, were not > selected to rush or be hasty. Instead, it was respect for our time > together (at least some of us) at the September sprint and to have all > proposals on the table by that time. I hadn't thought about the September sprint. I'd say it's up to people to discuss those things there if they want or not (I would prefer if we could avoid discussions in select groups like that, but I don't think there's any reasonable way to prevent it). > My biggest concern is that dragging this on into the new year will > result in more bikeshedding, more uncertainty, and less confidence in > the developer community decision making ability. That's a fair point. But there's also an opposite concern that discussions may be deterred or cut short by a too tight deadline. Even simple and uncontentious PEPs take time to write, discuss and finalize. Regards Antoine. > > Hoping we can compromise on a happy medium on a timeline. > > > > > On Thu, Jul 19, 2018, 10:36 AM Antoine Pitrou > wrote: > > > Le 19/07/2018 ? 19:26, Carol Willing a ?crit?: > > Would it be possible to have all proposals: > > > > - How to determine the governance structure (PEP 10 or other approval > > process) > > - The suggested governance structure > > > > submitted by AOE August 31, 2018? > > > > That would give everyone 40ish days to get their proposals in for > either > > topic. > > Much too short IMHO.? We are all volunteers, plus July-August is often > an extended leave (holiday) period in European countries (not for me, > but I imagine for other people perhaps). > > This is a serious decision to take, I don't think we gain anything in > hasting things.? Plus we are talking about a situation that seems to > have taken everyone by surprise, given what I can read of the various > e-mails. > > Let's let people think and elaborate at a calm pace. > > 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 antoine at python.org Thu Jul 19 14:09:05 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 20:09:05 +0200 Subject: [python-committers] Language moratorium In-Reply-To: <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org> References: <20180718161156.GA5506@bytereef.org> <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org> Message-ID: <399dbd04-3deb-9c23-b262-47d304613d2e@python.org> Le 19/07/2018 ? 20:03, Barry Warsaw a ?crit?: > > If PEP 572 were the only new syntax for 3.8, then so be it. +1. Which means that: > The other option of course is to push the release date of Python 3.8 > back to accommodate the new governance structure. is basically unnecessary ;-) Regards Antoine. From barry at python.org Thu Jul 19 14:41:32 2018 From: barry at python.org (Barry Warsaw) Date: Thu, 19 Jul 2018 11:41:32 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org> <5B4F0D2E.80702@stoneleaf.us> <5B4F63BE.6090300@stoneleaf.us> <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl> <5B4F70D3.6050301@stoneleaf.us> <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl> Message-ID: On Jul 18, 2018, at 17:31, Alex Martelli via python-committers wrote: > Humans do so love to argue! > > No we don't! (cfr http://www.montypython.net/scripts/argument.php)... I guess that means we do love getting hit on the head? -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 doug at doughellmann.com Thu Jul 19 14:52:11 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 19 Jul 2018 14:52:11 -0400 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> Message-ID: <1532026123-sup-9946@lrrr.local> Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200: > > Le 19/07/2018 ? 20:00, Carol Willing a ?crit?: > > I appreciate and respect the importance of these decisions. The dates > > that I suggested, and I am not anchored to any of them, were not > > selected to rush or be hasty. Instead, it was respect for our time > > together (at least some of us) at the September sprint and to have all > > proposals on the table by that time. > > I hadn't thought about the September sprint. I'd say it's up to people > to discuss those things there if they want or not (I would prefer if we > could avoid discussions in select groups like that, but I don't think > there's any reasonable way to prevent it). The best way to mitigate it is to agree that select groups who happen to be able to meet in person won't make any final decisions, and that any discussions they have that start to trend toward agreement will be summarized to the mailing list so that the folks not able to be present can benefit from and participate in the discussion. > > My biggest concern is that dragging this on into the new year will > > result in more bikeshedding, more uncertainty, and less confidence in > > the developer community decision making ability. > > That's a fair point. But there's also an opposite concern that > discussions may be deterred or cut short by a too tight deadline. Even > simple and uncontentious PEPs take time to write, discuss and finalize. Maybe it would be better to focus on a first date for submitting proposals and then wait to set the rest of the deadlines until after we have a bit more of the discussion behind us. That will give us a sense for how much consensus there is and how much more discussion might be needed. Doug From willingc at gmail.com Thu Jul 19 15:35:13 2018 From: willingc at gmail.com (Carol Willing) Date: Thu, 19 Jul 2018 12:35:13 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <1532026123-sup-9946@lrrr.local> References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> Message-ID: > On Jul 19, 2018, at 11:52 AM, Doug Hellmann wrote: > > Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200: >> >> Le 19/07/2018 ? 20:00, Carol Willing a ?crit : >>> I appreciate and respect the importance of these decisions. The dates >>> that I suggested, and I am not anchored to any of them, were not >>> selected to rush or be hasty. Instead, it was respect for our time >>> together (at least some of us) at the September sprint and to have all >>> proposals on the table by that time. >> >> I hadn't thought about the September sprint. I'd say it's up to people >> to discuss those things there if they want or not (I would prefer if we >> could avoid discussions in select groups like that, but I don't think >> there's any reasonable way to prevent it). > > The best way to mitigate it is to agree that select groups who happen to > be able to meet in person won't make any final decisions, and that any > discussions they have that start to trend toward agreement will be > summarized to the mailing list so that the folks not able to be present > can benefit from and participate in the discussion. Excellent suggestion. Reporting to the mailing list, python-committers and python-dev, would be the courteous and productive thing to do. > >>> My biggest concern is that dragging this on into the new year will >>> result in more bikeshedding, more uncertainty, and less confidence in >>> the developer community decision making ability. >> >> That's a fair point. But there's also an opposite concern that >> discussions may be deterred or cut short by a too tight deadline. Even >> simple and uncontentious PEPs take time to write, discuss and finalize. > > Maybe it would be better to focus on a first date for submitting > proposals and then wait to set the rest of the deadlines until after > we have a bit more of the discussion behind us. That will give us > a sense for how much consensus there is and how much more discussion > might be needed. This suggestion seems to balance well the different perspectives. Proposals due by Sept 9, 2018 AOE. No formal decisions prior to October 1, 2018. > > Doug > _______________________________________________ > 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 Thu Jul 19 15:43:46 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 19 Jul 2018 21:43:46 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> Message-ID: <53e93add-972b-2fe4-877d-e15552a86993@python.org> Le 19/07/2018 ? 21:35, Carol Willing a ?crit?: >> >>>> My biggest concern is that dragging this on into the new year will >>>> result in more bikeshedding, more uncertainty, and less confidence in >>>> the developer community decision making ability. >>> >>> That's a fair point. But there's also an opposite concern that >>> discussions may be deterred or cut short by a too tight deadline. Even >>> simple and uncontentious PEPs take time to write, discuss and finalize. >> >> Maybe it would be better to focus on a first date for submitting >> proposals and then wait to set the rest of the deadlines until after >> we have a bit more of the discussion behind us. That will give us >> a sense for how much consensus there is and how much more discussion >> might be needed. > > This suggestion seems to balance well the different perspectives. > > Proposals due by Sept 9, 2018 AOE. I still think it's too short. Imagine someone leaving in August. Besides catching up with work, the beginning of a new school year (if they have kids) and other things, they have only 9 days to contribute usefully. This is not something we can mobilize for to try and compress the time span as much possible. Regards Antoine. From brett at python.org Thu Jul 19 15:44:23 2018 From: brett at python.org (Brett Cannon) Date: Thu, 19 Jul 2018 12:44:23 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <1532026123-sup-9946@lrrr.local> References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> Message-ID: On Thu, 19 Jul 2018 at 11:52 Doug Hellmann wrote: > Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200: > > > > Le 19/07/2018 ? 20:00, Carol Willing a ?crit : > > > I appreciate and respect the importance of these decisions. The dates > > > that I suggested, and I am not anchored to any of them, were not > > > selected to rush or be hasty. Instead, it was respect for our time > > > together (at least some of us) at the September sprint and to have all > > > proposals on the table by that time. > > > > I hadn't thought about the September sprint. I'd say it's up to people > > to discuss those things there if they want or not (I would prefer if we > > could avoid discussions in select groups like that, but I don't think > > there's any reasonable way to prevent it). > > The best way to mitigate it is to agree that select groups who happen to > be able to meet in person won't make any final decisions, and that any > discussions they have that start to trend toward agreement will be > summarized to the mailing list so that the folks not able to be present > can benefit from and participate in the discussion. > We already do that for the language summit and I don't think any consensus reached at the dev sprints would be any different. My gut says that if we haven't reached a consensus on how to handle voting by the dev sprints then we will try to reach one there to bring back to the list to see if team-wide consensus also exists for the voting proposal. > > > > My biggest concern is that dragging this on into the new year will > > > result in more bikeshedding, more uncertainty, and less confidence in > > > the developer community decision making ability. > > > > That's a fair point. But there's also an opposite concern that > > discussions may be deterred or cut short by a too tight deadline. Even > > simple and uncontentious PEPs take time to write, discuss and finalize. > > Maybe it would be better to focus on a first date for submitting > proposals and then wait to set the rest of the deadlines until after > we have a bit more of the discussion behind us. That will give us > a sense for how much consensus there is and how much more discussion > might be needed. > But the amount of discussion can be unbounded (considering people write PhD theses on governance models and voting systems we could talk about this stuff forever ;), so putting a schedule in place to help focus the discussions can be beneficial. I'm +1 on Mariatta's schedule. That gives people more than 2 months to come up with governance proposals and all of us to settle on how we will vote. And if we say the month of November will be when voting is open then that would give people more then 3 months notice of when the first vote will occur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Jul 19 15:48:24 2018 From: brett at python.org (Brett Cannon) Date: Thu, 19 Jul 2018 12:48:24 -0700 Subject: [python-committers] Language moratorium In-Reply-To: <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org> References: <20180718161156.GA5506@bytereef.org> <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org> Message-ID: On Thu, 19 Jul 2018 at 11:04 Barry Warsaw wrote: > On Jul 19, 2018, at 08:41, Brett Cannon wrote: > > > > Then we would have to solve our governance problem sooner rather than > later. But i don't think every Python release has to make a huge splash. > > The other option of course is to push the release date of Python 3.8 back > to accommodate the new governance structure. > > > On Jul 18, 2018, at 19:23, Tim Peters wrote: > > > Unsure! Governance is needed to resolve conflict. When there's broad > agreement, "leaders" aren't really needed. For example, there's been a bit > of talk on python-ideas about adding a new `intmath` module capturing some > frequently reinvented functions for which decent implementations are known > but non-obvious (e.g., for generating the primes). Nobody could sanely > fight to death against something like that. Even whining about it would > appear petty ;-) > > > I don?t necessarily include new modules, other stdlib changes, build or > performance improvements, and other such ?normal development? work (i.e. > bug fixing) to be affected by a language moratorium. PEP 572-level > decisions would very definitely fall under that rubric. > > We have plenty of experts still in place that can make more minor > decisions. In fact, perhaps we should largely operate as if our BDFL were > just on a long vacation and not pronouncing on PEPs. That?s never frozen > Python development before, and shouldn?t now. > > If PEP 572 were the only new syntax for 3.8, then so be it. > That last time we had a language moratorium we allowed new stdlib modules ( https://www.python.org/dev/peps/pep-3003/). -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Thu Jul 19 16:29:34 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 19 Jul 2018 16:29:34 -0400 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> Message-ID: <1532032042-sup-4374@lrrr.local> Excerpts from Brett Cannon's message of 2018-07-19 12:44:23 -0700: > On Thu, 19 Jul 2018 at 11:52 Doug Hellmann wrote: > > > Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200: > > > > > > Le 19/07/2018 ? 20:00, Carol Willing a ?crit : > > > > I appreciate and respect the importance of these decisions. The dates > > > > that I suggested, and I am not anchored to any of them, were not > > > > selected to rush or be hasty. Instead, it was respect for our time > > > > together (at least some of us) at the September sprint and to have all > > > > proposals on the table by that time. > > > > > > I hadn't thought about the September sprint. I'd say it's up to people > > > to discuss those things there if they want or not (I would prefer if we > > > could avoid discussions in select groups like that, but I don't think > > > there's any reasonable way to prevent it). > > > > The best way to mitigate it is to agree that select groups who happen to > > be able to meet in person won't make any final decisions, and that any > > discussions they have that start to trend toward agreement will be > > summarized to the mailing list so that the folks not able to be present > > can benefit from and participate in the discussion. > > > > We already do that for the language summit and I don't think any consensus > reached at the dev sprints would be any different. My gut says that if we > haven't reached a consensus on how to handle voting by the dev sprints then > we will try to reach one there to bring back to the list to see if > team-wide consensus also exists for the voting proposal. That plan makes sense to me. > > > > My biggest concern is that dragging this on into the new year will > > > > result in more bikeshedding, more uncertainty, and less confidence in > > > > the developer community decision making ability. > > > > > > That's a fair point. But there's also an opposite concern that > > > discussions may be deterred or cut short by a too tight deadline. Even > > > simple and uncontentious PEPs take time to write, discuss and finalize. > > > > Maybe it would be better to focus on a first date for submitting > > proposals and then wait to set the rest of the deadlines until after > > we have a bit more of the discussion behind us. That will give us > > a sense for how much consensus there is and how much more discussion > > might be needed. > > > > But the amount of discussion can be unbounded (considering people write PhD > theses on governance models and voting systems we could talk about this > stuff forever ;), so putting a schedule in place to help focus the > discussions can be beneficial. Sure. I'm just suggesting not rushing to decide what that schedule should be. Maybe by the time all of the proposals are formally written up there will be a high enough level of consensus that it will be possible to move to a decision sooner than we expect right now. Either way, I do think having a schedule will give folks enough space and time to consider the options carefully. > I'm +1 on Mariatta's schedule. That gives people more than 2 months to come > up with governance proposals and all of us to settle on how we will vote. > And if we say the month of November will be when voting is open then that > would give people more then 3 months notice of when the first vote will > occur. From stefan at bytereef.org Thu Jul 19 16:40:19 2018 From: stefan at bytereef.org (Stefan Krah) Date: Thu, 19 Jul 2018 22:40:19 +0200 Subject: [python-committers] Language moratorium In-Reply-To: References: <20180718161156.GA5506@bytereef.org> Message-ID: <20180719204019.GA23495@bytereef.org> On Thu, Jul 19, 2018 at 10:24:17AM +0200, Victor Stinner wrote: > On of the reason which motivated Facebook and Instagram to migrate > from Python 2.7 directly to 3.5 was to get the new async and await > keywords. So new syntaxes can be the new "killer feature" of a > specific Python release, at least for some use cases. This is definitely true. But Python is very strong now, much stronger than during the last moratorium. So in general I think making a decision for a 12 months moratorium should not be viewed by the community as a weak "policy of not having a policy", but as a signal of strength. Suppose people take long vacations, take a distance to the whole PEP 572 situation, perhaps reevaluate; there is always the possibility of overlooking a very simple solution that becomes apparent after a while. Stefan Krah From p.f.moore at gmail.com Thu Jul 19 17:50:30 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 19 Jul 2018 22:50:30 +0100 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> Message-ID: On 19 July 2018 at 20:44, Brett Cannon wrote: > But the amount of discussion can be unbounded (considering people write PhD > theses on governance models and voting systems we could talk about this > stuff forever ;), so putting a schedule in place to help focus the > discussions can be beneficial. > > I'm +1 on Mariatta's schedule. That gives people more than 2 months to come > up with governance proposals and all of us to settle on how we will vote. > And if we say the month of November will be when voting is open then that > would give people more then 3 months notice of when the first vote will > occur. As long as we understand that the deadline is intended to help focus discussion, and not to pressure a premature or rushed decision, I think Maraiatta's schedule is fine. If, coming up to that date, people feel the need for more discussion/review, it should be easy to extend the timescale. I'd like to think no-one is going to demand an extension simply to delay the process, and conversely I assume that if someone *does* ask for an extension, that request would be treated with respect and consideration. So while I think a concrete timescale will help focus the discussion, I don't think it should be viewed as set in stone (otherwise we'll just have yet another debate on what precise dates we should choose!) Paul From vstinner at redhat.com Thu Jul 19 17:58:59 2018 From: vstinner at redhat.com (Victor Stinner) Date: Thu, 19 Jul 2018 23:58:59 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: <53e93add-972b-2fe4-877d-e15552a86993@python.org> References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: Please extend the deadline: next week, I will be at EuroPython (I don't think that I will have time to sit down and come up with something), and I'm (more or less) in holiday the whole month of August. Victor 2018-07-19 21:43 GMT+02:00 Antoine Pitrou : > > Le 19/07/2018 ? 21:35, Carol Willing a ?crit : >>> >>>>> My biggest concern is that dragging this on into the new year will >>>>> result in more bikeshedding, more uncertainty, and less confidence in >>>>> the developer community decision making ability. >>>> >>>> That's a fair point. But there's also an opposite concern that >>>> discussions may be deterred or cut short by a too tight deadline. Even >>>> simple and uncontentious PEPs take time to write, discuss and finalize. >>> >>> Maybe it would be better to focus on a first date for submitting >>> proposals and then wait to set the rest of the deadlines until after >>> we have a bit more of the discussion behind us. That will give us >>> a sense for how much consensus there is and how much more discussion >>> might be needed. >> >> This suggestion seems to balance well the different perspectives. >> >> Proposals due by Sept 9, 2018 AOE. > > I still think it's too short. Imagine someone leaving in August. > Besides catching up with work, the beginning of a new school year (if > they have kids) and other things, they have only 9 days to contribute > usefully. > > This is not something we can mobilize for to try and compress the time > span as much possible. > > 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 vstinner at redhat.com Thu Jul 19 19:47:00 2018 From: vstinner at redhat.com (Victor Stinner) Date: Fri, 20 Jul 2018 01:47:00 +0200 Subject: [python-committers] And Now for Something Completely Different Message-ID: or: Replace Dictatorship with Democracy. Hi, == Introduction: unjustified fears? == I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of these BD(FL) and/or council: what they are expected to do, what they cannot do, etc. It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python. Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python? In my experience, a consensus has been reached in less than one month on most PEPs without the help of the BDFL. There were a few controversal PEPs. The most controversial PEP is obviously the latest accepted PEP, the PEP 572 (assignment expressions). OK. But do you have other examples? In a different thread,I gave the example of my PEP 446 "Make newly created file descriptors non-inheritable": Guido approved it, even though Charles-Fran?ois Natali was against it (since it broke the backward compatibility). If I recall correctly, the issue with that PEP is that almost nobody cared about it: it was mostly Charles-Fran?ois and Guido :-) Hopefully, such cases are rare. == What is the image send to the community and contributors? == Last year, I mentored multiple contributors. What I learnt is that contributing to Python is much harder than what I expected. Most core developers are core for 5 years or longer (maybe 10 years for some of them?), and we (core developers) forgot how hard it is to contribute. When your name is known in a community: it's very easy to share your ideas, other people listen to you and respect your experience. It's much faster to get a pull request merged... sometimes simply because you merged your own PR :-) Becoming a core developer takes between 6 months and 2 years, it requires a lot of commitment, to have free time, etc. In short, it's *very hard* to recruit new core developers. It seems like many people forgot that. What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them? I'm not saying that a new governance will lead to such issues. I'm only opening the question of the image sent to the community. == Democracy: vote on PEPs open to all core developers == I would like to come back to my idea of using a vote restricted to core developers: a PEP would require "50% +1" (at least 50% of votes + 1 voter) to be approved. Maybe some more sensitive PEPs would require a bigger majority, like 66%+1, for example PEPs changing the Python language. The vote would only be opened once we (core devs) consider that the PEP is ready for a vote. Drawbacks. The main risk is that PEPs would fail to be approved if no consensus can be found. In practice, it means that Python remains unchanged. Honestly, I don't think that this consequence is a disaster: sometimes, doing nothing *is* a wise choice :-) The PEP author is free to retry in 6 or 12 months with a new PEP, maybe written differently, maybe with better examples. For example, if everybody agreed to reject the first version of the PEP 572, I expect a more positive result on the latest flavor of the PEP. The issue is sometimes the PEP itself, not the proposed change. Guido forced me to rewrite my very long PEP 540 "UTF-8 Mode" from scratch to make it shorter (and simpler), and it was a major enhancement for my PEP :-) OK, but sometimes everyone like the proposed change, but just not the PEP itself. What can be done? Well, the PEP can be modified. Another different PEP can be proposed. In the worst case, it's a dead end. Again, IMHO it's fine to done nothing. Moreover, I would like to insist that in last years, I don't think that such case occurred frequently. To be honest, I fail to find any example... Advantages. We saw drawbacks. What are advantages of a democracy where every core developer vote counts? First, the BDFL is no longer a bottleneck. Last years, Guido became less available, some PEPs took a lot of time to be approved, I'm thinking about PEP 525 and PEP 530. Moreover, core developers can take holiday. You are allowed to take care of friends, family, and just have a break. It's fine. There are other people who will take care of Python for you. The decision becomes taken by "the community" (core developers in practice) rather than an individual. Negative comments should no longer target an individual but the collective decision. Being a public person is not easy, it seems like Guido resigns partially because of that pressure. I know that Brett Cannon also suffered of negativity of some haters of the Internet. I also had a depression recently caused partially by Python. Working on an open source and public project causes specific issues. == Annex For Council Lovers == We already have a concept of *councils*. When I have a question on importlib, I will first ask Brett Cannon. If he is not available, I would ask Nick Coghlan and Barry Warsaw. When I have a question on C internals, I will ask Serhiy Storchaka and INADA Naoki. We even have a written list of "experts" (or "maintainers"): https://devguide.python.org/experts/ Note: this list is filled by core developers who add themselves :-) These experts are known references in their domain, and it's common that Guido delegates his BDFL role on PEPs. For example, INADA Naoki is the delegate of two Unicode PEPs: Nick's PEP 538 "C locale coercion" and my PEP 540 "UTF-8 Mode". If Naoki would reject my PEP, I would be fine with that: I trust and respect his judgment. == Summary == It is already very hard to become a core developer: a contributor only becomes a core dev once other core developers trust them. I propose to trust core developers judgment and let them all decide if a PEP should be accepted (or rejected). Common PEPs would require "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python language) would require 66%+1 majority (2/3). Known experts will help to lead the discussion and to refine the PEP. Core developers will decide when they consider that a PEP is mature enough for a vote. If a PEP is rejected by a vote, the author is free to make a new attempt 6 to 12 months later with a new PEP, maybe with a new stronger rationale and better examples. Or a competitor PEP can be proposed by a different author. I expect that the common case will be that the author will not attempt a new similar PEP since the vote result will be explicit enough. Rejecting a PEP doesn't mean a failure for Python: sometimes, doing nothing is the wisest choice :-) Victor From ethan at stoneleaf.us Thu Jul 19 20:51:46 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 19 Jul 2018 17:51:46 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: <5B513222.8020303@stoneleaf.us> On 07/19/2018 04:47 PM, Victor Stinner wrote: > or: Replace Dictatorship with Democracy. > > Hi, > > == Introduction: unjustified fears? == > > I see that many people are eager to replace the old governance based > on a single BDFL with a new governance with a new BD(FL) and/or a > council. My problem is that I don't see any clear definition of the > roles of these BD(FL) and/or council: what they are expected to do, > what they cannot do, etc. I imagine that will be made clear in that proposed PEP. > It seems that the main question for a new governance is how to take a > decision on PEPs (accept or reject them with some variants like > Deferred). I read that core developers are unable to make a decision > themselves (fail to reach a consensus) and that letting core > developers decide would make Python "inconsistent" (as if only a > single BDFL is able to keep Python consistent). I also read that the > BDFL is required to make unpopular decisions to enhance Python. This is, unfortunately, true -- with 100+ core-devs (give or take a few) that's basically 100+ different visions of Python, and on any particular issue the majority will be made up of different core-devs, therefore different visions will be approving/rejecting the PEPs, and internal consistency becomes impossible. > Can someone please explain me the rationale behind these fears? Do you > have examples? Maybe examples outside Python? Examples inside Python are good enough: - PEP 435 (Enum) [accepted] lots of minor decisions from BDFL about this or that choice, and still there were about 1,000 emails over several threads - PEP 461 (%-formatting for bytes and byte arrays) [accepted] IIRC there was lots of push-back on adding this to bytes and byte arrays - PEP 463 (exception-catching expressions) [rejected] lots of discussion here, not sure if it would have been accepted by majority vote - PEP 572 (assignment expressions) [accepted] 'nough said > In my experience, a consensus has been reached in less than one month > on most PEPs without the help of the BDFL. There were a few > controversal PEPs. The most controversial PEP is obviously the latest > accepted PEP, the PEP 572 (assignment expressions). OK. But do you > have other examples? See above. > I propose to trust core developers judgment and let them all decide if > a PEP should be accepted (or rejected). Common PEPs would require > "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python > language) would require 66%+1 majority (2/3). > > Known experts will help to lead the discussion and to refine the PEP. > Core developers will decide when they consider that a PEP is mature > enough for a vote. My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely not something easily done by 100+ voters. My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP. My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium. -- ~Ethan~ From larry at hastings.org Thu Jul 19 22:21:06 2018 From: larry at hastings.org (Larry Hastings) Date: Thu, 19 Jul 2018 19:21:06 -0700 Subject: [python-committers] [RELEASED] Python 3.4.9rc1 and Python 3.5.6rc1 are now available Message-ID: <3cd1fce0-6ce1-1812-d3b5-629d618b4315@hastings.org> On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.9rc1 and Python 3.5.6rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode.? Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.9rc1 here: https://www.python.org/downloads/release/python-349rc1/ And you can find Python 3.5.6rc1 here: https://www.python.org/downloads/release/python-356rc1/ Python's entrenched bureaucracy soldiers on, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Fri Jul 20 03:49:01 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 20 Jul 2018 09:49:01 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: <5B513222.8020303@stoneleaf.us> References: <5B513222.8020303@stoneleaf.us> Message-ID: Le 20/07/2018 ? 02:51, Ethan Furman a ?crit?: > My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, > "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely > not something easily done by 100+ voters. > > My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no > experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP. > > My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting > citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium. This is true. But it's a problem for the BDFL even more. Our ex-BDFL resigned because of pressure and exhaustion. Why would another BDFL fare better? Victor pointed out something I didn't know: that several prominent core devs (him, Brett Cannon) recently suffered from breakdown/burnout/depression. I find the PEP-delegate to be a powerful concept. Why wouldn't *every* PEP have a PEP-delegate? This way we don't need a BDFL anymore. We can discuss how to nominate PEP-delegates (Nick had an interesting proposal). Regards Antoine. From antoine at python.org Fri Jul 20 03:59:39 2018 From: antoine at python.org (Antoine Pitrou) Date: Fri, 20 Jul 2018 09:59:39 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: Le 20/07/2018 ? 01:47, Victor Stinner a ?crit?: > > What is the image sent to contributors if we create a subgroup inside > core developpers called "council"? What if we elect a new BDFL *for > life*? Does it mean that even core developers judgment are no longer > trusted, only the council decision matters? What about people outside > in the insider group of cores... regular contributors? Will anyone > still listen to them? That's a very good point, I think. Creating intimidating structures may not help attract new contributors. A BDFL is intimidating. Depending on its name and powers, a council or collegial body can be intimidating too (I'd recommend against naming it "Council of Elders", which IMHO sends the wrong message). Regards Antoine. From vstinner at redhat.com Fri Jul 20 07:57:01 2018 From: vstinner at redhat.com (Victor Stinner) Date: Fri, 20 Jul 2018 13:57:01 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: <5B513222.8020303@stoneleaf.us> References: <5B513222.8020303@stoneleaf.us> Message-ID: Hi Ethan, Thanks for your feedback! 2018-07-20 2:51 GMT+02:00 Ethan Furman : >> I see that many people are eager to replace the old governance based >> on a single BDFL with a new governance with a new BD(FL) and/or a >> council. My problem is that I don't see any clear definition of the >> roles of these BD(FL) and/or council: what they are expected to do, >> what they cannot do, etc. > > I imagine that will be made clear in that proposed PEP. In that case, I would prefer that people abstain from voting on this mailing list (I'm talking about "+1" emails), before a formal and well defined PEP is written ;-) > This is, unfortunately, true -- with 100+ core-devs (give or take a few) > that's basically 100+ different visions of Python, and on any particular > issue the majority will be made up of different core-devs, therefore > different visions will be approving/rejecting the PEPs, and internal > consistency becomes impossible. > >> Can someone please explain me the rationale behind these fears? Do you >> have examples? Maybe examples outside Python? > > Examples inside Python are good enough: > > - PEP 435 (Enum) [accepted] > lots of minor decisions from BDFL about this or that choice, Hum, first I would like to have better statistics on the number of active core developers. On St?phane Wirtel statistics on pull requests, the number of active core developers was closer to 34... Would you mind to elaborate? How would enum be inconsistent without the BDFL work? > and still there were about 1,000 emails over several threads Honestly, I don't recall the discussion on the enum module. What do you mean by this large number of emails? People are free to send emails, but at the end, a vote would occur on a proper PEP, not on emails. Let me try to guess what you mean. Do you mean that a 50%+1 majority would be impossible to reach because each core developer had a different taste on how enum should look like? What I saw in PHP RFC is that sometimes there are multiple votes on a single RFC, to choose between alternatives (translation for Python: replace RFC with PEP :-)). A recent example: https://wiki.php.net/rfc/array_key_first_last The RFC proposed to add array_key_first/last()" and array_value_first/last(). The array_value variant was controversial and so has been voted separately. There was a corner value for values: a value can really be null, whereas the RFC proposes to also return null to signal an error. This case doesn't occur with keys, since using null as a key is automatically replaced with an empty string: it's possible to distinguish null as an error. They decided to approve array_key_first()/last() but reject array_value_first()/last(), which IMHO is a wise choice :-) For enum, if you are talking about the two proposed alternatives "Not having to specify values for enums" and "Using special names or forms to auto-assign enum values", I guess that separated votes could be used: one vote for the main idea "having an Enum type", and a vote on the variants. The PEP author (and maybe an expert would him them to drive the PEP) would decide which votes are worth it. > - PEP 461 (%-formatting for bytes and byte arrays) [accepted] > IIRC there was lots of push-back on adding this to bytes and byte arrays Sorry, I don't understand what is wrong with this PEP. If I recall correctly, all core developers were in favor of adding back this feature to Python 3, no? I recall that I started to write a PEP 460, but Antoine wanted to "modify" it. In fact, he basically rewrote it from scratch, so I asked him to remove my name from it :-) Then you wrote a competitor PEP. At the end, your PEP won. I don't see how bytes % args is a good example of the need of a BDFL to keep Python consistent. Would you mind to elaborate? Do you have that having two PEPs in a competition goes against the principle of voting? > - PEP 463 (exception-catching expressions) [rejected] > lots of discussion here, not sure if it would have been accepted by > majority vote Hum, I don't recall well this discussion. If I recall correctly, the consensus quickly agreed to reject the PEP. Most people already disliked the PEP on python-ideas, no... I'm not sure of that. At least, I disliked the PEP since its start :-) What do you mean by "not sure if it would have been accepted by majority vote"?? > - PEP 572 (assignment expressions) [accepted] > 'nough said Joker! I will not comment that one. I don't have enough perspective on it yet. > My first issue with this model is, as discussed above, a lack of a > consistent vision. A BDFL is not just there to say, "this PEP is accepted," > but also to say, "change this one piece here, remove that piece there, add > this" -- definitely not something easily done by 100+ voters. I agree that an author can be confused when two different core developers ask to make two opposite changes. This is where an expert can help the author to drive the discussion and help the author to make choices. To formalize a little bit more, I would identify 3 groups: PEP authors (usually an individual), group who help authors to write the PEP and drive the discussion, group who vote (all core devs) at the end. I guess that the group helping the authors is supposed to like the proposed change, but I'm not sure that it's mandatory. It's like an advocate who is supposed to help their client even if their client killed someone ;-) If you want a recent example, on the PEP 572, Guido and Tim were strong supporters of the PEP and they helped a lot Chris to refine his PEP. At the end, they even decide to become co-authors. > My second issue is qualifications: there are plenty of PEPs that I either > have no interest in or whose field I have no experience with, and my voting > on those PEPs would be nonsensical; when that happens to a BDFL s/he > appoints a BDFOP. Sorry, what does BDFOP stand for? I saw people writing "mandatory votes" in a different thread. I don't see why anyone would be forced to vote on PEPs :-) (I'm not talking here about this very specific case of deciding a new governance for Python.) I prefer to abstain me from commenting PEPs in some areas like typing or distutils, since they are out of my interest area and I don't feel that I would add anything useful. I love that other experts who have a stronger background in these topics than me are able to provide good feedback to drive the discussion. Hum. Let me try to explain my point differently. Currently, some people don't read PEPs just because at the end, only the single BDFL vote counts. What's the point of spending hours (if not days) on reading a long PEP and the long discussion on mailing lists, if your count doesn't count? Now imagine that all votes count. I expect that people will spend more time on reading carefully each PEP and follow more closely discussions since they will be de facto more involved in the decision process. By the way, PHP votes on RFC votes is public. One advantage is that it forces voters to vote "seriously", since later someone can ask them why they voted like that :-) Are you sure that all core developers would have have the knee reaction of rejecting the PEP 572 if their vote really counts? On python-committers, I opened a *poll* on the PEP 572. The meaning is very different from a real vote where your voice really counts. Another way to explain it. It's really hard to force volunteers to work for free... In a regular job, IMHO a good way to involve workers is to give them more responsibilities. I already saw this issue on reviews. I read someone saying that they don't review pull requests since only core developers can merge changes, so what's the point of commenting? If you take the point of view of the core developer: merging a pull request means that it becomes your pet for life, you will have to clean up its shit for its whole life... So core developers feel more responsible when commenting pull requests. And now we ask regular contributor to do more reviews? I'm not sure that it works. If you want someone to do more review, IMHO you should give them the right to merge a PR. Suddenly, people are more careful on reviews :-) > My third issue is, quite simply, time. Working on patches takes time; > reviewing PRs takes time; and being a good voting citizen takes lots and > lots of time -- and we're all volunteers. Time is at a premium. See my previous point: you are not asked to vote on all PEPs. You are free to abstain from voting. "Time is at a premium." is very true in open source software where almost everybody is volunteer. This is why I consider that a BDFL or a council is not sustainable regarding the popularity of Python and the pressure on accepting changes. A BDFL was definitively a good choice 20 years ago, when Python was new and little used. Time changed. Python became #1 programming language in many area. They are million of users. We all feel the pressure of users who expect stability (this is partially why Python 2.7 is still very popular nowadays). IMHO a single BDFL can no longer handle the high number of PEPs nor the high traffic of python-ideas and python-dev lists. Moreover, since it has been written that no core developer is legitimate to replace BDFL, I expect even stronger criticism on the Internet against "unpopular" accepted changes... These problems go away when you replace a single BDFL with a collective decision. Dozens of core developers scale and accumulate skills. Victor From p.f.moore at gmail.com Fri Jul 20 08:14:49 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 20 Jul 2018 13:14:49 +0100 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5B513222.8020303@stoneleaf.us> Message-ID: On 20 July 2018 at 12:57, Victor Stinner wrote: > Hum. Let me try to explain my point differently. Currently, some > people don't read PEPs just because at the end, only the single BDFL > vote counts. What's the point of spending hours (if not days) on > reading a long PEP and the long discussion on mailing lists, if your > count doesn't count? My suspicion is that *most* people who don't read PEPs don't do so because they don't have the time, not because they don't believe that their opinion will matter. In actual fact, the evidence from many threads is that people are more than happy to express their opinion even though they haven't read the PEP. So I doubt that giving people more power to affect the result will make little practical difference. > Now imagine that all votes count. I expect that > people will spend more time on reading carefully each PEP and follow > more closely discussions since they will be de facto more involved in > the decision process. In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote. I suspect that the reality will be somewhere between these two extremes. Paul From doug at doughellmann.com Fri Jul 20 10:32:13 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 20 Jul 2018 10:32:13 -0400 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5B513222.8020303@stoneleaf.us> Message-ID: <1532097112-sup-2040@lrrr.local> Excerpts from Antoine Pitrou's message of 2018-07-20 09:49:01 +0200: > > Le 20/07/2018 ? 02:51, Ethan Furman a ?crit?: > > My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, > > "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely > > not something easily done by 100+ voters. > > > > My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no > > experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP. > > > > My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting > > citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium. > > This is true. But it's a problem for the BDFL even more. Our ex-BDFL > resigned because of pressure and exhaustion. Why would another BDFL > fare better? > > Victor pointed out something I didn't know: that several prominent core > devs (him, Brett Cannon) recently suffered from > breakdown/burnout/depression. > > I find the PEP-delegate to be a powerful concept. Why wouldn't *every* > PEP have a PEP-delegate? This way we don't need a BDFL anymore. We can > discuss how to nominate PEP-delegates (Nick had an interesting proposal). +1 Doug From doug at doughellmann.com Fri Jul 20 10:37:03 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 20 Jul 2018 10:37:03 -0400 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5B513222.8020303@stoneleaf.us> Message-ID: <1532097235-sup-9701@lrrr.local> Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100: > On 20 July 2018 at 12:57, Victor Stinner wrote: > > Hum. Let me try to explain my point differently. Currently, some > > people don't read PEPs just because at the end, only the single BDFL > > vote counts. What's the point of spending hours (if not days) on > > reading a long PEP and the long discussion on mailing lists, if your > > count doesn't count? > > My suspicion is that *most* people who don't read PEPs don't do so > because they don't have the time, not because they don't believe that > their opinion will matter. In actual fact, the evidence from many > threads is that people are more than happy to express their opinion > even though they haven't read the PEP. So I doubt that giving people > more power to affect the result will make little practical difference. > > > Now imagine that all votes count. I expect that > > people will spend more time on reading carefully each PEP and follow > > more closely discussions since they will be de facto more involved in > > the decision process. > > In contrast, I would imagine that people would continue to discuss > PEPs in exactly the same way that they currently do, so the result > would be that the votes are based more on partially-informed opinion > and "gut feeling". Certainly some people will work harder to provide > an informed vote, but I doubt that will be true in the majority of > cases. Worst case, people will feel a responsibility to vote, but > won't have any more time than they do right now so they'll vote with > limited information simply because "it's expected of them" to vote. > > I suspect that the reality will be somewhere between these two extremes. > > Paul In other communities that use this form of consensus approval for design changes I have seen folks who do not have time or interest to dig deeply into a proposed change learn to trust others who have the time, interest, and expertise. The team comes out stronger as a result of that built-up trust. Doug From ncoghlan at gmail.com Fri Jul 20 10:51:22 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 21 Jul 2018 00:51:22 +1000 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On 18 July 2018 at 16:42, Chris Jerdonek wrote: > I agree a name other than BDFL should be chosen, especially since (as > I understand it) Guido is still BDFL but just taking a permanent > vacation, and the name implies there should only be one. > > Also, if we're considering particular people, I think Nick should also > be considered. As much as I appreciate the vote of confidence, I'm actively working to reduce my open source commitments and responsibilities at the moment, not increase them. Burnout's a thing, y'all, especially when you have the attention span of a caffeinated squirrel and get involved in far more things than you could ever hope to see through to completion in a reasonable period of time :) And that's my primary concern with any proposals to put a comparable level of stress to that which Guido has been handling for years on to another volunteer's shoulders: I don't think it's an even remotely reasonable thing to request of a community volunteer. Guido was willing to do it for so long because Python was his creation, and he grew into the increasing demands of the BDFL role as time went by, but even he eventually reached the point of saying "I don't want to do this any more - the personal costs are outweighing the personal benefits". There's no way that a new individual in a comparable role to Guido's is going to have an easier time of it than Guido did, and a lot of good reasons to believe that they will find it significantly harder (not least of which is that Guido has been able to request 50% funded "BDFL-time" from his employers since he joined Google in 2005, and it's unlikely that a newcomer to the role would enjoy that benefit any time soon). In the 2 terms I spent on the PSF board, one of the things I aimed to help Ewa work towards was making being on the Board less of a recipe for burnout, and I've done what I could to help make working on the Python packaging ecosystem less of a burnout factory as well. Before my time on the Board, other folks had already started the process of having paid PSF staff take on more PyCon US management responsibilities to help reduce the burden on folks volunteering for PyCon US leadership roles. In that context, setting up a high profile volunteer leadership role that I'd expect to mainly let us burn out multiple people in succession really doesn't seem like a good response to a leading contributor deciding that it's time for them to step down :) So while I'm in favour of the minimal PEP 1 tweaks needed to keep the volunteer-per-PEP BDFL-Delegate model going for the less controversial proposals that don't touch core parts of the language, I *don't* think filing Guido's name off and writing Brett's (or anyone else's) name in is the right answer for the deeper community governance questions we're asking ourselves, and I think we'd be squandering a rare opportunity to explore the alternatives if we instead sought to preserve the status quo too directly. Yes, change is scary, and there's always a risk we'll find that we don't like the initial iteration of whatever we come up with, but that's just motivation to ensure that whatever system we come up with has mechanisms for change built into it (just as even the PSF's by-laws can be amended by a vote of the members). Personally, I think the contributor council approach is likely to prove to be a good way to go (since it distributes the burden of responsibility amongst mutiple volunteers and doesn't leave anyone feeling obliged to be "on" all the time), and it would then be up to the initial members of that council to come up with a way to appropriately rotate any spokesperson responsibilities that came up. I also think folks are placing too much weight on the notion of Guido as the primary spokesperson representing what the core contributors are thinking - if anyone were to be seen as occupying that role, I'd actually point to whoever takes the lead editor role for the What's New document in any given release, since most Pythonistas don't even think about the core development process until they're looking at a new release and asking themselves "Why on Earth did they add *that*?". (It could actually be an interesting trial addition to the PEP process to require that PEP authors include a draft What's New entry, as it forces you to step back from the intricacies of language and interpreter runtime design, and focus on the end user impact of a proposed change) Cheers, Nick. P.S. Since "What *do* you think is the upper limit on what's a reasonable request to make of a community volunteer?" is a natural follow-up question, I'm currently fairly comfortable with the scope of things like PSF Board membership, PSF Working Group membership, CPython release management, CPython module maintainership, and the packaging BDFL-Delegate responsibilities I recently handed over to Paul Moore (and I think that last one is borderline, and could stand to follow in CPython's footsteps if we can settle on a reasonable non-BDFL-dependent design management model). P.P.S. Full disclosure for folks that weren't there: I proposed at the 2018 Python Language Summit that we institute a PEP 3003 style language moratarium for Python 3.8, to give the ripple effects arising from some of the recent language changes like type hinting, native coroutines, and f-strings a chance to settle down before we embarked on more language level changes like assignment expressions and None-aware operators - I think imposing such a moratorium would cost us very little in the long run, and give the wider community a chance to catch up on all of the benefits that 3.6 and 3.7 can offer them. While Guido really wasn't a fan of the idea, the fact that I believe we should be thinking about how to reduce the demand for language level churn rather than worrying too much about how to enable more of it does mean that I'm entirely comfortable with the idea of postponing any further syntax changes beyond PEP 572 to Python 3.9 or later. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at python.org Fri Jul 20 11:58:09 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 08:58:09 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Fri, Jul 20, 2018, 07:51 Nick Coghlan, wrote: > On 18 July 2018 at 16:42, Chris Jerdonek wrote: > > I agree a name other than BDFL should be chosen, especially since (as > > I understand it) Guido is still BDFL but just taking a permanent > > vacation, and the name implies there should only be one. > > > > Also, if we're considering particular people, I think Nick should also > > be considered. > > As much as I appreciate the vote of confidence, I'm actively working > to reduce my open source commitments and responsibilities at the > moment, not increase them. Burnout's a thing, y'all, especially when > you have the attention span of a caffeinated squirrel and get involved > in far more things than you could ever hope to see through to > completion in a reasonable period of time :) > > And that's my primary concern with any proposals to put a comparable > level of stress to that which Guido has been handling for years on to > another volunteer's shoulders: I don't think it's an even remotely > reasonable thing to request of a community volunteer. > > Guido was willing to do it for so long because Python was his > creation, and he grew into the increasing demands of the BDFL role as > time went by, but even he eventually reached the point of saying "I > don't want to do this any more - the personal costs are outweighing > the personal benefits". There's no way that a new individual in a > comparable role to Guido's is going to have an easier time of it than > Guido did, and a lot of good reasons to believe that they will find it > significantly harder (not least of which is that Guido has been able > to request 50% funded "BDFL-time" from his employers since he joined > Google in 2005, and it's unlikely that a newcomer to the role would > enjoy that benefit any time soon). > While I'm purposefully staying out of this thread as my name is currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day). I also agreed to Barry's proposal under the expectation that I would still take a month off every year and one day a week like I do already. That plus a council of folks to help with the load makes me think I can handle the workload without having to sacrifice more personal time than I'm already comfortable doing now. I also think that we as a team and a community are a bit more aware of the issue of burnout thanks to Guido's retirement. Plus Andrea said it was okay ? (The cat was indifferent.) -Brett > In the 2 terms I spent on the PSF board, one of the things I aimed to > help Ewa work towards was making being on the Board less of a recipe > for burnout, and I've done what I could to help make working on the > Python packaging ecosystem less of a burnout factory as well. Before > my time on the Board, other folks had already started the process of > having paid PSF staff take on more PyCon US management > responsibilities to help reduce the burden on folks volunteering for > PyCon US leadership roles. > > In that context, setting up a high profile volunteer leadership role > that I'd expect to mainly let us burn out multiple people in > succession really doesn't seem like a good response to a leading > contributor deciding that it's time for them to step down :) > > So while I'm in favour of the minimal PEP 1 tweaks needed to keep the > volunteer-per-PEP BDFL-Delegate model going for the less controversial > proposals that don't touch core parts of the language, I *don't* think > filing Guido's name off and writing Brett's (or anyone else's) name in > is the right answer for the deeper community governance questions > we're asking ourselves, and I think we'd be squandering a rare > opportunity to explore the alternatives if we instead sought to > preserve the status quo too directly. > > Yes, change is scary, and there's always a risk we'll find that we > don't like the initial iteration of whatever we come up with, but > that's just motivation to ensure that whatever system we come up with > has mechanisms for change built into it (just as even the PSF's > by-laws can be amended by a vote of the members). > > Personally, I think the contributor council approach is likely to > prove to be a good way to go (since it distributes the burden of > responsibility amongst mutiple volunteers and doesn't leave anyone > feeling obliged to be "on" all the time), and it would then be up to > the initial members of that council to come up with a way to > appropriately rotate any spokesperson responsibilities that came up. > > I also think folks are placing too much weight on the notion of Guido > as the primary spokesperson representing what the core contributors > are thinking - if anyone were to be seen as occupying that role, I'd > actually point to whoever takes the lead editor role for the What's > New document in any given release, since most Pythonistas don't even > think about the core development process until they're looking at a > new release and asking themselves "Why on Earth did they add *that*?". > (It could actually be an interesting trial addition to the PEP process > to require that PEP authors include a draft What's New entry, as it > forces you to step back from the intricacies of language and > interpreter runtime design, and focus on the end user impact of a > proposed change) > > Cheers, > Nick. > > P.S. Since "What *do* you think is the upper limit on what's a > reasonable request to make of a community volunteer?" is a natural > follow-up question, I'm currently fairly comfortable with the scope of > things like PSF Board membership, PSF Working Group membership, > CPython release management, CPython module maintainership, and the > packaging BDFL-Delegate responsibilities I recently handed over to > Paul Moore (and I think that last one is borderline, and could stand > to follow in CPython's footsteps if we can settle on a reasonable > non-BDFL-dependent design management model). > > P.P.S. Full disclosure for folks that weren't there: I proposed at the > 2018 Python Language Summit that we institute a PEP 3003 style > language moratarium for Python 3.8, to give the ripple effects arising > from some of the recent language changes like type hinting, native > coroutines, and f-strings a chance to settle down before we embarked > on more language level changes like assignment expressions and > None-aware operators - I think imposing such a moratorium would cost > us very little in the long run, and give the wider community a chance > to catch up on all of the benefits that 3.6 and 3.7 can offer them. > While Guido really wasn't a fan of the idea, the fact that I believe > we should be thinking about how to reduce the demand for language > level churn rather than worrying too much about how to enable more of > it does mean that I'm entirely comfortable with the idea of postponing > any further syntax changes beyond PEP 572 to Python 3.9 or later. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Fri Jul 20 12:32:02 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 21 Jul 2018 02:32:02 +1000 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: <1532097235-sup-9701@lrrr.local> References: <5B513222.8020303@stoneleaf.us> <1532097235-sup-9701@lrrr.local> Message-ID: <20180720163201.GC8744@ando.pearwood.info> On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote: > Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100: [...] > > In contrast, I would imagine that people would continue to discuss > > PEPs in exactly the same way that they currently do, so the result > > would be that the votes are based more on partially-informed opinion > > and "gut feeling". Certainly some people will work harder to provide > > an informed vote, but I doubt that will be true in the majority of > > cases. Worst case, people will feel a responsibility to vote, but > > won't have any more time than they do right now so they'll vote with > > limited information simply because "it's expected of them" to vote. [...] > In other communities that use this form of consensus approval for > design changes I have seen folks who do not have time or interest > to dig deeply into a proposed change learn to trust others who have > the time, interest, and expertise. The team comes out stronger as > a result of that built-up trust. A few questions... You say folks "learn to trust others", but what does that mean in practice? The only interpretation I can think of is: People vote for a feature, because Fred says he's in favour of it and they trust him, or like him personally, or because he's more charismatic and persuasive than those against it. What happens when two trusted experts disagree and the voters don't have the expertise to tell which one is correct? How large are these communities you are referring to? The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model. Certainly the Python community as a whole is *significantly* bigger than a village. What about the core developers? Now? In the future? One factor that I don't think Victor has covered is that of what percentage of core devs would have to vote for the result to be accepted -- a quorum, or equivalent. When it comes to *representative democracy* I believe that the Australian model of mandatory voting (resulting in 90% turnouts or higher) has many advantages over other systems. But for a technical community like this, I don't know that mandatory voting is desirable. (Perhaps if we have an Abstain option as well as Yes or No.) So how many non-Abstain votes are needed? Victor mentioned "50% + 1" votes, but does that assume 100% turnout? What if only a handful of people vote on some exceedingly obscure, technical question of no interest to the majority? Personally, I'm not sure I'd even want to vote on every PEP that comes up. When I was first nominated to the PSF, I took the voting rights as both a privilege and a duty and took them very seriously indeed. But as time went on, I got somewhat disillusioned and burned out (for reasons we need not go into). And that is only voting once or twice a year. If I had to vote on a dozen or two dozen PEPs a year, most of which I have little or no interest in, the annoyance factor would be correspondingly greater. But if I don't vote, could that doom PEPs to fail because they don't get a quorum? Another issue we should consider: organised vote swapping. If votes are public, as Victor suggests, that would allow people to do deals: "I'll support your PEP for GOTO, if you support my PEP to deprecate tuples..." sort of thing. There's a reason why most ballots are secret. -- Steve From steve at pearwood.info Fri Jul 20 12:55:54 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 21 Jul 2018 02:55:54 +1000 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: <20180720165553.GD8744@ando.pearwood.info> On Fri, Jul 20, 2018 at 09:59:39AM +0200, Antoine Pitrou wrote: > > Le 20/07/2018 ? 01:47, Victor Stinner a ?crit?: > > > > What is the image sent to contributors if we create a subgroup inside > > core developpers called "council"? What if we elect a new BDFL *for > > life*? Does it mean that even core developers judgment are no longer > > trusted, only the council decision matters? What about people outside > > in the insider group of cores... regular contributors? Will anyone > > still listen to them? > > That's a very good point, I think. Creating intimidating structures may > not help attract new contributors. A BDFL is intimidating. Depending > on its name and powers, a council or collegial body can be intimidating > too (I'd recommend against naming it "Council of Elders", which IMHO > sends the wrong message). Perhaps we could call it the Pythonic Inquisition, whose three weapons are experience, intelligence, the PEP process, and a fanatical dedication to backwards compatibility, and absolutely no braces. *wink* Please be explicit: what message do you think it sends which is the wrong message? I think that the messages sent include: - there is someone in charge; - this is a meritocracy; - you too could get into the council, someday; - but you aren't in it yet; - trust and responsibility comes in degrees; - and must be earned, not just granted to random people on the Internet because they ask for core developer rights; - the evolution of the language is driven by reasoned argument, not popularity contests. We've had a BDFL for a quarter of a century, and Python has done pretty well, possibly by far the most popular programming language not driven by a corporate owner or patron (and more popular than many languages which do have corporate owners). Of course it is impossible to prove a negative, we cannot dismiss the possibility that Guido-as-BDFL has been "sending the wrong message" for two decades, scaring off contributors and acting as a drag on Python's success. But I doubt it, and I doubt that a new BDFL or Council or Triumvirate would do so either. -- Steve From steve.dower at python.org Fri Jul 20 14:04:28 2018 From: steve.dower at python.org (Steve Dower) Date: Fri, 20 Jul 2018 11:04:28 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5B513222.8020303@stoneleaf.us> Message-ID: Summary: appointing a BDFL or small council *does not* force them to do all the work themselves. On 20Jul2018 0457, Victor Stinner wrote: > mailing list (I'm talking about "+1" emails), before a formal and well > defined PEP is written ;-) Until your new process arrives, "+1" emails are not votes and have never been considered as such. They've always been an easy and impersonal way to provide the BDFL[-delegate] with the opinions of the experts within the team who have taken the time to review a proposal. Judging the general feeling of an email list is impossible without such emails. Counting these without taking into account the person providing the vote is a terrible idea (for example, if the topic is itertools, my +1 in no way comes close to cancelling out Raymond's -1, and nor should it). > People are free to send emails, but at the end, a vote would occur on > a proper PEP, not on emails. Substitute "vote" for "decision" (which may be decided by voting, but does not presuppose that voting is the only option) and I'm +1 on this. The final decision should always be made against the PEP, not the discussion. >> [Ethan] My first issue with this model is, as discussed above, a lack of a >> consistent vision. A BDFL is not just there to say, "this PEP is accepted," >> but also to say, "change this one piece here, remove that piece there, add >> this" -- definitely not something easily done by 100+ voters. > > I agree that an author can be confused when two different core > developers ask to make two opposite changes. This is where an expert > can help the author to drive the discussion and help the author to > make choices. > > To formalize a little bit more, I would identify 3 groups: PEP authors > (usually an individual), group who help authors to write the PEP and > drive the discussion, group who vote (all core devs) at the end. Despite apparently being completely opposed to the other proposals, this part matches them nearly identically. Everyone seems to be in support of a model where: * anyone can propose a change (PEP author) * trusted people should help sponsor/champion it (core committer bringing it to python-dev) * trusted person/people should make a final determination The only argument I see is entirely around how to choose that last group. The options: * choose one person who always has to make that determination * choose one person who chooses that group on a proposal-by-proposal basis * choose a small group who always has to make that determination * choose a small group who chooses that group on a proposal-by-proposal basis * don't choose and force everyone to make that determination Your proposal is the last one. My preference is the second or fourth. Some people seem to assume that unless we slow down now we will automatically end up with the first or third, but I don't see any basis for that assumption. A BDFL or Council are free to delegate as much or as little as they want, and could conceivably reduce their workload to "once a week I will review emails starting with '[PEP xxx] Request for delegate' and provide a response". > I saw people writing "mandatory votes" in a different thread. I don't > see why anyone would be forced to vote on PEPs :-) (I'm not talking > here about this very specific case of deciding a new governance for > Python.) > > I prefer to abstain me from commenting PEPs in some areas like typing > or distutils, since they are out of my interest area and I don't feel > that I would add anything useful. I love that other experts who have a > stronger background in these topics than me are able to provide good > feedback to drive the discussion. "Abstain" is counted as a vote, just not in any direction. The point about mandatory voting is whether we need to wait for you to respond before considering a decision to have been reached. If we make that decision numerical, then sooner or later we will need to make exceptions. If we have appointed 1-to-n people to determine when a decision has been reached, the flexibility is built in to the process. > Hum. Let me try to explain my point differently. Currently, some > people don't read PEPs just because at the end, only the single BDFL > vote counts. What's the point of spending hours (if not days) on > reading a long PEP and the long discussion on mailing lists, if your > count doesn't count? Now imagine that all votes count. I expect that > people will spend more time on reading carefully each PEP and follow > more closely discussions since they will be de facto more involved in > the decision process. If/when we choose a BDFL, it will need to be someone who is known for listening to all contributions and not excluding people for unfair or invalid reasons. It will also give them the power to declare how they want to hear contributions - they do not need to commit to reading and responding to every email! If you feel strongly against a proposal, you know who to go to in order to make that known. By contrast, if everyone gets an equal vote on each proposal, and I want to prevent your PEP from being accepted, I have my choice of up to 50% of voters to convince to vote against you! That leads to a dynamic that I'm *very* nervous about. I would much rather have a trusted delegate tell me "thanks for your feedback but I trust Victor on this issue more than you" and have that be the end of it. There is no good that comes out of me spending time on Twitter/emails/etc. advocating that people vote against your proposal. > I already saw this issue on reviews. I read someone saying that they > don't review pull requests since only core developers can merge > changes, so what's the point of commenting? If you take the point of > view of the core developer: merging a pull request means that it > becomes your pet for life, you will have to clean up its shit for its > whole life... So core developers feel more responsible when commenting > pull requests. > > And now we ask regular contributor to do more reviews? I'm not sure > that it works. If you want someone to do more review, IMHO you should > give them the right to merge a PR. Suddenly, people are more careful > on reviews :-) Massive change of subject here, but I agree. Core developers *are* taking responsibility for the code they merge, and being willing to take on that responsibility is one of the main reasons for getting the role. "Making contributions" is not the qualification - "making good decisions about contributions" is. > A BDFL was definitively a good choice 20 years ago, when Python was > new and little used. Time changed. Python became #1 programming > language in many area. They are million of users. We all feel the > pressure of users who expect stability (this is partially why Python > 2.7 is still very popular nowadays). IMHO a single BDFL can no longer > handle the high number of PEPs nor the high traffic of python-ideas > and python-dev lists. Moreover, since it has been written that no core > developer is legitimate to replace BDFL, I expect even stronger > criticism on the Internet against "unpopular" accepted changes... > > These problems go away when you replace a single BDFL with a > collective decision. Dozens of core developers scale and accumulate > skills. Perhaps, but they also go away when your single BDFL sets very clear limits on their availability and process, and when the process sets very clear expectations on their behaviour. Guido's problem is perhaps that he cared too much about every individual contribution and giving everyone an opportunity to make the case for shaping the language :) If a new BDFL declared "I do not read or respond on python-ideas, or proposals on python-dev that are not championed by a core developer" then that immediately reduces their workload without making it harder for people to contribute. Perhaps it will reduce their "celebrity" status, and maybe they won't be stalked at conferences as much as Guido suffers from (hopefully "suffered from"), but I doubt that is a concern for anyone that would be under consideration. From doug at doughellmann.com Fri Jul 20 14:05:20 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 20 Jul 2018 14:05:20 -0400 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: <20180720163201.GC8744@ando.pearwood.info> References: <5B513222.8020303@stoneleaf.us> <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info> Message-ID: <1532107977-sup-1296@lrrr.local> Excerpts from Steven D'Aprano's message of 2018-07-21 02:32:02 +1000: > On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote: > > Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100: > > [...] > > > In contrast, I would imagine that people would continue to discuss > > > PEPs in exactly the same way that they currently do, so the result > > > would be that the votes are based more on partially-informed opinion > > > and "gut feeling". Certainly some people will work harder to provide > > > an informed vote, but I doubt that will be true in the majority of > > > cases. Worst case, people will feel a responsibility to vote, but > > > won't have any more time than they do right now so they'll vote with > > > limited information simply because "it's expected of them" to vote. > > [...] > > In other communities that use this form of consensus approval for > > design changes I have seen folks who do not have time or interest > > to dig deeply into a proposed change learn to trust others who have > > the time, interest, and expertise. The team comes out stronger as > > a result of that built-up trust. > > A few questions... > > You say folks "learn to trust others", but what does that mean in > practice? The only interpretation I can think of is: > > People vote for a feature, because Fred says he's in favour > of it and they trust him, or like him personally, or because > he's more charismatic and persuasive than those against it. > > What happens when two trusted experts disagree and the voters don't have > the expertise to tell which one is correct? The same sort of thing that happens with PEPs. Either the proposal itself is changed to support more compromise, or it is abandoned and the status quo prevails. > How large are these communities you are referring to? OpenStack had 2000 contributors during 2017. Of those, I would estimate that on the order of a few hundred are considered core reviewers in some way and would have a formal vote in our specification process, although the group reviewing any given specification would be somewhat closer to the size of the python core developer team size. > The sort of participatory democracy Victor and you seem to be talking > about doesn't scale beyond small communities where everyone knows > everyone else. That's why such participatory democracy worked in ancient > Greece, and continues to be used in (eg) Swiss canons, but beyond that > communities have moved to a representative democratic model. It is certainly harder to implement as the size of the group grows. I don't think this group has hit the point where it is impossible to sustain, though. > Certainly the Python community as a whole is *significantly* bigger > than a village. What about the core developers? Now? In the future? I'm not sure the entire Python community is really the relevant size to consider. Another important aspect of open source governance to keep in mind is that decisions need to be made by the folks doing the work. That's one reason the existing PEP delegate process works so well today -- the person making that final decision is invested in not just the decision but the overall area where the work is happening. We already trust them to both know what they are doing technically and guide the decision making process to consensus. I find it interesting that the arguments in favor of a single BDFL tend to assume that the person selected will be responsible and informed enough to make good decisions, and the argument against a more democratic approach seems to be that the community would not be. Where in that latter assumption is the leadership of the person we would be giving the BDFL title to? Why are they unable to communicate, inform, and lead a democratically organized community to achieve goals for the common good? And if they can't, why are they qualified to be a dictator? > One factor that I don't think Victor has covered is that of what > percentage of core devs would have to vote for the result to be > accepted -- a quorum, or equivalent. Yes, this is a good point. I'm not sure a 1-size-fits-all approach necessarily works, but some way of deciding how to know when consensus is reached would be an important aspect of choosing a democratic approach. > Personally, I'm not sure I'd even want to vote on every PEP that comes > up. When I was first nominated to the PSF, I took the voting rights as > both a privilege and a duty and took them very seriously indeed. But as > time went on, I got somewhat disillusioned and burned out (for reasons > we need not go into). And that is only voting once or twice a year. > > If I had to vote on a dozen or two dozen PEPs a year, most of which I > have little or no interest in, the annoyance factor would be > correspondingly greater. But if I don't vote, could that doom PEPs to > fail because they don't get a quorum? One approach some of our teams take is to have a subset of the core reviewers serve as reviewers for specifications. This reduces the number of people needed for quorum, explicitly asks those people to commit to doing the reviews, and still supports a democratic decision making process. Combining that approach with the PEP delegation system already in use, we could designate a team for making decisions on individual PEPs. Core developers could volunteer or be drafted, and we could include knowledgeable and interested contributors who are not core, in some cases (PyPA comes to mind). > Another issue we should consider: organised vote swapping. If votes are > public, as Victor suggests, that would allow people to do deals: "I'll > support your PEP for GOTO, if you support my PEP to deprecate tuples..." > sort of thing. There's a reason why most ballots are secret. I don't know anyone currently on the core team who would engage in that sort of behavior, or who would put up with it if discovered in any current or future members. Within the OpenStack community we have *much* higher pressure from companies to add features supporting their products (supporting hardware, use cases, odd-ball customer configurations, etc.) than I have ever seen in any discussion related to Python itself. An open, democratic, approach *exposes* these sorts of issues, and lets us deal with them directly. Doug From barry at python.org Fri Jul 20 14:14:40 2018 From: barry at python.org (Barry Warsaw) Date: Fri, 20 Jul 2018 11:14:40 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5B513222.8020303@stoneleaf.us> Message-ID: On Jul 20, 2018, at 00:49, Antoine Pitrou wrote: > > I find the PEP-delegate to be a powerful concept. Why wouldn't *every* > PEP have a PEP-delegate? This way we don't need a BDFL anymore. We can > discuss how to nominate PEP-delegates (Nick had an interesting proposal). Because IMHO that would lead to a language designed by committee, with a less consistent vision. 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 steve.dower at python.org Fri Jul 20 14:25:30 2018 From: steve.dower at python.org (Steve Dower) Date: Fri, 20 Jul 2018 11:25:30 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On 20Jul2018 0858, Brett Cannon wrote: > While I'm purposefully staying out of this thread as my name is > currently so strongly associated with it and I don't want people > thinking I'm a megalomaniac, I will say that I see no reason why I > wouldn't get 50% time at Microsoft if I asked for it (I already get a > day/week plus email reading every day). I agree that this would likely happen. (Also that he's not a megalomaniac.) I've been talking with our senior management about all this a bit over the last week, and the general mood is concern for Python's future if we spend an extended time without leadership. Microsoft's future these days certainly includes the Python ecosystem, and providing time for an employee to contribute freely in such a leadership role should be very easy to arrange. And since most people are probably not aware of the "day job" breakdown we have, Brett does not spend his time working on Microsoft's policy directions on Python - that is largely me and some people who are not really known outside the company - so I wouldn't be concerned about Python being "forced into alignment" with anything except Visual Studio Code ;) > I also agreed to Barry's proposal under the expectation that I would > still take a month off every year and one day a week like I do already. > That plus a council of folks to help with the load makes me think I can > handle the workload without having to sacrifice more personal time than > I'm already comfortable doing now. I also think that we as a team and a > community are a bit more aware of the issue of burnout thanks to Guido's > retirement. > > Plus Andrea said it was okay ? (The cat was indifferent.) "Approval of his/her household" is actually a really good criteria for taking on this kind of role :) Cheers, Steve From donald at stufft.io Fri Jul 20 14:30:58 2018 From: donald at stufft.io (Donald Stufft) Date: Fri, 20 Jul 2018 14:30:58 -0400 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io> > On Jul 19, 2018, at 7:47 PM, Victor Stinner wrote: > > It seems that the main question for a new governance is how to take a > decision on PEPs (accept or reject them with some variants like > Deferred). I read that core developers are unable to make a decision > themselves (fail to reach a consensus) and that letting core > developers decide would make Python "inconsistent" (as if only a > single BDFL is able to keep Python consistent). I also read that the > BDFL is required to make unpopular decisions to enhance Python. I think the core difference behind all of the proposals, when you get down to brass tacks, will be the vision for where the langauge goes. There are independently good ideas that maybe should not be accepted, because they compromise the vision for the worse, or ideas that seem poor on the tin but that once they get added they mesh well with the overall language. The further you scale up the number of people directly deciding the direction of the language, the more likely you will find inconsistency. No two people have the same design sense, and so if you ask two people you're likely to get at least two answers. Of course with many things, there are grey areas. If you have some sort of council of N developers, with a small enough N you can arrive at a place where the design sense for all of N are closely enough aligned that the inconsistency produced by them are minor enough as to not be noticeable. However, the larger you make that group, the more likely you are to introduce larger and larger inconsitencies. Now, that doesn't mean that focusing on consistency to the end of all other things is the right choice. The laws of any democratic country tend to be extremely inconsistent, due to that very reason, but most people would not argue that we should revert democracy back to dictatorships in those countries. Democracy brings with it more power to the "masses" and helps protect against a sole leader drastically going against the will of "the people" over an extended period of time. So realistically, the choice comes down to whether we value consistency more (in which case, we'd want to favor solutions that have a small N) or more directly empowering people with a democracy. Of course, you could try to do something that combines the two of them. You could elect a BDFL, but have PEPs go through a vote process first where they need to get a simple majority, and at which point the BDFL could approve or veto, and if they veto, then the voting body gets an additional chance to vote and if they're able to get a larger majority (2/3?) then they can override the BDFL's veto. That provides some protections from both a "design by committee" effect (since the BDFL can veto) but also provides very popular proposals a chance to pass even if the BDFL is against them. The big loss of that compromise is that you again, give up some of the consistency, since a large enough group of developers can still introduce an inconsistent vision and you remove the ability for the BDFL to accept unpopular but long term necessary PEPs (since they'd have to get a simple majority first). -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Jul 20 16:42:02 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 13:42:02 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: On Thu, 19 Jul 2018 at 14:59 Victor Stinner wrote: > Please extend the deadline: next week, I will be at EuroPython (I > don't think that I will have time to sit down and come up with > something), and I'm (more or less) in holiday the whole month of > August. > The leading proposal of a deadline to get governance model proposals in and deciding on a voting procedure is October 1. Do you need more time than that? And if so how much are you asking for? -Brett > > Victor > > 2018-07-19 21:43 GMT+02:00 Antoine Pitrou : > > > > Le 19/07/2018 ? 21:35, Carol Willing a ?crit : > >>> > >>>>> My biggest concern is that dragging this on into the new year will > >>>>> result in more bikeshedding, more uncertainty, and less confidence in > >>>>> the developer community decision making ability. > >>>> > >>>> That's a fair point. But there's also an opposite concern that > >>>> discussions may be deterred or cut short by a too tight deadline. > Even > >>>> simple and uncontentious PEPs take time to write, discuss and > finalize. > >>> > >>> Maybe it would be better to focus on a first date for submitting > >>> proposals and then wait to set the rest of the deadlines until after > >>> we have a bit more of the discussion behind us. That will give us > >>> a sense for how much consensus there is and how much more discussion > >>> might be needed. > >> > >> This suggestion seems to balance well the different perspectives. > >> > >> Proposals due by Sept 9, 2018 AOE. > > > > I still think it's too short. Imagine someone leaving in August. > > Besides catching up with work, the beginning of a new school year (if > > they have kids) and other things, they have only 9 days to contribute > > usefully. > > > > This is not something we can mobilize for to try and compress the time > > span as much possible. > > > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Jul 20 17:14:39 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 14:14:39 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: On Thu, 19 Jul 2018 at 16:47 Victor Stinner wrote: > or: Replace Dictatorship with Democracy. > [SNIP] > > > == What is the image send to the community and contributors? == > > Last year, I mentored multiple contributors. What I learnt is that > contributing to Python is much harder than what I expected. > > Most core developers are core for 5 years or longer (maybe 10 years > for some of them?), and we (core developers) forgot how hard it is to > contribute. When your name is known in a community: it's very easy to > share your ideas, other people listen to you and respect your > experience. It's much faster to get a pull request merged... sometimes > simply because you merged your own PR :-) > > Becoming a core developer takes between 6 months and 2 years, it > requires a lot of commitment, to have free time, etc. In short, it's > *very hard* to recruit new core developers. It seems like many people > forgot that. > > What is the image sent to contributors if we create a subgroup inside > core developpers called "council"? What if we elect a new BDFL *for > life*? Does it mean that even core developers judgment are no longer > trusted, only the council decision matters? What about people outside > in the insider group of cores... regular contributors? Will anyone > still listen to them? > > I'm not saying that a new governance will lead to such issues. I'm > only opening the question of the image sent to the community. > This will also make it harder to become a core developer. In the past we have been willing to give people commit privileges for showing they know how to code to our standards, make decisions when it came to PRs, and knew when they were outside of their depth (e.g. giving someone commit privileges to work on Python code but not C). We've also given commit privileges away like candy to people who have attended sprints in the past, so we have not even held up that level of requirement for all of Python's history. Now we're being asked to also trust someone's design acumen as they will be voting on PEPs. Up until this point I didn't have to worry about whether every core dev would take the language in a direction I disagreed with because they simply didn't have the authority to; it rested with Guido. This proposed change, though, means I now have to judge all core developers not just on whether I can trust them to code appropriately but whether I think they would vote on PEPs that I agree with. That would mean I wouldn't have voted to give Pablo commit privileges because I simply do not know his contributions well enough to know if he would make decisions in a way I'm personally in favour of. > [SNIP] > > Advantages. > > [SNIP] > > The decision becomes taken by "the community" (core developers in > practice) rather than an individual. Negative comments should no > longer target an individual but the collective decision. Being a > public person is not easy, it seems like Guido resigns partially > because of that pressure. I know that Brett Cannon also suffered of > negativity of some haters of the Internet. I also had a depression > recently caused partially by Python. Working on an open source and > public project causes specific issues. > Steve pointed out in his reply about how this might increase load as people will have to start trying to get people on side to vote the way they want. In US politics this is done by someone called a *whip* who "whips up" votes for a bill. With 91 (or more if people start to come back to use their commit rights who have not added their GitHub usernames) of us getting grandfathered into this, people will be somewhat political in getting votes for or against PEPs they care about since only people post-Guido would be made core devs knowing they now have a vote on PEPs and thus take that into consideration when adding new members to the team. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Fri Jul 20 18:23:29 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 21 Jul 2018 00:23:29 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: 2018-07-20 22:42 GMT+02:00 Brett Cannon : > The leading proposal of a deadline to get governance model proposals in and > deciding on a voting procedure is October 1. Do you need more time than > that? And if so how much are you asking for? Carol wrote "Proposals due by Sept 9, 2018 AOE". I'm fine with October 1. Victor From njs at pobox.com Fri Jul 20 18:36:50 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 20 Jul 2018 15:36:50 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Fri, Jul 20, 2018, 08:58 Brett Cannon wrote: > > > > On Fri, Jul 20, 2018, 07:51 Nick Coghlan, wrote: >> >> Guido was willing to do it for so long because Python was his >> creation, and he grew into the increasing demands of the BDFL role as >> time went by, but even he eventually reached the point of saying "I >> don't want to do this any more - the personal costs are outweighing >> the personal benefits". There's no way that a new individual in a >> comparable role to Guido's is going to have an easier time of it than >> Guido did, and a lot of good reasons to believe that they will find it >> significantly harder (not least of which is that Guido has been able >> to request 50% funded "BDFL-time" from his employers since he joined >> Google in 2005, and it's unlikely that a newcomer to the role would >> enjoy that benefit any time soon). > > While I'm purposefully staying out of this thread as my name is currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day). Is that only if you were named BDFL, or do you think they might also support that if you were named "Chief PEP Herder", or "Member of the steering council",or similar? AFAICT Guido spent a lot of time behind the scenes moving PEPs along and generally keeping things organized. I think we might get a lot of value out of having more people with time to focus on these things, and it's not really limited to the BDFL. The Django project seems to benefit a lot from their fellows program [1], and in the recent grant the PSF got for PyPI, everyone was *very* happy that we spent money on a project manager [2]. (And at the risk of falling into megalovania myself, I've also written about this recently [3].) So I don't have a specific proposal or anything, but maybe as part of this discussion we should exploring ways to get more dedicated time on CPython, through company's donating time, or sponsoring people through the PSF, or whatever makes sense. -n [1] https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospective/ [2] https://twitter.com/EWDurbin/status/968180960066928640 [3] https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open-source-infrastructure/ From brett at python.org Fri Jul 20 18:42:15 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 15:42:15 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: On Fri, 20 Jul 2018 at 15:23 Victor Stinner wrote: > 2018-07-20 22:42 GMT+02:00 Brett Cannon : > > The leading proposal of a deadline to get governance model proposals in > and > > deciding on a voting procedure is October 1. Do you need more time than > > that? And if so how much are you asking for? > > Carol wrote "Proposals due by Sept 9, 2018 AOE". Yep, and most people disagreed. :) Mariatta's timeline seems to be what people like. > I'm fine with October 1. > Great! -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Jul 20 18:50:38 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 15:50:38 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith wrote: > On Fri, Jul 20, 2018, 08:58 Brett Cannon wrote: > > > > > > > > On Fri, Jul 20, 2018, 07:51 Nick Coghlan, wrote: > >> > >> Guido was willing to do it for so long because Python was his > >> creation, and he grew into the increasing demands of the BDFL role as > >> time went by, but even he eventually reached the point of saying "I > >> don't want to do this any more - the personal costs are outweighing > >> the personal benefits". There's no way that a new individual in a > >> comparable role to Guido's is going to have an easier time of it than > >> Guido did, and a lot of good reasons to believe that they will find it > >> significantly harder (not least of which is that Guido has been able > >> to request 50% funded "BDFL-time" from his employers since he joined > >> Google in 2005, and it's unlikely that a newcomer to the role would > >> enjoy that benefit any time soon). > > > > While I'm purposefully staying out of this thread as my name is > currently so strongly associated with it and I don't want people thinking > I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% > time at Microsoft if I asked for it (I already get a day/week plus email > reading every day). > > Is that only if you were named BDFL, or do you think they might also > support that if you were named "Chief PEP Herder", or "Member of the > steering council",or similar? > It isn't really title and more about workload/responsibility. So if the title changed to "Chief PEP herder" but it was still on my shoulders to have final say then I don't expect an issue as they would understand what that means to me and my time. If I'm one of three on a council then I might still get more time but I'm not as sure; it's definitely possible, but not as much of a sure thing. If the group was 10 then probably not because that means I am just one of about a quarter of all authors over the past year. > > AFAICT Guido spent a lot of time behind the scenes moving PEPs along > and generally keeping things organized. I think we might get a lot of > value out of having more people with time to focus on these things, > and it's not really limited to the BDFL. The Django project seems to > benefit a lot from their fellows program [1], and in the recent grant > the PSF got for PyPI, everyone was *very* happy that we spent money on > a project manager [2]. (And at the risk of falling into megalomania > myself, I've also written about this recently [3].) > > So I don't have a specific proposal or anything, but maybe as part of > this discussion we should be exploring ways to get more dedicated time on > CPython, through company's donating time, or sponsoring people through > the PSF, or whatever makes sense. > I think that's a constant discussion to have which never really ends. People with more time to effectively contribute is always welcome. :) -Brett > > -n > > [1] > https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospective/ > [2] https://twitter.com/EWDurbin/status/968180960066928640 > [3] > https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open-source-infrastructure/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Fri Jul 20 18:58:34 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Fri, 20 Jul 2018 15:58:34 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: As quick refresher, my proposed timeline is: Oct 1: Deadline for people to come up with proposals of governance model, candidates, and how to vote Dec 1: Deadline to choose a governance model, (and if possible, we choose the new leader(s) too) Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1. Mariatta -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at gmail.com Fri Jul 20 19:25:40 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 20 Jul 2018 18:25:40 -0500 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: Thanks all. I am glad that Victor likes October 1. :-) So can we formalize the timeline proposed by Mariatta? On Fri, Jul 20, 2018, 5:58 PM Mariatta Wijaya wrote: > As quick refresher, my proposed timeline is: > > Oct 1: Deadline for people to come up with proposals of governance model, > candidates, and how to vote > Dec 1: Deadline to choose a governance model, (and if possible, we choose > the new leader(s) too) > Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec > 1. > > 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 brett at python.org Fri Jul 20 19:32:02 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 16:32:02 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: On Fri, 20 Jul 2018 at 16:25 Carol Willing wrote: > Thanks all. I am glad that Victor likes October 1. :-) > > So can we formalize the timeline proposed by Mariatta? > Fine by me. Everyone who cares to comment seems to agree that Oct 1 is good and I think the Dec 1 deadline is very reasonable. We might need to re-evaluate the Jan 1 date as we get closer, but I don't think we need to worry about that right now. -Brett > > On Fri, Jul 20, 2018, 5:58 PM Mariatta Wijaya > wrote: > >> As quick refresher, my proposed timeline is: >> >> Oct 1: Deadline for people to come up with proposals of governance model, >> candidates, and how to vote >> Dec 1: Deadline to choose a governance model, (and if possible, we choose >> the new leader(s) too) >> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec >> 1. >> >> 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 vstinner at redhat.com Fri Jul 20 20:02:39 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 21 Jul 2018 02:02:39 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: <20180720163201.GC8744@ando.pearwood.info> References: <5B513222.8020303@stoneleaf.us> <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info> Message-ID: 2018-07-20 18:32 GMT+02:00 Steven D'Aprano : > What happens when two trusted experts disagree and the voters don't have > the expertise to tell which one is correct? In my proposal, if no consensus can be found, the vote fails to reach the majority, the PEP is rejected. Usually, people disagree on on specific aspect of a PEP, not on the overall idea. This is where I propose to separate the decision in two votes: one vote for the "overall PEP" and one vote to decide between two variants (paint it blue or green?). > The sort of participatory democracy Victor and you seem to be talking > about doesn't scale beyond small communities where everyone knows > everyone else. That's why such participatory democracy worked in ancient > Greece, and continues to be used in (eg) Swiss canons, but beyond that > communities have moved to a representative democratic model. Hum, I'm not sure if it's revelant here, but in France, 44 855 000 people vote for the president every 5 years. If you want numbers, it seems like PHP has around 32 voters on RFC. I also expect a number around 30 for Python. I'm not talking about the total number of core developers (who can vote), but the number of core developers that I expect to vote on a single PEP. I expect that many cores will abstain from voting because they consider that it's not their interest area, they didn't have time to follow the discussion or they are "away from keyboard". > One factor that I don't think Victor has covered is that of what > percentage of core devs would have to vote for the result to be > accepted -- a quorum, or equivalent. My worst example for a vote would be the PEP 446 example that I used previously. In short, they were 3 people who cared: Charles-Fran?ois Natali, Guido van Rossum and me (the author). First, I would suggest that the authors are not allowed to vote on their own PEP. For the PEP 446, it means that there were only 2 voters. I propose to require at least 3 voters on a PEP. For the 50%+1 majority case, it means 2 "+1" votes are enough to approve a PEP on a total of 3 voters. On sensitive PEPs (the ones with 66%+1 majority), I propose to require at least 5 voters. If there are not enough voters, the vote is canceled and a new vote can be attempted later. I don't think that we will reach this minimum often. If it occurs, maybe we can extend the vote window and ask people to vote. > When it comes to *representative democracy* I believe that the > Australian model of mandatory voting (resulting in 90% turnouts or > higher) has many advantages over other systems. But for a technical > community like this, I don't know that mandatory voting is desirable. Wait. I'm against mandatory voting. First, it's common that people are away from their computer for good reasons like holidays. Second, I would strongly suggest core developers to abstain to vote if they didn't read the PEP (at least) or if they consider that they don't know enough to be able to have an opinion on a PEP. > (Perhaps if we have an Abstain option as well as Yes or No.) I propose to not account "vote: 0" and missing voters to account the majority. Ballot example: * Like (+1): 6 * Dislike (-1): 5 * Abstain: 1 If you account Abstain, 50%+1 majority means: (6+5+1)//2+1, at least 7 "like" votes are needed for the majority. If you ignore Abstain, 50%+1 majority means: (6+5)//2+1, at least 6 "like" votes are needed for the majority. IMHO 6 to win the vote makes more sense than 7. It becomes even more obvious if you account all core developers who didn't vote, it would look more like: * Like (+1): 6 * Dislike (-1): 5 * Abstain: 60 :-) > Personally, I'm not sure I'd even want to vote on every PEP that comes > up. (...) Me neither :-) As I wrote, I'm already ignoring some topics like typing and packaging. > Another issue we should consider: organised vote swapping. If votes are > public, as Victor suggests, that would allow people to do deals: "I'll > support your PEP for GOTO, if you support my PEP to deprecate tuples..." > sort of thing. There's a reason why most ballots are secret. I propose to make the vote public. I expect that some people who are not sure about their vote will check who already voted (and what were their vote) to help them to make a choice. After talking with friends, I realized that I forgot to explain something: my proposal doesn't change anything on the long discussion which occurs *before* the vote. IMHO most tractions occurs during these discussions, not during the vote. (I'm not sure of the word "traction": I mean the pressure to pull most people on your side.) By the way, I propose that the vote window will be "short": just 1 week. Maybe we should announce the date of the vote 1 week before, to make sure that people who care about the PEP will be available to vote. Let me explain why I prefer a short window with a counter example. If a vote remains open for 1 month, the discussion will likely continue during the vote, and people who voted early may want to change their vote. I'm not sure that it's a good thing that people are tempted to change their vote. Victor From njs at pobox.com Fri Jul 20 20:04:57 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 20 Jul 2018 17:04:57 -0700 Subject: [python-committers] An alternative governance model In-Reply-To: References: Message-ID: On Fri, Jul 20, 2018 at 3:50 PM, Brett Cannon wrote: > > > On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith wrote: >> >> On Fri, Jul 20, 2018, 08:58 Brett Cannon wrote: >> > While I'm purposefully staying out of this thread as my name is >> > currently so strongly associated with it and I don't want people thinking >> > I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% >> > time at Microsoft if I asked for it (I already get a day/week plus email >> > reading every day). >> >> Is that only if you were named BDFL, or do you think they might also >> support that if you were named "Chief PEP Herder", or "Member of the >> steering council",or similar? > > It isn't really title and more about workload/responsibility. So if the > title changed to "Chief PEP herder" but it was still on my shoulders to have > final say then I don't expect an issue as they would understand what that > means to me and my time. If I'm one of three on a council then I might still > get more time but I'm not as sure; it's definitely possible, but not as much > of a sure thing. If the group was 10 then probably not because that means I > am just one of about a quarter of all authors over the past year. Right, my point was more that "workload" and "authority" are related but not exactly the same :-). For example, if we ended up with a governance model in which final PEP acceptance is based on consensus or voting or something, then we wouldn't have a BDFL, but it still might be *very* helpful to have people with dedicated time to help shepherd PEPs through the process of building consensus, working out exactly what the points of disagreement were that needed to be voted on, mediating arguments that get out of hand, and so forth [1] -- that's what I was trying to handwave at with the "Chief PEP herder" title. > I think that's a constant discussion to have which never really ends. People with more time to effectively contribute is always welcome. :) Sure, but there is something special about this moment too :-). If we think that funding positions like these would make a significant difference to the viability of our community post-Guido, then now is a time when we could go to companies and say "look, Python is going through this critical transition, it needs this kind of funding to survive and thrive, can you help?", and see how they respond. I don't want to put you on the spot and I know you can't make promises on behalf of MS, so maybe I shouldn't have asked. But generally ? we have some evidence that companies might be willing to fund someone to be the BDFL. It'd be useful to know whether companies would also be willing to fund crucial community work even if it didn't mean they got to boast about having the BDFL on their payroll. -n [1] personally I suspect that python's survival is going to depend much more on whether we have people doing this kind of work, than on which specific formal governance structure we end up with -- Nathaniel J. Smith -- https://vorpus.org From vstinner at redhat.com Fri Jul 20 20:04:57 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 21 Jul 2018 02:04:57 +0200 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: 2018-07-21 0:58 GMT+02:00 Mariatta Wijaya : > Oct 1: Deadline for people to come up with proposals of governance model, > candidates, and how to vote > Dec 1: Deadline to choose a governance model, (and if possible, we choose > the new leader(s) too) What happens between October and December? People have 2 months to vote for their preferred governance? Why is the vote open for 2 months? Can't we vote in 2 weeks for example? I guess that "Deadline" means that we are allowed to agree on something earlier :-) In that case, I'm fine with that. Victor From brett at python.org Fri Jul 20 20:39:18 2018 From: brett at python.org (Brett Cannon) Date: Fri, 20 Jul 2018 17:39:18 -0700 Subject: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions In-Reply-To: References: <5B500BA5.5010802@stoneleaf.us> <5B501F5C.3090401@stoneleaf.us> <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org> <1532026123-sup-9946@lrrr.local> <53e93add-972b-2fe4-877d-e15552a86993@python.org> Message-ID: On Fri, 20 Jul 2018 at 17:05 Victor Stinner wrote: > 2018-07-21 0:58 GMT+02:00 Mariatta Wijaya : > > Oct 1: Deadline for people to come up with proposals of governance model, > > candidates, and how to vote > > Dec 1: Deadline to choose a governance model, (and if possible, we choose > > the new leader(s) too) > > What happens between October and December? People have 2 months to > vote for their preferred governance? > Why is the vote open for 2 > months? I think the plan would be to discuss what goes on the ballot and figuring out who will vote (based on our decision by Oct 1), and then voting would be open for the month of November). > Can't we vote in 2 weeks for example? > Because others have been worried that a short amount of time to vote for such a serious thing, especially if people happen to not be available. Or put another way, people want enough lead time to be sure they are available to vote and know to look for a voter email if they happen to be travelling for all of November (just like you don't want us to make you write up your governance proposal in August ;) . > > I guess that "Deadline" means that we are allowed to agree on > something earlier :-) In that case, I'm fine with that. > Maybe. As I said, some people have asked for a large lead time to know when a vote will happen to make themselves available so I'm not sure how much we may be able to bring it up. It's possible, but I don't think it's guaranteed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Jul 21 12:09:46 2018 From: brett at python.org (Brett Cannon) Date: Sat, 21 Jul 2018 09:09:46 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5B513222.8020303@stoneleaf.us> <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info> Message-ID: On Fri, Jul 20, 2018, 17:03 Victor Stinner, wrote: > 2018-07-20 18:32 GMT+02:00 Steven D'Aprano : > > What happens when two trusted experts disagree and the voters don't have > > the expertise to tell which one is correct? > > In my proposal, if no consensus can be found, the vote fails to reach > the majority, the PEP is rejected. > > Usually, people disagree on on specific aspect of a PEP, not on the > overall idea. This is where I propose to separate the decision in two > votes: one vote for the "overall PEP" and one vote to decide between > two variants (paint it blue or green?). > > > > The sort of participatory democracy Victor and you seem to be talking > > about doesn't scale beyond small communities where everyone knows > > everyone else. That's why such participatory democracy worked in ancient > > Greece, and continues to be used in (eg) Swiss canons, but beyond that > > communities have moved to a representative democratic model. > > Hum, I'm not sure if it's revelant here, but in France, 44 855 000 > people vote for the president every 5 years. > But that's for representation, not policy. California is actually a direct democracy through its proposition system. > If you want numbers, it seems like PHP has around 32 voters on RFC. I > also expect a number around 30 for Python. I'm not talking about the > total number of core developers (who can vote), but the number of core > developers that I expect to vote on a single PEP. I expect that many > cores will abstain from voting because they consider that it's not > their interest area, they didn't have time to follow the discussion or > they are "away from keyboard". > > > > One factor that I don't think Victor has covered is that of what > > percentage of core devs would have to vote for the result to be > > accepted -- a quorum, or equivalent. > > My worst example for a vote would be the PEP 446 example that I used > previously. In short, they were 3 people who cared: Charles-Fran?ois > Natali, Guido van Rossum and me (the author). > > First, I would suggest that the authors are not allowed to vote on > their own PEP. For the PEP 446, it means that there were only 2 > voters. > > I propose to require at least 3 voters on a PEP. For the 50%+1 > majority case, it means 2 "+1" votes are enough to approve a PEP on a > total of 3 voters. On sensitive PEPs (the ones with 66%+1 majority), I > propose to require at least 5 voters. If there are not enough voters, > the vote is canceled and a new vote can be attempted later. > Who decides what's a sensitive PEP? -Brett > I don't think that we will reach this minimum often. If it occurs, > maybe we can extend the vote window and ask people to vote. > > > > When it comes to *representative democracy* I believe that the > > Australian model of mandatory voting (resulting in 90% turnouts or > > higher) has many advantages over other systems. But for a technical > > community like this, I don't know that mandatory voting is desirable. > > Wait. I'm against mandatory voting. > > First, it's common that people are away from their computer for good > reasons like holidays. > > Second, I would strongly suggest core developers to abstain to vote if > they didn't read the PEP (at least) or if they consider that they > don't know enough to be able to have an opinion on a PEP. > > > > (Perhaps if we have an Abstain option as well as Yes or No.) > > I propose to not account "vote: 0" and missing voters to account the > majority. > > Ballot example: > > * Like (+1): 6 > * Dislike (-1): 5 > * Abstain: 1 > > If you account Abstain, 50%+1 majority means: (6+5+1)//2+1, at least 7 > "like" votes are needed for the majority. > > If you ignore Abstain, 50%+1 majority means: (6+5)//2+1, at least 6 > "like" votes are needed for the majority. > > IMHO 6 to win the vote makes more sense than 7. It becomes even more > obvious if you account all core developers who didn't vote, it would > look more like: > > * Like (+1): 6 > * Dislike (-1): 5 > * Abstain: 60 > > :-) > > > > Personally, I'm not sure I'd even want to vote on every PEP that comes > > up. (...) > > Me neither :-) As I wrote, I'm already ignoring some topics like > typing and packaging. > > > > Another issue we should consider: organised vote swapping. If votes are > > public, as Victor suggests, that would allow people to do deals: "I'll > > support your PEP for GOTO, if you support my PEP to deprecate tuples..." > > sort of thing. There's a reason why most ballots are secret. > > I propose to make the vote public. I expect that some people who are > not sure about their vote will check who already voted (and what were > their vote) to help them to make a choice. > > After talking with friends, I realized that I forgot to explain > something: my proposal doesn't change anything on the long discussion > which occurs *before* the vote. IMHO most tractions occurs during > these discussions, not during the vote. (I'm not sure of the word > "traction": I mean the pressure to pull most people on your side.) > > By the way, I propose that the vote window will be "short": just 1 week. > > Maybe we should announce the date of the vote 1 week before, to make > sure that people who care about the PEP will be available to vote. > > Let me explain why I prefer a short window with a counter example. If > a vote remains open for 1 month, the discussion will likely continue > during the vote, and people who voted early may want to change their > vote. I'm not sure that it's a good thing that people are tempted to > change their vote. > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Sun Jul 22 12:22:14 2018 From: antoine at python.org (Antoine Pitrou) Date: Sun, 22 Jul 2018 18:22:14 +0200 Subject: [python-committers] "small" communities In-Reply-To: <20180720163201.GC8744@ando.pearwood.info> References: <5B513222.8020303@stoneleaf.us> <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info> Message-ID: Le 20/07/2018 ? 18:32, Steven D'Aprano a ?crit?: > > The sort of participatory democracy Victor and you seem to be talking > about doesn't scale beyond small communities where everyone knows > everyone else. That's why such participatory democracy worked in ancient > Greece, and continues to be used in (eg) Swiss canons, but beyond that > communities have moved to a representative democratic model. It is commonly estimated that there were between 30000 and 60000 citizens in ancient Athens, and that 6000 of them could physically take part in assembly sessions. That's small compared to modern Nation States, but that's *much* larger than the team of Python core developers. Regards Antoine. From antoine at python.org Mon Jul 23 04:10:51 2018 From: antoine at python.org (Antoine Pitrou) Date: Mon, 23 Jul 2018 10:10:51 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: Le 20/07/2018 ? 23:14, Brett Cannon a ?crit?: > > Steve pointed out in his reply about how this might increase load as > people will have to start trying to get people on side to vote the way > they want. In US politics this is done by someone called a /whip/ who > "whips up" votes for a bill. With 91 (or more if people start to come > back to use their commit rights who have not added their GitHub > usernames) of us getting grandfathered into this, people will be > somewhat political in getting votes for or against PEPs they care about > since only people post-Guido would be made core devs knowing they now > have a vote on PEPs and thus take that into consideration when adding > new members to the team. That's an interesting point, but do you have any evidence of such phenomena in other open source projects? Just because something happens in US politics doesn't mean it's likely to happen in a technical project populated with volunteers. Regards Antoine. From brett at python.org Mon Jul 23 10:37:54 2018 From: brett at python.org (Brett Cannon) Date: Mon, 23 Jul 2018 07:37:54 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: On Mon, Jul 23, 2018, 01:11 Antoine Pitrou, wrote: > > Le 20/07/2018 ? 23:14, Brett Cannon a ?crit : > > > > Steve pointed out in his reply about how this might increase load as > > people will have to start trying to get people on side to vote the way > > they want. In US politics this is done by someone called a /whip/ who > > "whips up" votes for a bill. With 91 (or more if people start to come > > back to use their commit rights who have not added their GitHub > > usernames) of us getting grandfathered into this, people will be > > somewhat political in getting votes for or against PEPs they care about > > since only people post-Guido would be made core devs knowing they now > > have a vote on PEPs and thus take that into consideration when adding > > new members to the team. > > That's an interesting point, but do you have any evidence of such > phenomena in other open source projects? Just because something happens > in US politics doesn't mean it's likely to happen in a technical project > populated with volunteers. > Nope, no evidence (but I suspect most of what any of us are suggesting has something we can directly compare against ?). This is just a potential worry of mine. -Brett > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Tue Jul 24 10:46:20 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 25 Jul 2018 00:46:20 +1000 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io> References: <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io> Message-ID: On 21 July 2018 at 04:30, Donald Stufft wrote: > > On Jul 19, 2018, at 7:47 PM, Victor Stinner wrote: > > It seems that the main question for a new governance is how to take a > decision on PEPs (accept or reject them with some variants like > Deferred). I read that core developers are unable to make a decision > themselves (fail to reach a consensus) and that letting core > developers decide would make Python "inconsistent" (as if only a > single BDFL is able to keep Python consistent). I also read that the > BDFL is required to make unpopular decisions to enhance Python. > > > I think the core difference behind all of the proposals, when you get down > to > brass tacks, will be the vision for where the langauge goes. There are > independently good ideas that maybe should not be accepted, because they > compromise the vision for the worse, or ideas that seem poor on the tin but > that > once they get added they mesh well with the overall language. > > The further you scale up the number of people directly deciding the > direction > of the language, the more likely you will find inconsistency. No two people > have > the same design sense, and so if you ask two people you're likely to get at > least two answers. One of the things that puzzles me about the "Who will set the direction of the language if Guido doesn't do it?" concern is that from my perspective, this is something that Guido mostly *didn't* do (and I'm OK with that). Python has never had a clear road map in the 15+ years I've been part of the core development community - it's just had assorted projects that different individuals have driven to varying levels of completion based on the strength of their convictions about the topic, and the time they've had available to devote to driving it (along with a few "definitely not" issues written down in the form of rejected PEPs). The projects that Guido has been directly involved in driving have been more ambitious in scope than most other folks would be prepared to pursue (e.g. Py3k, asyncio, type hinting), but there have been significant changes he accepted that were originated by others (such as f-strings and assignment expressions), as well as significant topics where he largely delegated decision making to others (such as Unicode handling, project dependency management, the import system, and scientific computing). If I were to write an article like https://www.curiousefficiency.org/posts/2011/08/of-python-and-road-maps-or-lack-thereof.html today, the specific topics I'd mention would be different, but the overall tone would be similar. And I think that's inevitable in an environment driven primarily by volunteer and sponsored development: the time to pursue particular activities has to come from somewhere, and that's either going to be the intrinsic motivations of individuals donating their own time, or else the extrinsic motivation of folks pursuing paid problem solving on behalf of an organisation. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Tue Jul 24 11:20:38 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 25 Jul 2018 01:20:38 +1000 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: On 21 July 2018 at 07:14, Brett Cannon wrote: > On Thu, 19 Jul 2018 at 16:47 Victor Stinner wrote: >> What is the image sent to contributors if we create a subgroup inside >> core developpers called "council"? What if we elect a new BDFL *for >> life*? Does it mean that even core developers judgment are no longer >> trusted, only the council decision matters? What about people outside >> in the insider group of cores... regular contributors? Will anyone >> still listen to them? >> >> I'm not saying that a new governance will lead to such issues. I'm >> only opening the question of the image sent to the community. > > > This will also make it harder to become a core developer. In the past we > have been willing to give people commit privileges for showing they know how > to code to our standards, make decisions when it came to PRs, and knew when > they were outside of their depth (e.g. giving someone commit privileges to > work on Python code but not C). We've also given commit privileges away like > candy to people who have attended sprints in the past, so we have not even > held up that level of requirement for all of Python's history. > > Now we're being asked to also trust someone's design acumen as they will be > voting on PEPs. Up until this point I didn't have to worry about whether > every core dev would take the language in a direction I disagreed with > because they simply didn't have the authority to; it rested with Guido. This > proposed change, though, means I now have to judge all core developers not > just on whether I can trust them to code appropriately but whether I think > they would vote on PEPs that I agree with. That would mean I wouldn't have > voted to give Pablo commit privileges because I simply do not know his > contributions well enough to know if he would make decisions in a way I'm > personally in favour of. I'd share Brett's concern about our being careful in changing the responsibilities of what it means to be a core developer - we're already pretty slow and cautious when it comes to promoting people and encouraging them to find their own comfort level with their new privileges and responsibilities, and so we should be wary of making that learning curve even steeper than it already is. By contrast, I think that adding more explicit responsibility levels beyond the initial step of becoming a core developer has the potential to help us avoid some of the pitfalls described decades ago in Jo Freeman's excellent discussion on the "Tyranny of Structurelessness": https://www.jofreeman.com/joreen/tyranny.htm It's already the case that we have differing levels of influence amongst the core development team - they're just currently acquired through years of personal interactions, both positive and negative, and thus I'd expect them to mainly correlate with "available time" (to increase the number of opportunities for positive interactions), "self-restraint" (to reduce the frequency of negative interactions), and "freedom to travel" (to provide more opportunities to meet people in person and increase trust levels that way). While those aspects of community influence and leadership are never going to go away, we have an opportunity now to set up a model that allows folks to ask themselves if they're interested in pursuing a more visible role not only amongst the core development team, but also in representing the core development team to the outside world (whether that's through day-to-day participation in python-dev and python-ideas, through presentations and personal articles, or through being a point of contact for media enquiries). Similar to the way PSF Board elections work, folks offering to serve in this role could be elected via Approval voting amongst the core developers, using the same Helios platform as the Board elections. That way even if we do decide that it still makes sense to have a Chief Shrubbery Tender (with or without obscure English comedy references in their role title), we can also build succession planning into the system by which we appoint them, by ensuring that more folks than just the primary designated spokesperson are gaining community visibility. Cheers, Nick. P.S. The Chief Shrubbery Tender suggestion isn't entirely in jest. In addition to being a Monty Python reference, it also ties in to a community management discussion that was rumbling along in the background (e.g. [1]) when I was still working for Red Hat: the upstream/downstream analogy that Linux distributions have long used to describe the way that open source software flows into their systems and then on to downstream rebuilds has a lot of problems, one of the most notable of which is that open source communities tend to require a lot more tending than oceans, rain clouds and natural springs do. While it doesn't look like the potential replacement analogies were ever fully elaborated in a public venue (at least, not that I can find), [2] touches on the one that seemed most compelling: building and maintaining a successful open source community is a lot like tending a garden, where the key activities are things like keeping weeds away and helping to provide water and appropriate amounts of sunlight, rather than trying to tell the individual plants how to grow leaves and flowers :) [1] http://community.redhat.com/blog/2017/05/let-the-river-flow/ [2] https://community.redhat.com/blog/2017/05/seeds-of-community/ -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at python.org Tue Jul 24 12:12:44 2018 From: brett at python.org (Brett Cannon) Date: Tue, 24 Jul 2018 09:12:44 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io> Message-ID: On Tue, 24 Jul 2018 at 07:46 Nick Coghlan wrote: > On 21 July 2018 at 04:30, Donald Stufft wrote: > > > > On Jul 19, 2018, at 7:47 PM, Victor Stinner wrote: > > > > It seems that the main question for a new governance is how to take a > > decision on PEPs (accept or reject them with some variants like > > Deferred). I read that core developers are unable to make a decision > > themselves (fail to reach a consensus) and that letting core > > developers decide would make Python "inconsistent" (as if only a > > single BDFL is able to keep Python consistent). I also read that the > > BDFL is required to make unpopular decisions to enhance Python. > > > > > > I think the core difference behind all of the proposals, when you get > down > > to > > brass tacks, will be the vision for where the langauge goes. There are > > independently good ideas that maybe should not be accepted, because they > > compromise the vision for the worse, or ideas that seem poor on the tin > but > > that > > once they get added they mesh well with the overall language. > > > > The further you scale up the number of people directly deciding the > > direction > > of the language, the more likely you will find inconsistency. No two > people > > have > > the same design sense, and so if you ask two people you're likely to get > at > > least two answers. > > One of the things that puzzles me about the "Who will set the > direction of the language if Guido doesn't do it?" concern is that > from my perspective, this is something that Guido mostly *didn't* do > (and I'm OK with that). Python has never had a clear road map in the > 15+ years I've been part of the core development community - it's just > had assorted projects that different individuals have driven to > varying levels of completion based on the strength of their > convictions about the topic, and the time they've had available to > devote to driving it (along with a few "definitely not" issues written > down in the form of rejected PEPs). > > The projects that Guido has been directly involved in driving have > been more ambitious in scope than most other folks would be prepared > to pursue (e.g. Py3k, asyncio, type hinting), but there have been > significant changes he accepted that were originated by others (such > as f-strings and assignment expressions), as well as significant > topics where he largely delegated decision making to others (such as > Unicode handling, project dependency management, the import system, > and scientific computing). > > If I were to write an article like > > https://www.curiousefficiency.org/posts/2011/08/of-python-and-road-maps-or-lack-thereof.html > today, the specific topics I'd mention would be different, but the > overall tone would be similar. > So I think if you replaced "direction" with "tone" in your opening phrase then that would encompass what a lot of people are worried about. It isn't necessarily about a roadmap (which we obviously have never had written down ;) , but Guido did set a tone for the language overall which he kept in his head and worked towards through thought and instinct. But Guido has done directional things like saying the removal of the GIL would be acceptable if single-threaded performance was kept, even potentially at the cost of a bit of the C API. So while we have never laid out explicit plans for the next 1, 5, or 10 years, I think there has been guidance and an implicit direction of where the language should be headed. -Brett > > And I think that's inevitable in an environment driven primarily by > volunteer and sponsored development: the time to pursue particular > activities has to come from somewhere, and that's either going to be > the intrinsic motivations of individuals donating their own time, or > else the extrinsic motivation of folks pursuing paid problem solving > on behalf of an organisation. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Tue Jul 24 19:50:37 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 25 Jul 2018 01:50:37 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: Brett: > This will also make it harder to become a core developer. In the past we > have been willing to give people commit privileges for showing they know how > to code to our standards, make decisions when it came to PRs, and knew when > they were outside of their depth (e.g. giving someone commit privileges to > work on Python code but not C). We've also given commit privileges away like > candy to people who have attended sprints in the past, so we have not even > held up that level of requirement for all of Python's history. I don't think that giving core dev priviledge just if you attend a sprint is a good practice :-) Maybe we did that in the past, but it seems like nowadays the process is more formalized and stricter. Some people wrote that they are "100+" core developers. If everyone vote on each PEP, one additional core dev just has 1 vote on 101 voters. I don't see any pressure here. > Now we're being asked to also trust someone's design acumen as they will be > voting on PEPs. Up until this point I didn't have to worry about whether > every core dev would take the language in a direction I disagreed with > because they simply didn't have the authority to; it rested with Guido. This > proposed change, though, means I now have to judge all core developers not > just on whether I can trust them to code appropriately but whether I think > they would vote on PEPs that I agree with. That would mean I wouldn't have > voted to give Pablo commit privileges because I simply do not know his > contributions well enough to know if he would make decisions in a way I'm > personally in favour of. IMHO it's ok if people make mistakes on voting if we are enough voters. Making mistakes is part of the learning process. If the vote results are public during the vote, if a voter "does a mistake", you are free to lobby to vote against this mistake to guide people to the right choice :-) Again, I expect that the discussion before a vote will already highlight the popular opinions. The vote result shouldn't be a surprise for anyone if the discussion goes well. Honestly, in many cases, I just follow the expert that I trust, when I'm unable to have my own opinion on a PEP. Victor From antoine at python.org Wed Jul 25 04:39:02 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 25 Jul 2018 10:39:02 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: <7cc59ce4-ccf3-428b-bded-5fadbbeb79c4@python.org> Le 25/07/2018 ? 01:50, Victor Stinner a ?crit?: > Brett: >> This will also make it harder to become a core developer. In the past we >> have been willing to give people commit privileges for showing they know how >> to code to our standards, make decisions when it came to PRs, and knew when >> they were outside of their depth (e.g. giving someone commit privileges to >> work on Python code but not C). We've also given commit privileges away like >> candy to people who have attended sprints in the past, so we have not even >> held up that level of requirement for all of Python's history. > > I don't think that giving core dev priviledge just if you attend a > sprint is a good practice :-) Maybe we did that in the past, but it > seems like nowadays the process is more formalized and stricter. It seems at some point it was believed that giving commit rights early would boost participation. Now we know that doesn't work. Regards Antoine. From brett at python.org Wed Jul 25 14:01:59 2018 From: brett at python.org (Brett Cannon) Date: Wed, 25 Jul 2018 11:01:59 -0700 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: On Tue, 24 Jul 2018 at 16:51 Victor Stinner wrote: > Brett: > > This will also make it harder to become a core developer. In the past we > > have been willing to give people commit privileges for showing they know > how > > to code to our standards, make decisions when it came to PRs, and knew > when > > they were outside of their depth (e.g. giving someone commit privileges > to > > work on Python code but not C). We've also given commit privileges away > like > > candy to people who have attended sprints in the past, so we have not > even > > held up that level of requirement for all of Python's history. > > I don't think that giving core dev priviledge just if you attend a > sprint is a good practice :-) It isn't now, but it was what we thought made sense at the time. Remember the team used to be quite a bit smaller. :) > Maybe we did that in the past, but it > seems like nowadays the process is more formalized and stricter. > Yes. > > Some people wrote that they are "100+" core developers. If everyone > vote on each PEP, one additional core dev just has 1 vote on 101 > voters. I don't see any pressure here. > There has been more than one person who has joined the core team since I did. ;) From my perspective this isn't about the next person, but the next 10, 20, or 50 people who will heavily influence the outcome of a vote. Remember, we are measuring time in decades here. > > > Now we're being asked to also trust someone's design acumen as they will > be > > voting on PEPs. Up until this point I didn't have to worry about whether > > every core dev would take the language in a direction I disagreed with > > because they simply didn't have the authority to; it rested with Guido. > This > > proposed change, though, means I now have to judge all core developers > not > > just on whether I can trust them to code appropriately but whether I > think > > they would vote on PEPs that I agree with. That would mean I wouldn't > have > > voted to give Pablo commit privileges because I simply do not know his > > contributions well enough to know if he would make decisions in a way I'm > > personally in favour of. > > IMHO it's ok if people make mistakes on voting if we are enough > voters. Making mistakes is part of the learning process. > I would rather we didn't learn on language changes we will be living with for decades if we can help it. ;) > > If the vote results are public during the vote, if a voter "does a > mistake", you are free to lobby to vote against this mistake to guide > people to the right choice :-) > I don't think any of us want to lobby against how an individual already voted. That seems like scare tactics against individuals. > > Again, I expect that the discussion before a vote will already > highlight the popular opinions. The vote result shouldn't be a > surprise for anyone if the discussion goes well. > Right, and your proposal means I now have to judge proposed core developers on which side of popular opinion they will come down on in hopes that they vote in ways I agree with and thus help take the language in a direction I think is appropriate. My point isn't about being surprised in an outcome. My point is it will shift how we judge people becoming core devs and the barrier to join will go up. So unless there's reasonable expectation of an increase in participants in the project due to a governance shift like this then we would need to be ready for having slower team growth if this is the governance model that is chosen. > > Honestly, in many cases, I just follow the expert that I trust, when > I'm unable to have my own opinion on a PEP. > Sure, and that's you. But that doesn't mean the 90 other people think that way. ;) And that's my point: I now have to find out how people will think going forward in language design and screen future core devs on this new, extra criteria. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed Jul 25 19:21:56 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 25 Jul 2018 19:21:56 -0400 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: > On Jul 25, 2018, at 2:01 PM, Brett Cannon wrote: > > Right, and your proposal means I now have to judge proposed core developers on which side of popular opinion they will come down on in hopes that they vote in ways I agree with and thus help take the language in a direction I think is appropriate. It makes me think a bit of the US Supreme Court, where judges who might someday want to be on that court, learn to be very careful about hiding their true opinions (without directly lying of course) on a number of very controversial topics, knowing that coming out for/against them is likely to blow up their changes of ever progressing to that point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Wed Jul 25 19:29:28 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 26 Jul 2018 01:29:28 +0200 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: <2e33162f-c8f9-1aeb-3255-b08c670944a7@python.org> Le 26/07/2018 ? 01:21, Donald Stufft a ?crit?: > >> On Jul 25, 2018, at 2:01 PM, Brett Cannon > > wrote: >> >> Right, and your proposal means I now have to judge proposed core >> developers on which side of popular opinion they will come down on in >> hopes that they vote in ways I agree with and thus help take the >> language in a direction I think is appropriate. > > It makes me think a bit of the US Supreme Court, where judges who might > someday want to be on that court, learn to be very careful about hiding > their true opinions (without directly lying of course) on a number of > very controversial topics, knowing that coming out for/against them is > likely to blow up their changes of ever progressing to that point. You know, I'm sure that's already the case in the Python community, on topics such as diversity policies, CoCs and the like. Regards Antoine. From alex.gaynor at gmail.com Wed Jul 25 19:34:28 2018 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 25 Jul 2018 19:34:28 -0400 Subject: [python-committers] And Now for Something Completely Different In-Reply-To: References: Message-ID: On Wed, Jul 25, 2018 at 7:24 PM Donald Stufft wrote: > > > On Jul 25, 2018, at 2:01 PM, Brett Cannon wrote: > > Right, and your proposal means I now have to judge proposed core > developers on which side of popular opinion they will come down on in hopes > that they vote in ways I agree with and thus help take the language in a > direction I think is appropriate. > > > It makes me think a bit of the US Supreme Court, where judges who might > someday want to be on that court, learn to be very careful about hiding > their true opinions (without directly lying of course) on a number of very > controversial topics, knowing that coming out for/against them is likely to > blow up their changes of ever progressing to that point. > _______________________________________________ > 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/ > (I've been quite on this thread thus far, just soaking everything else up, but this side note about SCOTUS made me want to share this potentially relevant observation/nerdery.) Recent trends in Supreme Court nominees increasingly have justices coming from the DC Circuit [0]. The reason for this (IMO) is that the DC Circuit deals very heavily in parts of the law that only lawyers care about -- primarily administrative law and suits against the federal government. They see almost no cases dealing with social issues. As a result, nominees tend to have records without cases that will generate significant controversy amongst the public (while still being able to demonstrate their judicial philosophy to folks who understand such things). The analogy in the Python-verse might be inviting a new core developer for their work on runtime internals, but then having the ability to sway stdlib design once they become a core dev. This type of system stands in contrast with the one the Rust community has, where they have dedicated teams, which people are members of (some people are members of many), and they define the scope of the team's responsibility/authority. So you can be a member of the compilers team, with no say over how the community team functions. Hope everyone enjoyed my Supreme Court nerdery, Alex [0]: Chief Justice Roberts, Justice Ginsburg, Justice Thomas, Judge Garland, and Judge Kavanaugh. -- All that is necessary for evil to succeed is for good people to do nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Fri Jul 27 12:02:32 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Fri, 27 Jul 2018 09:02:32 -0700 Subject: [python-committers] Mentoring Office Hours - the idea, and a question In-Reply-To: References: Message-ID: I've started a PR in the devguide adding the office hours of core devs that I know of. https://github.com/python/devguide/pull/402 Please add your own office hours in there, or create new PRs. I think we can leave it to each core devs of how they want to do their office hour. For myself, a fixed weekly schedule works for me, but others might have more flexible schedule. Mariatta On Thu, Jun 14, 2018 at 4:58 PM Mariatta Wijaya wrote: > Thanks for starting this, Brian. > > As such, it needs a person/persons/list to contact should something arise >> in this context that needs to be handled. What/who should that be? > > * Suggestion 2: Create some new list with a few key people on it. >> * Suggestion 3: List some direct names. Who? > > > I personally prefer knowing names. If it will be a mailing list, I'd like > to know who are in the mailing list. > > Related, I believe there is a new Code of Conduct working group within the > PSF, but I don't know what is the scope of that working group. > https://mail.python.org/pipermail/psf-community/2018-April/000488.html > > Perhaps to start it could just be some of us who wants to volunteer and do > it? > > I can set aside 1 hr each week Thursday as my office hours, between 7 PM - > 8 PM Pacific. > > > > Mariatta > > On Wed, May 16, 2018 at 3:08 PM, Victor Stinner > wrote: > >> 2018-05-16 11:31 GMT-04:00 Victor Stinner : >> > I'm usually available between 10:00 and 16:00 in the French timezone >> > (currently, it's CEST = UTC+2). >> >> Oh, let me be more specific: >> >> 10:00-12:00 and 14:00-16:00, Monday to Friday >> >> Yeah, in France we take our time to eat ;-) >> >> Victor >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Tue Jul 31 06:27:09 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 31 Jul 2018 12:27:09 +0200 Subject: [python-committers] Results of Pablo's promotion votes: Pablo is promoted as a core dev! In-Reply-To: References: Message-ID: Hi, 2018-06-19 19:43 GMT+02:00 Victor Stinner : > The result of the vote to to promote Pablo Salingo Salgado as core developer > after one week is positive: I declare that Pablo is now a core developer, > congrats! (...) > > Giving more responsibilities to Pablo is part of the learning process. > Reviewing as a core developer is different than a review as a contributor: core > developers are expected to actually merge a pull request once they approve the > change. Merging a pull request is a big responsibility and an investment in > the long-term, because the committer is expected to fix regressions and issues > related to this change for next months, if not next years. Sadly, I was less available than I expected to review his work, and so I don't feel comfortable yet to stop mentoring. I asked Pablo and he is fine if I extend the mentoring to the end of September. I expect that one extra month should be enough, but I will be in holiday most of August ;-) Victor From brett at python.org Tue Jul 31 12:47:26 2018 From: brett at python.org (Brett Cannon) Date: Tue, 31 Jul 2018 09:47:26 -0700 Subject: [python-committers] Results of Pablo's promotion votes: Pablo is promoted as a core dev! In-Reply-To: References: Message-ID: On Tue, 31 Jul 2018 at 03:27 Victor Stinner wrote: > Hi, > > 2018-06-19 19:43 GMT+02:00 Victor Stinner : > > The result of the vote to to promote Pablo Salingo Salgado as core > developer > > after one week is positive: I declare that Pablo is now a core developer, > > congrats! (...) > > > > Giving more responsibilities to Pablo is part of the learning process. > > Reviewing as a core developer is different than a review as a > contributor: core > > developers are expected to actually merge a pull request once they > approve the > > change. Merging a pull request is a big responsibility and an investment > in > > the long-term, because the committer is expected to fix regressions and > issues > > related to this change for next months, if not next years. > > Sadly, I was less available than I expected to review his work, and so > I don't feel comfortable yet to stop mentoring. > > I asked Pablo and he is fine if I extend the mentoring to the end of > September. I expect that one extra month should be enough, but I will > be in holiday most of August ;-) > I just wanted to say thanks for thinking about this to begin with. It's very easy to set a new core dev loose and forget what it takes to get up and running. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Tue Jul 31 12:56:25 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 31 Jul 2018 18:56:25 +0200 Subject: [python-committers] Results of Pablo's promotion votes: Pablo is promoted as a core dev! In-Reply-To: References: Message-ID: 2018-07-31 18:47 GMT+02:00 Brett Cannon : > I just wanted to say thanks for thinking about this to begin with. It's very > easy to set a new core dev loose and forget what it takes to get up and > running. I like the idea of putting one mentor per newly promoted core developer. IMHO it reduces the pressure to promote a contributor. Victor