Hi Gabriel, Gabriel Wicki <[email protected]> skribis:
> On Wed, Mar 18, 2026 at 06:28:11PM +0100, Ludovic Courtès wrote: >> Discussion is at least 30 days and at most 60 days: >> >> https://consensus.guix.gnu.org/gcd/001-gcd-process.html >> >> I think the discussion period officially started on Feb. 27 when a >> sponsor was found: >> <https://codeberg.org/guix/guix-consensus-documents/pulls/11#issuecomment-11059085>. >> >> So it will end, at your option, between March 27 and April 27. > I know about the proposed timelines, but I am in doubt we should cut-off > an ongoing debate just because the magical time-limit was reached. What > benefit could that possibly bring? The discussion phase of this GCD is > alive and well—we're still figuring out the scope and necessity of the > GCD. The GCD process is not up for debate; there are good reasons why it’s written this way. (We could debate it, but that’d be a separate GCD!) But that’s fine: if consensus cannot be built during that time frame, we can always start another GCD later, using feedback from this discussion and without time pressure. > I don't think I (so far) intended to write anything like that. My > proposal of re-approving the maintainers collective was not intended to > force anyone out of a position they are willing to go on doing (and are > good in). In my experience, volunteer run project always lack (capable) > worker, not the other way around. I agree, but to me it’s more about choosing the right rotation period: not too often, not too infrequent. >> As currently documented (info "(guix) Teams"), it’s either when the >> person quits or when they’ve been inactive for one year or more. > Yes. But who removes them? Anyone can do it, and a committer has to commit it. If you look at the history of the ‘.guix-authorizations’ file, you’ll see it’s often Leo Famulari who would take care of it, but you and I can do it as well. > We have (probably, still; or at least had) single-member teams, teams > without committers. Does the general public (other team members? > committers? maintainers collective? consensus reached on guix-devel?) > eventually decide that a team is not necessary anymore and dissolve it? That part (dissolving team) is not documented currently; it would be a useful addition. >> It’s already written: >> >> https://guix.gnu.org/manual/devel/en/html_node/Making-Decisions.html >> https://consensus.guix.gnu.org/gcd/001-gcd-process.html > True! So shall I omit any of that in GCD007 since it would be redundant? The document can always remind them. >> These documents are “binding”. > As true as that may be, they build on top of not-that-well-defined > terminology. What is meant by consensus, for example? Speaking from > experience, agreement through exhaustion is not what I think a project > like ours should strive for. I agree. The “Making Decisions” section refers to <https://www.seedsforchange.org.uk/consensus> to clarify what is meant by consensus. > I was asking this WRT roles. Since GCD007 describes some sort of > hierarchy, maybe it is important to explicitly state that the final goal > with all conflict is to reach a state of mutual agreement? And > also—maybe—to lay out a way to help arguing parties out of their > blockade. Maybe a conflict-resultion team would be nice? Some sort of > ombudsman? Disagreement should not escalate to the point where we reach > out to the maintainers to have them scold or exclude the other party. > > If we do not lay out processes and ways to resolve conflict, we are > bound for essential crises whenever major drama emerges. The whole agreement, disagreement, and conflict framing is somewhat foreign to consensus building—please again check the Seeds for Change page. What we’re aiming for is collaborative solution finding, not confrontation. I personally find that non-violent communication gets a long way in making this practical: <https://en.wikipedia.org/wiki/Nonviolent_Communication#Components>. >> > - How is dissent resolved in each of the roles (teams, committers, >> > maintainers)? Do we have, should we introduce and how do we write >> > down according procedures? >> > >> > Examples being: differences among committers (which change is the >> > best), among team members, between teams, etc. >> >> This is already documented as being addressed by seeking consensus and I >> think it has worked well for almost 15 years (it’s not perfect: some >> issues get ignored, too.) > WDYM "being addressed by seeking consensus" mean in this context? I am > sure we all are constantly trying to seek consensus, but this does not > prevent us from disagreeing. We can disagree and acknowledge that disagreement; what matters then is to ensure there’s a good understanding of each other’s needs so we can work out a solution that takes them into account. I hope that makes sense! Thanks, Ludo’.
