all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Andreas Enge <andreas@enge.fr>, Arun Isaac <arunisaac@systemreboot.net>
Cc: efraim@flashner.co.il, guix-devel@gnu.org,
	guix-maintainers@gnu.org, ludo@gnu.org, mail@cbaines.net,
	rekado@elephly.net, 74736@debbugs.gnu.org,
	Janneke Nieuwenhuizen <janneke@gnu.org>
Subject: Re: Guix Common Document process (v7) (was: Request-For-Comment, RFC)
Date: Wed, 15 Jan 2025 23:32:25 +0100	[thread overview]
Message-ID: <87msfr1zeu.fsf@gmail.com> (raw)
In-Reply-To: <Z4fVhpXCDeYXPzUE@jurong>

Hi,
On Wed, 15 Jan 2025 at 16:34, Andreas Enge <andreas@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



WARNING: multiple messages have this Message-ID (diff)
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Andreas Enge <andreas@enge.fr>, Arun Isaac <arunisaac@systemreboot.net>
Cc: guix-maintainers@gnu.org, ludo@gnu.org, mail@cbaines.net,
	efraim@flashner.co.il, rekado@elephly.net, guix-devel@gnu.org,
	74736@debbugs.gnu.org, Janneke Nieuwenhuizen <janneke@gnu.org>
Subject: [bug#74736] Guix Common Document process (v7) (was: Request-For-Comment, RFC)
Date: Wed, 15 Jan 2025 23:32:25 +0100	[thread overview]
Message-ID: <87msfr1zeu.fsf@gmail.com> (raw)
Message-ID: <20250115223225.j_2yTHsecMei2mMVODNiy-_SZLDaKEx7GvupVnHlacU@z> (raw)
In-Reply-To: <Z4fVhpXCDeYXPzUE@jurong>

Hi,
On Wed, 15 Jan 2025 at 16:34, Andreas Enge <andreas@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





  parent reply	other threads:[~2025-01-15 22:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31 11:14 Request-For-Comment process: concrete implementation Simon Tournier
2023-11-16 15:03 ` Ludovic Courtès
2023-11-20  9:42   ` Simon Tournier
2023-11-22 18:17     ` Ludovic Courtès
2023-11-23  7:04 ` Efraim Flashner
2023-11-28 13:34   ` Simon Tournier
2023-12-19 12:33 ` Simon Tournier
2023-12-20 11:49   ` Ricardo Wurmus
2024-02-03 10:09     ` Simon Tournier
2024-02-03 10:34 ` [post Guix Days] Guix Common Document (was: Request-For-Comment process) Simon Tournier
2024-02-07  8:27   ` Efraim Flashner
2025-01-03 18:38 ` Request-For-Comment process: concrete implementation (v5) Simon Tournier
2025-01-07 10:40   ` Ludovic Courtès
2025-01-08 15:15     ` Suhail Singh
2025-01-09 17:33     ` Simon Tournier
2025-01-09 23:49       ` bokr
2025-01-10  6:26       ` Suhail Singh
2025-01-15 18:42         ` Simon Tournier
2025-01-10  0:07     ` Guix Common Document process (v7) (was: Request-For-Comment, RFC) Simon Tournier
2025-01-12 15:11       ` Arun Isaac
2025-01-15 15:34         ` Andreas Enge
2025-01-15 21:50           ` Guix Common Document process (v7) indieterminacy
2025-01-15 22:32           ` Simon Tournier [this message]
2025-01-15 22:32             ` [bug#74736] Guix Common Document process (v7) (was: Request-For-Comment, RFC) Simon Tournier
2025-01-15 23:28             ` Vagrant Cascadian
2025-01-16  9:23               ` [bug#74736] " Andreas Enge
2025-01-16 12:04             ` Guix Common Document process (v7) Suhail Singh
2025-01-16 16:10           ` bug#74736: [PATCH v2 0/1] Add Request-For-Comment process Ludovic Courtès
2025-01-16 18:01             ` Simon Tournier
2025-01-17  9:37               ` Ludovic Courtès
2025-01-15 19:18         ` Guix Common Document process (v7) (was: Request-For-Comment, RFC) Simon Tournier
2025-01-16 13:21           ` Arun Isaac
2025-01-14 18:28       ` bokr
2025-01-15 19:22         ` Simon Tournier
2025-01-17  1:06 ` Guix Consensus Document process (v10) Simon Tournier
2025-01-19 21:52   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87msfr1zeu.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=74736@debbugs.gnu.org \
    --cc=andreas@enge.fr \
    --cc=arunisaac@systemreboot.net \
    --cc=efraim@flashner.co.il \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@gnu.org \
    --cc=janneke@gnu.org \
    --cc=ludo@gnu.org \
    --cc=mail@cbaines.net \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.