Hi Gabriel, all,
On Wed, 25 Mar 2026 at 15:18, Gabriel Wicki <[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.
>
> This is exactly what I was having in mind. We can repeat our tautology
> of consensus finding as much as we want, but when conflict eventually
> escalates we better be prepared with a clearly laid out process.
>
>> - Who is involved
>> - What is the process
>> - How is deadlock resolved
>
> From yet other experiences I know that whenever groups lack such
> processes, seniority or merit dominate informal hierarchies.
On these two blocks, I think we all agree on. And even it seems the aim
of the GCD 007, at least from my understanding. :-)
That said, what appears to me difficult to grasp is that we have a
mismatch about our understanding of “Making decision” for different
contexts. For instance, I think we agree that the current wording:
- Team members are expected to take part in ongoing discussions on
the guix-devel mailing list. They are expected to voice their
opinions in our consensus-finding process (GCD).
- All team members should strive for consensus finding rather than
pushing for what they perceive to be the best solution when dissent
or confusion about issues emerge.
is weak because it does not deal with the case how to resolve (move
forward) some Team conflicts. My understanding is that the current GCD
007 lacks one section for Teams.
When a conflict emerges that Teams members would not able to resolve,
then let escalate to the Maintainers who pick the option that appear to
them the best. Similarly, a conflict between Teams might also emerge;
thus I propose the same escalation process.
Please note that we could imagine that each Team internally organizes
themselves differently. In my view, GCD 007 isn’t about the internal
Team organization but it’s about the skeleton of the Teams
collaboration.
It remains internal conflicts of the Maintainers team. Maybe we could
design a Mediation team, why not? Well, I imagine that this kind of
conflicts could happen but on the other hand, Maintainers are long-time
committers to the Guix Project, trusted individuals that have proven
commitment to our cause time and time again, so I personally expect that
Maintainers would be wise enough to resolve their own conflicts. ;-)
Or, if Maintainers fail in this area, then it means we have an harder
problem than the conflict itself. ;-) Somehow, we have the same
chicken-or-the-egg problem with Code of Conducts enforcement; at some
point we need to trust a set of people who act for the common good.
>> This is exactly what you did for the GCD process. I'm asking for the
>> same thing here, that the process is defined.
>
> My suggestion would be to have a mediation team that helps conflicting
> parties reach consensus (or help them escalate the matter to the broader
> community for decision finding). How would you imagine our structure
> resolving emerging conflicts?
I think we should refrain to over-engineer and instead stick on our
current practises that worked for many years. :-) Somehow, the boring
task to document what we are already running.
Cheers,
simon
