or: Replace Dictatorship with Democracy.
Hi,
== Introduction: unjustified fears? ==
I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of these BD(FL) and/or council: what they are expected to do, what they cannot do, etc.
It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python.
Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python?
In my experience, a consensus has been reached in less than one month on most PEPs without the help of the BDFL. There were a few controversal PEPs. The most controversial PEP is obviously the latest accepted PEP, the PEP 572 (assignment expressions). OK. But do you have other examples?
In a different thread,I gave the example of my PEP 446 "Make newly created file descriptors non-inheritable": Guido approved it, even though Charles-François Natali was against it (since it broke the backward compatibility). If I recall correctly, the issue with that PEP is that almost nobody cared about it: it was mostly Charles-François and Guido :-) Hopefully, such cases are rare.
== What is the image send to the community and contributors? ==
Last year, I mentored multiple contributors. What I learnt is that contributing to Python is much harder than what I expected.
Most core developers are core for 5 years or longer (maybe 10 years for some of them?), and we (core developers) forgot how hard it is to contribute. When your name is known in a community: it's very easy to share your ideas, other people listen to you and respect your experience. It's much faster to get a pull request merged... sometimes simply because you merged your own PR :-)
Becoming a core developer takes between 6 months and 2 years, it requires a lot of commitment, to have free time, etc. In short, it's *very hard* to recruit new core developers. It seems like many people forgot that.
What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them?
I'm not saying that a new governance will lead to such issues. I'm only opening the question of the image sent to the community.
== Democracy: vote on PEPs open to all core developers ==
I would like to come back to my idea of using a vote restricted to core developers: a PEP would require "50% +1" (at least 50% of votes + 1 voter) to be approved. Maybe some more sensitive PEPs would require a bigger majority, like 66%+1, for example PEPs changing the Python language. The vote would only be opened once we (core devs) consider that the PEP is ready for a vote.
Drawbacks.
The main risk is that PEPs would fail to be approved if no consensus can be found. In practice, it means that Python remains unchanged. Honestly, I don't think that this consequence is a disaster: sometimes, doing nothing *is* a wise choice :-) The PEP author is free to retry in 6 or 12 months with a new PEP, maybe written differently, maybe with better examples. For example, if everybody agreed to reject the first version of the PEP 572, I expect a more positive result on the latest flavor of the PEP. The issue is sometimes the PEP itself, not the proposed change. Guido forced me to rewrite my very long PEP 540 "UTF-8 Mode" from scratch to make it shorter (and simpler), and it was a major enhancement for my PEP :-)
OK, but sometimes everyone like the proposed change, but just not the PEP itself. What can be done? Well, the PEP can be modified. Another different PEP can be proposed. In the worst case, it's a dead end. Again, IMHO it's fine to done nothing. Moreover, I would like to insist that in last years, I don't think that such case occurred frequently. To be honest, I fail to find any example...
Advantages.
We saw drawbacks. What are advantages of a democracy where every core developer vote counts?
First, the BDFL is no longer a bottleneck. Last years, Guido became less available, some PEPs took a lot of time to be approved, I'm thinking about PEP 525 and PEP 530.
Moreover, core developers can take holiday. You are allowed to take care of friends, family, and just have a break. It's fine. There are other people who will take care of Python for you.
The decision becomes taken by "the community" (core developers in practice) rather than an individual. Negative comments should no longer target an individual but the collective decision. Being a public person is not easy, it seems like Guido resigns partially because of that pressure. I know that Brett Cannon also suffered of negativity of some haters of the Internet. I also had a depression recently caused partially by Python. Working on an open source and public project causes specific issues.
== Annex For Council Lovers ==
We already have a concept of *councils*. When I have a question on importlib, I will first ask Brett Cannon. If he is not available, I would ask Nick Coghlan and Barry Warsaw. When I have a question on C internals, I will ask Serhiy Storchaka and INADA Naoki. We even have a written list of "experts" (or "maintainers"):
https://devguide.python.org/experts/
Note: this list is filled by core developers who add themselves :-)
These experts are known references in their domain, and it's common that Guido delegates his BDFL role on PEPs. For example, INADA Naoki is the delegate of two Unicode PEPs: Nick's PEP 538 "C locale coercion" and my PEP 540 "UTF-8 Mode". If Naoki would reject my PEP, I would be fine with that: I trust and respect his judgment.
== Summary ==
It is already very hard to become a core developer: a contributor only becomes a core dev once other core developers trust them.
I propose to trust core developers judgment and let them all decide if a PEP should be accepted (or rejected). Common PEPs would require "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python language) would require 66%+1 majority (2/3).
Known experts will help to lead the discussion and to refine the PEP. Core developers will decide when they consider that a PEP is mature enough for a vote.
If a PEP is rejected by a vote, the author is free to make a new attempt 6 to 12 months later with a new PEP, maybe with a new stronger rationale and better examples. Or a competitor PEP can be proposed by a different author. I expect that the common case will be that the author will not attempt a new similar PEP since the vote result will be explicit enough.
Rejecting a PEP doesn't mean a failure for Python: sometimes, doing nothing is the wisest choice :-)
Victor