Hi Steve,
On Wed, 25 Mar 2026 at 08:51, Steve George <[email protected]> wrote:
> The reason I'm pointing at this is that _when_ there is conflict,
> there should be clear rules so everyone knows how to deal with them.
>
> - Who is involved
> - What is the process
> - How is deadlock resolved
I agree.
> I'm asking for the
> same thing here, that the process is defined.
Could you please point which part of the GCD 007 needs clarifications?
Maybe I misread you. Your comment:
Re: [GCD007] Request for Comments
Steve George <[email protected]>
Thu, 19 Mar 2026 15:19:09 +0000
id:5eqr4ybgkgwrjcfqnfl7i6l3gfghzhgrmwmnomop4572lm7hc7@p453axq22p3t
https://lists.gnu.org/archive/html/guix-devel/2026-03
https://yhetil.org/guix/5eqr4ybgkgwrjcfqnfl7i6l3gfghzhgrmwmnomop4572lm7hc7@p453axq22p3t
appears to me a general* comment about Consensus. What appears to you
weak in the current GCD 007 proposal?
Cheers,
simon
*general comment: Below a reply that is out of scope the GCD 007
discussion but still appears to me worth because it’s an attempt to
be on the wavelength. :-)
--
PS: About the rest. :-)
>> 22.13 Making Decisions
>> ======================
>>
>> It is expected from all contributors, and even more so from
>> committers,
>> to help build consensus and make decisions based on consensus. By
>> using
>> consensus, we are committed to finding solutions that everyone can
>> live
>> with. It implies that no decision is made against significant
>> concerns
>> and these concerns are actively resolved with proposals that work for
>> everyone.
>>
>> A contributor (who may or may not have commit access) wishing to
>> block a proposal bears a special responsibility for finding
>> alternatives, proposing ideas/code or explain the rationale for the
>> status quo to resolve the deadlock. To learn what consensus decision
>> making means and understand its finer details, you are encouraged to
>> read <https://www.seedsforchange.org.uk/consensus>.
>>
>> > [0] https://guix.gnu.org/manual/1.5.0/en/html_node/Making-Decisions.html
> "It implies that no decision is made against significant concerns"
I think it’s defined in GCD 001:
Decision Making
===============
Contributors and even more so team members are expected to help build
consensus. By using consensus, we are committed to finding solutions
that everyone can live with.
Thus, no decision is made against significant concerns; these concerns
are actively resolved through counter proposals. A deliberating member
disapproving a proposal bears a responsibility for finding alternatives,
proposing ideas or code, or explaining the rationale for the status quo.
To learn what consensus decision making means and understand its finer
details, you are encouraged to read
<https://www.seedsforchange.org.uk/consensus>.
https://consensus.guix.gnu.org/gcd/001-gcd-process.html
> OK, so what does "implies" mean in this context? What is a
> "significant concern"?
A “significant concern” is a concern that one cannot live with and we
fail to find together a solution for overcoming it.
> When is a concern not "significant"? How many
> people involved must have such a concern? If one person has a concern
> does it block the outcome?
It seems to me that you’re reasoning as if someone™ must put a final-cut
or clear-cut proposal on the table, then the members just press a button
“I like” or “I dislike” using some all or nothing view where the members
are passive.
Consensus flips the process: the members are active and someone™ is the
shepherd about one topic that someone™ want to see progress. The
members aren’t expected to press a final button but instead they are
expected to engage themselves.
Somehow, we apply the same “Decision Making” methodology for regular
patches and for GCD. To me, it’s the same: someone™ wants to fix
something that annoys them, then send a patch and voilà we discuss it
trying to reach cross the final line. Taking a dumb illustration: no
one holds a merge because “sorry, I dislike this package update because
it does not fit my current setup”. ;-)
Consensus isn’t about raising an hand and just say “I disagree” but
instead it’s about saying “this specific part is an issue for me, here
why, and considering the whole, here what I’m proposing instead”. Yes,
there is situation where it’s binary choice A or B and there is no C.
For instance GCD 003 – to me, it’s more about a collective failure than
a flaw with the process, another discussion :-) – and the final outcome
of GCD 003 should have been either we stick on A because, or either we
move to B because. Anyway, another discussion. ;-)
All that said, there is two issues: the bikeshedding trap and the “Why
wasn't I consulted“ balance.
About the bikeshedding trap, it’s because most of us here have an
(strong) opinion on many topics. And it’s far much easier to raise a
voice about something written in plain English than a patch touching
guix-daemon or yet another core Guix module. ;-)
When discussing regular patches, most of the time, there is different
ways to achieve a result or a fix. Then, I barely read – except from
myself when I nitpick arf :-) – people commenting at length although
such patch might have a deep impact on their computations; it’s harder
to fall into the bikeshedding trap, somehow.
We must refrain ourselves to feed the bikeshedding trap and ask
ourselves: Can I live with this? If not, which specific part of the
proposal hurts me? Considering the current proposal, what could I
propose to resolve the part I cannot live with taking into account the
whole and the rest?
> Who is having such a concern, is it a
> committer, a team member, a user?
It’s where “Why wasn't I consulted“ balance comes in. :-)
If you have watched yet, I recommend you this talk [1]. And I extracted
the ideas that appeared to me the keys [2]. Or this post [3].
Somehow, the “who” is probably vague on purpose because of this:
“Why wasn’t I consulted” is the fundamental question of the
web. It is the rule from which other rules are derived. Humans
have a fundamental need to be consulted, engaged, to exercise
their knowledge (and thus power), and no other medium that came
before has been able to tap into that as effectively.
In other words, “who” is anyone who cares enough about Guix or who
depends on Guix. It might be a committer, a team member, an user, a
company, an academic stakeholder, etc.
Again, consensus is an active process and not some one-shot dropping an
personal opinion as “nah, I don’t like” or “hey here my awesome idea”.
1: https://youtu.be/m0rakUuPXFM
2: https://simon.tournier.info/posts/2023-10-30-toward-rfc.html
3: https://www.ftrain.com/wwic
> The manul provides an introduction to the principle, it doesn't deal
> with the specifics in the specific context.
Well, since it’s not the first time that you raise questions about
Consensus, yes, indeed maybe we should improve the wording and clarify
the expectations.
> OK, so if a user wishes that a package should stay in Guix do they
> have the right to block removal?
I don’t like to frame about “have the right”. Your “right” is my
obligation/duty, so what’s your obligation/duty to me?
I don’t see the life as if everything would be about granting rights.
Or, we need to speak about contracts – the counterpart of rights. :-)
> They can't realistically "contribute"
> to creating a solution, but this sentences "implies" they can do
> so.
I’ll not discuss the wording of GCD 006 here. :-)
> if something is not
> explicit it's implicit and open to argument.
I agree we should do our best to make explicit what is known implicitly
by roaming after years. :-)
However, please note that too much explicit also paves the way to
bureaucratic behavior. And the arguments are still there but by
interpreting the explicit. ;-) Well all the Courts are about that. :-)
And closer to us, Debian has many explicit rules and our beloved friends
still argue at length.
IMHO, what is hard is to keep is the right balance.
All that said, again I agree with your comment:
The reason I'm pointing at this is that _when_ there is conflict,
there should be clear rules so everyone knows how to deal with them.
- Who is involved
- What is the process
- How is deadlock resolved
Could you precise where it should included in the current GCD 007? :-)
