I’ll also note that the proposed process is actually heavier weight than the PEP process - the PEP process is essentially “the BDFL-Delegate decides whether or not consensus has been reached, and whether or not to accept a proposal based on their assessment of that consensus”. The alternative proposal currently on the table is more in line with PEP 13 - the more formal process that CPython now requires for changes to the governance structure itself (with voting timelines, eligible voter determination procedures, etc).
Now, I don’t think having such a process for PyPA would be a bad thing, which means the idea I’m actually objecting to is only the proposal to conflate the PyPA process for managing governance changes with the process for managing technical design decisions. We deliberately didn’t do that for Python core development (PEP 1 and PEP 13 are different documents that cover different kinds of decisions), and I don’t think we should do it for PyPA either.
So if the proposal were descoped to be only about PyPA governance (e.g. transferring the standing delegations to a new default BDFL-Delegate, or proposing changes to the structure of the PSF Packaging Working Group), and left the handling of technical specifications alone, then I’d be more in favour of it - it would be the PyPA’s equivalent to PEP 13, with technical decisions continuing to be handled under https://www.pypa.io/en/latest/specifications/ and PEP 1.
If it was descoped that way, then it could be formalised as PEP 14 (Python Packaging Authority Governance), rather than needing to define an entirely new standards management process of its own. (We’d also be establishing a potentially useful precedent for other “Interest Area Authorities” within the wider Python ecosystem, like PyCA and PyCQA).