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

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

Hi Ludo,

On Thu, 26 Dec 2024 at 12:28, Ludovic Courtès <ludo@gnu.org> wrote:

>> 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 like the spirit of it, and I would propose exactly that if people were
> to meet physically at a meeting.
>
> The problem I see here is that we’re online, all communication is
> asynchronous, sometimes concise, sometimes verbose, sometimes frequent,
> sometimes rare, participants may be friends or strangers, and yet we
> need to come to a clear shared understanding of whether the RFC is
> “accepted” or “withdrawn”.
>
> If we keep it too fuzzy, I fear we might be unable to decide what to do.
>
>>> 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.
>
> I’m all for consensus-based decision making, as you know.  My concern is
> making sure a clear and unambiguous decision is made at the end of the
> RFC period.
>
> The risk I see is that of the final withdrawn/accepted decision to be
> perceived as an arbitrary choice by the people in power (RFC editors,
> long-timers, etc.), or that of being unable to make that final decision.
> It’s a risk that perhaps exists only in the most contentious cases, but
> if we can use vote as a tool to avoid it, it’s worth considering.

As you wrote in [1], I think we have the same concern but we have a
different idea behind the same “voting” word.  Instead I agree, it’s a
deliberation period to be sure that the consensus reaches the quorum
(e.g., 25% of the all team members).

Somehow, +1/0/-1 seems another way to express the exact same idea for
the approval statuses (e.g., see Wayland [2]):

    + ACK, or “acknowledged”,
          meaning that the member supports in principle
    + NOPP, or “no opposition”,
          meaning that the member is not opposed in principle
    + NACK, or “negative acknowledgement”
          meaning that the member is opposed in principle.

which reads:

    - Support                +1  ACK   Awesome!
    - I can with with it      0  NOPP  LGTM
    - I cannot live with it  -1  NACK  WDYT about…


The last column is how we are collaborating over all the mailing lists
since years. 


Again, if someone wants to “block“ the RFC, then the blocker must be
active in proposing an alternative and/or explain with details why the
status quo is preferable.

In the other words, I disagree to add numbers: how many ’Support’ against
‘I cannot live with it’?  1 ’Support’ vs 2 ’I cannot live with it’?  Why
not 1 vs 3?  Or more?  Or less?

However, I agree that consensus might scale poorly and might outcome
some blocked situations.  That’s why ‘Decision making: consensus’ must
be included in the process itself and carefully worded. :-)  For these
potential blocked situations, the last word is about maintainers.


Well, a “positive consensus is reached” if after the “Deliberation
Period“, we have 25% of all the members of all the teams expressing
either ’Support’ or either ’I can live with it’.  If after this period,
we have only one ’I cannot live with it’, then the RFC is ’dismissed’.

Please note that ’I cannot live with it’ implies an active friendly
discussion before the end of the “Deliberation Period”.  In other words,
I cannot sleep and the day before the “Deliberation Period” just raise:
Hey, no ’I cannot live with it’.

WDYT?

Well, I will try to clarify the proposal in the coming days in order to
remove the “too fuzzy” (being active, being blocker, etc.)

Cheers,
simon


1: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
Ludovic Courtès <ludo@gnu.org>
Mon, 30 Dec 2024 12:03:29 +0100
id:87seq5tou6.fsf_-_@gnu.org
https://issues.guix.gnu.org/74736
https://issues.guix.gnu.org/msgid/87seq5tou6.fsf_-_@gnu.org
https://yhetil.org/guix/87seq5tou6.fsf_-_@gnu.org

2:
https://chromium.googlesource.com/external/anongit.freedesktop.org/git/wayland/wayland-protocols/+/HEAD/GOVERNANCE.md