-
-
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
Update language on PEP-Delegate #1445
Conversation
Looks good, thanks! Do you mind also clarifying or removing the bit that says:
I don't think python-dev has final acceptance power. |
Note that #1672 changed the header to PEP-Delegate, so the wording here may need to be changed to reflect that. |
Yes, there is a merge conflict now. |
This has been open for a long time with little action and has a conflict now. I suggest we close it and open a new PR if the current SC feels that a clarification on the PEP-Delegate procedure is necessary. |
Should probably just create an entry on the SC tracker, otherwise they will never make time for this. I think this is a good update to the PEP, too bad about the conflict. |
@@ -275,12 +275,17 @@ The final authority for PEP approval is the Steering Council. However, whenever | |||
a new PEP is put forward, any core developer that believes they are suitably | |||
experienced to make the final decision on that PEP may offer to serve as | |||
the BDFL-Delegate for that PEP, and they will then have the authority to approve |
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.
Just FYI, if this is re-opened, this line should probably be modified as well, since it mentions only BDFL-Delegate
in the context of current processes.
I'm happy to fix the merge conflict and reopen. The prior Steering Council had recommended the changes. |
Go for it! |
Add language about PEP-Delegate and self-nomination notification