PEP 1: Further refine phrasing and organization of PEP-Delegate description

[CAM-Gerlach]

Further refine the PEP 1 phrasing around PEP-delegates, as originally opened as #1445 and further reviewed and merged in #2256 . See my review on #2256 for the rationale behind the specific copyedits (which I've further refined since then).

Also, fixes a related instance where python-dev instead of the Steering Council was specified as the final approve of PEPs (I plan to open another issue to discuss also mentioning/linking the PEPs category of the Python Discourse, as well as a few related changes).

[willingc]

Looks good. Thanks. A few suggested edits.

[CAM-Gerlach]

(Just FYI, @willingc , since many devs don't realize this—GitHub allows you to do multiline comments and suggestions by dragging your mouse to the left of the lines when the blue plus appears, which is really handy for logical changes that span multiple physical lines like this one).

[JelleZijlstra]

FYI there's a merge conflict now.

[CAM-Gerlach]

@JelleZijlstra Thanks, fixed!

[JelleZijlstra]

A couple of suggestions

[AA-Turner]

This change has introduced inconsistency into PEP 1.

Paragraph 4 of PEP Review & Resolution says:

... any core developer who believes they are suitably experienced to make the final decision on that PEP may offer to serve as the PEP-Delegate for it. If the Steering Council assents to their offer, the PEP-Delegate will then have the authority to approve or reject that PEP.

Paragraph 7 says:

Such self-nominations [as PEP-Delegate] are accepted by default, but may be explicitly declined by the Steering Council.

I ran into this whilst writing up the PEP 676 delegate notification to the SC. Am I meant to ask for explicit assent of the PEP-Delegate, or simply not a veto?

A

[JelleZijlstra]

Let's see what the SC has to say on your linked message and update this PEP accordingly.

(Also, happy to see Barry as the delegate for PEP 676!)

[CAM-Gerlach]

I believe the key confusion here is between the SC's decision-making philosophy on PEP-Delegate nominations, which is accept-by-default (paragraph 7), and the notification procedure for PEP-Delegate acceptance (paragraph 4), which includes explicit notification of acceptance from the SC like any other SC ticket (otherwise, it creates a high potential for confusion, as offerers might assume after some unspecified period that they were accepted, upon not receiving an explicit notification of rejection over whatever channel they chose, rightly or wrongly, to communicate with the SC).

For some background, these changes were in response to #1430 (and @willingc 's original #2256 merged to address it), which in turn was prompted by @gvanrossum 's request for clarification on the SC acceptance process in python/steering-council#28 , where on behalf of the SC, @warsaw confirmed the former's appointment as PEP-Delegate by explicitly approving it, stating

The SC approves of @gvanrossum as PEP-Delegate for PEP 618. We will also be updating the PEP 1 language to clarify the process. Thank you!

The original paragraph 4 wording prior to this PR (which was unchanged in #2256) didn't explicitly mention that the Steering Council could veto a PEP Delegate, or indeed how one was confirmed at all, instead seemingly implying it was automatic and immediate (contrary to paragraph 7, which was essentially untouched by both PRs):

any core developer [...] may offer to serve as the PEP-Delegate for that PEP, and they will then have the authority to approve (or reject) that PEP.

Further details on how we got here:

My original change in e200328 added wording that matched paragraph 7,

any core developer [...] may offer to serve as the PEP-Delegate for that PEP, and [if] not declined by the Steering Council, they will then have the authority to approve or reject that PEP.

@willingc then suggested. a further clarification, adding the procedural note "and they should notify the Steering Council of their offer"

any core developer [...] may offer to serve as the PEP-Delegate for that PEP, and they should notify the Steering Council of their offer. If not declined by the Steering Council, the core developer will then have the authority to approve or reject that PEP.

At the time, given this was already discussed more specifically in paragraph seven, which discussed procedural matters, as opposed to the basic summary of the role of a PEP delegate in this paragraph, I elected to modify this somewhat to "assents", in my resulting revision c03489b , to attempt to make clear that the SC had to actively receive the notification, consider it, and respond accordingly (i.e., formally state on the GitHub issue that they accept, or otherwise):

any core developer [...] may offer to serve as the PEP-Delegate for [the PEP]. If the Steering Council assents to their offer, the PEP-Delegate will then have the authority to approve or reject that PEP.

To note, @willingc mentioned a related concern with this in reply,

In general, I think that is fine. I would be explicit about notification of the Steering Council is one step toward becoming the PEP-Delegate. Acceptance by the steering council is the second step.

However, as the comment was marked resolved, I didn't make further changes before the PR was merged.

To both clarify the situation further and address @willingc 's further suggestion, I suggest something like this for paragraph 4:

any core developer [...] may offer to serve as the PEP-Delegate for [the PEP] by notifying the Steering Council of their intent. If the Steering Council accepts their offer, the PEP-Delegate will then have the authority to approve or reject that PEP.

And slightly revising the above-quoted first sentence of paragraph 7 to read

The Steering Council will generally accept such self-nominations by default, but may choose to decline them.

This makes it more clear that the SC does need to explicitly state (i.e. on the relevant SC issue) that the nomination is accepted, while their decision is to accept by default, if a suitable reason is not present to decline.

EDIT: [Forgot to add this] That being said, I'll wait to see what the SC says before going ahead with a PR to that effect.

[willingc]

@CAM-Gerlach Nice job restating the intent of the SC when I wrote the original PR. Thanks for your work on this. @JelleZijlstra @AA-Turner Thanks for being so helpful and thoughtful on these documents.

[CAM-Gerlach]

Thanks for your very kind words, @willingc . Your feedback and suggestions were crucial in helping bring this discrepancy to light and point to a path forward, not to mention it was your previous PR that we're building upon here. I really should have given you more explicit credit in the somewhat coldly clinical summary above, as well as point out that had I carefully considered your thoughtful review comments before pushing ahead with this, we might have ended up with wording closer to the above before merging the PEP.

[willingc]

No worries @CAM-Gerlach. Iterating is a good thing. Thanks for shepherding it to merge.