[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

On Mon, 06 Jan 2025 at 23:29, Ludovic Courtès <ludo@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@gnu.org`.
> 5. Announce your RFC at `guix-devel@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:
>
> ![diagram.svg](Diagram of the RFC process.)

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