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.