[bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.

[Simon Tournier]

Hi,

On Mon, 23 Dec 2024 at 15:42, Ludovic Courtès <ludo@gnu.org> wrote:

>> +### 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 access 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.
>> +
>> +When a positive consensus is reached, the RFC becomes effective. If not,
>> +the proposal is archived and the status quo continues.
>
> It seems unchanged compared to v3.  WDYT of my comments, suggestions,
> and proposed wording:
>
>   https://issues.guix.gnu.org/74736#9
>
> ?

Quoting:

        > 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.

It’s not about infiltration, it’s about to be sure that people agree and
do not overlook.

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

I agree.

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

Well, I picked 50% almost randomly. ;-)  Somehow, I do not have a strong
opinion.  My concern is only to be sure that we have a consensus and not
something falling between the cracks.

        > 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.

For me, if we have only one minus, it means we do not have consensus.
Therefore, the person who cannot live with the proposal must be
proactive in finding a solution that we all agree on.

In other words, the numbers are not for being summed, the aim is to
capture:

 - Support
 - I can with with it
 - I cannot live with it

BTW, I do not like the word “Reject” and I prefer “Disagree” or even
better “I cannot live with it”.


> I think we should now make sure we reach consensus on the timeline, and
> in particular:
>
>   1. on the voting process;

Maybe I misunderstand something.  From my point, we do not “vote”
because we are trying to work using consensus.  When I proposed +1/0/-1
my aim was not to “vote“ but to be sure that the proposal is not
overlooked.

Therefore, instead of “Voting Period”, I would prefer “Replying Period”
or something like that.

WDYT?

Cheers,
simon