[python-committers] Transfer of power

[Brett Cannon]

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>