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: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Noé Lopez <noe <at> xn--no-cja.eu>, Noé Lopez <noelopez <at> free.fr>, 74736 <at> debbugs.gnu.org, Christopher Baines <mail <at> cbanes.net>
Subject: [bug#74736] [PATCH v3] rfc: Add Request-For-Comment process.
Date: Sat, 14 Dec 2024 11:47:19 +0100

Thanks for v3!

Some of my more superficial comments earlier this week remain
unaddressed:

  • I think it should be Markdown, and in a separate repo.

  • There are too many explicit references to Debbugs, which I think is
    not future-proof.

I think the text itself needs more work to address and remove remaining
comments that appear in the body, to improve grammar and wording, and to
make it shorter (it’s way too long IMO).  But that can come in a second
phase.

Questions/comments about the process that I overlooked before:

> +The lifetime of an RFC is structured into the following recommended periods:
> +
> +  submission (7d) ⟶ comments (30–60d) ⟶ last call (14d) ⟶ withdrawn OR final

This diagram doesn’t show everything I think; for example…

> +*** Submission (up to 7 days)
> +
> +The author submits their RFC proposal as a regular patch and look for
> +co-supporter(s). See 'Co-supporter' section.
> +
> +Once the RFC is co-supported, it marks the start of a discussion period.

… what happens when the submitter doesn’t find supporters in that
period? I’m guessing the RFC goes in “withdrawn” state?

The diagram should reflect that, and we can render it with Dot.

> +*** Last call (up to 14 days)
> +
> +The author publishes a final version of the RFC and a last grace period of 14
> +days is granted.  People are asked to agree or disagree by commenting:
> +
> + - +1 / LGTM: I support
> + - =0 / LGTM: I will live with it
> + - -1: I disagree with this proposal
> +
> +At least half of people with commit acces must express their voice with the
> +keys above during this last call.  We need to be sure that the RFC had been
> +read by people committed to take care of the project, since it proposes an
> +important change.

I think committers here are mentioned as a simple way to express
membership and avoid infiltration, but it has the downside of ignoring
many members and giving committers a special privilege.

I propose this definition: anyone who is on a team (in ‘teams.scm’) is a
voting member*.

We can keep a quorum, but I think 50% of the voters is too ambitious;
maybe 25%?

This would become¹:

  Once the final version is published, team members have 14 days to cast
  one of the following votes about the RFC:

    - Support (+1);
    - Accept (0);
    - Reject (-2).

  Votes are cast by replying on the patch-tracking entry of the RFC.

  The RFC is accepted if (1) at least 25% of the voting members cast a
  vote, and (2) the sum of votes is non-negative.  In other cases, the
  RFC is withdrawn.

Thoughts?

Ludo’.


* We’ll have to create new teams and update them so we don’t forget
  anyone, notably translators, sysadmins, graphics designers, and so on.

¹ Inspired by
  <https://codeberg.org/mergiraf/mergiraf/src/branch/main/GOVERNANCE.md>.

Previous Next

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