And the PEPs have served the community very well. I love the PEP process, even if I think it can be improved :)
Anyway, looks like the discussion has run its course, and is now repeating arguments. (My own last post is full of them. Couldn’t help myself in the moment, sorry for that!)
I’ve learned that Informational & Process PEPs have their place. So, it would be worth it to document them better – make the first-class citizens.
I suggest that PEP 1 should be restructured to clarify which parts only apply to standards-track PEPs (which is most of the text).
I also suggest that standards-track PEPs should link to the living standard or documentation before they’re marked Final. If the PEP itself is the living standard, it should be Informational/Process. I’ll suggest that PEP editors watch out for this from now on. (There can be exceptions, but they should be made intentionally.)
By default, an Informational PEP is essentially a personal blog post, but that’s not clear to everyone. IMO, we should that each Informational PEP explicitly says who’s responsible for it and how to change it.
It could be good to have another PEP Template, with sections that you can consciously omit, for Informational PEPs rather than Standards-Track ones. Rough draft:
- Abstract
- PEP status and maintenance
- Introduction/Rationale
- Specification (consider writing this so it can be copied as-is to start a living standard)
- Open Issues
- Changelog (if this builds on an earlier PEP)
- Copyright
And even with all these changes, I’d encourage people to put content in other places if the RFC-style “immutable document” model isn’t helpful.
In the Standards-Track PEPs, we might note that for Typing/Packaging-style PEPs, the Specification section might be copied as-is to start a living document, and writing it with that in mind may save work.
Does that make sense?