Subject: [bug#74736] Guix Common Document process (v7) (was: Request-For-Comment, RFC)

From: Simon Tournier <[email-masked]>
Date: Wed, 15 Jan 2025 23:32:25 +0100

Hi,
On Wed, 15 Jan 2025 at 16:34, Andreas Enge <[email-masked]> wrote:

> I like Arun's suggestion of having a separate mailing list for
> discussing these important changes (GCD? Greatest common divisors!)
> in the future instead of guix-devel.

Why do we need a special mailing list?  I understand why one does not
want to subscribe because the volume might appear to high.  Therefore,
in this case, I agree that guix-devel is not suitable for announcement.
That’s why, I proposed (v7) to use the low traffic info-guix for
announcing and asking for inputs.

However, I find better to have the discussion happens inside the bug
tracker.  And easier too; because some contributors when replying break
the email thread (incorrect in-reply-to) then it’s very painful to
follow.  Later, using the bug tracker for discussing, it’s also easy to
re-read all the comments for one willing to understand why we ended up
with such specific GCD.

WDYT?

> Concerning consensus, I am mildly worried about deadlocks (including 
> when trying to modify this RFC/GCD). What happens if some person insists
> on disapproving?

Today, how does it happen?

Well, I think that better to root the process on what we did over the
past 12 years. :-) And for now, we always managed the situation, I
guess. ;-)

Moreover, it’s bounded by an active participation during the “Discussion
Period”.  Therefore, if one person cannot live with the final state, it
means we failed to find a solution based on what we agree.  Somehow, the
whole idea with consensus is to be pro-active in resolving locks before
they happen, well that’s my understanding. :-)

Yes, I agree what happens with examples as: 3/4 support the proposal and
1/4 disagree?  Well, it would mean we do not have the consensus.  until
now we tried to rely on such method for decision making.  And it seems
to work, no?

> The RFC/GCD says: "A team member sending this reply should have made
> constructive comments during the discussion period." What if they have
> not?

They cannot.  A deliberating member must be active during the
“Discussion Period” else this member cannot disapprove.  Otherwise it
would be unfair for all non-deliberating participants. :-)

>      How about adding a quorum of "disapprove" votes to have effect?

Personally, I am more worried with the quorum of 25% that could be
difficult to reach than about one “disapprove”.

Well, maybe we could set to 2.  But why not 3? Or 4?  Or a percentage?
Somehow, a quorum defeats the idea of “Decision Making” based on
consensus, no?

> Notice also that the suggestion bootstraps the team members into a
> decision taking body - so far we have added people more or less randomly
> to teams.

Yes, I agree.  Currently, teams members is not really defined.  However,
it appears to me another work than the current proposal.  For instance,
we could imagine a GCD that explain the various roles: User,
Contributor, Team Member, Committer, Maintainer, etc.  Next step? :-)
                                                                                                                                           
>                           Or keep the proposal as is and immediately
> work on a new GCD to somehow safeguard the addition of people to a team?

I am in favor of that: work a new GCD about the various roles.

Cheers,
simon