<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 12 Jul 2018 at 10:13 Mariatta Wijaya <<a href="mailto:mariatta.wijaya@gmail.com">mariatta.wijaya@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Guido,<div><br></div><div>Thank you for all you've done for Python. It is well deserved break.</div><div><br></div><div>I'm sad, but I like to see this as an opportunity to further improve Python and this community.</div><div><br></div><div>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.</div><div>This is based on my experience with organizing meetup and conference (although these are not comparable to leading the community like Python).</div><div>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.</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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. ;)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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?</div></div></blockquote><div><br></div><div>That's why Guido is leaving it up to us. :)</div><div><br></div><div>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. ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession planning for your project <a href="https://www.youtube.com/watch?v=Jhkm2PA_Gf8" target="_blank">https://www.youtube.com/watch?v=Jhkm2PA_Gf8</a></div><div>The slides: <a href="https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf" target="_blank">https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf</a></div><div><br></div><div>Some ideas from that talk:</div><div>1. identify critical roles (e.g. PEP decision making)</div><div>2. refactor large roles</div><div>3. mentor the new successor, shadow the previous leader </div><div>4. document all the things</div><div><br></div><div>This might be selfish request, but I hope you can still assume power until we have new successor(s).</div><div><br></div><div>Thanks.</div></div><div dir="ltr"><div><br></div><div><div><div dir="ltr" class="m_-3628820498980216406gmail_signature"><div dir="ltr"><div>Mariatta</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)<br></div><div><br></div><div>I am not going to appoint a successor. <br></div><div><br></div><div>So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?<br></div><div><br></div><div>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.<br></div><div><br></div><div>The decisions that most matter are probably</div><div>- How are PEPs decided</div><div>- How are new core devs inducted<br></div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Finally. A reminder that the archives of this list are public (<a href="https://mail.python.org/pipermail/python-committers/" target="_blank">https://mail.python.org/pipermail/python-committers/</a>) although membership is closed (limited to core devs).</div><div><br></div><div>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.<br></div><div><br>-- <br><div class="m_-3628820498980216406m_3060962964860241466gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>
_______________________________________________<br>
python-committers mailing list<br>
<a href="mailto:python-committers@python.org" target="_blank">python-committers@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div>
_______________________________________________<br>
python-committers mailing list<br>
<a href="mailto:python-committers@python.org" target="_blank">python-committers@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>