<div>Process suggestions that could minimize non-BDFL's BDFL legwork:<br></div><div><br></div><div>* <a href="https://github.com/python/peps">https://github.com/python/peps</a></div><div>* <a href="https://github.com/pypa/interoperability-peps">https://github.com/pypa/interoperability-peps</a></div><div><br></div>* Use GitHub reactions for voting on BDFL delegates, PEP final approval, and PEP sub issues?<div>  * Specify a voting deadline?</div><div>  * How to make a quorum call?</div><div>  * Add '@core/team' as reviewers for every PEP?</div><div><br></div><div><div>* Link to the mailing list thread(s) at the top of the PR</div><div>  * [ ] Add unique message URLs to footers with mailman3</div><div><br></div><div>* What type of communications are better suited for mailing lists over PEP pull-requests and PEP code reviews?</div><div><br></div><div>It seems like everything's fine, but I would have no idea, BTW</div><div><br></div><div>[] <a href="https://en.wikipedia.org/wiki/Quorum_call">https://en.wikipedia.org/wiki/Quorum_call</a></div><div><br>On Saturday, September 22, 2018, Stephen J. Turnbull <<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp">turnbull.stephen.fw@u.tsukuba.ac.jp</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Executive summary:  Writing a PEP is an inherently uncertain process.<br>
Achieving "community consensus" is the goal of the process, not a<br>
precondition.<br>
<br>
Anders Hovmöller writes:<br>
<br>
 >  In general pep1 is frustratingly vague. Terms like “community<br>
 >  consensus” without defining community or what numbers would<br>
 >  constitute a consensus are not fun to read as someone who doesn’t<br>
 >  personally know anyone of the core devs. Further references to<br>
 >  Guido are even more frustrating now that he’s bowed out.<br>
<br>
These terms have little to do with what a new PEP's proponent needs to<br>
think about, though.  A PEP-able proposal by definition involves<br>
uncertainty.  Nobody, not even Guido, can tell you in advance whether<br>
a PEP will be accepted (for implementation).  The PEP process is<br>
rigorous enough that by the time you get close to needing consensus to<br>
proceed, you'll know what it means.<br>
<br>
"Community consensus" is not a condition for *anything* in the PEP<br>
process, except final acceptance.  It is the *goal* of the process.<br>
PEPs are approved (for publication) by default; the only requirement<br>
is editorial completeness.  PEPs are needed for two reasons: (1) to<br>
get the input of the community, both highly competent engineers for<br>
implementation and a variety of users for requirements, to refine a<br>
complex proposal or one with far-reaching implications for the<br>
language, and/or (2) to build a consensus for implementation.  Either<br>
way, by definition the outcome is unclear at the beginning.<br>
<br>
If your concern about "consensus" is that you want to know whether<br>
you're likely to get to consensus, and an accepted PEP, ask somebody<br>
who seems sympathetic and experienced enough to know about what it<br>
looks like on the list when a PEP is going to succeed.  Anything<br>
PEP-able is sufficiently unclear that rules can't be given in PEP 1.<br>
It is possible only to say that Python is now very mature, and there's<br>
a strong conservative bias against change.  That doesn't mean there<br>
aren't changes: Python attracts a lot of feature proposals, so the<br>
rate of change isn't slowing although the acceptance rate is declining<br>
gradually.<br>
<br>
"Consensus" is never defined by numbers in the English language, and<br>
it does not mean "unanimity".  In PEP 1, it means that some people<br>
agree, most people don't disagree, and even if a senior person<br>
disagrees, they're willing to go along with the "sense of the<br>
community".  As that adjective "senior" implies, some people count<br>
more to the consensus than others.  Usually when I write "senior" I'm<br>
referring to core developers (committers), but here there <br>
people who are "senior" enough despite not having commit bits.[1]<br>
<br>
"The community" is not well defined, and it can't be, short of a<br>
doctoral dissertation in anthropology.  The relevant channels are<br>
open-participation, some people speak for themselves, some people are<br>
"official" representatives of important constituencies such as the<br>
leaders of large independent projects or alternative implementations,<br>
and some people have acquired sufficient reputation to be considered<br>
representative of a group of people (especially when other members of<br>
the group rarely participate in the dev lists but for some reason are<br>
considered important to the community -- I'm thinking in particular of<br>
sysadmins and devops, and the problems we can cause them by messing<br>
with packaging and installation).<br>
<br>
References to the BDFL are, of course, in limbo.  AFAIK we don't have<br>
one at the moment.  Until we do, any PEPs will presumably be accepted<br>
either by a self-nominated BDFL-Delegate acceptable to the core devs,<br>
or by an ad hoc committee of interested core devs, and that part of<br>
PEP 1 can't be usefully updated yet.  This is not a weakness of the<br>
Python project, IMO.  Rather, the fact that, despite a sort of<br>
constitutional crisis, the whole process is continuing pretty much as<br>
usual shows its strength.<br>
<br>
This is possible because the BDFL is not, and has not been for many<br>
years, a "hands-on" manager.  It's true that where a proposal affects<br>
his own "development *in* Python", he's likely to work closely with a<br>
proponent, off- and on-list, or even *be* the proponent.  Of course<br>
such proposals are more likely to be approved, and a few community<br>
members have pushed back on that because it appears undemocratic.  But<br>
the general reaction is "maybe 'Although that way may not be obvious<br>
at first unless you're Dutch' applies to me in such cases!"  For most<br>
proposals, he's "just" a very senior developer whose comments are<br>
important because he's a great developer, but he is easily swayed by<br>
the sense of the community.  Bottom line: except in the rare case<br>
where your proposal directly affects the BDFL's own coding, the BDFL's<br>
now-traditional role is to declare that consensus has been achieved,<br>
postpone the PEP because it's clear that consensus is not forming, or<br>
in rare cases, make a choice despite the lack of consensus.<br>
<br>
But none of this is really of importance to a PEP proponent<br>
("champion" in the terminology of PEP 1).  PEP 1 is quite specific<br>
about the required components of the document, and many points of<br>
formatting and style.  Accept the uncertainty, and do what you need to<br>
do to meet those requirements, that's all there is to it.  If the<br>
community wants more, or wants changes, it will tell you, either as a<br>
demand about style or missing content from an editor or as a technical<br>
comment on the list.  Whether you accept those technical comments is<br>
up to you, but your star will rise far more rapidly if you are very<br>
sensitive to claims that "this change to the PEP will a big<br>
improvement for some significant consituency in the community".  If<br>
you want advice on whether the chance of acceptance is high enough to<br>
be worth putting in more work, ask the BDFL-Delegate (or the BDFL if<br>
she/he has "claimed" the PEP) where the proposal has an official<br>
adjudicator, and if not, a senior core developer.<br>
<br>
If one doesn't know who the senior developers are yet, she should think<br>
twice about whether she's ready to PEP anything.  That's not a litmus<br>
test; some PEPs have eventually succeeded though the proponent was new<br>
to the project development process.[2]  But it's a lot less painful if<br>
you can tell who's likely to be able to sway the whole project one way<br>
or the other.  And as a matter of improving your proposal, who surely<br>
does know more about what your proposal implies for the implementation<br>
than you do, so you should strongly consider whether *you* are the one<br>
who's missing something when you disagree with them.<br>
<br>
<br>
Footnotes: <br>
[1]  They are familiar to some of the core developers as drivers of<br>
important projects developing *in* Python.<br>
<br>
[2]  The ones I can think of involve the same kind of person as<br>
footnote 1, and a co-proponent who was a core developer.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div></div>