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

Re: RFC: formal perl-rfc mailing list for initial submission

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 16, 2021 07:50
Subject:
Re: RFC: formal perl-rfc mailing list for initial submission
Message ID:
20210616075029.GX16703@etla.org
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

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