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

Re: Creating an RFC process for Perl

Thread Previous | Thread Next
From:
mah.kitteh via perl5-porters
Date:
June 12, 2021 01:44
Subject:
Re: Creating an RFC process for Perl
Message ID:
mXQN3jN7eT_ALSGCetee7lPhhef9-weKs1gSxA6JIbDGbLM16uR49BSeb39fG7TEYN_UGG-ST1iDt_u5tESUXwihbwj3FlDE3i5eficljGE=@protonmail.ch
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, June 9th, 2021 at 7:56 PM, Tomasz Konojacki <me@xenu.pl> wrote:

> On Thu, 10 Jun 2021 10:35:33 +1000
>
> Tony Cook tony@develop-help.com 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'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.

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).

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.

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.

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.

Cheers,
Brett

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About