-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PEP 1: Update to reflect best practices in PEP annoucement/discussion #2346
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this up!
pep-0001.txt
Outdated
Except where otherwise approved by the Steering Council, pronouncements | ||
of PEP resolution will be posted to the `Python-Dev`_ mailing list, | ||
and may be mirrored on the official "Discussions-To" thread and other venues, | ||
as appropriate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except where otherwise approved by the Steering Council, pronouncements | |
of PEP resolution will be posted to the `Python-Dev`_ mailing list, | |
and may be mirrored on the official "Discussions-To" thread and other venues, | |
as appropriate. | |
Pronouncements | |
of PEP resolution will be posted to the `Python-Dev`_ mailing list. |
I believe this is current practice, though the SC can change it if they want. I don't think we need to explicitly mention that the pronouncement can be mirrored elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is current practice, though the SC can change it if they want.
It is except for packaging PEPs, which de jure per the SC standing delegations, the PyPA governance PEP (PEP-0609) and the normative PyPA governing documents, as well as de facto on the recent packaging-related PEPs I checked, are always officially announced, discussed and pronounced on the Packaging category on Discourse, with the Distutils-SIG mailing list finally being fully shut down and formally retired.
I don't think we need to explicitly mention that the pronouncement can be mirrored elsewhere.
Sure, fair enough. I eliminated those two lines.
bbbe260
to
cd7c956
Compare
Will review this in the morning, thanks for taking the time to write some text we can argue over ;-) A |
The writing was the "fun" part. The arguing part is what I don't look forward to; I just hope it won't take longer than the actual writing this time... |
cd7c956
to
614c73f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "Discussing a PEP" section feels a little verbose, but this can be cut down later if need be. Thanks!
It seems I was too premature in merging this; I missed Cam's line at the end of the PR message about an official request to the Council. I merged as I saw this as an update to reflect the de facto situation. So firstly sincere apologies for that. After a conversation with @CAM-Gerlach, instead of causing more noise and kerfuffle by reverting, if any of @python/pep-editors, @warsaw, @encukou, or others have feedback we will incorporate into a follow-up PR (which I will not merge!). Very happy to help drafting such a PR as I caused the slight mess here. A |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Definitely more clear than the earlier version of PEP 1 that I consulted recently.
Did leave a few nits and 1 question to consider.
If the chosen venue is not the `Python-Dev`_ mailing list, | ||
a brief announcement should be posted there when the draft PEP is | ||
committed to the PEP repository and available on the PEP website, | ||
with a link to the rendered PEP and the to canonical Discussions-To thread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: and the to
-> and to the
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thanks! I'll fix it in my forthcoming followup PR (see below).
with a link to the rendered PEP and the to canonical Discussions-To thread. | ||
|
||
If a PEP undergoes a significant re-write or other major, substantive | ||
changes to its proposed specification, a new thread should typically be created |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: changes
-> change
Comments, support, concerns and other feedback on this designated thread | ||
are a critical part of what the Steering Council or PEP-Delegate will | ||
consider when reviewing the PEP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Earlier it was mentioned that the "designated thread" may need to be updated/changed over time. Thus links to the earlier threads will be lost in the latest version of the PEP document.
Is it likely the case that the SC will want to go back and read not just the lastest designated thread, but perhaps all prior such threads? If so, then perhaps the SC would find it useful to keep multiple threads in the Discussions-To field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great point (albeit not really a regression), and the plan to tackle it was by inline-linking each date in Post-History
to that respective thread, making that field have a much clearer and more practically useful purpose following these changes. I almost included that change here as well, but since it was more purely technical in nature and a little out of the original scope, I decided to defer it to a followup PR once this one was in. I can open the followup PR with that change shortly, and include your other fixes as well.
This updates PEP 1 (and a few small relevant parts of PEP 12 and the template) to reflect present real-world practice by the SC , as well as the recommendations we agreed on in #2266 , in order to clarify the current process for official discussion, announcement and resolution of PEPs, and improve the experience for PEP authors, the SC/delegates and the community, and avoid confusion, uncertainty and mistakes around these points, and update/remove related out of date content that no longer accurately reflects the de jure or de facto process.
As part of this change, it re-organizes the various scattered, sometimes duplicative or even contradictory paragraphs discussing PEP discussion, announcement and similar into one coherent section, with a clearer, more sequential and logical ordering of the overall process, and adds additional clarifying detail and guidance on points that were previously considered implicit or not referred to at all.
To note, I did not make the changes proposed for the
Post-History
field (beyond those intrinsically linked here), leaving that for a separate PR (which shouldn't require SC review, as those changes are purely technical in nature). Additionally, while incidental to updating relevant outdated guidance on this specific topic, I did clarify the time and process to submit a PEP for SC consideration (another major point of confusion for some of the recent PEP author situations that motivated this change), further clarification and updates on that will be handled separately, with appropriate SC review. I also noticed some smaller, unrelated items that were out of date, that will also be addressed separately.Following editorial review by the PEP editors and those involved in that discussion, I'm thinking we'll want to request SC review on their issue tracker before we merge this?
Fixes #2266