[python-committers] Identify roles of the BDFL

Brett Cannon brett at python.org
Fri Jul 13 14:39:18 EDT 2018

On Fri, 13 Jul 2018 at 03:44 Victor Stinner <vstinner at redhat.com> wrote:

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

I view the first and second points as basically the same. This is the role
of final arbiter of PEP acceptance.

> * 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.

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 ;) .

> * 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.

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).

> * 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 ;-)

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.


> 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
> _______________________________________________
> 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/20180713/88fd887c/attachment.html>

More information about the python-committers mailing list