From: "Noé Lopez via Guix-patches via" <guix-patches@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 74736@debbugs.gnu.org, Simon Tournier <zimon.toutoune@gmail.com>
Subject: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
Date: Mon, 30 Dec 2024 12:58:46 +0100 [thread overview]
Message-ID: <875xn14c21.fsf@xn--no-cja.eu> (raw)
In-Reply-To: <87seq5tou6.fsf_-_@gnu.org>
Ludovic Courtès <ludo@gnu.org> writes:
> OK. As I wrote in my reply to Simon, my thought here was that “voting”*
> would give a clear and unambiguous way, not subject to interpretation,
> to decide whether the RFC is withdrawn: it’s easier to add numbers than
> to determine whether “a positive consensus is reached” (current
> wording).
>
This is why an ACK/NACK system works great in my opinion: you send “ACK”
or “NACK” litteraly so your opinion is clear. And you can just count
the number of each, without implying a vote.
> But I don’t know, I guess that’s an “I will live with it” from me on
> this one. :-)
>
> Two other issue I raised was the quorum: Simon proposed half of the
> committers; I propose 25% of team members. Thoughts?
>
I don’t have the experience to judge, but I would just do “as long as no
one is against it its good”.
The reason is that I’m afraid that people might just not participate
because they are fine with an RFC or don’t care, and so it would just
get stuck there.
If you look at this RFC, we are four participants, how many will we get
after the finalization?
Half of the committers is 25 people (based on .guix-authorizations), and
a quarter of the team members is 10. Personnally, I have trouble
imagining that this amount of people will come to send a mail to the
RFC.
> * Maybe “voting” is misleading; “deliberation” might be clearer.
>
>>> 2. on the submission -> withdrawn transition, in case nobody supports
>>> the RFC.
>
> [...]
>
>> I agree with that timeline, but I would have just “forgotten” an RFC
>> that doesn’t pass the submission period, since that would mean it is not
>> good enough to be discussed. It can just be kept in the mail archives
>> like any other unfinished idea.
>>
>> A withdrawn RFC would mean keeping it in the rfc/withdrawn directory.
>
> Oh right, forgotten/dismissed seems more appropriate than withdrawn
> here.
>
> Anyway, I think we should aim for finalization of v1 of the RFC process
> by, say, Jan. 15th. I will dedicate some time to tweak the wording, and
> then we can call it a thing.
>
Good idea! I’ll be waiting for your v5 then. And then I can bring
back the RFC template.
> (A bit sad that it’s just the three of us talking, we wouldn’t have the
> quorum here…)
>
Agreed.
Lastly, do we want to move the RFCs to a separate git repository?
Have a nice day,
Noé
prev parent reply other threads:[~2024-12-30 12:00 UTC|newest]
Thread overview: 20+ 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 [this message]
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=875xn14c21.fsf@xn--no-cja.eu \
--to=guix-patches@gnu.org \
--cc=74736@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=noe@xn--no-cja.eu \
--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).