Front page | perl.perl5.porters |
Postings from July 2022
Re: the RFC process is a pain
Thread Previous
|
Thread Next
From:
Oodler 577 via perl5-porters
Date:
July 18, 2022 22:56
Subject:
Re: the RFC process is a pain
Message ID:
YtXk9rsR1Q2jq9UW@odin.sdf-eu.org
* Sam Kington <sam@illuminated.co.uk> [2022-07-16 02:20:33 +0100]:
> On 15 Jul 2022, at 23:06, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> [snippage]
> > Pre-RFC
> >
> > The RFC process starts with an formal proposal to add or change a language feature in Perl. But you, the prospective author of an RFC, shouldn't start by writing one. Start by posting to p5p that you have an idea. Explain what problem you're solving, how you think you can solve it, and what prior art you looked at. Be clear and concise. Make it easy for the rest of the list to see what you're suggesting without reading an enormous wall of text, but don't lose so much detail as to be meaningless.
> >
> > Draft Proposal
> >
> > You decided your idea got enough acclaim that you should write it up. You get the template document and fill it out. You take its advice, thinking hard about what goes in each section. Then you post it to p5p as an email with the subject "PROPOSAL: my great idea". Members of the list will reply with more questions and suggested amendments. You should read them and amend the proposal to clarify your ideas or react to valid criticism.
> >
> > Open question: Is it better to have the text only emailed to the list, or better to put it in a repository? Right now, we use the perl/RFCs repository, which is fine, but has led to discussions happening in multiple places. The place to discuss these documents should largely be on perl5-porters, not on GitHub.
>
> I think discussion about pre-RFCs should be on p5p; but refinement of draft proposals should be primarily be on GitHub. This is because the nature of the discussion changes.
I agree. To take this further, it should be clear that the RFC process
is not simply a feature request bucket for those who reliably do the
heavy lifting for new features. But there should be a bucket like that
nonetheless in the event that someone with the skills to implement things
can pick it up.
>
> Pre-RFC threads are typically about (1) is this a good idea? and (2) could this go horribly wrong because of circumstances I haven?t thought of? Obviously #1 is inherently on-topic for p5p; but #2 is also appropriate, because there are a whole bunch of greybeards on p5p who are quite happy to lurk for years, only to occasionally chime up with stuff like ?actually, I think you?ll find that Perl scripts which happen to be part of the init process of Solaris v.ancient use this language feature you thought was obsolete?.
>
> But once someone says ?looks good, write it up as an RFC?, I think the discussion then happens (or should happen) on GitHub, because often there?s a an iterative cycle of feedback and editing, where people say ?looks good, but I think you should clarify this bit? / ?you?ve made a typo here?, and it?s fixed, and then more review happens.
Related to my comment above, there should also be an "okay great this looks
like good idea, now who is going to do it?" Where does this list live?
A gap I see is that once an idea is accepted, who is supposed to implement
the RFC. Or more generally, what are the process options after an RFC is
accepted?
>
> Now, it might well be that as a result of this conversation, people realise that there?s an important point that was missed in the pre-RFC discussion, at which point we should start a thread on p5p to bring it to the attention of those people who weren?t interested in copy-editing discussions on GitHub. But my feeling, as an outsider, is that the best way to discuss things is: pre-RFC on p5p, draft proposals on GitHub.
Another problem with having all the things happen on p5p is that a lot
of potentially useful artifacts and conversation points are lost. It's
also not feasible to track any planning and implementation/testing that
might happen after the RFC has been accepted.
I like to watch the regular planning meeting that FreeBSD streams online;
granted, they are very well funded and have the infrastructure. But using
this as an example of what good OSS coordination looks like, it might be
useful to treat quarterly or annual planning in a similarly organized fashion.
The key is that there are leads for each formal "project" (e.g., an accepted
RFC) and they try to have at the very least quarterly updates.
If done well, this will also help with the issue that there are not really
a lot of people who can implement these RFCs, as cool as they may be.
Cheers,
Brett
>
> Sam
> --
> Website: http://www.illuminated.co.uk/
>
--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Thread Previous
|
Thread Next