Front page | perl.perl5.porters |
Postings from July 2022
Re: the RFC process is a pain
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
July 15, 2022 22:07
Subject:
Re: the RFC process is a pain
Message ID:
eae01543-fc31-4c04-be6c-450a1d46f7c9@beta.fastmail.com
On Sat, Jun 18, 2022, at 15:12, Ricardo Signes wrote:
> I am glad we have tried to formalize "how we decide to change the design of things in perl" to something more structured than "post on p5p until you give up or get it." The RFC process as it's currently in place <https://github.com/Perl/RFCs/blob/main/docs/process.md>, though, feels like it's not good enough yet.
Okay, so. I have been putting off writing more about what we might do, because mostly it all seems like a pain. Today, I said I'd have a look at using new-style GitHub projects, but they felt like a pain in the butt.
Here's the diagram from the process (apologize for repeating this):
idea
|
v
mail p5p
|
better | rejected
on <-------?-------> with
CPAN | reasoning
v
Exploratory RFC
"we think this idea is worth exploring"
(Help us figure out how this will work)
|
v
Provisional RFC
"we think this idea is worth implementing"
(We have a firm idea of what we want to do)
|
v
Accepted RFC
"we think this plan looks viable"
(There is a sane plan for how to do it)
|
v
Implemented RFC
"docs, tests and implementation"
(And we can support it in the future)
|
v
Shipped
In a stable release, subject to "experimental features" process
|
v
Stable
In a stable release, now subject to normal "deprecation" rules
This is fine, as far as it goes, but these statuses are *states*. They are *static*. What we care about is the *dynamic*. When in each state, what can and should happen? Who should be taking action? When a state has multiple next steps, how is the next step decided? Also, our existing RFC tracker has a number of statuses not reflected in this diagram: Parked, Stalled, Draft submitted. How does it become parked or stalled? Through inaction.
The whole process feels optimized for stasis.
Here is my first, very rough, suggestion for an alternative. Note that this alternative is not necessarily very different from what we're doing, but the emphasis is different.
*_RFC Process Mark â…¡, draft_*
*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.
You are taking the temperature of the list. If there is a great outcry that this is a bad idea, or has been tried before, or was explicitly rejected before, you should probably stop. If everyone says, "Sounds great, flesh it out!" then you should write a formal RFC. Based on that feedback, either stop and go back to the drawing board, *or* write up a formal RFC.
In this stage of your idea's life, it isn't in the tracker. (There's no such thing as a "pre-RFC" in the RFC tracker. It's not an RFC yet!)
*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.
When you think your idea has been sufficiently scrutinized, and you gotten all the feedback you're going to benefit from, submit your updated document to the PSC. At this point, it will be assigned a row in the tracker. Its status will be *Exploratory*. The PSC (or other deputized folk) will begin the process of vetting the idea. They will review discussion about the idea, they will produce a list of questions not yet answered, and they will press existing core team members (or other experts) for input.
The PSC (or deputies) will eventually either:
* move the document to *Provisionally Approved* status (see below) because they believe it is ready for implementation
* move the document to *Rejected* status because they believe it should not be implemented; This may come with advice on how to formulate an alternate proposal that has more chance of being accepted. This isn't used for "it needs some edits", but for "it's fundamentally deeply flawed."
* move the document to the *Expired *status* *because the original proposer (or other vital personnel) are not responsive
"This didn't get nearly enough pre-submission discussion" is a valid reason to reject.
*Provisionally Accepted*
When a proposal is accepted, the PSC is stating that they'd like to see the idea implemented, and are likely to merge an implementation if it doesn't bring with it any unwelcome surprises or complications. It is now the responsibility of the proposer or some other volunteer to produce an implementation. The PSC will keep the item on the tracker while waiting for an implementation. They should make a regular note of accepted-but-not-implemented proposals on perl5-porters.
If no implementation has made progress for three months, the document moves to *Expired*.
If an implementation exposes serious problems that mean the PSC no longer believes the proposal can work, the document moves to *Rejected.*
If an implementation is delivered and it isn't clear that it's broken* as designed*, the document moves to *Testing* status.
*Testing*
Now there's an accepted proposal and an implementation. At this point, it needs to have enough tests, showing how it will work in real world conditions. The PSC will consult with the author, each other, perl5-porters, and other experts to produce a list of needed test cases. The proposer, implementer, or other volunteers will provide the testing. Once enough testing is done, then the document will be either…
* marked *Accepted*, with the code merged as a new (probably experimental!) feature of perl
* marked *Rejected*, because the quality or behavior of the feature or its implementation are not acceptable
Also, of course, the document may move to *Expired* if workers vanish.
*THE END*
In the above, I have tried to reduce the scope of "the process" at least as far as tracking a row in a list is concerned. I have tried to specify who is responsible for doing what at each phase, and that there is a timeout. Below is a rough diagram of the proposed structure. Dashed lines indicate the informal section.
--
rjbs
Thread Previous
|
Thread Next