On 07/19/2018 04:47 PM, Victor Stinner wrote:
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.
I imagine that will be made clear in that proposed PEP.
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.
This is, unfortunately, true -- with 100+ core-devs (give or take a few) that's basically 100+ different visions of Python, and on any particular issue the majority will be made up of different core-devs, therefore different visions will be approving/rejecting the PEPs, and internal consistency becomes impossible.
Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python?
Examples inside Python are good enough:
PEP 435 (Enum) [accepted] lots of minor decisions from BDFL about this or that choice, and still there were about 1,000 emails over several threads
PEP 461 (%-formatting for bytes and byte arrays) [accepted] IIRC there was lots of push-back on adding this to bytes and byte arrays
PEP 463 (exception-catching expressions) [rejected] lots of discussion here, not sure if it would have been accepted by majority vote
PEP 572 (assignment expressions) [accepted] 'nough said
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?
See above.
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.
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.
My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.
My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium.
-- ~Ethan~