[python-committers] Transfer of power

[Antoine Pitrou]

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/
>