Closing the loop here, the relevant paragraph in the specification rules is:
If a change being considered this way has the potential to affect software interoperability, then it must be escalated to the distutils-sig mailing list for discussion, where it will be either approved as a text-only change, or else directed to the PEP process for specification updates.
Assume “distutils-sig mailing list” is replaced by “Packaging area on Discourse”.
I’m going to assume that “approval as a text-only change” here means:
- Consensus on the thread that the change is uncontroversial, and a PEP isn’t needed.
- Consensus on the thread that it’s been sufficiently well publicised (where relevant).
- The PEP-delegate agrees (i.e. the PEP delegate can insist on a PEP for anything they feel needs it).
It’s important here to note that the maintainers of the spec documents will have to be responsible for ensuring these rules are followed. I have trouble following the github permissions maze, but that includes the “packaging user guide editors” group, most of whom aren’t active here, so I don’t know if they are OK with this responsibility. One thing I will say, though, is that as PEP delegate, I won’t be monitoring every PR for packaging.python.org to confirm if it’s a specification change that affects interoperability.
I do have a concern that we could gradually make significant changes to the specs via a series of “small, uncontroversial” changes. So I’ll probably apply a few personal rules here:
- Backward incompatible changes probably need a PEP (compatible with the de facto behaviour of existing tools is probably good enough here).
- Specs that are “volatile” (in the sense if getting a lot of proposals for changes) will need PEPs more frequently.