Splitting out the packaging PEPs, on the PEP site

Packaging
10

Summary of possible backend implementation strategies to achieve this:

  • Add Packaging option to existing Type header (Standards Track, Informational, etc)
    :+1: Arguably most natural fit within the existing frontend and backend
    :+1: Allows more easily codifying current and future process differences
    :-1: Requires more PEP 1/PEP 12 changes, both substantive and mechanical
    :-1: Carries potential governance implications

  • New Category header
    :+1: Useful and extensible to other PEPs
    :+1: Relatively lightweight from a policy perspective
    :-1: Implies categorizing other PEPs and requires a few more backend changes
    :-1: A bit odd to special-case packaging with it without more frontend changes

  • Use heuristics on Discussions-To header or hardcode list of packaging PEPs
    :+1: Requires fewer changes than some other options
    :-1: Awful, hacky and inherently unstable and unreliable

This was also my initial impression as well, based on the limited information in the OP. To note though, implementation wise, perhaps the most practical way that was suggested to achieve this within the existing system without hacks, excessive hardcoding/special-casing or affecting other PEPs is adding a new Packaging value for Type, which inherently carries at least some implied degree of significance for process/governance, for better (documenting existing practice and making future changes smoother) or worse (revisiting a bigger debate).

Also, to note, there’s been a concerted and growing push recently to make the PEP process as a whole friendlier, less arcane, more streamlined and better documented, coupled with a tighter focus on PEPs as change proposals rather than living specifications or documentation while working to find better homes for the latter (modeled on the mostly-successful effort to move PyPA specs to the PyPUG).