[Distutils] BDFL Delegates for distutils-sig PEPs

[Nick Coghlan]

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