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.