GNU bug report logs - #74736
[PATCH v2 0/1] Add Request-For-Comment process.

Previous Next

Full log

View this message in rfc822 format

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Noé Lopez <noe <at> xn--no-cja.eu>, Ludovic Courtès <ludo <at> gnu.org>, Christopher Baines <mail <at> cbaines.net>, 74736 <at> debbugs.gnu.org, Noé Lopez <noelopez <at> free.fr>
Subject: [bug#74736] [PATCH v6] Add Request-for-Comments process.
Date: Fri, 10 Jan 2025 14:17:03 +0100

Simon Tournier writes:

Hi Simon,

> On Fri, 10 Jan 2025 at 08:44, Janneke Nieuwenhuizen <janneke <at> gnu.org> wrote:
>
>>> # Motivation

[..]

>>   * to draw more attention to / have important discussions stand out
>>   more in all the "noise", and guided by

[..]

> Yes! :-)

Great!

>
>>                                    A drawback could be that it slows
>> development down, but for important changes that may be a good thing?
>
> I would you say yes :-)
>
> And I would also say it’s a counter measure against “Why wasn't I
> consulted“ [1] or some bullet points [2] from the talk that appear to me
> helpful and that had been inspiration.
>
> 1: https://youtu.be/m0rakUuPXFM
> 2: https://simon.tournier.info/posts/2023-10-30-toward-rfc.html

Yes, I tend to agree.  Especially improving the chance to get involved
is a very good thing.

>> The only things that I could suggest is to see if we should make it even
>> be more lightweight/nimble as a first version, e.g, require only two
>> *persons*, so that two authors could start a submission
>>
>>     The RFC is *submitted* once it has at least one co-author or
>>     supporter in addition to the initial author(s).
>
> Ah you mean that the case of ’two authors’ does not require a Sponsor*,
> right?

Ah yes,

Possibly I'm splitting hairs here too much.  But ISTM that having one
author and one sponsor being enough, whereas in the situation where an
early sponsor actually contributes to become a second author, they would
now have to go look for a third person.  Dunno.

> *Sponsor: was ’Supporter’ but renamed in order to avoid confusion
>  between supporting the Document before the Discussion Period and
>  replying ’I support’ during the Delibration Period.

Noted.  Sorry for being sloppy with the terms :)

>> or use shorter periods, e.g.
>>
>>     submission[label=<Submission Period<br />up to 7 days>]
>>     comments[label=<Discussion Period<br />15–60 days>]
>>     deliberation[label=<Deliberation Period<br />8-14 days>]
>>
>> but I have no strong opinion on these.
>
> About the Discussion Period, I do not have an opinion.  From my
> intuition, it appears to be helpful when all have the time and space for
> expressing their comments.
>
> About the Deliberation Period, I think we need to have enough time and 2
> weeks sound the good range based on what we are already doing for patch
> review.

Indeed, that mathes.  I was just thinking about a patch that "just
passes the RFC-importance threshold" but could have been applied within
a week because it got a lot of review and attention, then someone
proposes to create an RFC, and then you're automatically looking at
7+30+14 == ~7 weeks.

It's a puzzle indeed.  I was thinking: if "everyone involved" argees it
could be done/decided quicker, policy seems to prevent that.  Otoh, that
protects the "why wasn't I consulted" problem.  So yeah.

If nobody else sees the need to make the first iteration more
lightweight, I'm happy to try this.  Thanks again for your efforts.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.