[Distutils] BDFL Delegates for distutils-sig PEPs

[Donald Stufft]

If it’s more useful we could also just use an RFC repository like Rust does instead of doing a mishmash between having Python using PEPs and packaging using PEPs.

On September 4, 2015 at 11:42:21 PM, Nick Coghlan (ncoghlan at gmail.com) wrote:
> We've got to a point where the original standing delegations to myself
> and Richard Jones to act as BDFL-Delegates for metadata
> interoperability and pypi.python.org related aren't scaling
> adequately, so given Paul's recent delegation for PEP 470, and Donald
> handling PEP 503 directly, it seems like an opportune time to put
> something in writing about that.
>  
> For PyPA/distutils-sig specific PEPs, we've effectively adopted the
> following approach to assigning BDFL-Delegates in resolving PEPs 470
> and 503:
>  
> =================================
> Whenever a new PEP is put forward on distutils-sig, any PyPA core
> reviewer 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 PyPA core reviewer, the lead PyPI maintainer and the lead
> CPython representative on distutils-sig, then they will have the
> authority to approve (or reject) that PEP.
> =================================
>  
> And translating the nominated roles to the folks currently filling
> them: "lead PyPI maintainer" = Donald Stufft; "lead CPython
> representative on distutils-sig" = me.
>  
> "PyPA core reviewer" isn't a term we've previously used, but I'm
> aiming to capture "has approval rights for pull requests to one or
> more of the PyPA maintained source code or documentation repos".
>  
> Some further details for the benefit of folks not aware of the relevant history:
>  
> * a couple of years ago, we amended PEP 1 to give the "Discussions-To"
> header some additional force for PEPs which don't directly affect
> CPython: """PEP review and resolution may also occur on a list other
> than python-dev (for example, distutils-sig for packaging related PEPs
> that don't immediately affect the standard library). In this case, the
> "Discussions-To" heading in the PEP will identify the appropriate
> alternative list where discussion, review and pronouncement on the PEP
> will occur."""
>  
> * we *didn't* update the section about assignment of BDFL-Delegates.
> Instead, I received a general delegation for packaging metadata
> interoperability PEPs, and Richard Jones received one for
> pypi.python.org related PEPs
>  
> * Richard subsequently passed the latter delegation on to Donald,
> since Donald had taken over as the lead maintainer for PyPI
>  
> The section in PEP 1 for CPython BDFL-Delegates reads as follows:
> =================================
> 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.
> =================================
>  
> This process can be appropriately described as "volunteering to be
> blamed" - if a PEP from a less experienced contributor subsequently
> proves to be a mistake, that's on the BDFL-Delegate for saying "Yes",
> not on the PEP author for proposing it. Mostly though, it's so there's
> someone to have the final say on the fiddly little details that go
> into getting from a general concept to an actual implementation,
> without getting mired down in design-by-committee on every incidental
> detail.
>  
> As PEP authors, we'll also often ask someone else specifically to
> volunteer as BDFL-Delegate, because we trust their judgement in
> relation to the topic at hand (e.g. I asked Martin von Löwis to be
> BDFL-Delegate for the original ensurepip PEP because I knew he was
> skeptical of the idea, so a design that passed muster with him was
> likely to have suitably addressed the ongoing maintainability
> concerns. Guido did something similar when he asked Mark Shannon to be
> BDFL-Delegate for PEP 484's gradual typing).
>  
> Regards,
> Nick.
>  
> P.S. It's becoming clear to me that I should probably write a
> companion PEP to PEP 1 that specifically describes distutils-sig's
> usage of the PEP process (and how that differs from the normal CPython
> processes), but hopefully this post provides sufficient clarification
> for now.
>  
> --
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>  

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA