Hi,
On Wed, 15 Jan 2025 at 16:34, Andreas Enge <[email protected]> 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
