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.
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
