<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 13 Jul 2018 at 03:44 Victor Stinner <<a href="mailto:vstinner@redhat.com">vstinner@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <<a href="mailto:mariatta.wijaya@gmail.com" target="_blank">mariatta.wijaya@gmail.com</a>>:<br>
> What is the role of the successor(s)? Do we assume "whatever Guido did", or<br>
> is this an opportunity to come up with a new process?<br>
><br>
> One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession<br>
> planning for your project <a href="https://www.youtube.com/watch?v=Jhkm2PA_Gf8" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=Jhkm2PA_Gf8</a><br>
> The slides:<br>
> <a href="https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf" rel="noreferrer" target="_blank">https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf</a><br>
><br>
> Some ideas from that talk:<br>
> 1. identify critical roles (e.g. PEP decision making)<br>
> 2. refactor large roles<br>
> 3. mentor the new successor, shadow the previous leader<br>
> 4. document all the things<br>
<br>
I liked this talk! (I attended it at FOSDEM)<br>
<br>
To be able to replace the BDFL, IMHO first we need to define what are<br>
the roles of the BDFL. I also think that it's an opportunity to split<br>
the big central BDFL role into sub-roles: delegate some roles to<br>
multiple people.<br>
<br>
Let me try to list roles of the BDFL:<br>
<br>
* Take a decision/PEP. For a Python change (usually a PEP), when they<br>
are two good solutions and we fail to find a consensus, the BDFL<br>
chooses his favorite solution. Usually, when the BDFL pronounces,<br>
everybody has to follow his choice.<br>
<br>
* PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL<br>
final decision only comes after weeks of discussions and when there is<br>
already a kind of consensus (usually in favor of the PEP, otherwise<br>
the PEP is abandonned earlier). For example, python-ideas list already<br>
works well to reject ideas which should obviously be rejected for<br>
whatever reason. Sometimes when the consensus is to reject the PEP,<br>
the BDFL officially rejects it.<br></blockquote><div><br></div><div>I view the first and second points as basically the same. This is the role of final arbiter of PEP acceptance.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Public Relations. The BDFL is our reference for the Public<br>
Relations. We like to ask our BDFL what is his vision for the next 5<br>
years, even if he usually say that he doesn't know and he is usually<br>
not the one who propose new ideas :-)<br>
<br>
* Community? In case of conflict between two developers, sometimes the<br>
BDFL tries to solve the conflict. I'm not sure that it's an official<br>
role of the BDFL :-)<br>
<br>
* Community. (Here I will maybe speak for myself.) The BDFL is my<br>
reference for the right level of humour and right level of tone (on<br>
mailing lists and other medias). When the tone goes bad, sometimes the<br>
BDFL speaks up to cool down the discussion.<br></blockquote><div><br></div><div>While Guido played this role, I don't think that necessarily plays into governance. I suspect, though, that if we choose some council structure then those people will act as the public face of the team overall to help project the tone we hope to set overall. IOW I don' think we can appointment the head of humour (although if we do I'm nominating Tim ;) .<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Language. The BDFL is our designer for the Python language. I would<br>
like to generalize this definition to the general "taste" of Python:<br>
the BDFL defines what is "pythonic" or not by blessing some coding<br>
styles and blessing some new syntaxes. It's wider than just the pure<br>
grammar of the language.<br></blockquote><div><br></div><div>This is the other key part of the BDFL. I have always viewed Guido's BDFL role on PEPs to be an initial yea/nay, and then either delegating with some guiding words to a person who has domain expertise for a technical PEP or to make a pronouncement for a design-related PEP that isn't technical (e.g. function expressions).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Diversity. Last years, the BDFL was a strong player to enhance the<br>
diversity of core developers and contributors by mentoring directly<br>
Mariatta Wijaya, and suggesting regularly to mentor more people from<br>
minorities whenever possible. He also likes to wear PyLadies t-shirt<br>
and support DjangoGirls ;-)<br></blockquote><div><br></div><div>I lump this into the community and PR bucket as I don't know if we need to be worrying about appointing a head of diversity right now as that doesn't tie into governance. If, once this is all over, we want to take our diversity efforts to another level then a diversity SIG could be formed, but I don't see this as a BDFL thing and more of a team thing that someone choose to spearhead.<br></div><div> </div><div>-Brett<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Maybe it would also help if we list what the BDFL is not:<br>
<br>
* The BDFL is no longer the technical reference to review<br>
implementation changes. IMHO other people took this role somewhere<br>
between Python 1.0 and Python 3.7. As it has been said in the other<br>
thread, there are known experts in some areas of the Python which<br>
requires specific skills. For example, Yury Selivanov is my reference<br>
for asyncio. Well, that's a bad example, since Guido van Rossum ("as a<br>
developer, not as the BDFL") is my second reference here :-)<br>
<br>
* IMHO the BDFL is not the single one to decide to promote a<br>
contributor as a core developer. It seems like our process using a<br>
vote on python-committers works. I'm not sure that the process is<br>
perfect, but at least, I don't see the BDFL here as the central key to<br>
take a decision.<br>
<br>
<br>
These list are likely incomplete, don't hesitate to complete them :-)<br>
<br>
<br>
The question is now if a single people or a single small group of<br>
people should get all these roles? Or if we can distribute these roles<br>
to multiple people? Moreover, do all these tasks still need a BDFL?<br>
For example, do we need a diversity BDFL?<br>
<br>
IMHO the most critical roles of the BDFL is to design the language and<br>
take decisions on PEPs.<br>
<br>
<br>
To follow Vicky's talk, the second step is: "2. refactor large roles".<br>
<br>
Should we split the role "take the final decision on PEPs" into<br>
sub-roles for example? Do we need in advance to define BDFL-delegate<br>
for some kinds of PEPs? Or the BDFL should define per-PEP, which ones<br>
he doesn't want to handle and need a BDFL-delegate? In my experience,<br>
the BDFL delegation was done naturally, was not the source of<br>
conflict, and usually discussed directly with the BDFL.<br>
<br>
--<br>
<br>
By the way, I already started to work on "1. identify critical roles<br>
(e.g. PEP decision making)" a few months ago, not directly for the<br>
BDFL roles, but more generally on "maintenance tasks" and what are the<br>
key responsibilities in Python:<br>
<br>
<a href="http://pythondev.readthedocs.io/maintenance_tasks.html" rel="noreferrer" target="_blank">http://pythondev.readthedocs.io/maintenance_tasks.html</a><br>
<br>
Victor<br>
_______________________________________________<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>