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...@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/