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: <CALFfu7BzbHjhhFHO-o1vnwcmwV7i6P12fued=5xTHymiyL3HbA@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
 <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>
 <CAF4280KDHLJDL_x2gY75uMOmpCAzegOEyBXQFc74jt4PD3zYkA@mail.gmail.com>
 <CAPJVwBn9XAMr3niHmyVdHsYRPKuNerR4OAXfEfUktw6_LEjE5A@mail.gmail.com>
 <CALFfu7BzbHjhhFHO-o1vnwcmwV7i6P12fued=5xTHymiyL3HbA@mail.gmail.com>
Message-ID: <CALWZvp6bYFfvWnOjOhWdmt1dT40G5S6S7PR9shrtr+a2tXyAgg@mail.gmail.com>

On Sat, Jun 16, 2018 at 1:37 AM, Eric Snow <ericsnowcurrently at gmail.com> 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: <CAP7+vJLDLYsLsU+Jx_ceh=jpwQcOS65wBvBb9PtBKpYdes7y0g@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180706/b371f98c/attachment.html>

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: <eec06d76-c1cf-445b-be4c-e577a90963ea@hastings.org>



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: <http://mail.python.org/pipermail/python-committers/attachments/20180708/054b2b93/attachment.html>

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: <eec06d76-c1cf-445b-be4c-e577a90963ea@hastings.org>
References: <eec06d76-c1cf-445b-be4c-e577a90963ea@hastings.org>
Message-ID: <phsi1i$vd8$1@blaine.gmane.org>

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: <phsi1i$vd8$1@blaine.gmane.org>
References: <eec06d76-c1cf-445b-be4c-e577a90963ea@hastings.org>
 <phsi1i$vd8$1@blaine.gmane.org>
Message-ID: <e7623314-466c-04eb-ebac-01507d487c6f@hastings.org>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180708/c4532ca4/attachment.html>

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: <e7623314-466c-04eb-ebac-01507d487c6f@hastings.org>
References: <eec06d76-c1cf-445b-be4c-e577a90963ea@hastings.org>
 <phsi1i$vd8$1@blaine.gmane.org>
 <e7623314-466c-04eb-ebac-01507d487c6f@hastings.org>
Message-ID: <phtesn$27j$1@blaine.gmane.org>

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: <phtesn$27j$1@blaine.gmane.org>
References: <eec06d76-c1cf-445b-be4c-e577a90963ea@hastings.org>
 <phsi1i$vd8$1@blaine.gmane.org>
 <e7623314-466c-04eb-ebac-01507d487c6f@hastings.org>
 <phtesn$27j$1@blaine.gmane.org>
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: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
Message-ID: <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>

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 <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180711/67cafdf8/attachment.html>

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: <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
 <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
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: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
 <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
 <5B463EED.7010409@stoneleaf.us>
Message-ID: <CAP1=2W7vSJBPtSjBbV+WAdoMWxk3nE2io72ttcGph-_y0xEV6g@mail.gmail.com>

On Wed, 11 Jul 2018 at 10:31 Ethan Furman <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180711/45c91920/attachment.html>

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: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
 <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
 <5B463EED.7010409@stoneleaf.us>
Message-ID: <CAP7+vJ+DW_X5PhkXQ+1Q3L1Sh=Z0hYg28nvGk9pjgAspGYiu+A@mail.gmail.com>

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 <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180711/76f61590/attachment.html>

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: <CAP7+vJ+DW_X5PhkXQ+1Q3L1Sh=Z0hYg28nvGk9pjgAspGYiu+A@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
 <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
 <5B463EED.7010409@stoneleaf.us>
 <CAP7+vJ+DW_X5PhkXQ+1Q3L1Sh=Z0hYg28nvGk9pjgAspGYiu+A@mail.gmail.com>
Message-ID: <CAGbohnYzLyDPbC0ZPdx0rqpjuud-jjve_O3OuZbiOntQVGF1LQ@mail.gmail.com>

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 <guido at python.org> 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 <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180711/56569705/attachment-0001.html>

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: <CAGbohnYzLyDPbC0ZPdx0rqpjuud-jjve_O3OuZbiOntQVGF1LQ@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
 <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
 <5B463EED.7010409@stoneleaf.us>
 <CAP7+vJ+DW_X5PhkXQ+1Q3L1Sh=Z0hYg28nvGk9pjgAspGYiu+A@mail.gmail.com>
 <CAGbohnYzLyDPbC0ZPdx0rqpjuud-jjve_O3OuZbiOntQVGF1LQ@mail.gmail.com>
Message-ID: <CAP1=2W51_LOPVz6Z7VzcgrgDdxRoswRkBeY2pVB-ZSnBXEXWeg@mail.gmail.com>

I just renamed the stream so there's now just a single #. :)

On Wed, 11 Jul 2018 at 11:22 Mariatta Wijaya <mariatta.wijaya at gmail.com>
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 <guido at python.org>
> 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 <ethan at stoneleaf.us>
>> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180711/a963622d/attachment.html>

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: <CAGbohnYzLyDPbC0ZPdx0rqpjuud-jjve_O3OuZbiOntQVGF1LQ@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
 <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>
 <CAGbohnZCdyTp0hibOZbzX5Pg2wB8Xibm2TgmgP_eZ=DMVwfd7Q@mail.gmail.com>
 <5B463EED.7010409@stoneleaf.us>
 <CAP7+vJ+DW_X5PhkXQ+1Q3L1Sh=Z0hYg28nvGk9pjgAspGYiu+A@mail.gmail.com>
 <CAGbohnYzLyDPbC0ZPdx0rqpjuud-jjve_O3OuZbiOntQVGF1LQ@mail.gmail.com>
Message-ID: <CAP7+vJK=gVhGO3-DO7HFrqxmLLz_Z75XNcOgTPxb762BkU5ydA@mail.gmail.com>

On Wed, Jul 11, 2018 at 11:22 AM, Mariatta Wijaya <mariatta.wijaya at gmail.com
> 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 <guido at python.org>
> 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 <ethan at stoneleaf.us>
>> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180711/67b21da1/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/30a41d64/attachment-0001.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CA+3bQGHmje_1jUV6G83DPfD+NmNkB-OUpDS1dXZZ06iVYbhgyQ@mail.gmail.com>

Hi,

2018-07-12 16:57 GMT+02:00 Guido van Rossum <guido at python.org>:
> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <b9895fdd-4277-285c-9d2e-bf45768b56d5@hotpy.org>



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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org>
Message-ID: <baf0902d-d6e1-d2a4-d6e8-2877b098b5bc@hotpy.org>



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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>

On Thu, 12 Jul 2018 at 07:58 Guido van Rossum <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/055e3b90/attachment-0001.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CANiivoruykNc0tV=fQ8GBpvt0TE8H8Bh46GLOqJU2J4r6MPg8g@mail.gmail.com>

On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/282a226e/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>

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 <guido at python.org> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAF7AXFEfTmAawMMrFoUOmS0mr5dp29TiGnFsT287oVyLDrPTWQ@mail.gmail.com>

On Thu, Jul 12, 2018 at 7:57 AM, Guido van Rossum <guido at python.org> 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: <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
Message-ID: <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>


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 <guido at python.org
> <mailto:guido at python.org>> 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 <http://python.org/~guido>)
>     _______________________________________________
>     python-committers mailing list
>     python-committers at python.org <mailto: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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAGbohnbBFN1YohSazgDF_WkyQ1gsnnuWqebrrQy-FnwvrZRoKA@mail.gmail.com>

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 <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/79de2e02/attachment.html>

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: <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <8335669F-EF8C-4AE1-9A51-3D01D81C7F18@gmail.com>



> On Jul 12, 2018, at 4:57 PM, Guido van Rossum <guido at python.org> 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: <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
Message-ID: <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>

On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou <antoine at python.org> 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: <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
Message-ID: <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>

On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov <yselivanov.ml at gmail.com> 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: <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
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 <antoine at python.org> 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: <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
Message-ID: <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>

On Thu, 12 Jul 2018 at 10:29 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou <antoine at python.org>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/6dd275e1/attachment.html>

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: <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
Message-ID: <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>

On Thu, 12 Jul 2018 at 10:42 Eric Snow <ericsnowcurrently at gmail.com> wrote:

> On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov <yselivanov.ml at gmail.com>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/349b070a/attachment-0001.html>

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: <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
Message-ID: <CALFfu7AumSCycUHkgA839pj373uzyoB+PxjMO1o=EBXRrhzbyQ@mail.gmail.com>

On Thu, Jul 12, 2018 at 11:55 AM Brett Cannon <brett at python.org> 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: <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
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: <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
Message-ID: <CAF4280KccF-pUP3w2omo=wRTPEsj6q1Sr7nTQAr7z+ax=gNbMg@mail.gmail.com>

On Thu, Jul 12, 2018 at 8:41 PM, Eric Snow <ericsnowcurrently at gmail.com> 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: <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
Message-ID: <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>

On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon <brett at python.org> 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: <CAGbohnbBFN1YohSazgDF_WkyQ1gsnnuWqebrrQy-FnwvrZRoKA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAGbohnbBFN1YohSazgDF_WkyQ1gsnnuWqebrrQy-FnwvrZRoKA@mail.gmail.com>
Message-ID: <CAP1=2W7Lh5vmeoFOseUVmOsDb6Or-mvm4WM+ygMFwmzOHurfCg@mail.gmail.com>

On Thu, 12 Jul 2018 at 10:13 Mariatta Wijaya <mariatta.wijaya at gmail.com>
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 <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/9cf00189/attachment-0001.html>

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: <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
 <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org>
Message-ID: <CAP7h-xbKkNEPfi9z6GhHbTGfqvKAjrz6CvGryjBPGJ8g9tbGkA@mail.gmail.com>

On Thu, Jul 12, 2018 at 2:04 PM Antoine Pitrou <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/ef98fa04/attachment.html>

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: <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
Message-ID: <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>

On Thu, 12 Jul 2018 at 11:02 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/520468b4/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
 <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org>
Message-ID: <ec2c2ec5-e455-8690-7a81-743eabb27e80@python.org>

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: <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
 <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org>
Message-ID: <CAExdVN=Y9VecUL-MUG1d+wRy-JbU58dXxeXSKrAnXh5eiSx8Fw@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/1d4d7777/attachment-0001.html>

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: <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
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: <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
 <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
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 <yselivanov.ml at gmail.com> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
 <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
 <1531419654-sup-6867@lrrr.local>
Message-ID: <e5743de5-5759-da2e-9b76-016ce376e33d@python.org>


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 <yselivanov.ml at gmail.com> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <20180712175540.fqlcsyqia6kktzvd@python.ca>
Message-ID: <fe0649c5-b4a3-d0bd-4b7a-9362ee2c8b84@netwok.org>

  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: <e5743de5-5759-da2e-9b76-016ce376e33d@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
 <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
 <1531419654-sup-6867@lrrr.local>
 <e5743de5-5759-da2e-9b76-016ce376e33d@python.org>
Message-ID: <CAP1=2W7k2U_v4EXmHd8=2Tumu5ss9A1QEDjrMYths38Hc+R0+A@mail.gmail.com>

On Thu, 12 Jul 2018 at 11:28 Antoine Pitrou <antoine at python.org> 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 <yselivanov.ml at gmail.com>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/9913ba2c/attachment.html>

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: <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>

On Jul 12, 2018, at 07:57, Guido van Rossum <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/d5d59ce8/attachment.sig>

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: <CAP1=2W7k2U_v4EXmHd8=2Tumu5ss9A1QEDjrMYths38Hc+R0+A@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
 <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
 <1531419654-sup-6867@lrrr.local>
 <e5743de5-5759-da2e-9b76-016ce376e33d@python.org>
 <CAP1=2W7k2U_v4EXmHd8=2Tumu5ss9A1QEDjrMYths38Hc+R0+A@mail.gmail.com>
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: <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
Message-ID: <CAP1=2W7RhwEG6urOnLJfwdf_eE+ANY+tvrFS3ab0aGQ7hp+sHA@mail.gmail.com>

On Thu, 12 Jul 2018 at 11:53 Barry Warsaw <barry at python.org> wrote:

> On Jul 12, 2018, at 07:57, Guido van Rossum <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/9de98350/attachment-0001.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
 <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
 <1531419654-sup-6867@lrrr.local>
 <e5743de5-5759-da2e-9b76-016ce376e33d@python.org>
 <CAP1=2W7k2U_v4EXmHd8=2Tumu5ss9A1QEDjrMYths38Hc+R0+A@mail.gmail.com>
 <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: <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
Message-ID: <0AB7B5F8-4224-4AB7-B406-D6EBF0A6B447@gmail.com>



> On Jul 12, 2018, at 11:53 AM, Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
> 
> On Jul 12, 2018, at 07:57, Guido van Rossum <guido at python.org <mailto:guido at python.org>> 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 <https://neopythonic.blogspot.com/2016/04/kings-day-speech.html>

Warmly,

Carol




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180712/dcb1ff74/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <20180712181608.GC7318@ando.pearwood.info>
Message-ID: <57C64E16-4362-4192-B902-B3F500C4F830@python.org>

On Jul 12, 2018, at 11:16, Steven D'Aprano <steve at pearwood.info> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/660a03aa/attachment.sig>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <CAP1=2W7yan2Dn=g8i8o4HagCcwR643asLsCOkteNYR+anLVaGw@mail.gmail.com>
 <CA+St6D1xK5h1tBUCs=XCzVCkAwyDiLSyMExCYa_Z4RQ48ewL5A@mail.gmail.com>
 <CAP1=2W6rPoLec_82w2cikfrpH_s7VuPDwKv9Ss7ZgGAnU4j7PA@mail.gmail.com>
 <1531419654-sup-6867@lrrr.local>
 <e5743de5-5759-da2e-9b76-016ce376e33d@python.org>
 <CAP1=2W7k2U_v4EXmHd8=2Tumu5ss9A1QEDjrMYths38Hc+R0+A@mail.gmail.com>
 <8f20179b-9314-4838-73fa-0b6b728bdf4e@cheimes.de>
 <1531422465-sup-9106@lrrr.local>
Message-ID: <d16b24a6-fe59-69fe-9930-d618ed73df2e@python.org>


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: <CAExdVN=Y9VecUL-MUG1d+wRy-JbU58dXxeXSKrAnXh5eiSx8Fw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W6JuB6i8y7OCerHBKHBEpWs5DBH19ieiZCPJNhComnXXA@mail.gmail.com>
 <61cd4a43-360d-db5e-bea5-b8ad0e01aa00@python.org>
 <CAExdVN=Y9VecUL-MUG1d+wRy-JbU58dXxeXSKrAnXh5eiSx8Fw@mail.gmail.com>
Message-ID: <F5844C74-7BCF-492F-954F-81334E2B66B0@python.org>

On Jul 12, 2018, at 11:21, Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/dc7eb0fb/attachment.sig>

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: <CAP1=2W7RhwEG6urOnLJfwdf_eE+ANY+tvrFS3ab0aGQ7hp+sHA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
 <CAP1=2W7RhwEG6urOnLJfwdf_eE+ANY+tvrFS3ab0aGQ7hp+sHA@mail.gmail.com>
Message-ID: <EA6F5C6F-0D55-4619-B08A-27F1E7EE435C@python.org>

On Jul 12, 2018, at 12:16, Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/54a3c9e1/attachment.sig>

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: <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
Message-ID: <CAP1=2W4VJ_N2kZtSM25nOXNn_M61pELO8hefjE+fqo_SgzKeSA@mail.gmail.com>

On Thu, 12 Jul 2018 at 10:42 Eric Snow <ericsnowcurrently at gmail.com> wrote:

> On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov <yselivanov.ml at gmail.com>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/54470fa0/attachment.html>

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: <CAP1=2W4VJ_N2kZtSM25nOXNn_M61pELO8hefjE+fqo_SgzKeSA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W4VJ_N2kZtSM25nOXNn_M61pELO8hefjE+fqo_SgzKeSA@mail.gmail.com>
Message-ID: <CALFfu7CX5xG=cfAyH2-WPat2-xQoyaiVRfTfHX+CskecX4SHEw@mail.gmail.com>

On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon <brett at python.org> wrote:
> On Thu, 12 Jul 2018 at 10:42 Eric Snow <ericsnowcurrently at gmail.com> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <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 <antoine at python.org> 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: <CALFfu7CX5xG=cfAyH2-WPat2-xQoyaiVRfTfHX+CskecX4SHEw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CA+St6D0mBEmTVvTUFNcSOvawTbn+zfRarbzkgWGh5_6HPixchg@mail.gmail.com>
 <CALFfu7CMcW7SJdjD=sG9-pGY6pfEFnOU4W6EKJ0P7kfpdOH_yg@mail.gmail.com>
 <CAP1=2W4VJ_N2kZtSM25nOXNn_M61pELO8hefjE+fqo_SgzKeSA@mail.gmail.com>
 <CALFfu7CX5xG=cfAyH2-WPat2-xQoyaiVRfTfHX+CskecX4SHEw@mail.gmail.com>
Message-ID: <CABHLM6vEA60a6gtU9mPunVXBg_GmQtUs5JXAF4+fGdb0q8hoEQ@mail.gmail.com>

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 <ericsnowcurrently at gmail.com>
wrote:

> On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon <brett at python.org> wrote:
> > On Thu, 12 Jul 2018 at 10:42 Eric Snow <ericsnowcurrently at gmail.com>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/79658aef/attachment.html>

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: <EA6F5C6F-0D55-4619-B08A-27F1E7EE435C@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
 <CAP1=2W7RhwEG6urOnLJfwdf_eE+ANY+tvrFS3ab0aGQ7hp+sHA@mail.gmail.com>
 <EA6F5C6F-0D55-4619-B08A-27F1E7EE435C@python.org>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAFjbc8GJz+rLrpghgH5C0P3omoR4Kf2c3SanA3Mtaxg6eqOF5Q@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/c74a698e/attachment-0001.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <8539a52d-d7d2-7223-d547-bda427c6aad1@python.org>
 <776cba2b-96d0-370b-d5c0-2de7da9078ad@python.org>
 <701A566F-9A09-45E3-B492-950DE57D728B@gmail.com>
Message-ID: <CC6A83FB-C308-42C9-8EA8-EC35AEFA2B1B@langa.pl>


> On Jul 12, 2018, at 2:27 PM, Raymond Hettinger <raymond.hettinger at gmail.com> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/5d1fad8f/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>


(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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/ba8f0b26/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAPOVWORshGwaaE7PE3SD8=SBK4K24667s-4kUGsSn=9QSupSTA@mail.gmail.com>

On Thu, Jul 12, 2018 at 7:57 AM, Guido van Rossum <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180712/36c88601/attachment-0001.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAJ3HoZ2pR61Tr7QK6Y9HGnXvgSz6pjuTbhao11NWz18Po1akHQ@mail.gmail.com>

On Fri., 13 Jul. 2018, 02:58 Guido van Rossum, <guido at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/6215fce0/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CACac1F8on+0G7=iWYAOzgme1eFmG8E7VuJews_vKRcKWwk6P_g@mail.gmail.com>

On 12 July 2018 at 15:57, Guido van Rossum <guido at python.org> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <1531417396-sup-8296@lrrr.local>
Message-ID: <CANxH2eRjD8zgTMxN+zLoMoOk3Qv48dzfPCknC3L=H0us9bhLdQ@mail.gmail.com>

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 <doug at doughellmann.com> 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 <antoine at python.org>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/94c2314d/attachment.html>

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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>

Hi,

2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
> 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: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>

On Thu, Jul 12, 2018 at 6:35 PM, ?ukasz Langa <lukasz at langa.pl> 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: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
References: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
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: <CANxH2eRjD8zgTMxN+zLoMoOk3Qv48dzfPCknC3L=H0us9bhLdQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <1531417396-sup-8296@lrrr.local>
 <CANxH2eRjD8zgTMxN+zLoMoOk3Qv48dzfPCknC3L=H0us9bhLdQ@mail.gmail.com>
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 <anthonybaxter at gmail.com> 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 <doug at doughellmann.com <mailto:doug at doughellmann.com>> 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 <antoine at python.org <mailto:antoine at python.org>> 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 <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180713/19b6ca37/attachment-0001.html>

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: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
References: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
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 <lukasz at langa.pl> 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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
References: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
Message-ID: <CA+3bQGEuk_PZjjGh8PLU0tywG-omXD5fL7DTKwzyLUyrvmqStw@mail.gmail.com>

2018-07-13 12:40 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> * 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: <CA+3bQGEuk_PZjjGh8PLU0tywG-omXD5fL7DTKwzyLUyrvmqStw@mail.gmail.com>
References: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
 <CA+3bQGEuk_PZjjGh8PLU0tywG-omXD5fL7DTKwzyLUyrvmqStw@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <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: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
References: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
Message-ID: <CAP1=2W6UhoNEQmPBhKJ_0UopKuV8cCxySNpc8gPP_tJOt+L0Yw@mail.gmail.com>

On Fri, 13 Jul 2018 at 04:31 Nathaniel Smith <njs at pobox.com> wrote:

> On Thu, Jul 12, 2018 at 6:35 PM, ?ukasz Langa <lukasz at langa.pl> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/83e010c9/attachment-0001.html>

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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
References: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
Message-ID: <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>

On Fri, 13 Jul 2018 at 03:44 Victor Stinner <vstinner at redhat.com> wrote:

> Hi,
>
> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/88fd887c/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <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, <Jack.Jansen at cwi.nl>, 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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/ce4e7ff6/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <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 <jack.jansen at cwi.nl> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/c891bd92/attachment.sig>

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: <CANxH2eRjD8zgTMxN+zLoMoOk3Qv48dzfPCknC3L=H0us9bhLdQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <1531417396-sup-8296@lrrr.local>
 <CANxH2eRjD8zgTMxN+zLoMoOk3Qv48dzfPCknC3L=H0us9bhLdQ@mail.gmail.com>
Message-ID: <677B9C14-CC36-402A-9980-4FC0BD4F02C9@python.org>

On Jul 13, 2018, at 02:30, Anthony Baxter <anthonybaxter at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/8e70b517/attachment.sig>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <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 <jack.jansen at cwi.nl> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/7c4b1cc8/attachment-0001.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <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: <deaf6adc-2cae-0ccd-7fc9-f1d31ba3ab03@python.org>

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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
References: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
Message-ID: <66913909-F4DA-4E34-897D-EDACDC452AD0@python.org>

On Jul 13, 2018, at 03:40, Victor Stinner <vstinner at redhat.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/2de08466/attachment.sig>

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: <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>
References: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
 <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>
Message-ID: <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com>



> On Jul 13, 2018, at 11:39 AM, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> 
> 
> 
> On Fri, 13 Jul 2018 at 03:44 Victor Stinner <vstinner at redhat.com <mailto:vstinner at redhat.com>> wrote:
> Hi,
> 
> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com <mailto:mariatta.wijaya at gmail.com>>:
> 
> 
> * 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/c338d23b/attachment.html>

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: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
References: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
Message-ID: <5A00D362-56DC-4F18-97C9-4DC19FD7B792@python.org>

On Jul 13, 2018, at 04:31, Nathaniel Smith <njs at pobox.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/34343e76/attachment-0001.sig>

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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
 <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>
 <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 <willingc at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/d628d9e4/attachment.sig>

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: <CAPJVwBkCdrdnYGGK7OUFfNvBgXtrbbrfpo_7JB-OUqEHg_UboQ@mail.gmail.com>
 <5A00D362-56DC-4F18-97C9-4DC19FD7B792@python.org>
Message-ID: <B0D35F5E-BE2A-45C0-BD3B-11CA797428B2@gmail.com>


> On Jul 13, 2018, at 5:15 PM, Barry Warsaw <barry at python.org> wrote:
> 
> On Jul 13, 2018, at 04:31, Nathaniel Smith <njs at pobox.com> 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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
 <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>
 <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 <barry at python.org> wrote:
> 
> On Jul 13, 2018, at 17:11, Carol Willing <willingc at gmail.com> 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: <deaf6adc-2cae-0ccd-7fc9-f1d31ba3ab03@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <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>
 <deaf6adc-2cae-0ccd-7fc9-f1d31ba3ab03@python.org>
Message-ID: <fe919bc5-f1ce-7e79-60fa-4665312d0c32@hastings.org>



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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/86002678/attachment-0001.html>

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: <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
Message-ID: <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/05ef7e76/attachment.html>

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: <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
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: <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
Message-ID: <CAPJVwBmv1fhsrfLWpZUNEHGUGkzT5esUonFGJZhSfhsmaae_kQ@mail.gmail.com>

On Fri, Jul 13, 2018 at 6:54 PM, Tim Peters <tim.peters at gmail.com> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <5B4960F1.1020004@stoneleaf.us>
Message-ID: <CAExdVN=e4bTWxwTGA7qNY-Nsuh_ARqrqAdPr4ZjmYLSL4mcKhg@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/233665cc/attachment.html>

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: <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
Message-ID: <e0dd00ee-e840-bd2c-19a9-f614d3f0d9d3@hastings.org>



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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/e459f4c8/attachment-0001.html>

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: <CAPJVwBmv1fhsrfLWpZUNEHGUGkzT5esUonFGJZhSfhsmaae_kQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <CAPJVwBmv1fhsrfLWpZUNEHGUGkzT5esUonFGJZhSfhsmaae_kQ@mail.gmail.com>
Message-ID: <CAExdVN=CCNKpWvbO6=cOS74Ghg6ZbxmNXQ9xvK+zSsgcf=KRCw@mail.gmail.com>

[Nathaniel Smith <njs at pobox.com>]

> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/99566304/attachment.html>

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: <e0dd00ee-e840-bd2c-19a9-f614d3f0d9d3@hastings.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <e0dd00ee-e840-bd2c-19a9-f614d3f0d9d3@hastings.org>
Message-ID: <CAExdVNkEZQjG9j9g_wXTxz_2LmzL5L3p3nyXmMxppXNpDudORg@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/82bf60f1/attachment.html>

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: <CAExdVN=CCNKpWvbO6=cOS74Ghg6ZbxmNXQ9xvK+zSsgcf=KRCw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <CAPJVwBmv1fhsrfLWpZUNEHGUGkzT5esUonFGJZhSfhsmaae_kQ@mail.gmail.com>
 <CAExdVN=CCNKpWvbO6=cOS74Ghg6ZbxmNXQ9xvK+zSsgcf=KRCw@mail.gmail.com>
Message-ID: <CAPJVwBnGTk9oZPKBnnzPV_OJNj4CxHpgh8MHSaKgyRW-jz8L+w@mail.gmail.com>

On Fri, Jul 13, 2018 at 8:22 PM, Tim Peters <tim.peters at gmail.com> wrote:
> [Nathaniel Smith <njs at pobox.com>]
>>
>> 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: <CAPJVwBnGTk9oZPKBnnzPV_OJNj4CxHpgh8MHSaKgyRW-jz8L+w@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <CAPJVwBmv1fhsrfLWpZUNEHGUGkzT5esUonFGJZhSfhsmaae_kQ@mail.gmail.com>
 <CAExdVN=CCNKpWvbO6=cOS74Ghg6ZbxmNXQ9xvK+zSsgcf=KRCw@mail.gmail.com>
 <CAPJVwBnGTk9oZPKBnnzPV_OJNj4CxHpgh8MHSaKgyRW-jz8L+w@mail.gmail.com>
Message-ID: <CAExdVNnHFcmyskFY0pBxw++xMnNwoRpRGtoQF2GA+QXfZf26Hw@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/d8ddd02f/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <CAP1=2W4WF-265oz-8_HLdB=So0RQSQ=3Lr2T3++F5ndN44Z35g@mail.gmail.com>
 <b435ccc6-d993-dedf-d998-5b021a7ee87b@python.org>
 <CA+St6D0a6rZUipZJ-ouUdcmUAA+CCw0GnSm=CGv7hGABj8GDsQ@mail.gmail.com>
 <20180712175540.fqlcsyqia6kktzvd@python.ca>
 <433E219F-F761-4C16-AB76-8E4734D1131E@cwi.nl>
Message-ID: <CAE46Be86_iiME3DB0sHmDNEVzpyfCiQ4QiKKzEW2uaXET_tuag@mail.gmail.com>

>
>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/aebc52da/attachment.html>

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: <CAP1=2W7RhwEG6urOnLJfwdf_eE+ANY+tvrFS3ab0aGQ7hp+sHA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <E71059AB-A8BB-41EF-B97E-96E54BBCCAEF@python.org>
 <CAP1=2W7RhwEG6urOnLJfwdf_eE+ANY+tvrFS3ab0aGQ7hp+sHA@mail.gmail.com>
Message-ID: <CAGE7PN+npSUri7zS2JMCgBzt+yQPpZ_iJ9PkncNHbn5gmYdyyg@mail.gmail.com>

On Thu, Jul 12, 2018 at 12:17 PM Brett Cannon <brett at python.org> wrote:

> On Thu, 12 Jul 2018 at 11:53 Barry Warsaw <barry at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180713/761d962a/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CADiSq7fUeimL5yum2i0EGt--oFfRmp0BtvB9M-X1_YHrpFGS9w@mail.gmail.com>

On 13 July 2018 at 00:57, Guido van Rossum <guido at python.org> 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: <CADiSq7fck0JD9_dfkmDZTmUvcBme4eRt9oG_8DSLXZqPS8+raQ@mail.gmail.com>

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: <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
Message-ID: <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>


> On Jul 13, 2018, at 7:54 PM, Tim Peters <tim.peters at gmail.com> 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: <CADiSq7fck0JD9_dfkmDZTmUvcBme4eRt9oG_8DSLXZqPS8+raQ@mail.gmail.com>
References: <CADiSq7fck0JD9_dfkmDZTmUvcBme4eRt9oG_8DSLXZqPS8+raQ@mail.gmail.com>
Message-ID: <CACac1F9sYd1u_qP0i_KAyxcie6JbMhPKNm9ftL95WYdr4vS=zQ@mail.gmail.com>

On 14 July 2018 at 08:05, Nick Coghlan <ncoghlan at gmail.com> 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
Message-ID: <CAFYqXL-bHWFYy6reQYUne77c_jHjm_OGhoOSTDYCwV+NoXt0tA@mail.gmail.com>

On Thu, Jul 12, 2018 at 4:58 PM Guido van Rossum <guido at python.org> 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: <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
Message-ID: <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/c51f2706/attachment.html>

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: <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
Message-ID: <CAP1=2W405Ou=+qrUM6FaFXA41o9SpBVW-d4eYJwXFTQePNob9Q@mail.gmail.com>

On Sat, 14 Jul 2018 at 00:16 ?ukasz Langa <lukasz at langa.pl> wrote:

>
> > On Jul 13, 2018, at 7:54 PM, Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/9e676a85/attachment.html>

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: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
 <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>
 <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com>
Message-ID: <CAP1=2W6YvKu6DJbLVatFwHmm=bZxZ7uwig_0rz==voEw+xgS5w@mail.gmail.com>

On Fri, Jul 13, 2018, 17:11 Carol Willing, <willingc at gmail.com> wrote:

> On Jul 13, 2018, at 11:39 AM, Brett Cannon <brett at python.org> wrote:
>
> On Fri, 13 Jul 2018 at 03:44 Victor Stinner <vstinner at redhat.com> wrote:
>
>> Hi,
>>
>> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
>>
>>
>> * 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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/6e490312/attachment-0001.html>

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: <CAP1=2W78OR-hQgxpdLd6Zt3S4d=Hgz3S=McauJKD2oE1ZM8g=w@mail.gmail.com>

On Fri, Jul 13, 2018, 13:14 Neil Schemenauer, <nas-python at arctrix.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/016cff2c/attachment.html>

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: <CAP1=2W6YvKu6DJbLVatFwHmm=bZxZ7uwig_0rz==voEw+xgS5w@mail.gmail.com>
References: <CA+3bQGE+YXeau97wf7_inp=rEayqz+TdzxnpA2wPP0aw4fgz7w@mail.gmail.com>
 <CAP1=2W5PqzQxchBrCea7g5DE+_PBgWM71=09AXq_iS-9wExw2w@mail.gmail.com>
 <92703154-52E0-424A-BF35-41F100F4FEC5@gmail.com>
 <CAP1=2W6YvKu6DJbLVatFwHmm=bZxZ7uwig_0rz==voEw+xgS5w@mail.gmail.com>
Message-ID: <CAP1=2W6dsM3gDt3LnFH-X46FphS2Hx4ajDmxT=e7sV05JPVexg@mail.gmail.com>

On Sat, Jul 14, 2018, 15:56 Brett Cannon, <brett at python.org> wrote:

>
>
> On Fri, Jul 13, 2018, 17:11 Carol Willing, <willingc at gmail.com> wrote:
>
>> On Jul 13, 2018, at 11:39 AM, Brett Cannon <brett at python.org> wrote:
>>
>> On Fri, 13 Jul 2018 at 03:44 Victor Stinner <vstinner at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
>>>
>>>
>>> * 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: <http://mail.python.org/pipermail/python-committers/attachments/20180714/c1e9f63d/attachment.html>

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: <CACac1F9sYd1u_qP0i_KAyxcie6JbMhPKNm9ftL95WYdr4vS=zQ@mail.gmail.com>
References: <CADiSq7fck0JD9_dfkmDZTmUvcBme4eRt9oG_8DSLXZqPS8+raQ@mail.gmail.com>
 <CACac1F9sYd1u_qP0i_KAyxcie6JbMhPKNm9ftL95WYdr4vS=zQ@mail.gmail.com>
Message-ID: <CADiSq7c4O4eAsH6yvYFgna61uZC-9mUDhJONJzRKsUcByNSfxQ@mail.gmail.com>

On 14 July 2018 at 19:36, Paul Moore <p.f.moore at gmail.com> wrote:
> On 14 July 2018 at 08:05, Nick Coghlan <ncoghlan at gmail.com> 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: <CAP1=2W405Ou=+qrUM6FaFXA41o9SpBVW-d4eYJwXFTQePNob9Q@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAP1=2W405Ou=+qrUM6FaFXA41o9SpBVW-d4eYJwXFTQePNob9Q@mail.gmail.com>
Message-ID: <CA+St6D2qb_ZKM1MxtpXYAkgxo3RYe9Q7DAajy9bJbkRZFN8dFQ@mail.gmail.com>

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon <brett at python.org> 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: <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
Message-ID: <08710656-C7E7-4287-85C7-6773C5C5E167@python.org>

On Jul 14, 2018, at 00:16, ?ukasz Langa <lukasz at langa.pl> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/e134847c/attachment.sig>

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: <CA+St6D2qb_ZKM1MxtpXYAkgxo3RYe9Q7DAajy9bJbkRZFN8dFQ@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAP1=2W405Ou=+qrUM6FaFXA41o9SpBVW-d4eYJwXFTQePNob9Q@mail.gmail.com>
 <CA+St6D2qb_ZKM1MxtpXYAkgxo3RYe9Q7DAajy9bJbkRZFN8dFQ@mail.gmail.com>
Message-ID: <CAPdQG2o7OWuovy=1PYfDSRBn_trOCEqj_hS=ri9-Sv2DqfZQnA@mail.gmail.com>

On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov <yselivanov.ml at gmail.com>
wrote:

> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon <brett at python.org> 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 <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180715/30041f76/attachment.html>

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: <CAPdQG2o7OWuovy=1PYfDSRBn_trOCEqj_hS=ri9-Sv2DqfZQnA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAP1=2W405Ou=+qrUM6FaFXA41o9SpBVW-d4eYJwXFTQePNob9Q@mail.gmail.com>
 <CA+St6D2qb_ZKM1MxtpXYAkgxo3RYe9Q7DAajy9bJbkRZFN8dFQ@mail.gmail.com>
 <CAPdQG2o7OWuovy=1PYfDSRBn_trOCEqj_hS=ri9-Sv2DqfZQnA@mail.gmail.com>
Message-ID: <CAP1=2W6uYrwTmtZxpPTwaazTw2rKsQ5jZnFsxQ=96BVLNydcng@mail.gmail.com>

On Sun, Jul 15, 2018, 13:01 Thomas Wouters, <thomas at python.org> wrote:

> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
>
>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon <brett at python.org> 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 <thomas at python.org>
>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/21392e9d/attachment.html>

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: <CAP1=2W6uYrwTmtZxpPTwaazTw2rKsQ5jZnFsxQ=96BVLNydcng@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAP1=2W405Ou=+qrUM6FaFXA41o9SpBVW-d4eYJwXFTQePNob9Q@mail.gmail.com>
 <CA+St6D2qb_ZKM1MxtpXYAkgxo3RYe9Q7DAajy9bJbkRZFN8dFQ@mail.gmail.com>
 <CAPdQG2o7OWuovy=1PYfDSRBn_trOCEqj_hS=ri9-Sv2DqfZQnA@mail.gmail.com>
 <CAP1=2W6uYrwTmtZxpPTwaazTw2rKsQ5jZnFsxQ=96BVLNydcng@mail.gmail.com>
Message-ID: <CAP7+vJL7GTyqG2f-pqM5TfYJOqfc2FBrB4MY-XW14+GDE8i1hQ@mail.gmail.com>

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 <brett at python.org> wrote:

>
>
> On Sun, Jul 15, 2018, 13:01 Thomas Wouters, <thomas at python.org> wrote:
>
>> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov <yselivanov.ml at gmail.com>
>> wrote:
>>
>>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon <brett at python.org> 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 <thomas at python.org>
>>
>> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/a1816501/attachment-0001.html>

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: <BDFD6605-1CCA-45A8-884F-2C704F79B1EF@gmail.com>

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 <https://hackmd.io/s/BJPaxUFX7>

To view: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?view <https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?view>

To edit: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/01ed67c6/attachment.html>

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: <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
Message-ID: <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>

On Sat, 14 Jul 2018 at 11:37 Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/834f51f0/attachment.html>

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: <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
Message-ID: <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/101641a2/attachment-0001.html>

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: <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
Message-ID: <CAOTb1wdxyBMJiBjiY1jN7rE4hQpa1Lu9x0sWPMappO4kMTLA3w@mail.gmail.com>

On Sun, Jul 15, 2018 at 6:07 PM Brett Cannon <brett at python.org> wrote:

> On Sat, 14 Jul 2018 at 11:37 Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180715/6bc7319b/attachment.html>

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: <CAOTb1wdxyBMJiBjiY1jN7rE4hQpa1Lu9x0sWPMappO4kMTLA3w@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAOTb1wdxyBMJiBjiY1jN7rE4hQpa1Lu9x0sWPMappO4kMTLA3w@mail.gmail.com>
Message-ID: <CAExdVNmM_WGquyHMTbX_z6w3vnqT-xikHnb384pz1X51Zr9JcA@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/304e0a6c/attachment-0001.html>

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: <CAExdVNmM_WGquyHMTbX_z6w3vnqT-xikHnb384pz1X51Zr9JcA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAOTb1wdxyBMJiBjiY1jN7rE4hQpa1Lu9x0sWPMappO4kMTLA3w@mail.gmail.com>
 <CAExdVNmM_WGquyHMTbX_z6w3vnqT-xikHnb384pz1X51Zr9JcA@mail.gmail.com>
Message-ID: <CAOTb1wfWMUvjV_erN6w0dYfsDcd-QX_jvb19njtcz6c+F6g=Jg@mail.gmail.com>

On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters <tim.peters at gmail.com> 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: <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org>
Message-ID: <CAExdVNnNFBYgnHacvwZdGx6PTqmgTKBeYaDBiP+ZSP76Uo3EQA@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/3df76794/attachment.html>

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: <CAExdVNnNFBYgnHacvwZdGx6PTqmgTKBeYaDBiP+ZSP76Uo3EQA@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org>
 <CAExdVNnNFBYgnHacvwZdGx6PTqmgTKBeYaDBiP+ZSP76Uo3EQA@mail.gmail.com>
Message-ID: <bf15d69b-8d44-f4ac-923e-6a4d01a01b87@python.org>


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: <CAOTb1wfWMUvjV_erN6w0dYfsDcd-QX_jvb19njtcz6c+F6g=Jg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAOTb1wdxyBMJiBjiY1jN7rE4hQpa1Lu9x0sWPMappO4kMTLA3w@mail.gmail.com>
 <CAExdVNmM_WGquyHMTbX_z6w3vnqT-xikHnb384pz1X51Zr9JcA@mail.gmail.com>
 <CAOTb1wfWMUvjV_erN6w0dYfsDcd-QX_jvb19njtcz6c+F6g=Jg@mail.gmail.com>
Message-ID: <CAP1=2W7t_R1KQYjPqJViC2egvPyP9Kf=raaneQ+fde1UvS349w@mail.gmail.com>

On Mon, 16 Jul 2018 at 00:17 Chris Jerdonek <chris.jerdonek at gmail.com>
wrote:

> On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/938c437f/attachment-0001.html>

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: <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
Message-ID: <CAP1=2W4sBtbaO5X5WsWMnkF76Jc=f8o9ZEgLqz3uG0XoHaGndw@mail.gmail.com>

On Sun, 15 Jul 2018 at 19:38 Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/2fd29925/attachment.html>

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: <CAP1=2W7t_R1KQYjPqJViC2egvPyP9Kf=raaneQ+fde1UvS349w@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAOTb1wdxyBMJiBjiY1jN7rE4hQpa1Lu9x0sWPMappO4kMTLA3w@mail.gmail.com>
 <CAExdVNmM_WGquyHMTbX_z6w3vnqT-xikHnb384pz1X51Zr9JcA@mail.gmail.com>
 <CAOTb1wfWMUvjV_erN6w0dYfsDcd-QX_jvb19njtcz6c+F6g=Jg@mail.gmail.com>
 <CAP1=2W7t_R1KQYjPqJViC2egvPyP9Kf=raaneQ+fde1UvS349w@mail.gmail.com>
Message-ID: <CAExdVNmnocuBKcTXTtXpKaujeuGF_MBgC_xPYtV91cULPoQnmQ@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/4565c79a/attachment.html>

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: <bf15d69b-8d44-f4ac-923e-6a4d01a01b87@python.org>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <725e603c-3131-d9ce-2672-c6dc3c32cf75@python.org>
 <CAExdVNnNFBYgnHacvwZdGx6PTqmgTKBeYaDBiP+ZSP76Uo3EQA@mail.gmail.com>
 <bf15d69b-8d44-f4ac-923e-6a4d01a01b87@python.org>
Message-ID: <CAExdVNk4Q8E4btNTh=t=RHd1Hb2CmROQ2Seb-j=kV624Q8k_4A@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/1dacfecc/attachment-0001.html>

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: <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
Message-ID: <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>



> On  16-Jul-2018, at 04:38 , Tim Peters <tim.peters at gmail.com> 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, <Jack.Jansen at cwi.nl>, 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: <http://mail.python.org/pipermail/python-committers/attachments/20180717/c58c643e/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>
Message-ID: <CAP1=2W4cyWM3p+xBLFebnZfdT2drmijNHtG821ccB5xCzwSvnQ@mail.gmail.com>

On Mon, 16 Jul 2018 at 15:21 Jack Jansen <jack.jansen at cwi.nl> wrote:

>
>
> On  16-Jul-2018, at 04:38 , Tim Peters <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/6b78cc3e/attachment.html>

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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>
Message-ID: <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/fbf3990a/attachment-0001.html>

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: <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>
 <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>
Message-ID: <CAP1=2W4Rv_CSeh3eowRkZcZX4MpnSRinqDtuEnVNZwf=xAkQ7Q@mail.gmail.com>

On Mon, Jul 16, 2018, 17:02 Tim Peters, <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180716/b78aca90/attachment.html>

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: <CAP1=2W4Rv_CSeh3eowRkZcZX4MpnSRinqDtuEnVNZwf=xAkQ7Q@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>
 <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>
 <CAP1=2W4Rv_CSeh3eowRkZcZX4MpnSRinqDtuEnVNZwf=xAkQ7Q@mail.gmail.com>
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: <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>
References: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>
 <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>
Message-ID: <3BE02932-AEA8-4B29-8ACA-B5CFD1330AA6@cwi.nl>


> On 17 Jul 2018, at 02:02, Tim Peters <tim.peters at gmail.com> 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, <Jack.Jansen at cwi.nl>, 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: <CAP7+vJ+oK5q8a3kxizcbgUrrhwhOBbDj9VhSSNwZ0XgiOuBztQ@mail.gmail.com>
 <a50dc9fc-53f3-ba73-43c7-8780db6311e8@hastings.org>
 <CAExdVNkzz8WzfQE577-0_Ry_6HAe2=gn7bv=dd-zKnBvenJ2cw@mail.gmail.com>
 <F87F8241-86FB-4838-A991-327AE8D4F361@langa.pl>
 <CAExdVNniERC-eRRuda6NVCPkjwks1TkQDmyJjOojjKMtse+pPA@mail.gmail.com>
 <CAP1=2W7wYo0KjBbEhu20HBDUK0EE=ivmEUrtEDbCDCFReoExfw@mail.gmail.com>
 <CAExdVN=_81--y8czxeYDWorK48wF-9DmwK0J4QwHN24aaxocqg@mail.gmail.com>
 <4D846254-1CDF-48E2-9441-C9ECC0619235@cwi.nl>
 <CAExdVNn3pdLs-Q85gH4KscOWnp+=Rxqe7sag3o1gM8AWGicH3w@mail.gmail.com>
 <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 <tim.peters at gmail.com> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180717/3fc4bf6d/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
Message-ID: <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>

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: <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>
Message-ID: <19714581-A3B1-4473-B362-F70F34C575A8@python.org>

On Jul 17, 2018, at 22:15, Eric V. Smith <eric at trueblade.com> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>
 <19714581-A3B1-4473-B362-F70F34C575A8@python.org>
Message-ID: <CAM3VvhyqeA7rn35Ao5oNzCxfLMj-0LZkFmUYEUxW6odgCvUdpg@mail.gmail.com>

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 <nad at python.org> wrote:

> On Jul 17, 2018, at 22:15, Eric V. Smith <eric at trueblade.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180717/50d5459b/attachment.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
Message-ID: <CAE46Be8sp6vWeWzvZAXjBuG7UW5HHJkc0JHHtZnA7xzBz4B39g@mail.gmail.com>

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 <barry at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180717/0d689634/attachment-0001.html>

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: <CAE46Be8sp6vWeWzvZAXjBuG7UW5HHJkc0JHHtZnA7xzBz4B39g@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAE46Be8sp6vWeWzvZAXjBuG7UW5HHJkc0JHHtZnA7xzBz4B39g@mail.gmail.com>
Message-ID: <CAOTb1we+YppX8DWCiHL1fW43Ea1Ki=fDVMFMdLRhGmr07VJZxw@mail.gmail.com>

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
<python-committers at python.org> 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 <barry at python.org> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
Message-ID: <CAPOVWOT4YOCFVJfStvCVwcUEDQ254MotPfWHUJ_Grk8ZbJD-hg@mail.gmail.com>

On Tue, Jul 17, 2018 at 7:02 PM, Barry Warsaw <barry at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180717/4a484052/attachment.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
Message-ID: <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/b9ba1dd2/attachment-0001.html>

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: <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
Message-ID: <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>

On Wed, Jul 18, 2018 at 11:17 AM Tim Peters <tim.peters at gmail.com> 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: <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
Message-ID: <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>

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 <kushaldas at gmail.com> wrote:
> On Wed, Jul 18, 2018 at 11:17 AM Tim Peters <tim.peters at gmail.com> 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: <CAM3VvhyqeA7rn35Ao5oNzCxfLMj-0LZkFmUYEUxW6odgCvUdpg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>
 <19714581-A3B1-4473-B362-F70F34C575A8@python.org>
 <CAM3VvhyqeA7rn35Ao5oNzCxfLMj-0LZkFmUYEUxW6odgCvUdpg@mail.gmail.com>
Message-ID: <CACac1F8oUCCfrQ8jVjZf7_CwXj8mCzTJHgkL5B-3eTcFB26g7w@mail.gmail.com>

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 <willingc at gmail.com> 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 <nad at python.org> wrote:
>>
>> On Jul 17, 2018, at 22:15, Eric V. Smith <eric at trueblade.com> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
Message-ID: <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>


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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
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: <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <dee9fe51-2e59-d02d-905f-2bad46bb5616@trueblade.com>
Message-ID: <CALFfu7Ce4ruAQtEsBoxKHj=6_SzZSUugUa_=7wo0Cqsj1difYw@mail.gmail.com>

On Tue, Jul 17, 2018 at 8:15 PM Eric V. Smith <eric at trueblade.com> 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: <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
Message-ID: <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>


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: <D55CBB46-5EC2-49F1-8E27-2BF5E04F127E@langa.pl>

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 <stefan at bytereef.org> 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: <D55CBB46-5EC2-49F1-8E27-2BF5E04F127E@langa.pl>
References: <20180718161156.GA5506@bytereef.org>
 <D55CBB46-5EC2-49F1-8E27-2BF5E04F127E@langa.pl>
Message-ID: <CAGbohnbaV+U2-2Z08Zyi=rOcnuw82mdCoeaDoTAXTsgf--rR+w@mail.gmail.com>

>
> 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 <lukasz at langa.pl> 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 <stefan at bytereef.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/db8b32bc/attachment.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
Message-ID: <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>


> On Jul 18, 2018, at 10:58 AM, Ethan Furman <ethan at stoneleaf.us> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <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 <ethan at stoneleaf.us> 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: <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <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: <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
Message-ID: <CAExdVNnG3GVC0PdRsiAxUmbVg_1hxkCanC679TsGFY_Hpce1UQ@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/86e7bec8/attachment.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <452b9b71-b329-5486-1b67-c883cb9760c0@python.org>
Message-ID: <CAPOVWORivMDEHM2rXuACFYEszpHX3+NgSs=tW2HTv=ENYVB57Q@mail.gmail.com>

On Wed, Jul 18, 2018 at 9:38 AM, Antoine Pitrou <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/d827a749/attachment.html>

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: <CAPOVWOT4YOCFVJfStvCVwcUEDQ254MotPfWHUJ_Grk8ZbJD-hg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAPOVWOT4YOCFVJfStvCVwcUEDQ254MotPfWHUJ_Grk8ZbJD-hg@mail.gmail.com>
Message-ID: <CAExdVN=Kjydy15PzzVMfNtaZuBhyJToPY6UbDhg3LE+xy7XGmg@mail.gmail.com>

[Senthil Kumaran <senthil at uthcode.com>]

> ...

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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/e52070bc/attachment-0001.html>

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: <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
Message-ID: <2266A334-5A8D-4868-83A7-21D27562B393@python.org>

On Jul 17, 2018, at 22:55, Kushal Das <kushaldas at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/97bb8487/attachment.sig>

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: <CAExdVNnG3GVC0PdRsiAxUmbVg_1hxkCanC679TsGFY_Hpce1UQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
 <CAExdVNnG3GVC0PdRsiAxUmbVg_1hxkCanC679TsGFY_Hpce1UQ@mail.gmail.com>
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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
Message-ID: <CALFfu7DmfNtCHQ9m_SF_rBdRyTJ9-Ca9CRpmaA77j=MCXKvjZQ@mail.gmail.com>

On Wed, Jul 18, 2018 at 2:43 AM Antoine Pitrou <antoine at python.org> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
Message-ID: <CALFfu7Dhgzoc07LzFXV3BGL-SXHhpX+y+7Bx-3jhEgCB1+4YMw@mail.gmail.com>

On Wed, Jul 18, 2018 at 10:36 AM ?ukasz Langa <lukasz at langa.pl> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
 <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org>
Message-ID: <CALFfu7BkpLOa1UUpMY60CwKhd1gV=N9d+-7npn_Q8N6PGgTUWw@mail.gmail.com>

On Wed, Jul 18, 2018 at 10:44 AM Steve Dower <steve.dower at python.org> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <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 <antoine at python.org> 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 <https://en.wikipedia.org/wiki/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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/42723022/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <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 <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/e48dae7c/attachment.sig>

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: <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
Message-ID: <A6220890-409B-47DE-862B-A660816AD943@python.org>

On Jul 18, 2018, at 03:04, Antoine Pitrou <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/54f90134/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <5B4F1706.5040309@stoneleaf.us>
Message-ID: <15B6DD76-4A6E-4190-85B7-C37A38B97610@python.org>

On Jul 18, 2018, at 03:31, Ethan Furman <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/1041d9e0/attachment-0001.sig>

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: <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
Message-ID: <33C6F50B-84C9-4650-A792-F4A7602017A4@python.org>

On Jul 18, 2018, at 09:10, Antoine Pitrou <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/73923317/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <b2e1b6e7-4a8d-5291-0260-050d6dd0983b@python.org>
 <532c2391-3d46-3c66-b369-0c1fcf0dc135@python.org>
Message-ID: <CC7F3588-40E7-4A55-8091-1AFFA5A44526@python.org>

On Jul 18, 2018, at 09:44, Steve Dower <steve.dower at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/5eada23d/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
Message-ID: <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>


> On Jul 18, 2018, at 11:54 AM, Ethan Furman <ethan at stoneleaf.us> 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: <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
Message-ID: <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>

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 <lukasz at langa.pl> wrote:

>
> > On Jul 18, 2018, at 11:54 AM, Ethan Furman <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/4cdde6f3/attachment-0001.html>

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: <CALFfu7DmfNtCHQ9m_SF_rBdRyTJ9-Ca9CRpmaA77j=MCXKvjZQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <CALFfu7DmfNtCHQ9m_SF_rBdRyTJ9-Ca9CRpmaA77j=MCXKvjZQ@mail.gmail.com>
Message-ID: <9706D627-344A-4487-81B6-CFB8A33ADB78@python.org>

On Jul 18, 2018, at 10:13, Eric Snow <ericsnowcurrently at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/fe556049/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <3E916CE1-9E84-4E50-8008-D98BA7A635EB@python.org>
Message-ID: <ec48c4e9-baab-32f6-d9a5-2a0c941d971b@python.org>


Le 18/07/2018 ? 19:51, Barry Warsaw a ?crit?:
> On Jul 18, 2018, at 01:43, Antoine Pitrou <antoine at python.org> 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 <stefan at bytereef.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/b10335a4/attachment.sig>

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: <c4cf4f38-b1f1-fb91-482c-519776fea02e@python.org>


Le 18/07/2018 ? 20:47, Barry Warsaw a ?crit?:
> On Jul 18, 2018, at 09:11, Stefan Krah <stefan at bytereef.org> 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 <stefan at bytereef.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/063f0c9d/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <CALFfu7DmfNtCHQ9m_SF_rBdRyTJ9-Ca9CRpmaA77j=MCXKvjZQ@mail.gmail.com>
 <9706D627-344A-4487-81B6-CFB8A33ADB78@python.org>
Message-ID: <CAExdVNkgioidzQ2gvXQiTwQKi36+xTMO4Qmfpjn4YPBT4R5QZA@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/53383ddd/attachment.html>

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 <stefan at bytereef.org> 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: <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
Message-ID: <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>


> On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax at google.com> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
Message-ID: <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>

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 <lukasz at langa.pl> wrote:

>
> > On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax at google.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/eb087de7/attachment-0001.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
Message-ID: <A1EDE800-1D78-42B2-862E-2D60266CA565@cwi.nl>

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 <lukasz at langa.pl> wrote:
> 
> 
>> On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax at google.com> 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, <Jack.Jansen at cwi.nl>, 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/d2102b69/attachment.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
Message-ID: <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>

[starting a new thread]

On Wed, 18 Jul 2018 at 14:04 ?ukasz Langa <lukasz at langa.pl> wrote:

>
> > On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax at google.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/16fec580/attachment.html>

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: <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
Message-ID: <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>


> On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya <mariatta.wijaya at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/c8c52609/attachment-0001.html>

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: <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
Message-ID: <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>


> On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett at python.org> 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: <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@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 <brett at python.org> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org>
Message-ID: <CA+3bQGEGmLJCiD++Jsh79G3J2K17u0t7WB2vqdoO5dC5zyeivw@mail.gmail.com>

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 <antoine at 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 <brett at python.org> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org>
Message-ID: <B26F3385-3C9C-43DC-85D8-EEA099DD1852@langa.pl>

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 <antoine at python.org> 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 <brett at python.org> 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: <CA+3bQGEGmLJCiD++Jsh79G3J2K17u0t7WB2vqdoO5dC5zyeivw@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org>
 <CA+3bQGEGmLJCiD++Jsh79G3J2K17u0t7WB2vqdoO5dC5zyeivw@mail.gmail.com>
Message-ID: <c5275ba3-7192-8eae-a2ab-f8e7d7dbc154@python.org>


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 <antoine at 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 <brett at python.org> 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: <c5275ba3-7192-8eae-a2ab-f8e7d7dbc154@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org>
 <CA+3bQGEGmLJCiD++Jsh79G3J2K17u0t7WB2vqdoO5dC5zyeivw@mail.gmail.com>
 <c5275ba3-7192-8eae-a2ab-f8e7d7dbc154@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: <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
Message-ID: <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>



> On Jul 18, 2018, at 6:18 PM, ?ukasz Langa <lukasz at langa.pl> wrote:
> 
> 
>> On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett at python.org> 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: <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
Message-ID: <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>

> On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya <mariatta.wijaya at gmail.com> 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 <lukasz at langa.pl> 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.    <fred at fdrake.net>
"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: <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
 <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
Message-ID: <FBABED45-D109-4155-8AF1-7A9952F9FC0A@stufft.io>


> On Jul 18, 2018, at 7:06 PM, Fred Drake <fred at fdrake.net> 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/ <https://www.python.org/dev/peps/pep-0010/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180718/a0e9e348/attachment.html>

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: <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
 <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
Message-ID: <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org>

On Jul 18, 2018, at 16:06, Fred Drake <fred at fdrake.net> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/ae8c8496/attachment.sig>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
 <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
 <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org>
Message-ID: <CAGbohnYZqZVWpWE5bvwwC_SabOqtvUyVd5SsYXOLGs-CWfPydA@mail.gmail.com>

Next available is PEP lucky number 13 ?

Mariatta


On Wed, Jul 18, 2018 at 4:14 PM Barry Warsaw <barry at python.org> wrote:

> On Jul 18, 2018, at 16:06, Fred Drake <fred at fdrake.net> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/c0dcc1bb/attachment.html>

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: <c5275ba3-7192-8eae-a2ab-f8e7d7dbc154@python.org>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org>
 <CA+3bQGEGmLJCiD++Jsh79G3J2K17u0t7WB2vqdoO5dC5zyeivw@mail.gmail.com>
 <c5275ba3-7192-8eae-a2ab-f8e7d7dbc154@python.org>
Message-ID: <CA+3bQGGi_1yYoAhqxz-Euq0gT+tgVenM7wK7DfJ5Fv-kWyfX0g@mail.gmail.com>

2018-07-19 0:36 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> 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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>
Message-ID: <CAP1=2W4=R9mfp8q2eMF41=MWQZom7TKU_h2yH2pW+qz6NV3XTA@mail.gmail.com>

On Wed, 18 Jul 2018 at 15:46 Donald Stufft <donald at stufft.io> wrote:

>
>
> > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa <lukasz at langa.pl> wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/e285a149/attachment.html>

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: <B26F3385-3C9C-43DC-85D8-EEA099DD1852@langa.pl>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <8ec3b4fa-e640-8628-9e9b-7526755a8a66@python.org>
 <B26F3385-3C9C-43DC-85D8-EEA099DD1852@langa.pl>
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: <CAGbohnYZqZVWpWE5bvwwC_SabOqtvUyVd5SsYXOLGs-CWfPydA@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
 <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
 <24BF8222-C3E0-4AB7-B3F4-8296EAF2B3FB@python.org>
 <CAGbohnYZqZVWpWE5bvwwC_SabOqtvUyVd5SsYXOLGs-CWfPydA@mail.gmail.com>
Message-ID: <CAFT4OTGoZ_r=4QZByf+Q9xvR56wG02_nCuJWPwydgDzBE-x8Vw@mail.gmail.com>

On Wed, Jul 18, 2018 at 7:16 PM Mariatta Wijaya <mariatta.wijaya at gmail.com>
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.    <fred at fdrake.net>
"A storm broke loose in my mind."  --Albert Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180718/97c8f5a8/attachment.html>

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: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>
Message-ID: <CAE46Be_dEbgai_uRCReuRhEgTYESpGcm0NXG_CMpotVC8kbToQ@mail.gmail.com>

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 <donald at stufft.io> wrote:

>
>
> > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa <lukasz at langa.pl> wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/c5265101/attachment-0001.html>

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: <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
 <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
Message-ID: <CAE46Be_apGeOOF256_CaFBvJtOiBdGU2xs=NaU-pV-VYOCDvUQ@mail.gmail.com>

On Wed, Jul 18, 2018 at 4:09 PM Fred Drake <fred at fdrake.net> wrote:

> > On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya <mariatta.wijaya at gmail.com>
> 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 <lukasz at langa.pl> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/8919b844/attachment.html>

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: <CAE46Be_dEbgai_uRCReuRhEgTYESpGcm0NXG_CMpotVC8kbToQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>
 <CAE46Be_dEbgai_uRCReuRhEgTYESpGcm0NXG_CMpotVC8kbToQ@mail.gmail.com>
Message-ID: <CAP1=2W4RYvt59=nFX67ii8tjfR_1GzJcAJRO643+K-GhKrhLHg@mail.gmail.com>

[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 <donald at stufft.io> wrote:
>
>>
>>
>> > On Jul 18, 2018, at 6:18 PM, ?ukasz Langa <lukasz at langa.pl> wrote:
>> >
>> >
>> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/52bd6815/attachment-0001.html>

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: <CAP1=2W4RYvt59=nFX67ii8tjfR_1GzJcAJRO643+K-GhKrhLHg@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>
 <CAE46Be_dEbgai_uRCReuRhEgTYESpGcm0NXG_CMpotVC8kbToQ@mail.gmail.com>
 <CAP1=2W4RYvt59=nFX67ii8tjfR_1GzJcAJRO643+K-GhKrhLHg@mail.gmail.com>
Message-ID: <CAE46Be-EhK7TaFKm6wU67gBAs-W2zAVc6enDOVNkqVW=18uxqQ@mail.gmail.com>

Hi Brett,

On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/f2c39399/attachment.html>

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: <CAE46Be-EhK7TaFKm6wU67gBAs-W2zAVc6enDOVNkqVW=18uxqQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>
 <CAE46Be_dEbgai_uRCReuRhEgTYESpGcm0NXG_CMpotVC8kbToQ@mail.gmail.com>
 <CAP1=2W4RYvt59=nFX67ii8tjfR_1GzJcAJRO643+K-GhKrhLHg@mail.gmail.com>
 <CAE46Be-EhK7TaFKm6wU67gBAs-W2zAVc6enDOVNkqVW=18uxqQ@mail.gmail.com>
Message-ID: <CAP1=2W4cnDS0PydD69WW+HhSyqr6MC6Yn3kHxPeYnq5kTZNTOQ@mail.gmail.com>

On Wed, Jul 18, 2018, 18:09 Alex Martelli, <aleax at google.com> wrote:

> Hi Brett,
>
> On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/74fe4b6d/attachment.html>

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: <CAP1=2W4cnDS0PydD69WW+HhSyqr6MC6Yn3kHxPeYnq5kTZNTOQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAP1=2W6KZJAqcF+edsbaiWGWBZ3w7eyyeBLzcXmSsSn7n1X6BQ@mail.gmail.com>
 <AA126DC6-8BA8-4EB1-8639-3CD0235658A9@langa.pl>
 <07AB3BB5-5E75-4483-9202-E0577500A9D7@stufft.io>
 <CAE46Be_dEbgai_uRCReuRhEgTYESpGcm0NXG_CMpotVC8kbToQ@mail.gmail.com>
 <CAP1=2W4RYvt59=nFX67ii8tjfR_1GzJcAJRO643+K-GhKrhLHg@mail.gmail.com>
 <CAE46Be-EhK7TaFKm6wU67gBAs-W2zAVc6enDOVNkqVW=18uxqQ@mail.gmail.com>
 <CAP1=2W4cnDS0PydD69WW+HhSyqr6MC6Yn3kHxPeYnq5kTZNTOQ@mail.gmail.com>
Message-ID: <CAP1=2W7oCpc+_-zpo8ugO+w6BmEYjz4Gr1U=mR1MOJZt+RO49g@mail.gmail.com>

On Wed, Jul 18, 2018, 18:49 Brett Cannon, <brett at python.org> wrote:

>
>
> On Wed, Jul 18, 2018, 18:09 Alex Martelli, <aleax at google.com> wrote:
>
>> Hi Brett,
>>
>> On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/4c80da16/attachment.html>

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: <CAGbohnbaV+U2-2Z08Zyi=rOcnuw82mdCoeaDoTAXTsgf--rR+w@mail.gmail.com>
References: <20180718161156.GA5506@bytereef.org>
 <D55CBB46-5EC2-49F1-8E27-2BF5E04F127E@langa.pl>
 <CAGbohnbaV+U2-2Z08Zyi=rOcnuw82mdCoeaDoTAXTsgf--rR+w@mail.gmail.com>
Message-ID: <CAP1=2W5eUChjwQRTb_NE2=t+nu9eJBh7Ck-ej=eCqbjsNyQ5bQ@mail.gmail.com>

On Wed, Jul 18, 2018, 09:32 Mariatta Wijaya, <mariatta.wijaya at gmail.com>
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 <lukasz at langa.pl> 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 <stefan at bytereef.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/f674fd29/attachment-0001.html>

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: <CAExdVNk=HZS34pf372COApaXOqPzaU_cyU_u+JKtz3s1bLRohw@mail.gmail.com>

[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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/acdafb89/attachment.html>

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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>

[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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
Message-ID: <CAJ3HoZ33S_4o2+YndM8BhOuFFSZjp2de_79J1w5LAsJuUDvwrA@mail.gmail.com>

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 <njs at pobox.com> 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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <5B4FFD8D.3090604@stoneleaf.us>
Message-ID: <CAKJDb-MnBgaFuvyi5OVhepycL1B1auSVOjPWx=xJXpMtM-i5qA@mail.gmail.com>

+1

--
Zach
(On a phone)

On Wed, Jul 18, 2018, 21:54 Ethan Furman <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/a7f39d6e/attachment-0001.html>

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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
Message-ID: <CAE46Be8xngbDFECwdj1dCEAHnkS8aLLY+y3V7BH4+yhmTa1Y=g@mail.gmail.com>

FWIW, +1.

Alex

On Wed, Jul 18, 2018 at 7:36 PM Nathaniel Smith <njs at pobox.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/fe333d21/attachment.html>

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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
Message-ID: <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>


> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith <njs at pobox.com> 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: <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
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 <njs at pobox.com> 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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
Message-ID: <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>

+1


On Wed, Jul 18, 2018, 8:54 PM Ethan Furman <ethan at stoneleaf.us> wrote:

> On 07/18/2018 08:45 PM, ?ukasz Langa wrote:>
>  >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith <njs at pobox.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/6708c666/attachment-0001.html>

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: <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
Message-ID: <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>

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 <mariatta.wijaya at gmail.com>
wrote:

> +1
>
>
> On Wed, Jul 18, 2018, 8:54 PM Ethan Furman <ethan at stoneleaf.us> wrote:
>
>> On 07/18/2018 08:45 PM, ?ukasz Langa wrote:>
>>  >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith <njs at pobox.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/fc991d14/attachment.html>

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: <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
Message-ID: <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>

Thanks Ethan for clarifying. Totally cool if that is the case.

On Wed, Jul 18, 2018, 10:19 PM Ethan Furman <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/c56a78c8/attachment.html>

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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
Message-ID: <mailman.0.1531980324.5454.python-committers@python.org>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180718/74d1f1ba/attachment.html>

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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
Message-ID: <CA+St6D2bndkqhao6M5A=zJyRYhgfuCfyELGeHsSZCzZqPE7Q_Q@mail.gmail.com>

On Thu, Jul 19, 2018 at 5:36 AM Nathaniel Smith <njs at pobox.com> 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: <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>

Hi,

2018-07-18 18:11 GMT+02:00 Stefan Krah <stefan at bytereef.org>:
> 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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <2d496893-c63e-458c-087f-4d516d213644@python.org>
Message-ID: <CACac1F9Xx=gT8i24GUpSHka3d9vUA3uymKJT93CT2QtzBbKrQw@mail.gmail.com>

On 19 July 2018 at 08:33, Antoine Pitrou <antoine at python.org> 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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
Message-ID: <bc39f737-1ee6-0632-db65-73ce1687a233@hotpy.org>



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: <b781aeee-b2a4-0186-c7ee-8084b44d1cda@hastings.org>



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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/d863cb39/attachment-0001.html>

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: <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
References: <20180718161156.GA5506@bytereef.org>
 <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
Message-ID: <CAP1=2W4-Ny21pv=dNeZ-TakKUp7VysKGbUuL-ThnupCnuPwJLw@mail.gmail.com>

On Thu, Jul 19, 2018, 01:24 Victor Stinner, <vstinner at redhat.com> wrote:

> Hi,
>
> 2018-07-18 18:11 GMT+02:00 Stefan Krah <stefan at bytereef.org>:
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/d90a7e46/attachment.html>

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: <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
Message-ID: <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>

On Wed, Jul 18, 2018, 22:32 Carol Willing, <willingc at gmail.com> wrote:

> Thanks Ethan for clarifying. Totally cool if that is the case.
>
> On Wed, Jul 18, 2018, 10:19 PM Ethan Furman <ethan at stoneleaf.us> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/c2cb104b/attachment.html>

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: <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
Message-ID: <CAGbohnba4znw9+wTaVzaaOCkztsaO8MEeVa3Z4686VCZu03w0A@mail.gmail.com>

On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/88dd548b/attachment.html>

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: <CAGbohnba4znw9+wTaVzaaOCkztsaO8MEeVa3Z4686VCZu03w0A@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <CAGbohnba4znw9+wTaVzaaOCkztsaO8MEeVa3Z4686VCZu03w0A@mail.gmail.com>
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 <brett at python.org 
> <mailto:brett at python.org>> 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: <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
Message-ID: <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>

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 <brett at python.org <mailto:brett at python.org>> wrote:
> 
> 
> 
> On Wed, Jul 18, 2018, 22:32 Carol Willing, <willingc at gmail.com <mailto:willingc at gmail.com>> wrote:
> Thanks Ethan for clarifying. Totally cool if that is the case.
> 
> On Wed, Jul 18, 2018, 10:19 PM Ethan Furman <ethan at stoneleaf.us <mailto:ethan at stoneleaf.us>> 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 <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180719/603855a4/attachment-0001.html>

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: <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <CAGbohnba4znw9+wTaVzaaOCkztsaO8MEeVa3Z4686VCZu03w0A@mail.gmail.com>
 <4f26cd3d-edaa-f5c2-d503-9c6af6746ab1@udel.edu>
Message-ID: <B6DD24D2-9C72-4AC3-921E-CA5D5F0C4ACC@python.org>

On Jul 19, 2018, at 10:19, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> On 7/19/2018 1:10 PM, Mariatta Wijaya wrote:
>> On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon <brett at python.org <mailto:brett at python.org>> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/ae21dddf/attachment.sig>

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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
Message-ID: <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>

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 <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/afd3ad02/attachment.html>

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: <CAP1=2W4-Ny21pv=dNeZ-TakKUp7VysKGbUuL-ThnupCnuPwJLw@mail.gmail.com>
References: <20180718161156.GA5506@bytereef.org>
 <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
 <CAP1=2W4-Ny21pv=dNeZ-TakKUp7VysKGbUuL-ThnupCnuPwJLw@mail.gmail.com>
Message-ID: <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org>

On Jul 19, 2018, at 08:41, Brett Cannon <brett at python.org> 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 <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/189e682d/attachment-0001.sig>

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: <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
Message-ID: <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>


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 <antoine at python.org
> <mailto:antoine at python.org>> 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 <mailto: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>
 <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
 <CAP1=2W4-Ny21pv=dNeZ-TakKUp7VysKGbUuL-ThnupCnuPwJLw@mail.gmail.com>
 <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: <CAE46Be_apGeOOF256_CaFBvJtOiBdGU2xs=NaU-pV-VYOCDvUQ@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <8b711aa3-0794-4010-ffa0-e3d5641050c9@python.org>
 <5B4F0D2E.80702@stoneleaf.us>
 <c9ad88a7-e962-0af9-b959-ae107af6d56d@python.org>
 <5B4F63BE.6090300@stoneleaf.us>
 <014E3722-F64F-4827-9ECF-2D4C9F06830D@langa.pl>
 <5B4F70D3.6050301@stoneleaf.us>
 <ED519F34-8FE1-4A33-96D4-F518D0853E6A@langa.pl>
 <CAE46Be8hY6h407B=LYpHYVTp4GdjM5KUK-h_LGPVkEpqd-P3TQ@mail.gmail.com>
 <8DA3B181-F9A6-4E21-8060-976622BBD7E2@langa.pl>
 <CAGbohnYrJ48UH601TJoOVtBBbw0Fh-HDsZGQy+kG8uwQr6zxGA@mail.gmail.com>
 <D79611ED-408E-4AC0-BE5E-51477B87DD87@langa.pl>
 <CAFT4OTEmwU7rXC70Lwcfyqdqgg4N0KzHajGVzoV+rsA=i_hxmg@mail.gmail.com>
 <CAE46Be_apGeOOF256_CaFBvJtOiBdGU2xs=NaU-pV-VYOCDvUQ@mail.gmail.com>
Message-ID: <AB68C59E-F90F-4633-A98C-ABC71526E709@python.org>

On Jul 18, 2018, at 17:31, Alex Martelli via python-committers <python-committers at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/7f5c0870/attachment.sig>

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: <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
Message-ID: <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>


> On Jul 19, 2018, at 11:52 AM, Doug Hellmann <doug at doughellmann.com> 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: <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
Message-ID: <CAP1=2W5KYQgqR8pmBfcsTFRiV7Jd0seBLb9f2JwHsg3HBMZmYw@mail.gmail.com>

On Thu, 19 Jul 2018 at 11:52 Doug Hellmann <doug at doughellmann.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/800e2cb5/attachment.html>

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>
 <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
 <CAP1=2W4-Ny21pv=dNeZ-TakKUp7VysKGbUuL-ThnupCnuPwJLw@mail.gmail.com>
 <13E0EEAD-0EE6-4146-A736-BD56411B0977@python.org>
Message-ID: <CAP1=2W4CMgL84YiZ_UYo3Mu-mNyE+r=08njedF7hNapce9GeAA@mail.gmail.com>

On Thu, 19 Jul 2018 at 11:04 Barry Warsaw <barry at python.org> wrote:

> On Jul 19, 2018, at 08:41, Brett Cannon <brett at python.org> 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 <tim.peters at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/62149d96/attachment.html>

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: <CAP1=2W5KYQgqR8pmBfcsTFRiV7Jd0seBLb9f2JwHsg3HBMZmYw@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <CAP1=2W5KYQgqR8pmBfcsTFRiV7Jd0seBLb9f2JwHsg3HBMZmYw@mail.gmail.com>
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 <doug at doughellmann.com> 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: <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
References: <20180718161156.GA5506@bytereef.org>
 <CA+3bQGHQZ1r3iyBsdys7rikxJ08mBvuWsmtZFHkHFpaU-_73Xw@mail.gmail.com>
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: <CAP1=2W5KYQgqR8pmBfcsTFRiV7Jd0seBLb9f2JwHsg3HBMZmYw@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <CAP1=2W5KYQgqR8pmBfcsTFRiV7Jd0seBLb9f2JwHsg3HBMZmYw@mail.gmail.com>
Message-ID: <CACac1F9i9Yr6dBzLBnXD4cHoO2pu-FdGuepMV-Uj7pGmEAT0TQ@mail.gmail.com>

On 19 July 2018 at 20:44, Brett Cannon <brett at python.org> 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: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
Message-ID: <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>

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 <antoine at 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.
> _______________________________________________
> 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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20180719/ab67b135/attachment.html>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
Message-ID: <f4d51184-82cf-2314-4eb0-ea6b17c5d107@python.org>


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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
Message-ID: <ace81b43-4f78-0333-9764-0bd48696e0b5@python.org>


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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
Message-ID: <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>

Hi Ethan,

Thanks for your feedback!

2018-07-20 2:51 GMT+02:00 Ethan Furman <ethan at stoneleaf.us>:
>> 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: <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
Message-ID: <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>

On 20 July 2018 at 12:57, Victor Stinner <vstinner at redhat.com> 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: <f4d51184-82cf-2314-4eb0-ea6b17c5d107@python.org>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <f4d51184-82cf-2314-4eb0-ea6b17c5d107@python.org>
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: <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
 <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
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 <vstinner at redhat.com> 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: <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
 <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
Message-ID: <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>

On 18 July 2018 at 16:42, Chris Jerdonek <chris.jerdonek at gmail.com> 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: <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
 <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
 <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>
Message-ID: <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>

On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan at gmail.com> wrote:

> On 18 July 2018 at 16:42, Chris Jerdonek <chris.jerdonek at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/81be33f4/attachment.html>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
 <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
 <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: <ace81b43-4f78-0333-9764-0bd48696e0b5@python.org>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <ace81b43-4f78-0333-9764-0bd48696e0b5@python.org>
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: <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
Message-ID: <ae22de73-6cd7-d50d-c57e-0e375186475f@python.org>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
 <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
 <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: <f4d51184-82cf-2314-4eb0-ea6b17c5d107@python.org>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <f4d51184-82cf-2314-4eb0-ea6b17c5d107@python.org>
Message-ID: <CBD2CF48-A1B9-470A-97A4-DDF0DCD010DC@python.org>

On Jul 20, 2018, at 00:49, Antoine Pitrou <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/595cc098/attachment.sig>

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: <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
 <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
 <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>
 <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>
Message-ID: <ebbd7b6a-2d3d-3f60-b85e-78d77e1b304e@python.org>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
Message-ID: <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io>


> On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner at redhat.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/dbaae407/attachment.html>

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: <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
Message-ID: <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>

On Thu, 19 Jul 2018 at 14:59 Victor Stinner <vstinner at redhat.com> 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 <antoine at 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.
> > _______________________________________________
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/a91f9781/attachment-0001.html>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
Message-ID: <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>

On Thu, 19 Jul 2018 at 16:47 Victor Stinner <vstinner at redhat.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/d4634e2f/attachment.html>

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: <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
Message-ID: <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>

2018-07-20 22:42 GMT+02:00 Brett Cannon <brett at python.org>:
> 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: <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
 <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
 <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>
 <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>
Message-ID: <CAPJVwB=uSq=VAGv6jnkPSKhYPQrPSEP_WcmQ2aWzyYnP+zGY9w@mail.gmail.com>

On Fri, Jul 20, 2018, 08:58 Brett Cannon <brett at python.org> wrote:
>
>
>
> On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan at gmail.com> 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: <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
 <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
Message-ID: <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>

On Fri, 20 Jul 2018 at 15:23 Victor Stinner <vstinner at redhat.com> wrote:

> 2018-07-20 22:42 GMT+02:00 Brett Cannon <brett at python.org>:
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/099f7c76/attachment-0001.html>

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: <CAPJVwB=uSq=VAGv6jnkPSKhYPQrPSEP_WcmQ2aWzyYnP+zGY9w@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
 <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
 <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>
 <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>
 <CAPJVwB=uSq=VAGv6jnkPSKhYPQrPSEP_WcmQ2aWzyYnP+zGY9w@mail.gmail.com>
Message-ID: <CAP1=2W7ryK5AtgRq0M7drZckNKUM6HDDsq3ED3KneQtqU0W7Zw@mail.gmail.com>

On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Jul 20, 2018, 08:58 Brett Cannon <brett at python.org> wrote:
> >
> >
> >
> > On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/46072ecd/attachment.html>

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: <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
 <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
 <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>
Message-ID: <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/711d67a7/attachment.html>

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: <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
 <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
 <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>
 <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>
Message-ID: <CAM3VvhxGnTFB7HNq+j4z6yU3ddSo3bJ6qVcTx4vAe1VSrwwWPg@mail.gmail.com>

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 <mariatta.wijaya at gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/317c276e/attachment-0001.html>

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: <CAM3VvhxGnTFB7HNq+j4z6yU3ddSo3bJ6qVcTx4vAe1VSrwwWPg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
 <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
 <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>
 <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>
 <CAM3VvhxGnTFB7HNq+j4z6yU3ddSo3bJ6qVcTx4vAe1VSrwwWPg@mail.gmail.com>
Message-ID: <CAP1=2W6exRfXr1z8ky+HFHdUisVU_W6jS47XECJLD3+jWO9PuQ@mail.gmail.com>

On Fri, 20 Jul 2018 at 16:25 Carol Willing <willingc at gmail.com> 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 <mariatta.wijaya at gmail.com>
> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/70035761/attachment.html>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
 <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
 <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info>
Message-ID: <CA+3bQGG4GkQr+kJGH-GM6CRkR2iA8mCRFJ6mEDjjsgnS20M6tw@mail.gmail.com>

2018-07-20 18:32 GMT+02:00 Steven D'Aprano <steve at pearwood.info>:
> 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: <CAP1=2W7ryK5AtgRq0M7drZckNKUM6HDDsq3ED3KneQtqU0W7Zw@mail.gmail.com>
References: <B2242542-C86B-47CA-B82A-D1FC56E2BF4C@python.org>
 <CAExdVNnpLt_9E8djY8vktA0t7oW758MpZrsrB1o0mQqJus_0hA@mail.gmail.com>
 <CAAzeMbzcjK-6TeW1GWCFbsXNh-sA_vr1g2gBg046OZuHVr98Mg@mail.gmail.com>
 <CAOTb1wd=0OQvonfJv0Pco7pqQzHobbrXfbiUWsO9X9kMZOrbUA@mail.gmail.com>
 <CADiSq7f5ShXCtpPa=HQfBJj2AzUCCuFC2wckkPqw70YaXYuMew@mail.gmail.com>
 <CAP1=2W65Hz7xxkwYLV0gQr8ZJe3KyfkRBhBGNu59mkpn9=LaQw@mail.gmail.com>
 <CAPJVwB=uSq=VAGv6jnkPSKhYPQrPSEP_WcmQ2aWzyYnP+zGY9w@mail.gmail.com>
 <CAP1=2W7ryK5AtgRq0M7drZckNKUM6HDDsq3ED3KneQtqU0W7Zw@mail.gmail.com>
Message-ID: <CAPJVwBkfPw0RvRuZ3F+4N5Ca=jqS=UVtO4KtbfnyFjHzEAQJGA@mail.gmail.com>

On Fri, Jul 20, 2018 at 3:50 PM, Brett Cannon <brett at python.org> wrote:
>
>
> On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith <njs at pobox.com> wrote:
>>
>> On Fri, Jul 20, 2018, 08:58 Brett Cannon <brett at python.org> 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: <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
 <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
 <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>
 <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>
Message-ID: <CA+3bQGHHsAFhVZE77RCCW3rhuiSLq2DWDRph9iN=-dGZZrnjTg@mail.gmail.com>

2018-07-21 0:58 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
> 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: <CA+3bQGHHsAFhVZE77RCCW3rhuiSLq2DWDRph9iN=-dGZZrnjTg@mail.gmail.com>
References: <CAPJVwB=MY2N2O4u6-4u4Mpeq2+eWpvrgtZBn=zz219F5=ZV2Vg@mail.gmail.com>
 <EBFD313A-FB5F-4D08-BA1E-52274E20CADA@langa.pl>
 <5B500BA5.5010802@stoneleaf.us>
 <CAGbohnaVx58xWwKn8DLFBvtqvPj4zYyvFsJv07f=8t1FyZhs4w@mail.gmail.com>
 <CAM3VvhwnJecu05FOsGNY5WBaThiDa28SFs600cLmXNzXcNC+cw@mail.gmail.com>
 <5B501F5C.3090401@stoneleaf.us>
 <CAM3VvhxdSiz7vfZju8i6fUtJzikLDaMfHPu2xzs-mBAh3muTAg@mail.gmail.com>
 <CAP1=2W4yHrOvmfpM-TDQ9KqZontn+1nXoK0PmRgUc5Bu3W4iug@mail.gmail.com>
 <D1E1869D-F937-44B5-A437-BA0066B1C0A0@gmail.com>
 <767aed93-6cf0-e1f4-4a10-878a3941d5cd@python.org>
 <CAM3Vvhz2Sb_Bg1scLLU4BNzs6fv9fdk9FXMfzefw5SroNgRz6A@mail.gmail.com>
 <c580ffca-e9c2-4b69-0e43-084bebdd0ef9@python.org>
 <1532026123-sup-9946@lrrr.local>
 <A0598301-6C35-42EC-97C1-275DFCA929D5@gmail.com>
 <53e93add-972b-2fe4-877d-e15552a86993@python.org>
 <CA+3bQGGDmbBOOyn=cZjoVsDpMi+sjXMwN4srJ0OqgwjO=uOumA@mail.gmail.com>
 <CAP1=2W4G9bWQP4d23SLB=qh2ujL38n5MRon3UnCSymmbyQaaFA@mail.gmail.com>
 <CA+3bQGEbG6PkOejOnQVLMLEfi+eicBw11M=ce5nTKXi5vLqPWQ@mail.gmail.com>
 <CAP1=2W50XJ0YtqA=QUCmdJMFRZ=kzkG4M39Qty9ynKB4MotHQw@mail.gmail.com>
 <CAGbohnbVHDFxWvnHCFWk90srQ7HDCYdSYGHsV0zVib6r-zyA+A@mail.gmail.com>
 <CA+3bQGHHsAFhVZE77RCCW3rhuiSLq2DWDRph9iN=-dGZZrnjTg@mail.gmail.com>
Message-ID: <CAP1=2W69uTjGQNKpTEakqOdZyaC0Z51owTkXNtv-6vLPn=OTRg@mail.gmail.com>

On Fri, 20 Jul 2018 at 17:05 Victor Stinner <vstinner at redhat.com> wrote:

> 2018-07-21 0:58 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180720/05be0d70/attachment.html>

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: <CA+3bQGG4GkQr+kJGH-GM6CRkR2iA8mCRFJ6mEDjjsgnS20M6tw@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
 <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
 <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info>
 <CA+3bQGG4GkQr+kJGH-GM6CRkR2iA8mCRFJ6mEDjjsgnS20M6tw@mail.gmail.com>
Message-ID: <CAP1=2W7FLs3+BNn9wqJ0E3CEUri775FVVXj5VLxxDpAU444D7g@mail.gmail.com>

On Fri, Jul 20, 2018, 17:03 Victor Stinner, <vstinner at redhat.com> wrote:

> 2018-07-20 18:32 GMT+02:00 Steven D'Aprano <steve at pearwood.info>:
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180721/d662d2fb/attachment.html>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5B513222.8020303@stoneleaf.us>
 <CA+3bQGGrR-KCeJdnHP0D8E=QtTr4n4nOipANbNryLov25hbw+g@mail.gmail.com>
 <CACac1F8G+=bqVDK-_RR85P842BZoPOYqcoF+iXsWi86U98=wRw@mail.gmail.com>
 <1532097235-sup-9701@lrrr.local> <20180720163201.GC8744@ando.pearwood.info>
Message-ID: <a4d63bfd-a879-b486-5ea6-1dfd498f89a9@python.org>


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: <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
Message-ID: <ec546876-0023-e615-f1a2-b8ed024ad832@python.org>


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: <ec546876-0023-e615-f1a2-b8ed024ad832@python.org>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
 <ec546876-0023-e615-f1a2-b8ed024ad832@python.org>
Message-ID: <CAP1=2W6maPdtYMF7xjGHyL69W6a-_WEHm9ZJo1Kr0dosPVQT-A@mail.gmail.com>

On Mon, Jul 23, 2018, 01:11 Antoine Pitrou, <antoine at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180723/216a2be3/attachment.html>

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: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io>
Message-ID: <CADiSq7eEC17suHDkRqkS3QeX9dwWuYx4r=rmmHbLv8E6KOZAiA@mail.gmail.com>

On 21 July 2018 at 04:30, Donald Stufft <donald at stufft.io> wrote:
>
> On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner at redhat.com> 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: <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
Message-ID: <CADiSq7edYzPJWBwJb3jpAiEMtjk_fbBOU-wNgxqO-5kRhzuqiw@mail.gmail.com>

On 21 July 2018 at 07:14, Brett Cannon <brett at python.org> wrote:
> On Thu, 19 Jul 2018 at 16:47 Victor Stinner <vstinner at redhat.com> 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: <CADiSq7eEC17suHDkRqkS3QeX9dwWuYx4r=rmmHbLv8E6KOZAiA@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <5BD69DF2-7B57-4B33-B1EE-E698B49A195B@stufft.io>
 <CADiSq7eEC17suHDkRqkS3QeX9dwWuYx4r=rmmHbLv8E6KOZAiA@mail.gmail.com>
Message-ID: <CAP1=2W5LhBu1uxV-=gtvsiX8i_yBZxfy1JPQZ+0wt5EouaM9xA@mail.gmail.com>

On Tue, 24 Jul 2018 at 07:46 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 21 July 2018 at 04:30, Donald Stufft <donald at stufft.io> wrote:
> >
> > On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner at redhat.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180724/f4900582/attachment.html>

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: <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
Message-ID: <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>

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: <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
 <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
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: <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
 <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
Message-ID: <CAP1=2W47eFLPEnq_wvnYHocvqZ+1FauTxYd74H3jfb-P0eLX6g@mail.gmail.com>

On Tue, 24 Jul 2018 at 16:51 Victor Stinner <vstinner at redhat.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180725/4d5928a9/attachment.html>

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: <CAP1=2W47eFLPEnq_wvnYHocvqZ+1FauTxYd74H3jfb-P0eLX6g@mail.gmail.com>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
 <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
 <CAP1=2W47eFLPEnq_wvnYHocvqZ+1FauTxYd74H3jfb-P0eLX6g@mail.gmail.com>
Message-ID: <AED9FF63-7B16-43FE-86B5-EA73F3318938@stufft.io>



> On Jul 25, 2018, at 2:01 PM, Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180725/cdc1aaf0/attachment.html>

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: <AED9FF63-7B16-43FE-86B5-EA73F3318938@stufft.io>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
 <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
 <CAP1=2W47eFLPEnq_wvnYHocvqZ+1FauTxYd74H3jfb-P0eLX6g@mail.gmail.com>
 <AED9FF63-7B16-43FE-86B5-EA73F3318938@stufft.io>
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 <brett at python.org
>> <mailto:brett at python.org>> 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: <AED9FF63-7B16-43FE-86B5-EA73F3318938@stufft.io>
References: <CA+3bQGH54jDOsiiZFFqxxx7cb15-VamMeZVgn9g1jQAF4TLpJQ@mail.gmail.com>
 <CAP1=2W5J6KPVO6O4o5C9f8yYtVkdVLrraNHvzUM5zijvMSuFBQ@mail.gmail.com>
 <CA+3bQGH4Nr_mSj_rVc1tkCt1J+hZC-UjuZ_Qt2=bM+9j7Cd6SA@mail.gmail.com>
 <CAP1=2W47eFLPEnq_wvnYHocvqZ+1FauTxYd74H3jfb-P0eLX6g@mail.gmail.com>
 <AED9FF63-7B16-43FE-86B5-EA73F3318938@stufft.io>
Message-ID: <CAFRnB2Vs0RqsxvqhviQX5O5AvwFKkDqvtBeDGB6BL1FNCxOLKQ@mail.gmail.com>

On Wed, Jul 25, 2018 at 7:24 PM Donald Stufft <donald at stufft.io> wrote:

>
>
> On Jul 25, 2018, at 2:01 PM, Brett Cannon <brett at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20180725/f4bfc23f/attachment-0001.html>

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: <CAGbohnbSoM+O0YH796ERVqFYVDH=JFv+RkgOYSAhKM+F1Fr9Yg@mail.gmail.com>
References: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>
 <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>
 <CA+3bQGGxKFTdharHKzp1Jgx9UgWzB6LvSvnVuXf0QnwB+eXLVw@mail.gmail.com>
 <CAGbohnbSoM+O0YH796ERVqFYVDH=JFv+RkgOYSAhKM+F1Fr9Yg@mail.gmail.com>
Message-ID: <CAGbohnaWGGBtiGcpWKHO-8RvxYWV4JyOTLHwBQa_UQrHe7YwjQ@mail.gmail.com>

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 <mariatta.wijaya at gmail.com>
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 <vstinner at redhat.com>
> wrote:
>
>> 2018-05-16 11:31 GMT-04:00 Victor Stinner <vstinner at redhat.com>:
>> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180727/b35b5110/attachment.html>

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: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
Message-ID: <CA+3bQGFCbYTcYnNZ4qUzbav-++f9RkFfAGekPKPz6DoHk+z52w@mail.gmail.com>

Hi,

2018-06-19 19:43 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> 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: <CA+3bQGFCbYTcYnNZ4qUzbav-++f9RkFfAGekPKPz6DoHk+z52w@mail.gmail.com>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
 <CA+3bQGFCbYTcYnNZ4qUzbav-++f9RkFfAGekPKPz6DoHk+z52w@mail.gmail.com>
Message-ID: <CAP1=2W58ow07OatfXDw8H19vZhUM83EDH9rFf1=+AJ+K_CbG4g@mail.gmail.com>

On Tue, 31 Jul 2018 at 03:27 Victor Stinner <vstinner at redhat.com> wrote:

> Hi,
>
> 2018-06-19 19:43 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> > 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: <http://mail.python.org/pipermail/python-committers/attachments/20180731/e4d0495d/attachment.html>

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: <CAP1=2W58ow07OatfXDw8H19vZhUM83EDH9rFf1=+AJ+K_CbG4g@mail.gmail.com>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
 <CA+3bQGFCbYTcYnNZ4qUzbav-++f9RkFfAGekPKPz6DoHk+z52w@mail.gmail.com>
 <CAP1=2W58ow07OatfXDw8H19vZhUM83EDH9rFf1=+AJ+K_CbG4g@mail.gmail.com>
Message-ID: <CA+3bQGE5Zi4445q8o+=dHqCE+7tr49YhVeihEew4T0zKQiACHw@mail.gmail.com>

2018-07-31 18:47 GMT+02:00 Brett Cannon <brett at python.org>:
> 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