Hi Ethan,
Thanks for your feedback!
2018-07-20 2:51 GMT+02:00 Ethan Furman <ethan@stoneleaf.us>:
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.
In that case, I would prefer that people abstain from voting on this mailing list (I'm talking about "+1" emails), before a formal and well defined PEP is written ;-)
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,
Hum, first I would like to have better statistics on the number of active core developers. On Stéphane Wirtel statistics on pull requests, the number of active core developers was closer to 34...
Would you mind to elaborate? How would enum be inconsistent without the BDFL work?
and still there were about 1,000 emails over several threads
Honestly, I don't recall the discussion on the enum module. What do you mean by this large number of emails?
People are free to send emails, but at the end, a vote would occur on a proper PEP, not on emails.
Let me try to guess what you mean. Do you mean that a 50%+1 majority would be impossible to reach because each core developer had a different taste on how enum should look like?
What I saw in PHP RFC is that sometimes there are multiple votes on a single RFC, to choose between alternatives (translation for Python: replace RFC with PEP :-)). A recent example:
https://wiki.php.net/rfc/array_key_first_last
The RFC proposed to add array_key_first/last()" and array_value_first/last(). The array_value variant was controversial and so has been voted separately. There was a corner value for values: a value can really be null, whereas the RFC proposes to also return null to signal an error. This case doesn't occur with keys, since using null as a key is automatically replaced with an empty string: it's possible to distinguish null as an error. They decided to approve array_key_first()/last() but reject array_value_first()/last(), which IMHO is a wise choice :-)
For enum, if you are talking about the two proposed alternatives "Not having to specify values for enums" and "Using special names or forms to auto-assign enum values", I guess that separated votes could be used: one vote for the main idea "having an Enum type", and a vote on the variants. The PEP author (and maybe an expert would him them to drive the PEP) would decide which votes are worth it.
- PEP 461 (%-formatting for bytes and byte arrays) [accepted] IIRC there was lots of push-back on adding this to bytes and byte arrays
Sorry, I don't understand what is wrong with this PEP. If I recall correctly, all core developers were in favor of adding back this feature to Python 3, no?
I recall that I started to write a PEP 460, but Antoine wanted to "modify" it. In fact, he basically rewrote it from scratch, so I asked him to remove my name from it :-)
Then you wrote a competitor PEP. At the end, your PEP won.
I don't see how bytes % args is a good example of the need of a BDFL to keep Python consistent. Would you mind to elaborate? Do you have that having two PEPs in a competition goes against the principle of voting?
- PEP 463 (exception-catching expressions) [rejected] lots of discussion here, not sure if it would have been accepted by majority vote
Hum, I don't recall well this discussion. If I recall correctly, the consensus quickly agreed to reject the PEP. Most people already disliked the PEP on python-ideas, no... I'm not sure of that. At least, I disliked the PEP since its start :-)
What do you mean by "not sure if it would have been accepted by majority vote"??
- PEP 572 (assignment expressions) [accepted] 'nough said
Joker! I will not comment that one. I don't have enough perspective on it yet.
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.
I guess that the group helping the authors is supposed to like the proposed change, but I'm not sure that it's mandatory. It's like an advocate who is supposed to help their client even if their client killed someone ;-)
If you want a recent example, on the PEP 572, Guido and Tim were strong supporters of the PEP and they helped a lot Chris to refine his PEP. At the end, they even decide to become co-authors.
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.
Sorry, what does BDFOP stand for?
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.
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.
By the way, PHP votes on RFC votes is public. One advantage is that it forces voters to vote "seriously", since later someone can ask them why they voted like that :-)
Are you sure that all core developers would have have the knee reaction of rejecting the PEP 572 if their vote really counts? On python-committers, I opened a *poll* on the PEP 572. The meaning is very different from a real vote where your voice really counts.
Another way to explain it. It's really hard to force volunteers to work for free... In a regular job, IMHO a good way to involve workers is to give them more responsibilities.
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 :-)
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.
See my previous point: you are not asked to vote on all PEPs. You are free to abstain from voting.
"Time is at a premium." is very true in open source software where almost everybody is volunteer. This is why I consider that a BDFL or a council is not sustainable regarding the popularity of Python and the pressure on accepting changes.
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.
Victor