Front page | perl.perl5.porters |
Postings from June 2021
Re: Creating an RFC process for Perl
From: Nicholas Clark
June 12, 2021 07:13
Re: Creating an RFC process for Perl
Message ID: 20210612071251.GI16703@etla.org
On Sat, Jun 12, 2021 at 01:44:00AM +0000, mah.kitteh via perl5-porters wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, June 9th, 2021 at 7:56 PM, Tomasz Konojacki <email@example.com> wrote:
> > On Thu, 10 Jun 2021 10:35:33 +1000
> > Tony Cook firstname.lastname@example.org wrote:
> > > Adding grammar isn't all that hard*, I've done it in limited ways to
> > >
> > > fix a bug.
> > >
> > > Nicholas didn't seem to have much problem in producing the grammar
> > >
> > > changes for his foreach change.
> > >
> > > The hard part is deciding the behaviour to implement and the
> > >
> > > lack of process in actually getting it into perl.
> > >
> > > This RFC process should help with both parts, since we didn't really
> > >
> > > have a process beyond "commit if you have a commit bit".
> > >
> > > Tony
> > >
> > > - relative to any other code having to deal with the OP tree and internals
> > Anyone who wants to learn how to implement a new Perl feature should
> > read LeoNerd's tutorial:
> > http://leonerds-code.blogspot.com/2021/02/writing-perl-core-feature.html
> Which is precisely how we got into this trim mess. That and an attempt to call ones bluff. Probably not the best way to handle things in the future.
I'm not sure what you're meaning here.
The RFC process we're trialling *would* avoid one huge part of the trim mess -
it would have exposed the entire problem of revisiting the question of
"in place" vs "returning a value" *after* that decision seemed to have been
settled, and hence it was fair to work on an implementation.
The problem effectively is attempting to re-legislate something that is
Much like it *is* decided that (at least) an efficient trim function belongs
in the core, and it is not helpful to try to re-open that discussion to get
a different answer.
> I'd like to see an RFC process that also allows for people to suggest things that don't know how to implement them, as Neil has suggested. But bonus points if they are onboard to help and learn.
I believe that that is exactly what the process we are trialling can do.
> What we have here is an opportunity to create a formalized process. It's also an opportunity to build this process out as a series of RFCs (for the RFC, yes).
No, as I wrote in https://github.com/Perl/RFCs/blob/master/docs/others.md
PEPs and TIPs are both used both for code improvements and process
improvements. This conflation seems awkward - it requires a
special status ("Active") for process related PEPs/TIPs, and many
of the sections needed for feature changes are irrelevant for
process changes. It also means that the official document for the
process itself is the change document for the process, not the
procedure document. I think this is a bad idea and we should not
imitate it. PHP's RFCs only cover code. I like this better, but I
think we can "borrow" more of the detail from the Python and TCL
approach than from PHP's.
It does not make sense to use the same style of RFC to describe process as
to describe code.
> As such, we should be on the look out for the different kinds of RFCs that get proposed. Furthermore, we should be mindful of the motivations of the RFC and what is being asked. I get it; this is still embryonic, but has huge potential to bring great improvements to perl, Perl, and our processes. We must be mindful of dirty pool and saying "NO" in its many forms. The process must be "fair", meaning that each RFC gets its fair shake. I also would love to see the PSC or whomever picks some "themes" or "areas" for RFCs. This is also a great target for "grand challenges" - e.g., "2022 is the year of <<doing something>> with <<some area of perl/Perl>>'. Just because the RFCs come from the wild doesn't mean our overlords can suggest a focus area or more.
I doubt that declaring something expecting movement is helpful.
There's a massive disparity between how many ideas we have and how
many people we have to even mentor others, let alone implement
To get out of this hole, we need an approach that acknowledges
this and emphasises scaling up and out with what we have, instead
of pretending that we're short on ideas and long on under-used
Declaring the 2022 the "year of foozles" might produce lots of suggestions
about foozles, but it won't increase the number of folks working on them.
*Also*, strictly, "2022" doesn't work as our cycle is roughly June-June.
2022.5 doesn't quite have that ring to it.
> In addition to having a "nomination" and a "sponsor" (or second), there be a process by which less-skilled or seasoned individuals who wish to participate in implementation be given an opportunity to do so - especially if they are the one who proposed it. Think of it as GSC but for Perl and all year long. Does it need a group of seasoned Obi Wans or Luke Skywalkers to mentor? Yes. I think we have a few of those, and with the right amount of beer or appeals to cementing their legacies, maybe they will be cajoled into fulfilling this role.
It's "Author" and "Sponsor" - have you read it before commenting on it?
The explicit intent is that the "Author" need not be skilled in the internals
of Perl: https://github.com/Perl/RFCs/blob/master/docs/future.md
The Author is the champion for the RFC. Their motivation and enthusiasm
to have the feature successfully implemented and shipped drives the
process. Their task is to eliminate each "lowest hanging excuse" in turn
to get to shipping code. They are responsible for
* seeking input
* shepherding discussion to some sort of consensus (or appealing to the
PSC to resolve an impasse)
* ensuring all sections in the RFC are complete (working with
implementers and others as necessary)
I looked at the git history of the trim branch and this is pretty much
exactly how the work was divided up. LeoNerd *just* did the coding.
Scott Baker wrote the tests, wrote the documentation, and did all the
cleanup to get things into a presentable state. I think he also handled
shepherding the discussions, but I've not gone to check that.
This split maximises the time we have from our limited number of skilled
contributors, and also helps get more people familiar with more parts of
It's already what's being proposed.
> We don't need the reason of "we have no one to implement your idea" ever be a reason to not do something. This would necessary require a volunteer mentor to assist such individuals. But if the spirit of this idea is followed, then you'll simultaneous permit good ideas "from the field" to come to light and also develop new classes and generations of contributors.
We have a template for what an completed implemented RFC should end up
as, but if all you have is an idea - don't worry, we'll help you get
Any RFC (before merging) can be marked "Deferred" if work has paused, or
if they have no-one implementing them. RFCs have at least on Author, who
acts as champion for the idea, and ideally writes documentation and
tests. "Accepted" RFCs should have a core team member as a Sponsor, who
acts as mentor and point of contact. If the Author can't implement their
idea alone, and no-one else volunteers, then the PSC will try to find
someone to implement an "Accepted" RFC, but this may not be possible,
and the RFC will stall.
ie it is planned (and designed) such that we can "Accept" an RFC without
having anyone down to implement it.
it is intended that we can accept good *ideas* from anyone and turn them
It is clear that you haven't actually read https://github.com/Perl/RFCs
before "commenting" on it, because you are making specific criticisms
about missing things are present.
*Had* you read it, you would have been criticising why they weren't the
best way to achieve the shared goal.
Thank you for wasting my time.