Skip to content
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

Merged
merged 1 commit into from
Feb 22, 2022

Conversation

CAM-Gerlach
Copy link
Member

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

Copy link
Member

@JelleZijlstra JelleZijlstra left a 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
Comment on lines 396 to 399
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Member Author

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.

@CAM-Gerlach CAM-Gerlach force-pushed the pep-1-update-python-dev branch from bbbe260 to cd7c956 Compare February 21, 2022 00:51
@AA-Turner
Copy link
Member

Will review this in the morning, thanks for taking the time to write some text we can argue over ;-)

A

@CAM-Gerlach
Copy link
Member Author

Will review this in the morning, thanks for taking the time to write some text we can argue over ;-)

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...

@CAM-Gerlach CAM-Gerlach force-pushed the pep-1-update-python-dev branch from cd7c956 to 614c73f Compare February 21, 2022 22:30
Copy link
Member

@AA-Turner AA-Turner left a 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!

@AA-Turner AA-Turner merged commit b1e81ac into python:main Feb 22, 2022
AA-Turner added a commit that referenced this pull request Feb 22, 2022
@AA-Turner
Copy link
Member

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

@CAM-Gerlach
Copy link
Member Author

Following a conversation with @encukou , I went ahead and opened a SC issue to look over the changes. I would also appreciate individual feedback from @encukou , @warsaw and any other PEP editors that wish to weigh in. Thanks!

Copy link
Contributor

@davidfstr davidfstr left a 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.
Copy link
Contributor

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

Copy link
Member Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: changes -> change

Comment on lines +314 to +316
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.
Copy link
Contributor

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?

Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PEP 1: Revise, clarify and update language around python-dev, announcements and the discussion venue
5 participants