* Link to the mailing list thread(s) at the top of the PR

  * [ ] Add unique message URLs to footers with mailman3

* What type of communications are better suited for mailing lists over PEP pull-requests and PEP code reviews?

It seems like everything's fine, but I would have no idea, BTW

[] https://en.wikipedia.org/wiki/Quorum_call

On Saturday, September 22, 2018, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

Executive summary:  Writing a PEP is an inherently uncertain process.
Achieving "community consensus" is the goal of the process, not a
precondition.

Anders Hovmöller writes:

 >  In general pep1 is frustratingly vague. Terms like “community
 >  consensus” without defining community or what numbers would
 >  constitute a consensus are not fun to read as someone who doesn’t
 >  personally know anyone of the core devs. Further references to
 >  Guido are even more frustrating now that he’s bowed out.

These terms have little to do with what a new PEP's proponent needs to
think about, though.  A PEP-able proposal by definition involves
uncertainty.  Nobody, not even Guido, can tell you in advance whether
a PEP will be accepted (for implementation).  The PEP process is
rigorous enough that by the time you get close to needing consensus to
proceed, you'll know what it means.

"Community consensus" is not a condition for *anything* in the PEP
process, except final acceptance.  It is the *goal* of the process.
PEPs are approved (for publication) by default; the only requirement
is editorial completeness.  PEPs are needed for two reasons: (1) to
get the input of the community, both highly competent engineers for
implementation and a variety of users for requirements, to refine a
complex proposal or one with far-reaching implications for the
language, and/or (2) to build a consensus for implementation.  Either
way, by definition the outcome is unclear at the beginning.

If your concern about "consensus" is that you want to know whether
you're likely to get to consensus, and an accepted PEP, ask somebody
who seems sympathetic and experienced enough to know about what it
looks like on the list when a PEP is going to succeed.  Anything
PEP-able is sufficiently unclear that rules can't be given in PEP 1.
It is possible only to say that Python is now very mature, and there's
a strong conservative bias against change.  That doesn't mean there
aren't changes: Python attracts a lot of feature proposals, so the
rate of change isn't slowing although the acceptance rate is declining
gradually.

"Consensus" is never defined by numbers in the English language, and
it does not mean "unanimity".  In PEP 1, it means that some people
agree, most people don't disagree, and even if a senior person
disagrees, they're willing to go along with the "sense of the
community".  As that adjective "senior" implies, some people count
more to the consensus than others.  Usually when I write "senior" I'm
referring to core developers (committers), but here there
people who are "senior" enough despite not having commit bits.[1]

"The community" is not well defined, and it can't be, short of a
doctoral dissertation in anthropology.  The relevant channels are
open-participation, some people speak for themselves, some people are
"official" representatives of important constituencies such as the
leaders of large independent projects or alternative implementations,
and some people have acquired sufficient reputation to be considered
representative of a group of people (especially when other members of
the group rarely participate in the dev lists but for some reason are
considered important to the community -- I'm thinking in particular of
sysadmins and devops, and the problems we can cause them by messing
with packaging and installation).

References to the BDFL are, of course, in limbo.  AFAIK we don't have
one at the moment.  Until we do, any PEPs will presumably be accepted
either by a self-nominated BDFL-Delegate acceptable to the core devs,
or by an ad hoc committee of interested core devs, and that part of
PEP 1 can't be usefully updated yet.  This is not a weakness of the
Python project, IMO.  Rather, the fact that, despite a sort of
constitutional crisis, the whole process is continuing pretty much as
usual shows its strength.

This is possible because the BDFL is not, and has not been for many
years, a "hands-on" manager.  It's true that where a proposal affects
his own "development *in* Python", he's likely to work closely with a
proponent, off- and on-list, or even *be* the proponent.  Of course
such proposals are more likely to be approved, and a few community
members have pushed back on that because it appears undemocratic.  But
the general reaction is "maybe 'Although that way may not be obvious
at first unless you're Dutch' applies to me in such cases!"  For most
proposals, he's "just" a very senior developer whose comments are
important because he's a great developer, but he is easily swayed by
the sense of the community.  Bottom line: except in the rare case
where your proposal directly affects the BDFL's own coding, the BDFL's
now-traditional role is to declare that consensus has been achieved,
postpone the PEP because it's clear that consensus is not forming, or
in rare cases, make a choice despite the lack of consensus.

But none of this is really of importance to a PEP proponent
("champion" in the terminology of PEP 1).  PEP 1 is quite specific
about the required components of the document, and many points of
formatting and style.  Accept the uncertainty, and do what you need to
do to meet those requirements, that's all there is to it.  If the
community wants more, or wants changes, it will tell you, either as a
demand about style or missing content from an editor or as a technical
comment on the list.  Whether you accept those technical comments is
up to you, but your star will rise far more rapidly if you are very
sensitive to claims that "this change to the PEP will a big
improvement for some significant consituency in the community".  If
you want advice on whether the chance of acceptance is high enough to
be worth putting in more work, ask the BDFL-Delegate (or the BDFL if
she/he has "claimed" the PEP) where the proposal has an official
adjudicator, and if not, a senior core developer.

If one doesn't know who the senior developers are yet, she should think
twice about whether she's ready to PEP anything.  That's not a litmus
test; some PEPs have eventually succeeded though the proponent was new
to the project development process.[2]  But it's a lot less painful if
you can tell who's likely to be able to sway the whole project one way
or the other.  And as a matter of improving your proposal, who surely
does know more about what your proposal implies for the implementation
than you do, so you should strongly consider whether *you* are the one
who's missing something when you disagree with them.


Footnotes:
[1]  They are familiar to some of the core developers as drivers of
important projects developing *in* Python.

[2]  The ones I can think of involve the same kind of person as
footnote 1, and a co-proponent who was a core developer.


_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/