develooper Front page | perl.perl5.porters | Postings from June 2021

Re: Creating an RFC process for Perl

Thread Previous | Thread Next
Nicholas Clark
June 12, 2021 07:13
Re: Creating an RFC process for Perl
Message ID:
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 <> wrote:
> > On Thu, 10 Jun 2021 10:35:33 +1000
> >
> > Tony Cook 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:
> >
> >
> 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
already decided.

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

    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:

    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
the core.

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
into RFCs.

It is clear that you haven't actually read
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.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About