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

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

Hi Noé,

On Sun, 05 Jan 2025 at 13:51, Noé Lopez via Guix-patches via <guix-patches@gnu.org> wrote:

> To take a realistic example, say I make an RFC for P2P substitute
> distribution with GNUNet/ERIS, this is a big change that requires an RFC
> but I have trouble imagining that ten people in the team members are
> interested in that.
>
> Teams are specialized after all, if I add myself to the games team it
> doesn’t mean I care about RFCs for what would be the core team.

Well, considering this example, I remember a session at Guix Days last
year (or last last year?) when pukkamustard explained ERIS.  If I
remember correctly, we were more than 10 people and after the
explanations and questions/answers, we had an informed opinion; I mean I
guess most attendees were able to express either Support, Accept or
Disagree.

For sure, the number of people able to tackle all the implementation
details is probably lower than 10.  However, I am confident that more
than 10 team members are skilled enough to build a consensus on any
topic*.

Today, merging a patch is done using “Lazy Consensus“: it assumes
general consent if no responses are posted within a defined period (15
days).

For “significant changes”, we are looking for a “Consensus Approval”.

Therefore, we need a way to define this “Consensus Approval”.  That’s
what it’s named “Deliberation Period”: after a “Comment Period” where we
all try to forge an informed opinion (if we are not an expert on the
topic at hand), then we express what we judge the best for the project.

That’s said, maybe 25% is too much?  What does it appear to you better?

Cheers,
simon

PS: About “Lazy Consensus” and “Consensus Approval”, see Apache [1]. :-)

*build consensus on any topic: FWIW, I have seen random citizens without
apriori knowledge took complex decisions in Court about crime.


1: https://community.apache.org/committers/decisionMaking.html