Re: [python-committers] Transfer of power

[Chris Jerdonek]

On Sun, Jul 15, 2018 at 6:07 PM Brett Cannon  wrote:

> On Sat, 14 Jul 2018 at 11:37 Tim Peters  wrote:
>
>> [Tim]
>>
>>> > If there are 3 Elders [snip]
>>>
>>
>> [Łukasz Langa]
>>
>> It looks like the number 3 is popular in this context. What makes it so
>>> attractive?
>>>
>>
>> Likely because it was the first specific non-insane number someone
>> mentioned.  It helps to be concrete, but I don't know that anyone is wedded
>> to 3.
>>
>>
>>> I see a bunch of problems with such a low number, like the ability for a
>>> single corporation to take over the design process of Python by employing
>>> just two of the three members (consistently voting over the third one).
>>
>>
>> Perhaps then you don't want a "supreme court" at all.  We've been living
>> for decades with the possibility that a single corporation could buy off
>> Guido.  Would it really help to change 3 to 5?  Then Evil Corp only needs
>> to buy off 3 - but the larger the number, the more likely Evil Corp will
>> get some votes in its favor without needing to pay.
>>
>> If semi-dictators are part of the New Order at all, they need to be
>> trusted a whole lot (although I suggested a mechanism for impeachment too).
>>
>>
>>
>>> 3 also has high likelihood of ties if one of the members abstains.
>>
>>
>> I don't care about that.  How often did Guido abstain?  it's an Elder's
>> _job_ to make potentially unpopular decisions.  If one abstained without
>> extraordinarily solid reason, I'd move to impeach them - they're not doing
>> the job in that case.
>>
>> If they tied, that's fine too.  Ties favor the status quo (same as if the
>> proposed change had been rejected).  For that reason, I'm not even wedded
>> to an odd number.
>>
>
> That's a good point. Since this is typically going to be a yes/no question
> instead of an A/B question, ties that go in favour of the status quo aren't
> a stalemate issue.
>

I don’t think we should assume that a stalemate would be okay in all cases.
There may be cases in which a decision has to be made (e.g. if nothing
changes, bad things will happen). I think one of the most important roles a
BDFL serves is to provide a mechanism of last resort to resolve such
stalemates should they ever arise. If the replacement we come up with can
itself stalemate, I think there will be a problem.

—Chris



> -Brett
>
>
>>
>>
>>
>>> And so on.
>>>
>>
>> Likewise in the other direction.  For example, how many "extremely
>> trusted" people can we even get to volunteer for a contentious, long-term,
>> non-paying job?  I don't know.  "3" probably started with the first person
>> here who suggested specific names and could only come up with 3 ;-)
>>
>>
>> Taking a step back, before we talk names, term limits and even numbers of
>>> council members, Python needs a "constitution" which will codify what the
>>> council is and how it functions.
>>
>>
>> "Feedback loops" - all decisions feed into each other, in all
>> directions.  For example, the number of people on the council has real
>> effects on what it's _possible_ for it do, and on how it functions.  It
>> doesn't hurt to think about everything at once ;-)
>>
>>
>>  Barry calls it PEP 2 but I'd like to understand who is supposed to
>>> author it and who is supposed to accept it.
>>
>>
>>> Any committer is in a position to suggest parts of or the entirety of
>>> such a document. Otherwise we create a fractal problem of who and how
>>> decides on who shouId be writing it. Ultimately we are volunteers, the ones
>>> who step up and do the work.
>>>
>>
>>  Sure!
>>
>> Ideally Guido would accept the PEP but I'm not sure if he is willing to.
>>
>>
>> His initial message here seemed very clear that he wants us to "figure
>> something out for yourselves".  He's tired of the battles, and perhaps you
>> have to be as old as him (as I was 4 years ago) to grasp what "bone weary"
>> really means ;-)
>>
>>
>>> If that is indeed the case then how should this be done so that the
>>> document is universally accepted by all committers?
>>>
>>
>> Perhaps it won't be - after all, much of the point to a
>> dictator-workalike is that universal acceptance is a rare thing in real
>> life. Guido left us with an interesting puzzle to solve :-)
>>
>> ___
>> python-committers mailing list
>> python-committers@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@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Sat, 14 Jul 2018 at 11:37 Tim Peters  wrote:

> [Tim]
>
>> > If there are 3 Elders [snip]
>>
>
> [Łukasz Langa]
>
> It looks like the number 3 is popular in this context. What makes it so
>> attractive?
>>
>
> Likely because it was the first specific non-insane number someone
> mentioned.  It helps to be concrete, but I don't know that anyone is wedded
> to 3.
>
>
>> I see a bunch of problems with such a low number, like the ability for a
>> single corporation to take over the design process of Python by employing
>> just two of the three members (consistently voting over the third one).
>
>
> Perhaps then you don't want a "supreme court" at all.  We've been living
> for decades with the possibility that a single corporation could buy off
> Guido.  Would it really help to change 3 to 5?  Then Evil Corp only needs
> to buy off 3 - but the larger the number, the more likely Evil Corp will
> get some votes in its favor without needing to pay.
>
> If semi-dictators are part of the New Order at all, they need to be
> trusted a whole lot (although I suggested a mechanism for impeachment too).
>
>
>
>> 3 also has high likelihood of ties if one of the members abstains.
>
>
> I don't care about that.  How often did Guido abstain?  it's an Elder's
> _job_ to make potentially unpopular decisions.  If one abstained without
> extraordinarily solid reason, I'd move to impeach them - they're not doing
> the job in that case.
>
> If they tied, that's fine too.  Ties favor the status quo (same as if the
> proposed change had been rejected).  For that reason, I'm not even wedded
> to an odd number.
>

That's a good point. Since this is typically going to be a yes/no question
instead of an A/B question, ties that go in favour of the status quo aren't
a stalemate issue.

-Brett


>
>
>
>> And so on.
>>
>
> Likewise in the other direction.  For example, how many "extremely
> trusted" people can we even get to volunteer for a contentious, long-term,
> non-paying job?  I don't know.  "3" probably started with the first person
> here who suggested specific names and could only come up with 3 ;-)
>
>
> Taking a step back, before we talk names, term limits and even numbers of
>> council members, Python needs a "constitution" which will codify what the
>> council is and how it functions.
>
>
> "Feedback loops" - all decisions feed into each other, in all directions.
> For example, the number of people on the council has real effects on what
> it's _possible_ for it do, and on how it functions.  It doesn't hurt to
> think about everything at once ;-)
>
>
>  Barry calls it PEP 2 but I'd like to understand who is supposed to author
>> it and who is supposed to accept it.
>
>
>> Any committer is in a position to suggest parts of or the entirety of
>> such a document. Otherwise we create a fractal problem of who and how
>> decides on who shouId be writing it. Ultimately we are volunteers, the ones
>> who step up and do the work.
>>
>
>  Sure!
>
> Ideally Guido would accept the PEP but I'm not sure if he is willing to.
>
>
> His initial message here seemed very clear that he wants us to "figure
> something out for yourselves".  He's tired of the battles, and perhaps you
> have to be as old as him (as I was 4 years ago) to grasp what "bone weary"
> really means ;-)
>
>
>> If that is indeed the case then how should this be done so that the
>> document is universally accepted by all committers?
>>
>
> Perhaps it won't be - after all, much of the point to a dictator-workalike
> is that universal acceptance is a rare thing in real life. Guido left us
> with an interesting puzzle to solve :-)
>
> ___
> python-committers mailing list
> python-committers@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Summarizing our discussion about Governance

[Carol Willing]

Hi folks,

There have been lots of good comments the past few days. 

For those who are interested, I've compiled a Markdown document that pulls out 
and summarizes many comments. The  document builds around the questions/issues 
that Guido posed in his message.

We've been using Hackmd for collaborative writing for Project Jupyter for a 
while. It's similar to etherpad but with some additional versioning - if you 
have a GitHub account you can authenticate to make edits. 

This is a working document so please feel free to make edits. If you are adding 
content, please keep it brief and try to avoid personal names or attributions 
to yourself or others. As this is a gathering of information, the source of the 
information is less important than the information itself.

https://hackmd.io/s/BJPaxUFX7 

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


To edit: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?edit 


Note: I got about 80% through the messages on python-committers, but need to 
travel now. Will add the rest tomorrow or others please feel free to do so (I 
left off with Barry's July 12 14:53:18 message.

Carol

‌Carol Willing‌

Research Software Engineer
Project Jupyter at Cal Poly State University, San Luis Obispo
@willingc on GitHub and @willingcarol on Twitter

Signature Strengths
Empathy - Relator - Ideation - Strategic - Learner

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Guido van Rossum]

I’m still here, but I would like to be out of the debate and out of the
decision loop. I’m also still President of the PSF. But this is not for the
PSF to decide. You all are doing fine.

—Guido

On Sun, Jul 15, 2018 at 1:37 PM Brett Cannon  wrote:

>
>
> On Sun, Jul 15, 2018, 13:01 Thomas Wouters,  wrote:
>
>> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov 
>> wrote:
>>
>>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  wrote:
>>> [..]
>>> >> Ideally Guido would accept the PEP but I'm not sure if he is willing
>>> to. If that is indeed the case then how should this be done so that the
>>> document is universally accepted by all committers?
>>> >
>>> >
>>> > In my ideal scenario, people write up PEPs proposing a governance
>>> model and Guido chooses one, making it PEP 2.
>>>
>>>
>>> That would be indeed the ideal scenario, legitimizing the whole thing.
>>>
>>
>> I don't know how to read these comments... Are you afraid Guido wouldn't
>> accept the proposed arrangement, or are people really doubting that Guido
>> is still involved in this decision? I've seen the latter idea expressed by
>> non-core-developers, but to me, Guido's use of "try" (twice) and "we" in
>> his original email makes it clear that he's still involved; he just doesn't
>> want to (or can't) dictate what he'll be replaced by. If people feel like
>> Guido's participation in this is in doubt, should we just ask him to
>> confirm one way or the other? (You don't have to wait for an answer to that
>> question, Guido :)
>>
>
>
> For me, Guido's participation just hasn't been agreed to by him yet . I
> have viewed the retirement email as saying "you all have to decide how you
> want things to be as I'm not going to force something upon you" and not a
> mic drop of "I ain't participating". But Guido hasn't spoken up yet as I
> think he's still processing all of this. So I'm just hedging my phrasing in
> case he takes a pass.
>
> -Brett
>
>
>> --
>> Thomas Wouters 
>>
>> Hi! I'm an email virus! Think twice before sending your email to help me
>> spread!
>> ___
>> python-committers mailing list
>> python-committers@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@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Sun, Jul 15, 2018, 13:01 Thomas Wouters,  wrote:

> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov 
> wrote:
>
>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  wrote:
>> [..]
>> >> Ideally Guido would accept the PEP but I'm not sure if he is willing
>> to. If that is indeed the case then how should this be done so that the
>> document is universally accepted by all committers?
>> >
>> >
>> > In my ideal scenario, people write up PEPs proposing a governance model
>> and Guido chooses one, making it PEP 2.
>>
>>
>> That would be indeed the ideal scenario, legitimizing the whole thing.
>>
>
> I don't know how to read these comments... Are you afraid Guido wouldn't
> accept the proposed arrangement, or are people really doubting that Guido
> is still involved in this decision? I've seen the latter idea expressed by
> non-core-developers, but to me, Guido's use of "try" (twice) and "we" in
> his original email makes it clear that he's still involved; he just doesn't
> want to (or can't) dictate what he'll be replaced by. If people feel like
> Guido's participation in this is in doubt, should we just ask him to
> confirm one way or the other? (You don't have to wait for an answer to that
> question, Guido :)
>


For me, Guido's participation just hasn't been agreed to by him yet . I
have viewed the retirement email as saying "you all have to decide how you
want things to be as I'm not going to force something upon you" and not a
mic drop of "I ain't participating". But Guido hasn't spoken up yet as I
think he's still processing all of this. So I'm just hedging my phrasing in
case he takes a pass.

-Brett


> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
> ___
> python-committers mailing list
> python-committers@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Thomas Wouters]

On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov 
wrote:

> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  wrote:
> [..]
> >> Ideally Guido would accept the PEP but I'm not sure if he is willing
> to. If that is indeed the case then how should this be done so that the
> document is universally accepted by all committers?
> >
> >
> > In my ideal scenario, people write up PEPs proposing a governance model
> and Guido chooses one, making it PEP 2.
>
>
> That would be indeed the ideal scenario, legitimizing the whole thing.
>

I don't know how to read these comments... Are you afraid Guido wouldn't
accept the proposed arrangement, or are people really doubting that Guido
is still involved in this decision? I've seen the latter idea expressed by
non-core-developers, but to me, Guido's use of "try" (twice) and "we" in
his original email makes it clear that he's still involved; he just doesn't
want to (or can't) dictate what he'll be replaced by. If people feel like
Guido's participation in this is in doubt, should we just ask him to
confirm one way or the other? (You don't have to wait for an answer to that
question, Guido :)

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 14, 2018, at 00:16, Łukasz Langa  wrote:

> Taking a step back, before we talk names, term limits and even numbers of 
> council members, Python needs a "constitution" which will codify what the 
> council is and how it functions. Barry calls it PEP 2 but I'd like to 
> understand who is supposed to author it and who is supposed to accept it.

Yes, I’ve been thinking the same thing.  PEP 2 would serve as the Python 
development constitution.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Yury Selivanov]

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  wrote:
[..]
>> Ideally Guido would accept the PEP but I'm not sure if he is willing to. If 
>> that is indeed the case then how should this be done so that the document is 
>> universally accepted by all committers?
>
>
> In my ideal scenario, people write up PEPs proposing a governance model and 
> Guido chooses one, making it PEP 2.


That would be indeed the ideal scenario, legitimizing the whole thing.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/