On Saturday, September 22, 2018, Wes Turner <wes.tur...@gmail.com> wrote:
> > It seems like everything's fine, but I would have no idea, BTW > Would project boards be helpful for coordinating proposal status information, or extra process for something that's already working just fine? https://github.com/python/peps/projects https://github.com/pypa/interoperability-peps/projects TBH, I like Waffle.io boards, but core team may be more comfortable with GH projects with swimlanes? > [] https://en.wikipedia.org/wiki/Quorum_call > > On Saturday, September 22, 2018, Stephen J. Turnbull < > turnbull.stephen...@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/ >> >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/