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

["Noé Lopez via Guix-patches via" <guix-patches@gnu.org>]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Noé,
>
> Thanks for this new version.
>
> Noé Lopez <noe@noé.eu> skribis:
>
>> +### 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.
>
> [...]
>
>> +### 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
>
> ?

As Simon said, I think a vote goes against the principle of
consensus. Maybe we can take inspiration from the wayland protocol?

If a stakeholder thinks the RFC is complete and satisfactory, they ACK
it.  If the RFC needs changes, they simply comment and if they are
against it they NACK it.

Quoting Mike Blumenkrantz:
>A NACK for an experimental protocol carries some variation on the following meanings:
>This idea is broken and cannot work.
>OR
>This approach is fundamentally against the core principles or spirit of Wayland.
>A NACK must be well-justified, as determined by members of the
>governance team, who are assumed to be acting in good faith for the best interests of the project.

In this way, we can say that an RFC needs a specific amount of ACKs and
no NACKs to be merged, ensuring everybody is at least fine with it and
the stakeholders are interested enough to ACK it.

>
> I think we should now make sure we reach consensus on the timeline, and
> in particular:
>
>   1. on the voting process;
>
>   2. on the submission -> withdrawn transition, in case nobody supports
>      the RFC.
>
> Once we have that, we can fine-tune the language and hopefully be done
> within a couple of weeks.
>
> I like the Dot graph you submitted!  Here’s an updated version, with a
> new submission -> withdrawn arrow (as proposed in the comment above) and
> with hopefully clearer names (in particular “Voting Period” rather than
> “Last call”):
>
> --8<---------------cut here---------------start------------->8---
> digraph "RFC Timeline" {
>     submission[label=<Submission Period<br />7 days>]
>     comments[label=<Discussion Period<br />30–60 days>]
>     last_call[label=<Voting Period<br />14 days>]
>     withdrawn[label=Withdrawn, shape=rectangle]
>     final[label=Final, shape=rectangle]
>     
>     submission -> comments
>     submission -> withdrawn
>     comments -> last_call
>     last_call -> withdrawn
>     last_call -> final
>     
>     withdrawn -> submission [label="New version"]
>     
>     comments -> withdrawn
> }
> --8<---------------cut here---------------end--------------->8---
>
> Thoughts?

I agree with that timeline, but I would have just “forgotten” an RFC
that doesn’t pass the submission period, since that would mean it is not
good enough to be discussed.  It can just be kept in the mail archives
like any other unfinished idea.

A withdrawn RFC would mean keeping it in the rfc/withdrawn directory.

This was also why I had proposed the idea of keeping a set of available
co-supporters, since any well written RFC should be able to get past the
submission period even if you can’t find someone to co-support.

Good evening,
Noé