On Saturday, September 22, 2018, Wes Turner <wes.tur...@gmail.com> wrote:
> Here are links to the Apache governance docs: > > https://www.apache.org/foundation/governance/#technical > > https://www.apache.org/foundation/governance/pmcs.html > > Which are the PSF docs for these exact same processes for open source > governance? (In re: to transitioning from BDFL is not dead, but) > > 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.deme...@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 <songofaca...@gmail.com> wrote: 2018年10月3日(水) 21:24 Jeroen Demeyer <j.deme...@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 Saturday, September 22, 2018, Wes Turner <wes.tur...@gmail.com> wrote: > >> >> >> 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/
