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? On Saturday, September 22, 2018, Wes Turner <[email protected]> wrote: > > > On Saturday, September 22, 2018, Wes Turner <[email protected]> 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 < >> [email protected]> 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 >>> [email protected] >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
