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-Delegate notification for PEP 676 #97

Closed
AA-Turner opened this issue Jan 23, 2022 · 11 comments
Closed

PEP-Delegate notification for PEP 676 #97

AA-Turner opened this issue Jan 23, 2022 · 11 comments
Labels
PEP Python Enhancement Proposal

Comments

@AA-Turner
Copy link
Member

AA-Turner commented Jan 23, 2022

Per PEP 1, I'm notifying the SC of @warsaw's nomination as PEP Delegate for PEP 676.

He is a long serving PEP editor and core developer, as well as a former SC member, so I am very happy to have him serve as delegate.

(Note: a recent update to PEP 1 has left it unclear as to if this request is for explicit approval or simply a notification to enable the chance to veto, see python/peps#2257 (comment) for a longer explanation).

A

@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented Jan 23, 2022

To note, python/peps#2257 (comment) provides further clarification of the key point of confusion, summarizes the history/background, and suggests a couple further wording tweaks that would clarity it.

TL;DR: The confusion seems to be between the SC's decision making for approval being approve-by-default, and the notification of the result being an explicit statement of SC approval on this issue, to be consistent with the process for other other tickets here (including past PEP-Delegate nominations I could find, e.g. #28 , on which the existing lack of clarity over this same point led to the PRs that prompted this latest conundrum), and to avoid any confusion over the notification method, waiting period and what consistences the SC "not declining to approve" a nomination (none of which is currently specified in the PEP, and would be a more substantive change to add).

@encukou
Copy link
Member

encukou commented Jan 24, 2022

Thanks! I added it to the SC agenda.

@warsaw
Copy link
Member

warsaw commented Jan 24, 2022

To confirm, I self-nominate to be PEP Delegate for this PEP.

@Yhg1s
Copy link
Member

Yhg1s commented Jan 24, 2022

The SC is happy with Barry as PEP Delegate.

@Yhg1s Yhg1s closed this as completed Jan 24, 2022
@encukou
Copy link
Member

encukou commented Jan 24, 2022

That leaves the question of PEP 1 being ambiguous, though. I didn't add that part -- apologies.
Let's keep this open?

(FWIW, I don't think there's much of a practical difference between the two options. It's fine for the aspiring delegate to start their work before they're confirmed, and before they make a pronouncement they should be reasonably sure they won't get vetoed.)

@encukou encukou reopened this Jan 24, 2022
@CAM-Gerlach
Copy link
Member

Thanks, @encukou !

(FWIW, I don't think there's much of a practical difference between the two options. It's fine for the aspiring delegate to start their work before they're confirmed, and before they make a pronouncement they should be reasonably sure they won't get vetoed.)

Actually, if I understand you correctly, that's actually another good point—that the SC can veto a PEP-Delegate's decision on a PEP; at least as currently written in PEP 1, the formally-specified process for this is by removing the PEP-Delegate, which is stated to revert any decision they have made.

What the present discussion seems to more be about, though, is clarifying the process for notifying and seeking the Council's acceptance (or equivalently, non-declining) of a PEP-Delegate offer to begin with, such that it can be formally documented in the PEP header; the current underspecified approach seems to be the source of the confusion here.

For SC consideration, the proposed revised language for the sentence in paragraph 4, based on consultation with @willingc and @AA-Turner , and the current de-facto process as has been practiced on recent PEPs I'm aware of, is:

any core developer [...] may offer to serve as the PEP-Delegate for it [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 tweaking the first sentence of paragraph 7 to read,

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

I would also link [Steering Council] to this issue tracker in paragraph 6 (on notifying the SC and others).

@AA-Turner
Copy link
Member Author

I'd concur with Cam, the issue seems to be on power versus the (default) exercise of power. The Council could take a view to require all Delegates to be explicitly approved (more work, greater oversight) or vice versa, with the opposite attributes.

Regardless, above my pay grade, but thanks all for looking into it.

And thanks for approving Barry as Delegate so quickly! I shall update the PEP in due course.

A

@CAM-Gerlach
Copy link
Member

I'd concur with Cam, the issue seems to be on power versus the (default) exercise of power. The Council could take a view to require all Delegates to be explicitly approved (more work, greater oversight) or vice versa, with the opposite attributes.

In practice, there isn't any practical difference in terms of who gets approved, what changes is just clarifying the process by which the Steering Council is notified and given and opportunity to decline/approve, as it has been phrased by the SC in practice on past issues like this, and ensuring the wording in the PEP matches the current process in practice (opening a SC issue here and the SC responding in the negative or the affirmative, however specifically it is phrased).

@brettcannon
Copy link
Member

The Council could take a view to require all Delegates to be explicitly approved

That's the way it has always been. Typically it's the SC asking someone to be the delegate, not someone volunteering. And we have even turned down volunteers before.

@CAM-Gerlach
Copy link
Member

Thanks for clarifying. Yeah, the way I saw the above suggested changes is just making the wording clear, specific and consistent with the actual process as it is done in practice for volunteers (open a SC ticket and wait for SC 👍 or 👎). I opened PR python/peps#2273 to that effect and requested your review on it so we can move forward with something. Thanks!

@brettcannon brettcannon added the PEP Python Enhancement Proposal label Feb 16, 2022
@encukou
Copy link
Member

encukou commented Mar 1, 2022

The PR was merged, so I'll close this issue as well.

@encukou encukou closed this as completed Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PEP Python Enhancement Proposal
Projects
None yet
Development

No branches or pull requests

6 participants