Dear Maxim,
On 2026-08-27 03:31, Maxim Cournoyer wrote:
Not exactly replying to the above, but related: GCDs should perhaps be
*encouraged* to be mostly about technical matters? Browsing the Python
PEPs [https://peps.python.org/#index-by-category] for example, the most
"meta" or non-technical PEPs appear to be
about governance or the release process. The vast majority of them is
focused on technical topics. Personally, I find reasoning about
technical topics much simpler, as they tend to be well defined and not
overly broad/complex/diffuse, and can thus be reasoned in a more
mathematical sense, which I suspect is how many of us Guix are wired to
reason, which in turns facilitates consensus.
GNU, like many socio-technological projects (such as say Bitcoin),
which are designed and practiced under the assumption that a wider range
of behaviours and outcomes are possible.
It would be naive to assume that this occurs without problems and issues
from time to time.
For example, the differences between Nix and Guix in many respects stem
from the politics around licensing rather than tooling.
Such distinctions is fine, admirable even.
It worth clarifying that many of my digressions that I have written
about within GDC conversations were not an attempt to bludgeon different
opinions; or use the convenience of sophistry; but to make the
non-technical contradictions less hidden.
While I would prefer everybody to always be preoccupied with technical
matters, Im not sure its advisable.
* Every GCD as a separate project
I envision each GCD as a new project for the initial draft, which is a
reference from which to submit issues and/or pull requests, and also
gives the ability to compare changes across revisions, see when a
change
was merged, etc. we can track the primary author(s) of a given change
using git metadata, and use various *-by git commit traileer
conventions.
We can keep the whole change history archive as a reference, and
possibly only merge the final result into the repository of official
policies...
Yeah, that sounds like a good idea for a more structured, clear
resolution of points, though even heavier than the already heavy
process
we currently have (which is that authors address points as they see fit
and issue new revisions).
* word choices
I think the "deliberation" phase in the current GCD process is very
confusing to me as a native English speaker, as it more commonly is a
synonym for "discussion" rather than the tallying the final results of
a
decision. Inevitibly, social creatures that we are, we will want to
discuss all the way through, but at some point it should refocus.
It confuses me as well, even in my native French, and probably invites
the post-result discussions we've seen. Something like "Test for
Agreement" would convey the stage better (that's stage 6 in [1]).
As somebody who has always struggled with foreign languages (I really
have tried),
Im astonished by how much people are able to understand and express
themselves to effectively.
Its worth noting that in Britain there is the Plain English Campaign:
https://www.plainenglish.co.uk/
In many respects, the UK is better than other countries regarding the
quality of clear English communication.
You should understand that these movements not only exist for reasons of
equality of access and attainment
but have been adopted as part of the philosophy of New Public
Management.
I hope Guix is getting better at involving non native English speakers
over time,
this will probably always have limitations as it is volunteer dependent.
I guess, just as it is with coding that such matters need plenty of
examples.
[1] https://www.seedsforchange.org.uk/consensus#stages
I find "disapprove" to be far too weak of a word given the severe
implications for the process. Again, with my native English speaker
hat
on, the difference between "disapprove" and "accept" is just a matter
of
degree, whereas the function "disapprove" holds in the process is much
more severe than anyone's individual opinion. Not entirely sure of a
better choice, but perhaps "reject" is more honest?
I wouldn't want to make disapproving even a bigger deal than it already
is. While it shouldn't hopefully be a routine outcome, I believe it's
part of a healthy process that disapproving is
allowed/recognized/valued
as a potential outcome of the process.
Also using "I accept" "I support" "I disapprove" centers "I" more than
the issues raised, which again, it should not be about the individual
community members, but about the issues and concerns raised by the
community.
Good point. Another unrelated point that I'd like to emphasis, that
others have mentioned in past discussions, is that we seem to not have
any kind of opening out of a discussion; we jump straight to a proposed
draft, that then enters a discussion/editing phase; thus the original
shape or even content of the document may be far from the shape it'd
need to have for it to be agreed by the community.
Taking an approach where the community would be more involved into
recognizing a problem and looking for a solution early, rather than
being asked to review a complete proposal, would help consensus a lot
here, I think. This corresponds to the stages 1: Introduce and clarify
the issue, 2: Open out the discussion and 3: Explore ideas in a broad
discussion of the Consensus-decision making document linked above [1]
(which is also referenced in our documentation).
I was a little surprised that GCDs were not emphasizing an approach
closer to issues.
I have spoken about the fact that GCD governance has deficiencies
because of the need to avoid dissent at the voting stage.
Having taken the time to analyze properly the parent document by
seedsforchange (SFC),
I have better internalize the quality of the work that went into it and
why it would have been considered by the Guix community.
Its worth noting that SFC is a document operates as a means of
reconciling differences within smaller groups
and allowing this to form an aggregate community perspective.
I consider that the GCD process would be more effective (spiritually and
in terms of noise) were earlier stages to be conducted in smaller
groups.
As such, a smaller group can involve more tangential brain storming
locally and then an articulation of viewpoints in more neutral ways to
the other groupings.
For example:
"In this group as a majority we felt this to be the case. We could not
reach consensus on these topics because these concerns could not be
fully resolved and certain members of the group could not appreciate the
subtleties regarding FOO and BAR"
This would permit the ability to speak truthfully using group centric
communications (such as a video call), Chatham House style and still use
clearer, more concise communication as part of the aggregate discussion.
It could also permit misunderstandings on language to be corrected.
But the SFC document as a means of encouraging political communities
does have quite clear descriptions as to why community fit is a bit
deal.
If this tension between community coherence and disagreements do not
work then those initiatives suffer.
I have seen multiple communities change over time (fwiw, I normally
prefer being in environments with people from different backgrounds and
viewpoints as a loose coalition - Id prefer that wholeheartedly though
like most people there are a few biases that are a matter of
conscience).
Ive noticed it takes a lot of experience to judge whether a community is
changing too much; too little; or not enough.
Not suggesting any specifics in Guix, I know from experience the costs
to communities from treating tolerance; trust; and patience as ideals
above else,
as people end up silently moving on and the cost on those trying to
defend an older ideal becomes large.
I have even seen some beautiful coalitions break up, as once consensual
leaders knowing they are moving on play some cruel games.
Its not clear cut unfortunately.
Kind regards,
Jonathan
