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

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

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

Right.  (Though I think infiltration is also a valid concern.)

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

Yes, agreed.

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

Yes.

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

WDYT?

Ludo’.