Package: guix-patches;
Reported by: Noé Lopez <noe <at> xn--no-cja.eu>
Date: Sun, 8 Dec 2024 12:29:02 UTC
Severity: important
Tags: patch
Merged with 66844
Done: Noé Lopez <noe <at> xn--no-cja.eu>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Simon Tournier <zimon.toutoune <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org>, 74736 <at> debbugs.gnu.org Cc: Noé Lopez <noe <at> xn--no-cja.eu>, Noé Lopez <noelopez <at> free.fr>, Christopher Baines <mail <at> cbaines.net> Subject: [bug#74736] [PATCH v6] Add Request-for-Comments process. Date: Thu, 09 Jan 2025 17:21:19 +0100
Hi,
On Mon, 06 Jan 2025 at 23:29, Ludovic Courtès <ludo <at> gnu.org> wrote:
> title: Requests-for-Comment Process
> id: 000
I think it’s better to start with 001 and have 000 for the template.
> status: submitted
> discussion: https://issues.guix.gnu.org/74736
> authors: Simon Tournier, Noé Lopez, Ludovic Courtès
> supporters: ?
> submitted: 2024-12-12
I think the choice of this date is unclear. Do you consider that your
reply or mine implies being Supporter?
Well, since this document bootstrap the process it’s difficult. :-)
Especially when the first draft had been sent on 2023-10-31.
I suggest to clarify and to extend:
> The RFC is *submitted* once it has at least one supporter in addition to
> the author(s).
with:
The RFC is *submitted* once it has at least one supporter in
addition to the author(s). See Submission Period below.
> date: 2025-01-15
> ---
>
> # Summary
[...]
> # Motivation
[...]
> # Detailed Design
>
> ## When to Follow This Process
[...]
> ## How the Process Works
>
> 1. Clone https://git.savannah.gnu.org/git/guix/requests-for-comments.git .
> 2. Copy `0000-template.md` to `00XY-short-name.md` where `short-name`
> is a short descriptive name long and `XY` is the sequence number.
I suggest: `XY` increments the sequence number.
> 3. Write your RFC following the template’s structure. The RFC must not
> be prospective; it must formalize an idea and sketch a plan to
> implement it, even if not all details are known. If it intends to
> deprecate a previously-accepted RFC, it must explicitly say so.
> 4. Submit the RFC as a patch to `guix-patches <at> gnu.org`.
> 5. Announce your RFC at `guix-devel <at> gnu.org` and look for *supporters*:
> one or more people who will support the RFC and participate in
> discussions by your side (see below).
>
> The RFC is *submitted* once it has at least one supporter in addition to
> the author(s).
See above.
>
> ## Supporters
>
> A supporter is a contributor sufficiently familiar with the project’s
> practices, hence it is recommended, but not mandatory, to be a team
> member. Supporters do not have to agree with all the points of the RFC
> but should generally be satisfied that the proposed additions are a good
> thing for the community.
>
> Supporters help the author(s) by participating in discussions, amending
> the document as it is being discussed, and acting as timekeepers.
I would add (picked from v5):
Please make sure that all have the time and space for expressing
their comments. The RFC is about significant changes, thus more
opinions is better than less.
I think that important to have this written somewhere in the document.
And because author is focused on the proposal – if one took the time to
write something, it means one has an idea on some topic that one want to
defend :-) –, then it might be difficult to have the right distance.
Hence Supporter(s) are also the helper / facilitator here.
> ## Timeline
>
> The lifetime of an RFC is structured into the following recommended
> periods:
>
> 
I would replace the node ’comments’ by discussion in order to have
something more homogeneous. Nitpicking? ;-)
> ```dot <- TODO: make this a separate file
I would prefer to let the dot file here as-is. Because it’s easier to
read in full terminal mode. In addition, yes maybe we could display the
graph as an image file.
> digraph "RFC Timeline" {
> submission[label=<Submission Period<br />up to 7 days>]
> comments[label=<Discussion Period<br />30–60 days>]
discussion[label=<Discussion Period<br />30–60 days>]
> deliberation[label=<Deliberation Period<br />14 days>]
> withdrawn[label=Withdrawn, shape=rectangle]
> final[label=Final, shape=rectangle]
>
> submission -> comments
> submission -> withdrawn
> comments -> deliberation
discussion -> deliberation
> deliberation -> withdrawn
> deliberation -> final
>
> withdrawn -> submission [label="New version"]
>
> comments -> withdrawn
> }
> ```
>
> The subsections below detail the various stages and their duration.
>
> ### Submission Period (up to 7 days)
>
> Anyone can author and submit an RFC as a regular patch and look for
> supporters (see below). The RFC is *submitted* once it has one or more
> supporters; the next step is the *discussion period*.
As said above, I would clarify:
The RFC is *submitted* once one or more
people publicly reply “I support” and volunteers to be
supporters; the next step is the *discussion period*.
> Author(s) may withdraw their RFC at any time; they can resubmit it again
> later, possibly under a new RFC number.
>
> ### Discussion Period (at least 30 days, up to 60 days)
[...]
> ### Deliberation Period (14 days)
>
> All members of any team of the Guix project can participate in
> deliberation and are encouraged to do so.
I would restore the past suggestion to mention the file ’teams.scm’; see
suggestion below (mark **).
> Once the final version is published, team members have 14 days to send
> one of the following replies on the patch-tracking entry of the RFC:
>
> - “I support”, meaning that one supports the proposal);
---^
) extra
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply must have actively
> proposed alternative solutions during the discussion period.
I do not think the wording of the last sentence is accurate enough:
Because maybe there is no alternative solution or the status quo is the
one, etc.
Instead, I would write:
A team member sending this reply must have actively cooperated
with for discussing the RFC during the discussion period. See
Decision Making.
> The RFC is *accepted* if (1) at least 25% of all team members send a
> reply, and (2) no one disagrees. In other cases, the RFC is
> *withdrawn*.
Here, I would replace ’disagrees’ with ’disapproves’. It appears to me
clearer.
> Deliberation aims at consolidating consensus; see “Decision Making”
> below.
Here (remember mark ** :-)), I would add this sentence.
Anyone who is on a team (see file ‘teams.scm’) is a deliberating
member and is asked to contribute to the deliberation.
> ## Decision Making
[...]
> ## Merging Final RFCs
[...]
>
> ## RFC Template
>
> The expected structure of RFCs is captured by the template in the file
> `0000-template.md`, written in English with Markdown ornaments.
The number of 000 must be in agreement with the top, IMHO.
> ## Cost of Reverting
[...]
> ## Drawbacks
[...]
> ## Open Issues
[...]
Cheers,
simon
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.