GNU bug report logs -
#74736
[PATCH v2 0/1] Add Request-For-Comment process.
Previous Next
Reported by: Noé Lopez <noe <at> xn--no-cja.eu>
Date: Sun, 8 Dec 2024 12:29:02 UTC
Severity: important
Tags: patch
Merged with 66844
Done: Noé Lopez <noe <at> xn--no-cja.eu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hi,
On Wed, 15 Jan 2025 at 16:34, Andreas Enge <andreas <at> enge.fr> 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
This bug report was last modified 89 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.