PEPs from non-core devs now need a sponsor
The steering council has implemented a new idea called sponsors to the PEP process (added in https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a1434510528f...). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process, a core developer needs to sign on to be a sponsor of the PEP. Being a sponsor does *not* preclude the core dev from eventually becoming a co-author or BDFL-delegate later on (but obviously not both), but the expectation is the sponsor is supportive of the idea (because if a single core dev won't sign on to help then what chance does the PEP have of being accepted?). If this doesn't turn out well we can obviously revert this, but hopefully this will make things smoother for those who are new to the PEP process.
On Mon, Mar 4, 2019 at 10:13 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
Does this apply to existing draft PEPs or only new ones?
Only new ones; this is not retroactive. -Brett
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
Hi, Le mar. 5 mars 2019 à 02:53, Brett Cannon <brett@snarky.ca> a écrit :
The steering council has implemented a new idea called sponsors to the PEP process (...). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process (...)
Hum, this isn't fully new, some PEPs already got a "PEP champion" (old name), no? A recent example is PEP 572 who has been "championed" by Guido van Rossum, then by Tim Peters. In this specific case, they became co-authors :-)
... eventually becoming a co-author or BDFL-delegate later
Nitpick: since Python has no more BDFL, maybe the expression should becocme "PEP-delegate"? ;-) Victor -- Night gathers, and now my watch begins. It shall not end until my death.
On Tue, Mar 5, 2019 at 3:36 AM Victor Stinner <vstinner@redhat.com> wrote:
Hi,
Le mar. 5 mars 2019 à 02:53, Brett Cannon <brett@snarky.ca> a écrit :
The steering council has implemented a new idea called sponsors to the PEP process (...). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process (...)
Hum, this isn't fully new, some PEPs already got a "PEP champion" (old name), no?
Sure. You can consider this just making it a more formal thing then. -Brett
A recent example is PEP 572 who has been "championed" by Guido van Rossum, then by Tim Peters. In this specific case, they became co-authors :-)
... eventually becoming a co-author or BDFL-delegate later
Nitpick: since Python has no more BDFL, maybe the expression should becocme "PEP-delegate"? ;-)
That's covered in PEP 1 as to why the name has been kept so far. -Brett
Victor -- Night gathers, and now my watch begins. It shall not end until my death.
because if a single core dev won't sign on to help then what chance does the PEP have of being accepted?
If this is the justification, then I feel like it is a barrier that could be disassembled, rather than one people need to be granted permission to climb over. I am named on one PEP with two others (PEP 3135) and none of us were core developers, I think? I don't want that barrier added to newcomers, and I don't disagree there is a pre-existing barrier, but I can't help but feel this is not the best solution to it. I'm worried this creates a gatekeeping perception that will scare away contributors. On Mon, Mar 4, 2019 at 8:53 PM Brett Cannon <brett@snarky.ca> wrote:
The steering council has implemented a new idea called sponsors to the PEP process (added in https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a1434510528f...). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process, a core developer needs to sign on to be a sponsor of the PEP. Being a sponsor does *not* preclude the core dev from eventually becoming a co-author or BDFL-delegate later on (but obviously not both), but the expectation is the sponsor is supportive of the idea (because if a single core dev won't sign on to help then what chance does the PEP have of being accepted?).
If this doesn't turn out well we can obviously revert this, but hopefully this will make things smoother for those who are new to the PEP process. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cspealma%40redhat.com
-- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspealma@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
On 2019-03-05 14:05, Calvin Spealman wrote:
I'm worried this creates a gatekeeping perception that will scare away contributors.
+1 I also expressed this worry at https://github.com/python/peps/pull/903 You could keep the positive part of the sponsoring idea (somebody acting as mentor) but drop the negative part (make it a hard requirement to find a sponsor supporting the proposal before the proposal can even become a draft PEP).
I have to say, this is sort of surprising for what seems like the first official action of the steering committee. Are there really *that many *PEPs that a team that is now, what, 5x the size of the BFDL model is worried that they'll be able to keep up? As a long-time lurker, this hardly seems to be the case. Despite the seemingly-well-intentioned rationale, this seems like an ominous sign. On Tue, Mar 5, 2019 at 8:33 AM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2019-03-05 14:05, Calvin Spealman wrote:
I'm worried this creates a gatekeeping perception that will scare away contributors.
+1
I also expressed this worry at https://github.com/python/peps/pull/903
You could keep the positive part of the sponsoring idea (somebody acting as mentor) but drop the negative part (make it a hard requirement to find a sponsor supporting the proposal before the proposal can even become a draft PEP). _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jheiv%40jheiv.com
On 05Mar2019 0620, James Edwards wrote:
I have to say, this is sort of surprising for what seems like the first official action of the steering committee. Are there really /that many /PEPs that a team that is now, what, 5x the size of the BFDL model is worried that they'll be able to keep up? As a long-time lurker, this hardly seems to be the case. Despite the seemingly-well-intentioned rationale, this seems like an ominous sign.
FWIW, I'm 100% on board with this idea (and feel free to continue stealing ideas from PEP 8013 ;) ). However, the presentation of it certainly didn't emphasize the good rationale for the decision. In short, the five person steering council is not the equivalent of 5x BDFL. If they want to delegate early decision making to the core team as a whole, they can, and that's what they've done here. For non-core developers, and particularly first-time contributors, the PEP process typically starts at python-ideas. (Even core devs probably ought to start there, though part of being accepted as a core developer means we trust your judgement in selecting the correct venue for discussion, so if security-sig, datetime-sig, capi-sig, core-workflow, or just python-dev is more appropriate, feel free to start there.) To "get out" of python-ideas, someone needs to suggest where it goes next. Most of the time, this is python-dev. However, if you don't have *a single* core developer on board from python-ideas, chances are the whole team is going to reject the proposal. In the past, an idea would be shut down by just one negative vote (Guido's). In this future, an idea is promoted by just one positive vote (any core developer's). It's actually much easier for an "outsider" to get their idea in front of the whole core team than before. And python-ideas has core developers and regular contributors who have self-selected to "triage" ideas and help move them along. If the triagers don't like your idea, it's probably not a good idea :) Asking for proclamation from the council/delegate is literally saying "this proposal is ready". As a contributor (first time or 100th time), if you think your proposal is ready without *anyone else* agreeing with you, then *we* think you have a humility problem and we'd like you to go work on that. It's not a big ask to have one of the lower level mailing lists look at your proposal before the council has to make an official decision. You should *want* the mailing lists to look at your proposal. I certainly do, because every time they do my proposals get better, and I get better at writing proposals. This is a situation where everyone wins. Cheers, Steve
On 2019-03-05 18:14, Steve Dower wrote:
However, if you don't have *a single* core developer on board from python-ideas, chances are the whole team is going to reject the proposal.
Sure, I couldn't agree more. But this is something that a PEP mentor (instead of sponsor) also could deal with. Any potential mentor would quickly dismiss the PEP as having no chance and that would work just fine. The problem with the "sponsor" idea is that the sponsor must come from the group of core devs supporting the PEP. What if all core devs supporting it don't have time to act as sponsor or just don't care enough? On the other hand, if there is some support for an idea, then anybody should be able to mentor even if the mentor doesn't personally support the idea. I guess the mentor shouldn't be opposed either, but there is a large gray zone of -0/+0 in between where mentors could come from. Jeroen.
On Tue, Mar 5, 2019 at 11:59 AM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2019-03-05 18:14, Steve Dower wrote:
However, if you don't have *a single* core developer on board from python-ideas, chances are the whole team is going to reject the proposal.
Sure, I couldn't agree more. But this is something that a PEP mentor (instead of sponsor) also could deal with. Any potential mentor would quickly dismiss the PEP as having no chance and that would work just fine.
The problem with the "sponsor" idea is that the sponsor must come from the group of core devs supporting the PEP. What if all core devs supporting it don't have time to act as sponsor or just don't care enough?
If no one cares enough then there isn't enough support to begin with. I can't think of a PEP that was accepted with a universally lukewarm reception; there's always been at least one person who liked the idea to care.
On the other hand, if there is some support for an idea, then anybody should be able to mentor even if the mentor doesn't personally support the idea. I guess the mentor shouldn't be opposed either, but there is a large gray zone of -0/+0 in between where mentors could come from.
If the hypothetical situation comes up of: 1. An external person proposes a PEP 2. No supportive core dev has time to sponsor 3. Someone who doesn't support the PEP is willing to sponsor then we can talk about changing the process, but otherwise we are worrying about a hypothetical situation versus personal experience which suggests this won't be the case. IOW we need to give this a shot before we consider changing it.
On Wed, Mar 6, 2019 at 7:41 AM Brett Cannon <brett@python.org> wrote:
On Tue, Mar 5, 2019 at 11:59 AM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2019-03-05 18:14, Steve Dower wrote:
However, if you don't have *a single* core developer on board from python-ideas, chances are the whole team is going to reject the proposal.
Sure, I couldn't agree more. But this is something that a PEP mentor (instead of sponsor) also could deal with. Any potential mentor would quickly dismiss the PEP as having no chance and that would work just fine.
The problem with the "sponsor" idea is that the sponsor must come from the group of core devs supporting the PEP. What if all core devs supporting it don't have time to act as sponsor or just don't care enough?
If no one cares enough then there isn't enough support to begin with. I can't think of a PEP that was accepted with a universally lukewarm reception; there's always been at least one person who liked the idea to care.
On the other hand, if there is some support for an idea, then anybody should be able to mentor even if the mentor doesn't personally support the idea. I guess the mentor shouldn't be opposed either, but there is a large gray zone of -0/+0 in between where mentors could come from.
If the hypothetical situation comes up of:
An external person proposes a PEP No supportive core dev has time to sponsor Someone who doesn't support the PEP is willing to sponsor
then we can talk about changing the process, but otherwise we are worrying about a hypothetical situation versus personal experience which suggests this won't be the case. IOW we need to give this a shot before we consider changing it.
How much effort does it take to sponsor a PEP? I'm not a core dev, but I can help someone with the work of writing and publishing. So if, in that hypothetical situation, some (very busy) core dev were willing to say "yeah, go ahead, put my name on it", would that be sufficient? If so, it shouldn't be a problem to require this - any proposal with enough support to be worth PEPing should have at least one person who's willing to have his/her name in the headers. ChrisA
On 05Mar2019 1245, Chris Angelico wrote:
How much effort does it take to sponsor a PEP? I'm not a core dev, but I can help someone with the work of writing and publishing. So if, in that hypothetical situation, some (very busy) core dev were willing to say "yeah, go ahead, put my name on it", would that be sufficient? If so, it shouldn't be a problem to require this - any proposal with enough support to be worth PEPing should have at least one person who's willing to have his/her name in the headers.
For the record, now that he's joined the conversation, Chris is who I had in mind when I invented the term "PEP triager" in my email :) If we had a way of appointing people who we trust to be non-core dev sponsors of PEPs, I'd nominate him. Though I suspect he's well known enough to the council that they'd accept his support of a PEP as sufficient to consider it from someone who's otherwise completely unknown. There are always grey areas in any policy. Cheers, Steve
On Tue, Mar 5, 2019 at 9:04 PM Steve Dower <steve.dower@python.org> wrote:
On 05Mar2019 1245, Chris Angelico wrote:
How much effort does it take to sponsor a PEP? I'm not a core dev, but I can help someone with the work of writing and publishing. So if, in that hypothetical situation, some (very busy) core dev were willing to say "yeah, go ahead, put my name on it", would that be sufficient? If so, it shouldn't be a problem to require this - any proposal with enough support to be worth PEPing should have at least one person who's willing to have his/her name in the headers.
For the record, now that he's joined the conversation, Chris is who I had in mind when I invented the term "PEP triager" in my email :)
If we had a way of appointing people who we trust to be non-core dev sponsors of PEPs, I'd nominate him. Though I suspect he's well known enough to the council that they'd accept his support of a PEP as sufficient to consider it from someone who's otherwise completely unknown. There are always grey areas in any policy.
If core devs trust someone enough to let them act as a PEP sponsor, they probably know at least one core dev well enough to get them to add their name as sponsor on the condition that they are only responsiible for ensuring their "proxy" (?) responds adequately and in a sufficiently timely manner. I don't have a great deal to add to most conversations here, but I would urge all concerned to consider Brett's point, from my own now distant experience as a PSF chair. If I may paraphrase him, it's easier to change the rules when someone wants or needs to do something outside their current scope than it is to devise bullet-proof rules. It was only after I learned this lesson that much of the constitutional lawyering in the PSF was (gradually) replaced by useful mission-directed volunteer-led activity. Please don't concern yourselves too much about process, but instead focus on the desired results. If lawyering is needed, delegate it to the PSF! I'd rather have you pushing Python forward ;-). Finally, thanks again to everyone who contributes, particularly for managing to hide a great deal of Python's modern-day complexity from those who neither want nor need to know about it. Ultimately I think that is perhaps the biggest factor fuelling the language's continued growth. Kind regards Steve Holden
On Tue, Mar 5, 2019 at 5:33 AM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2019-03-05 14:05, Calvin Spealman wrote:
I'm worried this creates a gatekeeping perception that will scare away contributors.
It might, but if people are not prepared properly for the PEP process then it's best to spare them and everyone else the time sink.
+1
I also expressed this worry at https://github.com/python/peps/pull/903
You could keep the positive part of the sponsoring idea (somebody acting as mentor) but drop the negative part (make it a hard requirement to find a sponsor supporting the proposal before the proposal can even become a draft PEP).
The hard requirement is on purpose. This is not a suggestion for a reason as PEPs are not a cheap, cost-free thing for both authors and those participating in the discussion. They take up a ton of time and if people are not properly equipped to be successful then it just leads to a massive loss of time that could be been better used by everyone involved. Please also realize that the top 4 PEP authors are on the steering council, and some of the longest active core devs and PEP editors are on the council, so this isn't coming from people that lack experience and exposure to all facets of the PEP process. As I said in my announcement email, if this turns out to be a bad decision then we can change the process back/again, but please do realize this is not coming out of thin air just because we like fiddling with the PEP process.
Just to clarify a key point here which is covered in PEP 1 but based on offline conversations is being missed, the need for a sponsor only kicks in for committing it to the peps repo which typically kicks in when transitioning from python-ideas to python-dev (although if one gets a sponsor sooner then great as getting mentoring on how to handle the process is always beneficial) . This should not be a barrier to presenting an idea or writing up a proto-PEP for python-ideas if people are too shy to ask upfront for a sponsor until their idea shows merit (and remember that we already ask people to fork the peps repo and get feedback on their proto-PEPs in their own fork instead of in the official repo). Nor should this impact slow-burning ideas which people have to warm up to as that typically happens before a PEP is written anyway. I also don't see this preventing PEPs written to be explicitly rejected either. I personally am happy to sponsor such PEPs as I'm sure several other core devs are as well. On Mon, Mar 4, 2019 at 5:43 PM Brett Cannon <brett@snarky.ca> wrote:
The steering council has implemented a new idea called sponsors to the PEP process (added in https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a1434510528f...). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process, a core developer needs to sign on to be a sponsor of the PEP. Being a sponsor does *not* preclude the core dev from eventually becoming a co-author or BDFL-delegate later on (but obviously not both), but the expectation is the sponsor is supportive of the idea (because if a single core dev won't sign on to help then what chance does the PEP have of being accepted?).
If this doesn't turn out well we can obviously revert this, but hopefully this will make things smoother for those who are new to the PEP process.
As a non core-dev, my enthusiasm for submitting a pep has been diminished by some 40%. yours, Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius
On Mar 6, 2019, at 10:28, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
As a non core-dev, my enthusiasm for submitting a pep has been diminished by some 40%.
I’m sorry to hear that. I think it’s worth keeping in mind that successfully navigating the PEP process can be quite daunting an demoralizing at times. I wish that weren’t the case, and it was certainly not the intention when the PEP process was originally designed, but Python is a large diverse community now, and a mature, slow moving language, so it’s rare that a great idea makes it through without contention. I think that the requirement to find a sponsor can help with that, regardless of whether the PEPable idea is ultimately accepted or rejected. Core devs generally have a pretty good sense of what it takes to get a PEP through the process, can provide encouragement when the millithreads get you down or overwhelmed, and can help short circuit the disappointment, time and emotional investment when the idea has a poor chance of being accepted. Many of our core devs have gone through it, with both outcomes, so their guidance can be very valuable. I like to think of the sponsor as a PEP mentor, although sponsors can of course have a range of involvement. Our core devs want you to succeed (or conversely save you from wasting your time), and they’ve been there, done that. Core dev sponsors can be a great resource for folks new to the process. Cheers, -Barry
i think that "should have at least a mentor guiding you" sounds a lot more better than a core developer needs to sign on to be a sponsor that sounds a lot more that without backing, you can't submit a pep, i guess the core devs wanted to make things easier but the sponsor thing etc put me off. for someone using py, ideas sometimes come but since i've not yet submitted a pep, when i see a change in the flow, i ask: will it be easier or more difficult to submit peps now? i really got the impression that now chances are slimmer. great idea that core mentors now volunteer to guide peps, sorry for trouble. yours, Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius
On Wed, Mar 6, 2019 at 8:58 PM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:
i think that "should have at least a mentor guiding you" sounds a lot more better than
a core developer needs to sign on to be a sponsor
that sounds a lot more that without backing, you can't submit a pep, i guess the core devs wanted to make things easier but the sponsor thing etc put me off. for someone using py, ideas sometimes come but since i've not yet submitted a pep, when i see a change in the flow, i ask: will it be easier or more difficult to submit peps now? i really got the impression that now chances are slimmer.
Before submitting a PEP one (including core-devs) usually starts a discussion on python-dev/ideas in order to start collecting feedback and, most importantly, to figure out whether the idea deserves a PEP or not (often times it doesn't). If the proposal is good it means somebody agreed with you: those persons are likely gonna be the ones who'll likely sponsor your PEP. If you can't find such a person immediately and the idea received positive feedback I imagine you'll just be asked to write a proto-PEP first, and if that is good enough somebody will eventually sponsor it and possibly even help you. If you can't find any person then it probably means it wasn't such a good idea, and that's also good because it will save you from the trouble of writing the PEP in the first place (meeting the PEP quality standards is not exactly a piece of cake). I doubt we'll end up in a situation where a good proposal won't happen just because nobody is willing to sponsor it. -- Giampaolo - http://grodola.blogspot.com
I'm confused about this. Didn't you need someone with merge permissions already to merge a pep into the pep repo? Isn't this just adding a layer of paperwork to something that was already the case for all practical purposes?
-----Original Message----- From: Python-Dev <python-dev-bounces+tritium- list=sdamon.com@python.org> On Behalf Of Brett Cannon Sent: Monday, March 4, 2019 8:44 PM To: python-dev <python-dev@python.org> Subject: [Python-Dev] PEPs from non-core devs now need a sponsor
The steering council has implemented a new idea called sponsors to the PEP process (added in https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a14 34510528f68). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process, a core developer needs to sign on to be a sponsor of the PEP. Being a sponsor does not preclude the core dev from eventually becoming a co-author or BDFL- delegate later on (but obviously not both), but the expectation is the sponsor is supportive of the idea (because if a single core dev won't sign on to help then what chance does the PEP have of being accepted?).
If this doesn't turn out well we can obviously revert this, but hopefully this will make things smoother for those who are new to the PEP process.
On 3/8/19 8:09 AM, Alex Walters wrote:
I'm confused about this. Didn't you need someone with merge permissions already to merge a pep into the pep repo? Isn't this just adding a layer of paperwork to something that was already the case for all practical purposes?
I would say the difference that before, the non-committer proposer just needed to convince some committer that the PEP was 'a good idea' and worth being discussed. Now, that person needs to persuade some committer that not only is it a good idea, but that it is worth the committer committing themselves to supporting the proposer through the process. -- Richard Damon
On Fri, Mar 8, 2019 at 5:46 AM Richard Damon <Richard@damon-family.org> wrote:
I'm confused about this. Didn't you need someone with merge permissions already to merge a pep into the pep repo? Isn't this just adding a layer of paperwork to something that was already the case for all practical
On 3/8/19 8:09 AM, Alex Walters wrote: purposes?
Nope. We don't like paperwork anymore than you or anyone else.
I would say the difference that before, the non-committer proposer just needed to convince some committer that the PEP was 'a good idea' and worth being discussed. Now, that person needs to persuade some committer that not only is it a good idea, but that it is worth the committer committing themselves to supporting the proposer through the process.
What Richard said. Before, PEP editors would make sure a PEP was basically grammatically correct and not totally bonkers, but otherwise didn't make judgments. Now we're saying there needs to be a core dev to help you through the process to help make sure you will be successful and at least *someone* thinks it's a good idea. -Brett
-- Richard Damon
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
participants (14)
-
Abdur-Rahmaan Janhangeer -
Alex Walters -
Barry Warsaw -
Brett Cannon -
Brett Cannon -
Calvin Spealman -
Chris Angelico -
Giampaolo Rodola' -
James Edwards -
Jeroen Demeyer -
Richard Damon -
Steve Dower -
Steve Holden -
Victor Stinner