[python-committers] And Now for Something Completely Different

[Victor Stinner]

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