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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
