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