PEP 1: Update language on sponsorships#1170
Conversation
|
Are non-core-dev sponsors preapproved ("these are the people the SC acknowledges as valid sponsors"), or is such sponsorship approved on a per-PEP basis ("I'd like to sponsor this PEP, is the SC okay with that?")? |
IMHO, I think the SC should explicitly approve a non-core sponsor on a per-PEP basis. If the author is a non-core dev, and they have identified a non-core dev sponsor, then I think it's fine to propose that in the PR of the PEP and signal to the SC (via our public issue tracker) that such an approval is needed. |
|
Is there some context to this change? I understood the previous reading was meant to help avoid random python-ideas inflating PEP numbers and wasting everybody's time. IIUC, the role of the core developer sponsor here was to prepare the author for the expected scrutiny, PEP 1 uses the wording "somewhat acting like [a] mentor". Is the non-core developer experience fitting this definition of a sponsor? |
|
I noticed that recently someone tried to propose a PEP (for an idea that
had been hashed out previously on python-ideas) and Chris A, wistfully,
noticed that he wasn't a core dev and so couldn't be a sponsor. Which
reminded me that there are plenty of people who for some reason aren't core
devs but who I would fully trust as PEP sponsors.
I brought this up with the SC and there was agreement that some
non-core-dev would make fine PEP sponsors. (With the exception of actually
landing PRs to the peps repo, which the PEP editors can handle.) This would
be a fine way to get some people more involved in contributing, and it
would lighten the load for other core devs, so seemed like an easy win all
around.
Because it's a new thing we decided to phrase PEP 1 so that this would have
to be allowed by the SC on a case-by-case basis.
…On Wed, Sep 18, 2019 at 12:56 PM Łukasz Langa ***@***.***> wrote:
Is there some context to this change?
I understood the previous reading was meant to help avoid random
python-ideas inflating PEP numbers and wasting everybody's time. IIUC, the
role of the core developer sponsor here was to prepare the author for the
expected scrutiny, PEP 1 uses the wording "somewhat acting like [a]
mentor". Is the non-core developer experience fitting this definition of a
sponsor?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#1170?email_source=notifications&email_token=AAWCWMXZ3HMHI3GRKSYWGALQKIJOFA5CNFSM4IXWB2CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD67ZY6A#issuecomment-532651128>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWCWMTTO2KXFHCALZXEFL3QKIJOFANCNFSM4IXWB2CA>
.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
|
|
Thank you for the explanation, that makes it absolutely clear what the intent is. While I have no vote here, I'm spiritually +1. |
|
Thanks for the reviews everyone. I've pushed an update. |
gvanrossum
left a comment
There was a problem hiding this comment.
Fix the whitespace nit first!
In today's (2019-09-17) Steering Council meeting, we agreed to relax the language around requiring a core developer to be a PEP sponsor. This PR modifies the language to allow any person (core or otherwise) to become a PEP sponsor with the approval of the Steering Council. Of course, if the PEP author is a core dev, it's still the case that a sponsor is not required.