[python-committers] Transfer of power

Chris Jerdonek chris.jerdonek at gmail.com
Mon Jul 16 01:26:10 EDT 2018


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>


More information about the python-committers mailing list