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

Wed Oct 3 11:56:36 EDT 2018

re: Updating the BDFL-Delegate policy (in PEP 1)

On Wednesday, October 3, 2018, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Saturday, September 22, 2018, Wes Turner <wes.turner at gmail.com> wrote:
>
>> [...]
>>
>> https://devguide.python.org/#contributing
>>
>> https://devguide.python.org/experts/
>> - 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":
>
> ""'
> Jeroen Demeyer
> 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 [...]
> """
>
> """
> INADA Naoki
> 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 ...
>
> Łukasz Langa
> > My understand is that accepting *any* PEP by anyone is out of the
> question until the governance situation gets resolved. That's the only
> reason why...
> """
>
> """
> On Wednesday, October 3, 2018, INADA Naoki <songofacandy at gmail.com> wrote:
>
> 2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer at ugent.be>:
> Hello,
>
> >> I am well aware of the current governance issues, but several people
> have mentioned that the BDFL-Delegate process can still continue for
> now.
>
> > Really?
> > 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¶"
> https://devguide.python.org/langchanges/#pep-process
> https://github.com/python/devguide/blob/master/langchanges.rst
>
>
> And PEP 1:
>
> "PEP 1 -- PEP Purpose and Guidelines"
>   "PEP Workflow"
> https://www.python.org/dev/peps/pep-0001/#pep-workflow
>   "PEP Editors"
> https://www.python.org/dev/peps/pep-0001/#pep-editors
>   "PEP Editor Responsibilities & Workflow"
> https://www.python.org/dev/peps/pep-0001/#pep-editor-
> responsibilities-workflow
>
> https://github.com/python/peps/blob/master/pep-0001.txt
>
> And the devguide has a list of experts:
> https://devguide.python.org/experts/
>
>
> Maybe PEP1 is the place to list current BDFL-Delegates
> (in addition to in the PEP metadata as in the OT PR:
> python/peps#797
> "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 2018-10-03 17:12, Wes Turner wrote:
> AFAIU, there is not yet a documented process for BDFL-delegate assignment.

PEP 1 says:

"""
However, whenever a new PEP is put forward, any core developer that
believes they are suitably experienced to make the final decision on
that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for
that PEP. If their self-nomination is accepted by the other core
developers and the BDFL, then they will have the authority to approve
(or reject) that PEP.
"""

I know that it says "core developers and the BDFL". However, if the core
developers agree that Petr can become BDFL-Delegate, I don't see why
that wouldn't be possible.
'''

The phrase "core developers and the BDFL"
is where some sort of alternate quorum/majority policy would need to be
specified if this is a contentious issue in practice?

(TBC, I'm +1 on the particular delegation that's not the question here)

>
>
>>
>> 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
>>> 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.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/20181003/b389bb08/attachment-0001.html>