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
next prev 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: linkBe 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.