From: Janneke Nieuwenhuizen <janneke@gnu.org>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: "Noé Lopez" <noe@xn--no-cja.eu>, "Ludovic Courtès" <ludo@gnu.org>,
"Christopher Baines" <mail@cbaines.net>,
74736@debbugs.gnu.org, "Noé Lopez" <noelopez@free.fr>
Subject: [bug#74736] [PATCH v6] Add Request-for-Comments process.
Date: Fri, 10 Jan 2025 14:17:03 +0100 [thread overview]
Message-ID: <871pxaolkg.fsf@gnu.org> (raw)
In-Reply-To: <87y0zikfch.fsf@gmail.com> (Simon Tournier's message of "Fri, 10 Jan 2025 13:45:02 +0100")
Simon Tournier writes:
Hi Simon,
> On Fri, 10 Jan 2025 at 08:44, Janneke Nieuwenhuizen <janneke@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@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
next prev parent reply other threads:[~2025-01-10 13:20 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-08 12:29 [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process Noé Lopez via Guix-patches via
2024-12-08 12:31 ` [bug#74736] [PATCH v2 1/1] rfc: " Noé Lopez via Guix-patches via
2024-12-12 18:14 ` [bug#74736] [PATCH v2 0/1] " Ludovic Courtès
2024-12-12 19:47 ` Simon Tournier
2024-12-14 10:06 ` Ludovic Courtès
2024-12-23 17:58 ` Simon Tournier
2024-12-26 11:15 ` Ludovic Courtès
2024-12-09 20:47 ` Artyom V. Poptsov
2024-12-12 19:30 ` [bug#74736] [PATCH v3] rfc: " Simon Tournier
2024-12-14 10:47 ` Ludovic Courtès
2024-12-22 13:06 ` Noé Lopez via Guix-patches via
2024-12-22 13:56 ` [bug#74736] [PATCH v4 0/1] " Noé Lopez via Guix-patches via
2024-12-22 13:56 ` [bug#74736] [PATCH v4 1/1] " Noé Lopez via Guix-patches via
2024-12-23 14:42 ` [bug#74736] [PATCH v2 0/1] " Ludovic Courtès
2024-12-23 17:33 ` Simon Tournier
2024-12-26 11:28 ` Ludovic Courtès
2024-12-31 15:23 ` Simon Tournier
2024-12-29 18:31 ` Noé Lopez via Guix-patches via
2024-12-30 11:03 ` Ludovic Courtès
2024-12-30 11:58 ` Noé Lopez via Guix-patches via
2025-01-04 17:28 ` Ludovic Courtès
2025-01-05 12:51 ` Noé Lopez via Guix-patches via
2025-01-06 10:29 ` Simon Tournier
2025-01-06 17:40 ` Ludovic Courtès
2025-01-08 10:53 ` Ludovic Courtès
2025-01-09 13:27 ` Ludovic Courtès
2025-01-09 22:48 ` Simon Tournier
2025-01-10 10:39 ` Noé Lopez via Guix-patches via
2025-01-10 13:02 ` Simon Tournier
2025-01-10 16:48 ` Noé Lopez via Guix-patches via
2025-01-03 18:14 ` [bug#74736] [PATCH v5] rfc: " Simon Tournier
2025-01-06 22:29 ` [bug#74736] [PATCH v6] Add Request-for-Comments process Ludovic Courtès
2025-01-07 17:06 ` Noé Lopez via Guix-patches via
2025-01-08 15:12 ` [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process Suhail Singh
2025-01-09 17:21 ` Simon Tournier
[not found] ` <825F8319-4F41-4F4C-81B3-2C84A73A13CF@housseini.me>
2025-01-08 6:33 ` [bug#74736] [PATCH v6] Add Request-for-Comments process reza via Guix-patches via
2025-01-09 23:22 ` Simon Tournier
2025-01-08 16:26 ` [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process pukkamustard
2025-01-09 17:18 ` Simon Tournier
2025-01-09 21:00 ` Ludovic Courtès
2025-01-09 21:16 ` Ludovic Courtès
2025-01-09 16:21 ` [bug#74736] [PATCH v6] Add Request-for-Comments process Simon Tournier
2025-01-09 22:32 ` [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process Ludovic Courtès
2025-01-09 23:56 ` Simon Tournier
2025-01-10 0:40 ` [bug#74736] [PATCH v6] Add Request-for-Comments process Vagrant Cascadian
2025-01-10 12:25 ` Simon Tournier
2025-01-10 7:44 ` Janneke Nieuwenhuizen
2025-01-10 12:45 ` Simon Tournier
2025-01-10 13:17 ` Janneke Nieuwenhuizen [this message]
2025-01-07 19:40 ` [bug#74736] Add Request-For-Comment process Ricardo Wurmus
2025-01-09 23:45 ` [bug#74736] [PATCH v7] Add Guix Common Document process Simon Tournier
2025-01-10 17:15 ` [bug#74736] [PATCH v8] Add Request-For-Comment process Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871pxaolkg.fsf@gnu.org \
--to=janneke@gnu.org \
--cc=74736@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=mail@cbaines.net \
--cc=noe@xn--no-cja.eu \
--cc=noelopez@free.fr \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).