[post Guix Days] Guix Common Document (was: Request-For-Comment process)

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi all,

I hope that the discussion we had yesterday (Friday 2nd) in Guix Days
has clarified the idea behind this proposal.

I am waiting Ludo’s notes in order to refine this proposal, integrate
many comments and/or ideas, and polish.

Thanks all participants.


The aim of the proposal is to have a process to document our processes
with the least bureaucracy as possible.  Well, Debian project is often
cited as an example (social contract, voting system, etc.).  Indeed,
however there is more bureaucracy in Debian than in French State. ;-)

Instead, let just formalize what we are already doing.

Currently, we are just adding more and more sections to the manual and
for other parts the structure for making decisions is not clear.  For
sure, it works… until now but I think it does not scale and we are
touching the limits about what can be done with this informal structure.

Let me clarify my attempt behind this “RFC proposal”.  First,
pukkamustard proposed the name “Guix Common Document” echoing “greatest
common divisor“ (gcd): the greatest common divisor of two or more
integers is the largest positive integer that divides each of the
integers – other said, that’s the larger integer in common with all.

I like it because it captures well the idea; although such different
name could be confusing from the outside.   Anyway.  That’s an
implementation detail. ;-)

Second, from my point of view, the core components of the proposal are:

 + consensus;
 + co-supporter.

Consensus, because it is how we already collaborate.  Somehow, it
changes almost nothing for our daily operations but having an explicit
formalization will help outsiders.  The definition of “consensus” is
twofold:

 1. can live with;
 2. concerns are actively resolved.

Other said, the definition wording of “consensus” specifies how to avoid
being blocked by disagreements: when one wish to block a proposal then
one bears a special responsibility for finding alternatives, proposing
ideas/code or explaining the rationale for the status quo.

And to make it clear, the first idea for making decision is “voting” but
then we need to define “who” votes.  Well, this appears to me a
counter-measure against something that would be rare and this solution
does not trust in the values of our community (being welcoming,
inclusive, taking care of each other, etc. well as least, trying as much
as possible :-)).

For me, the counter-measure against an hostile takeover is somehow
captured the point #2 above.


Co-supporter, because similarly as the manual section « (guix) Reviewing
the Work of Others » [1], the aim is to cross the final line, make
progress by incremental focused improvements.  Therefore, a proposal
needs the help of someone committed to the project (long-standing
contributor, committer, etc.).

I agree that “contributor sufficiently familiar” is maybe too vague and
needs more specific examples as “contributor sufficiently familiar
(committers or people with X commits)”.  Well, that’s part refining the
proposal. :-)


Last, I think that the time-frame for discussing needs to be bounded.
Somehow this bound will help in the incremental improvement and will
avoid the trap of the perfect-as-the-first-try.


Well, let recover from these awesome Guix Days and from FOSDEM and then
resume this proposal.

Cheers,
simon

1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others