[python-committers] PEP stewardship delegation: the minimal change approach

[Nick Coghlan]

Hi folks,

While I think the threads suggesting that we treat Guido's retirement
as an opportunity to conduct a critical self-review of our community
governance structures and practices are an excellent idea, I also want
to note that there's only a relatively minimal change required to PEP
1 to permit changes to proceed in areas that would likely previously
have been handled by a BDFL-Delegate anyway.

The gist is that both PEP 1 and the derived process I set up for PyPA
allow for folks to *volunteer* as BDFL-Delegates for a PEP, rather
than waiting for Guido (or the default BDFL-Delegate in the PyPA case)
to pick someone. (The unwritten addendum to both these clauses is that
PEP authors may also ask core devs with suitable experience to
consider volunteering as BDFL-Delegate)

Quoting the relevant paragraph from PEP 1 [1]:

=====================
The final authority for PEP approval is the BDFL. 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 happens most frequently with PEPs where the BDFL has
granted in principle approval for something to be done, but there are
details that need to be worked out before the PEP can be accepted.
=====================

And the relevant section from the PyPA process documentation [2]:

=====================
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 reviewers, the lead PyPI maintainer and the default
BDFL delegate for package distribution metadata PEPs, then they will
have the authority to approve (or reject) that PEP.

Otherwise, the default BDFL-Delegate depends on the area the PEP affects.

- Package Distribution Metadata PEPs: Paul Moore
- Package Index Interface PEPs: Donald Stufft

For Package Distribution Metadata, the default BDFL-Delegate was
originally appointed directly by Guido van Rossum as Python’s BDFL
(hence the use of the term BDFL-Delegate), but is now nominated by the
previous default BDFL-Delegate (and the transfer of delegation
approved by Guido).

For Package Index Interfaces, the default responsible decision maker
is the lead maintainer for the Python Package Index.
=====================

So stealing Brett's excellent suggestion of "Design Steward" as a
BDFL-independent term for the current BDFL-Delegate role, a potential
PEP 1 amendment for the appointment process would be:

=====================
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 "Design Steward" for that PEP. If their
self-nomination is accepted by the other core developers, then they
will have the authority to approve (or reject) that PEP.
=====================

This is similar to the "any core developer can approve a commit, any
other core developer can subsequently ask for that commit to be
reverted" principle that applies for smaller changes, just applied in
advance to more complex design reviews and decisions.

The PyPA amendment would be similar - replacing "BDFL-Delegate" with
"Design Steward", and removing any references to Guido's previously
priviliged role in the process.

There are some proposals where I wouldn't expect this simple
modification to be sufficient (e.g. PEP 505's proposal for new
None-aware operators, or PEP 572's assignment expressions), due to a
lack of core developers that would consider themselves suitably
experienced to be solely responsible for language level design
decisions of that magnitude. However, I'd expect it to be sufficient
in cases where the main motivation for requiring a PEP is due to a
generally supported change's design complexity, rather than due to it
being a particularly controversial decision on whether or not to do
anything at all.

Cheers,
Nick.

[1] https://www.python.org/dev/peps/pep-0001/#pep-review-resolution
[2] https://www.pypa.io/en/latest/specifications/#proposing-new-specifications

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia