[Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]
wes.turner at gmail.com
Wed Oct 3 11:25:24 EDT 2018
On Saturday, September 22, 2018, Wes Turner <wes.turner at gmail.com> wrote:
> Here are links to the Apache governance docs:
> Which are the PSF docs for these exact same processes for open source
> governance? (In re: to transitioning from BDFL is not dead, but)
> - is there a different BDFL-delegate org chart, or would this be the page
> to add to and refer to?
re: Documenting the BDFL-Delegate process (in PEP 1?)
I'm just not good with a MUA; Markdown in a linear GH issue is far easier
to unsubscribe from; so I just added triple quotes:
>From "[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580":
Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580,
titled "The C call protocol". He has co-authored several PEPs [...]
2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer at ugent.be>:
> > Hello, Really? I don't know process to assign BDFL-delegate without
BDFL. This PEP is ...
> My understand is that accepting *any* PEP by anyone is out of the
question until the governance situation gets resolved. That's the only
On Wednesday, October 3, 2018, INADA Naoki <songofacandy at gmail.com> wrote:
2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer at ugent.be>:
>> I am well aware of the current governance issues, but several people
have mentioned that the BDFL-Delegate process can still continue for
> I don't know process to assign BDFL-delegate without BDFL.
AFAIU, there is not yet a documented process for BDFL-delegate assignment.
There's this in the devguide; which links to PEP1:
"20.2. PEP Process¶"
And PEP 1:
"PEP 1 -- PEP Purpose and Guidelines"
"PEP Editor Responsibilities & Workflow"
And the devguide has a list of experts:
Maybe PEP1 is the place to list current BDFL-Delegates
(in addition to in the PEP metadata as in the OT PR:
"PEP 580: Petr Viktorin as BDFL-Delegate"
Not to bikeshed, but is BDFL-Delegate still the current term because that's
what's in all the other PEPs' metadata?
Maybe a "delegation" GH Issue label or similar (and a commit prefix) on the
python/peps repo would be helpful?
> On Saturday, September 22, 2018, Wes Turner <wes.turner at gmail.com> wrote:
>> On Saturday, September 22, 2018, Wes Turner <wes.turner at 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
>> 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.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
>>>> 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
>>>> "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.
>>>> "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. 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.
>>>>  They are familiar to some of the core developers as drivers of
>>>> important projects developing *in* Python.
>>>>  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
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas