PEP 684: Update Discussions-To and Post-History

[ericsnowcurrently]

No description provided.

[CAM-Gerlach]

A few critical fixes to the header format. Also, please fix CODEOWNERS, which was broken by #2387 and merged before we had a chance to review to catch it. Done in #2393 , thanks.

[CAM-Gerlach]

Oh and thanks for the quick followup PR to update this; we certainly appreciate that.

[CAM-Gerlach]

I'm not sure I understand why this was merged to main in the face of an unresolved, blocking changes-requested review by a PEP Editor and infra team member stating that the syntax of the added Discussions-To header was invalid (per lengthy discussion, consensus, implementation, PEP 1/12 and SC approval), and would have been a hard error by the pre-commit and CI validation (save for a clerical delay merging such).

Could you perhaps explain how I could have communicated that more clearly in the future?

[ericsnowcurrently]

My apologies. Until recently I've never had any real interaction with others when posting a new PEP or making updates. There was rarely any review. At worst, a change would break something and I'd fix it the next day. 99% of the effort in the PEP process was either writing it or discussing it on python-dev. That's where I'm coming from.

I guess I didn't realize that the PEPs repo has an increased level of gatekeeping and process now. I appreciate the effort of the PEP editors. I also hope we can keep the PEP process at super low overhead.

[CAM-Gerlach]

I guess I didn't realize that the PEPs repo has an increased level of gatekeeping and process now. I appreciate the effort of the PEP editors. I also hope we can keep the PEP process at super low overhead.

While it is an evolving process with some amount of short-term friction as we transition (such as the Discussions-To field here, which once PEP 676 is fully implemented PEP authors won't need to worry about at all as it will be generated automatically based on the Post-History), a big part of the goal of the new systems being put in place is to allow us to do more things automatically without PEP authors having to worry about them, while supporting a wider array of reST/Sphinx syntax, roles, directives and styles for PEP editors to use. In particular, automatic validation of the header fields in a simple, consistent machine-parsable format, with immediate and specific feedback to PEP authors, allows us to do a lot of those such things.

Also, there has been a lot of effort lately toward updating, simplifying or eliminating many of the arcane and outdated requirements in PEP 1, PEP 12 and the template, while focusing these resources and this repo's Readme, Contributing guide and documentation on clearly and helpfully explaining the important parts of the modern PEP process that previously were left undocumented or unspoken.

Finally, long term, we've begun a broader move toward the PEP repo being focused more specifically on change proposals, rather than whitepapers, living specifications, documentation and the like. This decreases the need for editorial review and continuing maintenance beyond strictly technical aspects and places this more exclusively in the hands of the proposals' authors and the community behind them, while shifting those resources toward more appropriate and widely-applicable venues such as the documentation, dedicated specification sites and the devguide.