-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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: Further clarify PEP-Delegate notification & acceptance process #2273
PEP 1: Further clarify PEP-Delegate notification & acceptance process #2273
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.
I think this is helpful in making the process more explicit, and being more instructive for authors and potential sponsors.
Some suggestions (and the one when I clicked the wrong button when trying to start the review)
A
pep-0001.txt
Outdated
The Steering Council will generally accept such self-nominations by default, | ||
but may choose to decline them. |
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 Steering Council will generally accept such self-nominations by default, | |
but may choose to decline them. | |
The Steering Council will ordinarily approve such self-nominations, | |
but may choose to decline them. |
If "ordinarily" is too formal, "usually" also works.
"approve" makes more explicit that you must hear back in the affirmative from the Council.
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.
I see what you're trying to do here, but I'm concerned it is getting a bit far away from the original intended meaning—it now implies that the SC will typically approve nominations, but no longer directly mentions the decision-making rationale of approve-by-default, the original purpose of this sentence. It is now making a statement on approval probabilty (offers will be ordinarily approved) rather than approval strategy (offers will be approved by default unless there is a significant reason not to do so), as "ordinarily" (and "usually") refers to frequency while "generally" more generically is a general hedge, while "accept [...] by default" was what "generally" was referencing, not "accept" alone.
A more conservative suggestion that keeps the original meaning but applies your "approve" change would be the following:
The Steering Council will generally accept such self-nominations by default, | |
but may choose to decline them. | |
The Steering Council will generally approve such self-nominations by default, | |
but may choose to decline them. |
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.
Also, @brettcannon, thoughts?
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 the added rationale -- the "generally" and "by default" felt odd in the same sentence, but I see they are serving different purposes.
Co-authored-by: Adam Turner <[email protected]> Co-authored-by: Brett Cannon <[email protected]>
359fca9
to
318a336
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.
Substantive changes look good
Hey @brettcannon , is there any objection to going ahead with this? Or should we ask for another formal round of SC review here? |
Nope, go ahead and merge it! |
Thanks @brettcannon ! |
Followup to #1430 and PRs #2256 and #2257 , and discussed on python/steering-council#97 , to ensure the description of how PEP delegates should notify and request approval of the Steering Council is clear and consistent, and matches actual established practice, based on the descrepencies with the current merged language identified by @AA-Turner and discussed further with @willingc .