Mailing List Archive

RFC: formal perl-rfc mailing list for initial submission
I've been studying this process document,

https://github.com/Perl/RFCs/blob/master/docs/process.md

This suggestion is sort of a meta-RFC for the process, but it seems like there could be some value in establishing
a formal mailing list for the pre-RFC'ing process that perl porters is currently being used for? I would have added this as a GH "issue" in the
repo, but that has been disabled (probably a good idea).

Benefits:

A new list will allow for there to be strict expectations set from the very beginning and allow for there
to be more control over the direction of the conversation. A list moderator could actually moderate as to
the current set of RFCs being discussed. For example, the flow would look like:

* user X send in preliminary RFC to get it on the weekly "docket"
* moderator then schedules discussion
* there could be a formal open and close of discussion for 1 RFC proposals at a time
* anyone wishing to opine would be strongly encouraged to do so formally, in a self-contained "amicus brief" style - i.e., not in a tit-for-tat inline discussion
* detailed discussions would be directed to p5p, but only formal "briefs" sent to the rfc list should be considered since they should be self contained and well reasoned
to the same standard that RFCs are expected to be

Yes this is sounding like a court room. But there might be value is such formalism. Once the pre-RFC period has ended, then PRC or whomever would
then take under advisement and "rule" on it in some fair amount of time. The rulings could be more refined than "yes" or "no" - could be also "tabled".

One the RFC is formalized, the "amicus" briefs or whatever could be added as part of the preliminary findings. Those who submitted in the pre-process
would be discouraged from submitting again unless something has radically changed either in their understanding or as to the RFC proposal itself.

Using p5p as the initial arbiter of the merits of an RFC or pre-RFC seems difficult because it's impossible to tame.

Problems/Unknowns:

* a new list would necessarily require an "opt in" phase
* I don't know what it'd look like if p5p and the rfc list were simultaneously discussing the same thing or what bleed-over might occur

Hope this helps.

Cheers,
Brett
Re: RFC: formal perl-rfc mailing list for initial submission [ In reply to ]
Mailing lists have weak and blunt moderation controls, nor do they offer
any features to aid annotations, revisions, or provide a consistent
experience etc. Nor do they lend themselves to socializing the new ideas
widely.

Moving RFC's out of perl5-porters is the right idea, but should go in to
a system that is suited to that purpose.

Dean

On 2021-06-14 12:40, mah.kitteh via perl5-porters wrote:

> I've been studying this process document,
>
> https://github.com/Perl/RFCs/blob/master/docs/process.md
>
> This suggestion is sort of a meta-RFC for the process, but it seems like there could be some value in establishing
> a formal mailing list for the pre-RFC'ing process that perl porters is currently being used for? I would have added this as a GH "issue" in the
> repo, but that has been disabled (probably a good idea).
>
> Benefits:
>
> A new list will allow for there to be strict expectations set from the very beginning and allow for there
> to be more control over the direction of the conversation. A list moderator could actually moderate as to
> the current set of RFCs being discussed. For example, the flow would look like:
>
> * user X send in preliminary RFC to get it on the weekly "docket"
> * moderator then schedules discussion
> * there could be a formal open and close of discussion for 1 RFC proposals at a time
> * anyone wishing to opine would be strongly encouraged to do so formally, in a self-contained "amicus brief" style - i.e., not in a tit-for-tat inline discussion
> * detailed discussions would be directed to p5p, but only formal "briefs" sent to the rfc list should be considered since they should be self contained and well reasoned
> to the same standard that RFCs are expected to be
>
> Yes this is sounding like a court room. But there might be value is such formalism. Once the pre-RFC period has ended, then PRC or whomever would
> then take under advisement and "rule" on it in some fair amount of time. The rulings could be more refined than "yes" or "no" - could be also "tabled".
>
> One the RFC is formalized, the "amicus" briefs or whatever could be added as part of the preliminary findings. Those who submitted in the pre-process
> would be discouraged from submitting again unless something has radically changed either in their understanding or as to the RFC proposal itself.
>
> Using p5p as the initial arbiter of the merits of an RFC or pre-RFC seems difficult because it's impossible to tame.
>
> Problems/Unknowns:
>
> * a new list would necessarily require an "opt in" phase
> * I don't know what it'd look like if p5p and the rfc list were simultaneously discussing the same thing or what bleed-over might occur
>
> Hope this helps.
>
> Cheers,
> Brett
Re: RFC: formal perl-rfc mailing list for initial submission [ In reply to ]
Sure. Perhaps the value here is the formalization of the initial phase, one that encourages orderly and bounded submission og high quality "comments" for the PRC (or whomever) to consider.

It would also generate a nice set of artifacts of (hopefully) high quality opinions based on some sort of analysis that would serve well as background information for the future.

Cheers,
Brett
??????? Original Message ???????
On Monday, June 14th, 2021 at 2:52 PM, Dean Hamstead <dean@fragfest.com.au> wrote:

> Mailing lists have weak and blunt moderation controls, nor do they offer any features to aid annotations, revisions, or provide a consistent experience etc. Nor do they lend themselves to socializing the new ideas widely.
>
> Moving RFC's out of perl5-porters is the right idea, but should go in to a system that is suited to that purpose.
>
> Dean
>
> On 2021-06-14 12:40, mah.kitteh via perl5-porters wrote:
>
>> I've been studying this process document,
>>
>> https://github.com/Perl/RFCs/blob/master/docs/process.md
>>
>> This suggestion is sort of a meta-RFC for the process, but it seems like there could be some value in establishing
>> a formal mailing list for the pre-RFC'ing process that perl porters is currently being used for? I would have added this as a GH "issue" in the
>> repo, but that has been disabled (probably a good idea).
>>
>> Benefits:
>>
>> A new list will allow for there to be strict expectations set from the very beginning and allow for there
>> to be more control over the direction of the conversation. A list moderator could actually moderate as to
>> the current set of RFCs being discussed. For example, the flow would look like:
>>
>> * user X send in preliminary RFC to get it on the weekly "docket"
>> * moderator then schedules discussion
>> * there could be a formal open and close of discussion for 1 RFC proposals at a time
>> * anyone wishing to opine would be strongly encouraged to do so formally, in a self-contained "amicus brief" style - i.e., not in a tit-for-tat inline discussion
>> * detailed discussions would be directed to p5p, but only formal "briefs" sent to the rfc list should be considered since they should be self contained and well reasoned
>> to the same standard that RFCs are expected to be
>>
>> Yes this is sounding like a court room. But there might be value is such formalism. Once the pre-RFC period has ended, then PRC or whomever would
>> then take under advisement and "rule" on it in some fair amount of time. The rulings could be more refined than "yes" or "no" - could be also "tabled".
>>
>> One the RFC is formalized, the "amicus" briefs or whatever could be added as part of the preliminary findings. Those who submitted in the pre-process
>> would be discouraged from submitting again unless something has radically changed either in their understanding or as to the RFC proposal itself.
>>
>> Using p5p as the initial arbiter of the merits of an RFC or pre-RFC seems difficult because it's impossible to tame.
>>
>> Problems/Unknowns:
>>
>> * a new list would necessarily require an "opt in" phase
>> * I don't know what it'd look like if p5p and the rfc list were simultaneously discussing the same thing or what bleed-over might occur
>>
>> Hope this helps.
>>
>> Cheers,
>> Brett
Re: RFC: formal perl-rfc mailing list for initial submission [ In reply to ]
Re-ordering your message to make it easier for me to reply to
(I realise, not something that any line-by-line code review system lets you
do. Well, because, ideas aren't code.)

On Mon, Jun 14, 2021 at 07:40:45PM +0000, mah.kitteh via perl5-porters wrote:
> I've been studying this process document,
>
> https://github.com/Perl/RFCs/blob/master/docs/process.md
>
> This suggestion is sort of a meta-RFC for the process, but it seems like there could be some value in establishing
> a formal mailing list for the pre-RFC'ing process that perl porters is currently being used for? I would have added this as a GH "issue" in the
> repo, but that has been disabled (probably a good idea).

> Problems/Unknowns:
>
> * a new list would necessarily require an "opt in" phase
> * I don't know what it'd look like if p5p and the rfc list were simultaneously discussing the same thing or what bleed-over might occur

Yes :-)

(*For now*) I tried to have the configuration set such that discussion
*both* about RFCs themselves and the RFC process generally was in one place.

And that that place was this list.

Because, as you observe, it's a problem if discussion is in more than once
place.

Right, so this sentence is key:

> Using p5p as the initial arbiter of the merits of an RFC or pre-RFC seems difficult because it's impossible to tame.

I think that your entire plan is predicated on the idea that p5p is
impossible to tame. The current steering committee *all* thinks otherwise.
And whilst I won't be on PSC in two weeks from now, the maths of the
election means that at least 1 of Neil or Rik will be on the new PSC, and
will be advocating the same plan as currently

Several specific reasons

1) More generally, if it's not possible to have useful discussion on the
mailing list, we might as well turn it off
2) But if so, why would *any other* discussion forum be any better? It's
not like GitHub comments are structurally much different from a mailing
list (with *some* advantages, but loosing others such as proper
threading)
3) The PSC felt that the quality of discussion in the RFC threads was good.
(ie "above average" compared with some recent threads)

If anything, this is suggesting that *having* the RFC process apply some
structure to p5p list traffic is acting as a good influence.

> Benefits:
>
> A new list will allow for there to be strict expectations set from the very beginning and allow for there
> to be more control over the direction of the conversation. A list moderator could actually moderate as to
> the current set of RFCs being discussed. For example, the flow would look like:

Needing a "moderator" rather goes against one of the goals of the process,
which was to reduce the need for specific people to do "editorial" tasks.
The PEP process keeps stressing "the PEP editor does this" or "does that",
and I've been told that there are about 8 editors (implying "it needs that
many") but it seems that you can't see the list (and hence count them):

https://github.com/orgs/python/teams/pep-editors/members

unless you're in the Python org on GitHub.

(I'm going to assume that this is because that file contains personal
contact information and shouldn't be published, given that there's a similar
restriction stated for some other membership list primary source files,
and in this case it so rarely matters that there's no automated publication
mirror.)

Also, I'm not convinced that building a system that assumes "moderation" is
great. One person's "moderation" is another person's censorship.

> * user X send in preliminary RFC to get it on the weekly "docket"
> * moderator then schedules discussion
> * there could be a formal open and close of discussion for 1 RFC proposals at a time
> * anyone wishing to opine would be strongly encouraged to do so formally, in a self-contained "amicus brief" style - i.e., not in a tit-for-tat inline discussion
> * detailed discussions would be directed to p5p, but only formal "briefs" sent to the rfc list should be considered since they should be self contained and well reasoned
> to the same standard that RFCs are expected to be

I think "to the same standard" is key here. PSC would like *most* traffic
generally to be of this standard, whether it's on RFC, other list traffic,
or comments on GitHub. (Yes, sure, jokes and silly comments are allowed.
It's important to have fun and stay sane. But they shouldn't swamp the
"signal")

> Hope this helps.

Yes, thanks for the feedback.


I'm really keen to create a process that minimises the amount of central
work that needs to be done, and "empowers" contributors to "enable" them to
do it themselves. (ie, what I really mean is that longer term they are
*expected* to do more of this, or their idea stalls, and that's the deal for
getting your idea to progress)

Right now for RFCs *I* am *all* of

* ghost writer for the RFCs themselves
* editor
* in charge of figuring out the process
* actually implementing the thing
* executive management (who do their own typing)

and it's getting a bit tiring. This scales about as well as "DentOps":

https://www.programmersought.com/article/19515332833/

(If anyone is wondering why I'm not standing again for the PSC, this is part
of it)


*Right now* the "RFC on the RFC" that think would be useful is

1) Do we have the correct states for RFCs?

What isn't going to be obvious from process.md is that we have one more "in
progress" state that Python has in its PEPs. *I* know this because Neil had
a discussion with me about why he felt it important, and he was right, so
it's in.

2) Do we have the correct rules for state transitions?

Both "do we have the correct criteria for progressing?" and "do we have the
correct people listed as checking this and approving?"

3) Do we have the correct sections in the template?

Despite Python running their PEPs for 20 years now, we've quickly found that
it's better to split "Future Scope" from "Rejected" than lump both together.

4) Do we have useful guidelines on what ideas will get accepted, and which
are impractical?


and then more generally we need to see if

1) Can we get to a point where more people can sketch out their idea in
the right shape for an RFC?

2) Are more people able to take discussion and summarise it into an RFC?

3) Is the quality of the discussion useful?

4) Is the quality of idea submission improving?
(ie does the combination of better guidelines *and* a growing corpus of
"this was accepted" "this was not, because..." cause potential
submitters to realise that an idea is obviously non-viable and not even
submit it. Or that an idea needs to be framed in a particular way to
make sense, and perform that step *before* submission)



Once we can get some of *that*, then I think we're in a position where it's
time to think about *where* RFCs might work better. Rust and Matrix both
implement them as "pull" requests on an RFC repository. That seems like a
better idea than a mailing list. *But*, it assumes that most ideas arrive as
*drafted* RFCs in a pull request. Not 4 to 16 line "feature requests".

Give this current approach a couple of months, and we might have an idea
whether and when we can move to that. But talking too much about it now is
trying to run before we can walk.


Nicholas Clark
Re: RFC: formal perl-rfc mailing list for initial submission [ In reply to ]
Thank you for the thoughtful reply. I don't disagree with any of it, nor do I feel like I have the right to.

It's become clear to me that the "value" of my original suggestion was to generate an orderly and organized clearing house of high quality input and to suggest a way for RFC facilitators to act distinctly human.

So rather than suggest a change to the process, I'll just list what I think would be valuable for everyone moving ahead - most importantly, provide an orderly and "fair" way (as in it will eventually be read) input process. That is to say, ideas should be told: "yes", "no", "tabling", or "need more info".

0. once a RFC idea is proposed to p5p; this in favor/against should provide their comments regarding the merit of the idea for the PSC to consider in a high qaulity, self contained submission (not part of a discussion)
1. once a RFC is selected for some official C'ing, there should be some organized set of pre-comments (those arguing that this should be an official RFC or has merit)
2. once a RFC is in the C'ing phase, input should be accepted and considered on as high quality and self-contained submissions (i.e., not in a 'discussion' form) detailing for/agains (and reasons)

Also:

* high quality artifacts generated from all the above phases should be saved and organized for research purposes, even for RFC ideas not "selected" (unless it was total crap)
* RFCs being promoted to an official C-phase should spring to life with the high quality/self-contained pre-RFC comments available (and marked as such)
* individuals will be encouraged submit high quality, self conained comments in the above phases; one per phase - this doesn't include on going "research" one might do for an active RFC (these could captured elsewhere, including in a git brach as code changes or example code changes)

The main point here is to:

a. capture high quality input for preservation at all stages, this will help organize input and provide a body of growing work for researching future ideas and also for learning more about perl/Perl/etc
b. make this process as efficient as possible for PRC or whomever is mediating any part of the RFC
c. establish a tradition of "high quality" and "collegial" RFC efforts

Regarding actual "discussion" on p5p - I do not think this should be discouraged in *any* way; but I do think:

* they should not be part of any "official" record
* RFC facilitators should be able to participate in the gutter with everyone else, without worrying about simultaneously organizing them or remembering what everyone said
* RFC facilitators should be able to do their job strictly from high quality, self-contained submissions at any of the stages of an RFC's life

This will also provide a natural and well documented account of a new "feature" as it progressed from "an idea", to "an RFC", to "a prototype", to an "experiment", and finally to either a full feature or one that doesn't make it. There should be no "failed" experiments - only conclusions: "it's awesome", "back to the drawing board", "or this was a bad idea afterall, trash it".

Please also note, and I should have said this to start. I am highly focused on making this a humane and fair process for all. I do not think the PSC or anyone mediating this process should be expected to be a hero. We can make this easier on all of us if we just ask that "formal" opinions be submitted for a) consideration and b) preservation.

I've outline what I "think" as well as possible, so to attempt to not be a hypocrite, I will just leave this for consideration and speak no more of it unless prompted. I am happy to help in organizing any or all of the above in an unbiased and neutral way.

Cheers,
Brett

??????? Original Message ???????

On Wednesday, June 16th, 2021 at 2:50 AM, Nicholas Clark <nick@ccl4.org> wrote:

> Re-ordering your message to make it easier for me to reply to
>
> (I realise, not something that any line-by-line code review system lets you
>
> do. Well, because, ideas aren't code.)
>
> On Mon, Jun 14, 2021 at 07:40:45PM +0000, mah.kitteh via perl5-porters wrote:
>
> > I've been studying this process document,
> >
> > https://github.com/Perl/RFCs/blob/master/docs/process.md
> >
> > This suggestion is sort of a meta-RFC for the process, but it seems like there could be some value in establishing
> >
> > a formal mailing list for the pre-RFC'ing process that perl porters is currently being used for? I would have added this as a GH "issue" in the
> >
> > repo, but that has been disabled (probably a good idea).
>
> > Problems/Unknowns:
> >
> > - a new list would necessarily require an "opt in" phase
> > - I don't know what it'd look like if p5p and the rfc list were simultaneously discussing the same thing or what bleed-over might occur
>
> Yes :-)
>
> (For now) I tried to have the configuration set such that discussion
>
> both about RFCs themselves and the RFC process generally was in one place.
>
> And that that place was this list.
>
> Because, as you observe, it's a problem if discussion is in more than once
>
> place.
>
> Right, so this sentence is key:
>
> > Using p5p as the initial arbiter of the merits of an RFC or pre-RFC seems difficult because it's impossible to tame.
>
> I think that your entire plan is predicated on the idea that p5p is
>
> impossible to tame. The current steering committee all thinks otherwise.
>
> And whilst I won't be on PSC in two weeks from now, the maths of the
>
> election means that at least 1 of Neil or Rik will be on the new PSC, and
>
> will be advocating the same plan as currently
>
> Several specific reasons
>
> 1. More generally, if it's not possible to have useful discussion on the
>
> mailing list, we might as well turn it off
> 2. But if so, why would any other discussion forum be any better? It's
>
> not like GitHub comments are structurally much different from a mailing
>
> list (with some advantages, but loosing others such as proper
>
> threading)
> 3. The PSC felt that the quality of discussion in the RFC threads was good.
>
> (ie "above average" compared with some recent threads)
>
> If anything, this is suggesting that having the RFC process apply some
>
> structure to p5p list traffic is acting as a good influence.
>
> > Benefits:
> >
> > A new list will allow for there to be strict expectations set from the very beginning and allow for there
> >
> > to be more control over the direction of the conversation. A list moderator could actually moderate as to
> >
> > the current set of RFCs being discussed. For example, the flow would look like:
>
> Needing a "moderator" rather goes against one of the goals of the process,
>
> which was to reduce the need for specific people to do "editorial" tasks.
>
> The PEP process keeps stressing "the PEP editor does this" or "does that",
>
> and I've been told that there are about 8 editors (implying "it needs that
>
> many") but it seems that you can't see the list (and hence count them):
>
> https://github.com/orgs/python/teams/pep-editors/members
>
> unless you're in the Python org on GitHub.
>
> (I'm going to assume that this is because that file contains personal
>
> contact information and shouldn't be published, given that there's a similar
>
> restriction stated for some other membership list primary source files,
>
> and in this case it so rarely matters that there's no automated publication
>
> mirror.)
>
> Also, I'm not convinced that building a system that assumes "moderation" is
>
> great. One person's "moderation" is another person's censorship.
>
> > - user X send in preliminary RFC to get it on the weekly "docket"
> > - moderator then schedules discussion
> > - there could be a formal open and close of discussion for 1 RFC proposals at a time
> > - anyone wishing to opine would be strongly encouraged to do so formally, in a self-contained "amicus brief" style - i.e., not in a tit-for-tat inline discussion
> > - detailed discussions would be directed to p5p, but only formal "briefs" sent to the rfc list should be considered since they should be self contained and well reasoned
> >
> > to the same standard that RFCs are expected to be
>
> I think "to the same standard" is key here. PSC would like most traffic
>
> generally to be of this standard, whether it's on RFC, other list traffic,
>
> or comments on GitHub. (Yes, sure, jokes and silly comments are allowed.
>
> It's important to have fun and stay sane. But they shouldn't swamp the
>
> "signal")
>
> > Hope this helps.
>
> Yes, thanks for the feedback.
>
> I'm really keen to create a process that minimises the amount of central
>
> work that needs to be done, and "empowers" contributors to "enable" them to
>
> do it themselves. (ie, what I really mean is that longer term they are
>
> expected to do more of this, or their idea stalls, and that's the deal for
>
> getting your idea to progress)
>
> Right now for RFCs I am all of
>
> - ghost writer for the RFCs themselves
> - editor
> - in charge of figuring out the process
> - actually implementing the thing
> - executive management (who do their own typing)
>
> and it's getting a bit tiring. This scales about as well as "DentOps":
>
> https://www.programmersought.com/article/19515332833/
>
> (If anyone is wondering why I'm not standing again for the PSC, this is part
>
> of it)
>
> Right now the "RFC on the RFC" that think would be useful is
>
> 1. Do we have the correct states for RFCs?
>
> What isn't going to be obvious from process.md is that we have one more "in
>
> progress" state that Python has in its PEPs. I know this because Neil had
>
> a discussion with me about why he felt it important, and he was right, so
>
> it's in.
> 2. Do we have the correct rules for state transitions?
>
> Both "do we have the correct criteria for progressing?" and "do we have the
>
> correct people listed as checking this and approving?"
> 3. Do we have the correct sections in the template?
>
> Despite Python running their PEPs for 20 years now, we've quickly found that
>
> it's better to split "Future Scope" from "Rejected" than lump both together.
> 4. Do we have useful guidelines on what ideas will get accepted, and which
>
> are impractical?
>
> and then more generally we need to see if
> 5. Can we get to a point where more people can sketch out their idea in
>
> the right shape for an RFC?
> 6. Are more people able to take discussion and summarise it into an RFC?
> 7. Is the quality of the discussion useful?
> 8. Is the quality of idea submission improving?
>
> (ie does the combination of better guidelines and a growing corpus of
>
> "this was accepted" "this was not, because..." cause potential
>
> submitters to realise that an idea is obviously non-viable and not even
>
> submit it. Or that an idea needs to be framed in a particular way to
>
> make sense, and perform that step before submission)
>
> Once we can get some of that, then I think we're in a position where it's
>
> time to think about where RFCs might work better. Rust and Matrix both
>
> implement them as "pull" requests on an RFC repository. That seems like a
>
> better idea than a mailing list. But, it assumes that most ideas arrive as
>
> drafted RFCs in a pull request. Not 4 to 16 line "feature requests".
>
> Give this current approach a couple of months, and we might have an idea
>
> whether and when we can move to that. But talking too much about it now is
>
> trying to run before we can walk.
>
> Nicholas Clark