[python-committers] Identify roles of the BDFL

[Victor Stinner]

Hi,

2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
> 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?
>
> 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

I liked this talk! (I attended it at FOSDEM)

To be able to replace the BDFL, IMHO first we need to define what are
the roles of the BDFL. I also think that it's an opportunity to split
the big central BDFL role into sub-roles: delegate some roles to
multiple people.

Let me try to list roles of the BDFL:

* Take a decision/PEP. For a Python change (usually a PEP), when they
are two good solutions and we fail to find a consensus, the BDFL
chooses his favorite solution. Usually, when the BDFL pronounces,
everybody has to follow his choice.

* PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL
final decision only comes after weeks of discussions and when there is
already a kind of consensus (usually in favor of the PEP, otherwise
the PEP is abandonned earlier). For example, python-ideas list already
works well to reject ideas which should obviously be rejected for
whatever reason. Sometimes when the consensus is to reject the PEP,
the BDFL officially rejects it.

* Public Relations. The BDFL is our reference for the Public
Relations. We like to ask our BDFL what is his vision for the next 5
years, even if he usually say that he doesn't know and he is usually
not the one who propose new ideas :-)

* Community? In case of conflict between two developers, sometimes the
BDFL tries to solve the conflict. I'm not sure that it's an official
role of the BDFL :-)

* Community. (Here I will maybe speak for myself.) The BDFL is my
reference for the right level of humour and right level of tone (on
mailing lists and other medias). When the tone goes bad, sometimes the
BDFL speaks up to cool down the discussion.

* Language. The BDFL is our designer for the Python language. I would
like to generalize this definition to the general "taste" of Python:
the BDFL defines what is "pythonic" or not by blessing some coding
styles and blessing some new syntaxes. It's wider than just the pure
grammar of the language.

* Diversity. Last years, the BDFL was a strong player to enhance the
diversity of core developers and contributors by mentoring directly
Mariatta Wijaya, and suggesting regularly to mentor more people from
minorities whenever possible. He also likes to wear PyLadies t-shirt
and support DjangoGirls ;-)


Maybe it would also help if we list what the BDFL is not:

* The BDFL is no longer the technical reference to review
implementation changes. IMHO other people took this role somewhere
between Python 1.0 and Python 3.7. As it has been said in the other
thread, there are known experts in some areas of the Python which
requires specific skills. For example, Yury Selivanov is my reference
for asyncio. Well, that's a bad example, since Guido van Rossum ("as a
developer, not as the BDFL") is my second reference here :-)

* IMHO the BDFL is not the single one to decide to promote a
contributor as a core developer. It seems like our process using a
vote on python-committers works. I'm not sure that the process is
perfect, but at least, I don't see the BDFL here as the central key to
take a decision.


These list are likely incomplete, don't hesitate to complete them :-)


The question is now if a single people or a single small group of
people should get all these roles? Or if we can distribute these roles
to multiple people? Moreover, do all these tasks still need a BDFL?
For example, do we need a diversity BDFL?

IMHO the most critical roles of the BDFL is to design the language and
take decisions on PEPs.


To follow Vicky's talk, the second step is: "2. refactor large roles".

Should we split the role "take the final decision on PEPs" into
sub-roles for example? Do we need in advance to define BDFL-delegate
for some kinds of PEPs? Or the BDFL should define per-PEP, which ones
he doesn't want to handle and need a BDFL-delegate? In my experience,
the BDFL delegation was done naturally, was not the source of
conflict, and usually discussed directly with the BDFL.

--

By the way, I already started to work on "1. identify critical roles
(e.g. PEP decision making)" a few months ago, not directly for the
BDFL roles, but more generally on "maintenance tasks" and what are the
key responsibilities in Python:

http://pythondev.readthedocs.io/maintenance_tasks.html

Victor