Mailing List Archive

Den 18.06.2022 21:12, skrev Ricardo Signes:
> Porters,
>
> 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.

> …

> The problem with this as a state diagram is that it defines the
> /states/ pretty well, but very little about the /transitions/.
>
> First:  what happens at that "?" box after submission to p5p?  Then,
> if the next result is "exploratory RFC", who decides that?  How is it
> communicated?  Who is responsible for doing it, whatever "it" is?  (It
> seems to be "someone who can commit to the RFCs repo assigns an ID and
> creates the exploratory RFC, which I believe means "edits the README
> file.")
>
> I would like to rewrite this document, not to change particularly
> much, but to very clearly define each phase and how the RFC moves from
> one to the other, and who is intended to do what.  I may propose some
> procedural changes if documenting current ones makes clear that
> current procedures are too unclear or onerous.
>
> Finally, I am tempted to include "discussion belongs on p5p, not Yet
> Another Issue Tracker," unless stopped.  While code review on GitHub
> is just great, having three places for discussion of designs is not.
>
> This is your chance to get out in front of me and say "don't do it!"
> or "I will buy you a beer if you get it done by July!" I am not
> looking for suggestions on massive overhauls at this time.
>
+1 for more defined transition documentation/definition.

Is there a need for exploratory step on top of p5p discussion and
pre-rfc threads or could one just go for the provisional step?

(Finding the sweet spot between rigid structural, well-defined processes
and having a low threshold to contributing is always great)

--

Nicolas Mendoza

On Sat, Jun 18, 2022 at 4:13 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

>
> Finally, I am tempted to include "discussion belongs on p5p, not Yet
> Another Issue Tracker," unless stopped. While code review on GitHub is
> just great, having three places for discussion of designs is not.
>

/me stands still


> This is your chance to get out in front of me and say "don't do it!" or "I
> will buy you a beer if you get it done by July!" I am not looking for
> suggestions on massive overhauls at this time.
>

Thank you for raising this issue. If you get it done b?y? ?J?u?l?y? at all,
I'll definitely buy you that beer :)

Cheers!

I'd also also say create GitHub discussions for p5p to easily do
discussions around Perl by everyone (it might be possible to forward p5p
mailing list replys to it as well).
Thanks.

19 iyn 2022, B. 05:12 tarixind? breno <oainikusama@gmail.com> yazd?:

> On Sat, Jun 18, 2022 at 4:13 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
> wrote:
>
>>
>> Finally, I am tempted to include "discussion belongs on p5p, not Yet
>> Another Issue Tracker," unless stopped. While code review on GitHub is
>> just great, having three places for discussion of designs is not.
>>
>
> /me stands still
>
>
>> This is your chance to get out in front of me and say "don't do it!" or
>> "I will buy you a beer if you get it done by July!" I am not looking for
>> suggestions on massive overhauls at this time.
>>
>
> Thank you for raising this issue. If you get it done b?y? ?J?u?l?y? at
> all, I'll definitely buy you that beer :)
>
> Cheers!
>

On Sat, Jun 18, 2022 at 03:12:51PM -0400, Ricardo Signes wrote:
> Finally, I am tempted to include "discussion belongs on p5p, not Yet
> Another Issue Tracker," unless stopped. While code review on GitHub is
> just great, having three places for discussion of designs is not.

I am very much in favour of the discussions being on p5p rather than
github. But then I am a dinosaur :-).

--
"I do not resent criticism, even when, for the sake of emphasis,
it parts for the time with reality".
-- Winston Churchill, House of Commons, 22nd Jan 1941.

On Sat, Jun 18, 2022 at 03:12:51PM -0400, Ricardo Signes wrote:
>This is your chance to get out in front of me and say "don't do it!" or
>"I will buy you a beer if you get it done by July!"

From a P5P mostly-lurker: the RFC process has made what's changing (or
not changing) in the language much easier to follow. Long may it
continue, and if further formalizing the process makes that more likely,
that seems like a good idea to me, especially the bit about specifying
one place (P5P) for the RFCs to be discussed.

--
Tom Ryder <https://sanctum.geek.nz/>
Maybe we can bring back the light.

On Sun, Jun 19, 2022, at 08:57, Dave Mitchell wrote:
> I am very much in favour of the discussions being on p5p rather than github. But then I am a dinosaur :-).

Same. But then, I am in the pocket of Big Email.

--
rjbs

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

On Fri, 15 Jul 2022 18:06:58 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

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

This is way too ambiguous. There are many more possible results than
just "everyone hates it" and "everyone loves it". A proposal might be
controversial, or perhaps the reactions will be lukewarm, or maybe it
will be completely ignored.

This ambiguity creates very bad incentives. It will incentivize some
people to push with their RFC regardless of feedback *and* discourage
others from pursuing their RFC after receiving minor, unimportant
criticsm.

I really think that part of the process should be more formal. The most
obvious way is to have PSC decide whether a given proposal should be
made into an RFC or not. Another option would be some kind of voting. But
that sounds complicated. Or maybe a specified minimum number of +1
replies? I don't know.

On Fri, Jul 15, 2022, at 18:45, Tomasz Konojacki wrote:
> On Fri, 15 Jul 2022 18:06:58 -0400 "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
> I really think that part of the process should be more formal. The most
> obvious way is to have PSC decide whether a given proposal should be
> made into an RFC or not. Another option would be some kind of voting. But
> that sounds complicated. Or maybe a specified minimum number of +1
> replies? I don't know.

What I want to do is avoid "the PSC must follow the thread closely to know when to say *now is the time, OP! Strike!*"

What about:

"After you've seen the response you get, and you think you've engaged as much as is useful with any response, post that you'd like the PSC to greenlight a formal proposal."

This creates an unambiguous trigger event for PSC to do something, and the something is clear:
* say "yes please do"
* say "no, you have more work to do, which is X"
--
rjbs

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.

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.

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.

Sam
--
Website: http://www.illuminated.co.uk/

On Fri, 15 Jul 2022 21:13:07 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> What I want to do is avoid "the PSC must follow the thread closely to know when to say *now is the time, OP! Strike!*"
>
> What about:
>
> "After you've seen the response you get, and you think you've engaged as much as is useful with any response, post that you'd like the PSC to greenlight a formal proposal."
>
> This creates an unambiguous trigger event for PSC to do something, and the something is clear:
> * say "yes please do"
> * say "no, you have more work to do, which is X"

It's definitely better than the original version.

* 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

On Fri, Jul 15, 2022, at 18:06, Ricardo Signes wrote:
> Okay, so. I have been putting off writing more about what we might do, because mostly it all seems like a pain.

I have put this proposal into a branch, with modest but non-trivial changes.

You can look at the process document in its branch <https://github.com/rjbs/RFCs/blob/process-v2/docs/process.md>, or you can look at it in the PR that I filed <https://github.com/Perl/RFCs/pull/24>.

I would like to get the required acceptance of this to justify my time in going through the existing RFC tracker and matching things up to new statuses. Then we can very clearly state who ought to be moving things forward, which I hope will be helpful.

Thumbs up required from:
- [ ] BooK
- [ ] LeoNerd

Thumbs up from Nicholas, author of v1, would also be nice.

I will certainly consider strong arguments against…

--
rjbs

On Fri, Aug 05, 2022 at 05:05:22PM -0400, Ricardo Signes wrote:
> On Fri, Jul 15, 2022, at 18:06, Ricardo Signes wrote:
> > Okay, so. I have been putting off writing more about what we might do, because mostly it all seems like a pain.
>
> I have put this proposal into a branch, with modest but non-trivial changes.
>
> You can look at the process document in its branch <https://github.com/rjbs/RFCs/blob/process-v2/docs/process.md>, or you can look at it in the PR that I filed <https://github.com/Perl/RFCs/pull/24>.
>
> I would like to get the required acceptance of this to justify my time in going through the existing RFC tracker and matching things up to new statuses. Then we can very clearly state who ought to be moving things forward, which I hope will be helpful.
>
> Thumbs up required from:
> - [ ] BooK
> - [ ] LeoNerd

Thumbs up from me.

There's a bunch of valid feedback in the PR, but I like that it makes
clear in each phase who should move things forward.

(The naming of phases is better too: e.g. "Implementing" instead of
"Implemented".)

--
Philippe Bruhat (BooK)

Too many believe only in the belief.
(Moral from Groo The Wanderer #58 (Epic))

On Fri, Aug 5, 2022, at 17:05, Ricardo Signes wrote:
> You can look at the process document in its branch <https://github.com/rjbs/RFCs/blob/process-v2/docs/process.md>, or you can look at it in the PR that I filed <https://github.com/Perl/RFCs/pull/24>.

I've made a number of fairly small changes based on feedback, and added some more commentary on there, but the short version is: I think it's pretty much okay, and should do a better job of helping us limit the number of vaguely-in-process stuff. I think it should also make clearer who should be "doing stuff".

I also, more importantly, did the next hunk of work I said I'd do: I made a new copy of the proposal tracker <https://docs.google.com/spreadsheets/d/1hVOS7ePuLbVkYcf5S-e_eAodj4izm9Cj7AVs25HvngI/edit#gid=2054807862> with a "New Status" column, mapping what state I think things should be in. Most things are now rejected or "not tracked", meaning they would not have become tracked documents yet. Only eight documents are currently live, and next I'd like to make clear who we think is on the hook to do what. I expect one or two should become expired and that the PSC needs to take clear action in a few other cases.

Before I do that, this is a chance for folks to say "something is quite wrong there."

--
rjbs