[Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

[Wes Turner]

Process suggestions that could minimize non-BDFL's BDFL legwork:

* https://github.com/python/peps
* https://github.com/pypa/interoperability-peps

* Use GitHub reactions for voting on BDFL delegates, PEP final approval,
and PEP sub issues?
  * Specify a voting deadline?
  * How to make a quorum call?
  * Add '@core/team' as reviewers for every PEP?

* 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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180922/2a3ea991/attachment.html>