[python-committers] And Now for Something Completely Different

[Steve Dower]

Summary: appointing a BDFL or small council *does not* force them to do 
all the work themselves.

On 20Jul2018 0457, Victor Stinner wrote:
> mailing list (I'm talking about "+1" emails), before a formal and well
> defined PEP is written ;-)

Until your new process arrives, "+1" emails are not votes and have never 
been considered as such. They've always been an easy and impersonal way 
to provide the BDFL[-delegate] with the opinions of the experts within 
the team who have taken the time to review a proposal.

Judging the general feeling of an email list is impossible without such 
emails. Counting these without taking into account the person providing 
the vote is a terrible idea (for example, if the topic is itertools, my 
+1 in no way comes close to cancelling out Raymond's -1, and nor should it).


> People are free to send emails, but at the end, a vote would occur on
> a proper PEP, not on emails.

Substitute "vote" for "decision" (which may be decided by voting, but 
does not presuppose that voting is the only option) and I'm +1 on this. 
The final decision should always be made against the PEP, not the 
discussion.


>> [Ethan] My first issue with this model is, as discussed above, a lack of a
>> consistent vision.  A BDFL is not just there to say, "this PEP is accepted,"
>> but also to say, "change this one piece here, remove that piece there, add
>> this" -- definitely not something easily done by 100+ voters.
> 
> I agree that an author can be confused when two different core
> developers ask to make two opposite changes. This is where an expert
> can help the author to drive the discussion and help the author to
> make choices.
> 
> To formalize a little bit more, I would identify 3 groups: PEP authors
> (usually an individual), group who help authors to write the PEP and
> drive the discussion, group who vote (all core devs) at the end.

Despite apparently being completely opposed to the other proposals, this 
part matches them nearly identically.

Everyone seems to be in support of a model where:
* anyone can propose a change (PEP author)
* trusted people should help sponsor/champion it (core committer 
bringing it to python-dev)
* trusted person/people should make a final determination

The only argument I see is entirely around how to choose that last 
group. The options:

* choose one person who always has to make that determination
* choose one person who chooses that group on a proposal-by-proposal basis
* choose a small group who always has to make that determination
* choose a small group who chooses that group on a proposal-by-proposal 
basis
* don't choose and force everyone to make that determination

Your proposal is the last one. My preference is the second or fourth. 
Some people seem to assume that unless we slow down now we will 
automatically end up with the first or third, but I don't see any basis 
for that assumption.

A BDFL or Council are free to delegate as much or as little as they 
want, and could conceivably reduce their workload to "once a week I will 
review emails starting with '[PEP xxx] Request for delegate' and provide 
a response".

> I saw people writing "mandatory votes" in a different thread. I don't
> see why anyone would be forced to vote on PEPs :-) (I'm not talking
> here about this very specific case of deciding a new governance for
> Python.)
> 
> I prefer to abstain me from commenting PEPs in some areas like typing
> or distutils, since they are out of my interest area and I don't feel
> that I would add anything useful. I love that other experts who have a
> stronger background in these topics than me are able to provide good
> feedback to drive the discussion.

"Abstain" is counted as a vote, just not in any direction. The point 
about mandatory voting is whether we need to wait for you to respond 
before considering a decision to have been reached. If we make that 
decision numerical, then sooner or later we will need to make 
exceptions. If we have appointed 1-to-n people to determine when a 
decision has been reached, the flexibility is built in to the process.

> Hum. Let me try to explain my point differently. Currently, some
> people don't read PEPs just because at the end, only the single BDFL
> vote counts. What's the point of spending hours (if not days) on
> reading a long PEP and the long discussion on mailing lists, if your
> count doesn't count? Now imagine that all votes count. I expect that
> people will spend more time on reading carefully each PEP and follow
> more closely discussions since they will be de facto more involved in
> the decision process.

If/when we choose a BDFL, it will need to be someone who is known for 
listening to all contributions and not excluding people for unfair or 
invalid reasons. It will also give them the power to declare how they 
want to hear contributions - they do not need to commit to reading and 
responding to every email! If you feel strongly against a proposal, you 
know who to go to in order to make that known.

By contrast, if everyone gets an equal vote on each proposal, and I want 
to prevent your PEP from being accepted, I have my choice of up to 50% 
of voters to convince to vote against you! That leads to a dynamic that 
I'm *very* nervous about. I would much rather have a trusted delegate 
tell me "thanks for your feedback but I trust Victor on this issue more 
than you" and have that be the end of it. There is no good that comes 
out of me spending time on Twitter/emails/etc. advocating that people 
vote against your proposal.


> I already saw this issue on reviews. I read someone saying that they
> don't review pull requests since only core developers can merge
> changes, so what's the point of commenting? If you take the point of
> view of the core developer: merging a pull request means that it
> becomes your pet for life, you will have to clean up its shit for its
> whole life... So core developers feel more responsible when commenting
> pull requests.
> 
> And now we ask regular contributor to do more reviews? I'm not sure
> that it works. If you want someone to do more review, IMHO you should
> give them the right to merge a PR. Suddenly, people are more careful
> on reviews :-)

Massive change of subject here, but I agree. Core developers *are* 
taking responsibility for the code they merge, and being willing to take 
on that responsibility is one of the main reasons for getting the role. 
"Making contributions" is not the qualification - "making good decisions 
about contributions" is.


> A BDFL was definitively a good choice 20 years ago, when Python was
> new and little used. Time changed. Python became #1 programming
> language in many area. They are million of users. We all feel the
> pressure of users who expect stability (this is partially why Python
> 2.7 is still very popular nowadays). IMHO a single BDFL can no longer
> handle the high number of PEPs nor the high traffic of python-ideas
> and python-dev lists. Moreover, since it has been written that no core
> developer is legitimate to replace BDFL, I expect even stronger
> criticism on the Internet against "unpopular" accepted changes...
> 
> These problems go away when you replace a single BDFL with a
> collective decision. Dozens of core developers scale and accumulate
> skills.

Perhaps, but they also go away when your single BDFL sets very clear 
limits on their availability and process, and when the process sets very 
clear expectations on their behaviour. Guido's problem is perhaps that 
he cared too much about every individual contribution and giving 
everyone an opportunity to make the case for shaping the language :) If 
a new BDFL declared "I do not read or respond on python-ideas, or 
proposals on python-dev that are not championed by a core developer" 
then that immediately reduces their workload without making it harder 
for people to contribute.

Perhaps it will reduce their "celebrity" status, and maybe they won't be 
stalked at conferences as much as Guido suffers from (hopefully 
"suffered from"), but I doubt that is a concern for anyone that would be 
under consideration.