Hi, 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wij...@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 _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/