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

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 4564 bytes --]

On Sat, Feb 03, 2024 at 11:34:13AM +0100, Simon Tournier wrote:
> 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. :-)

For this part I think that for 'contributor sufficiently familiar' can
be interpreted as someone sufficiently familiar with Guix, the coding
standards, etc., and it could also be interpreted as someone
sufficiently familiar with the subject matter being proposed. For
example, I don't know about AVR chips or programming them or knowing
what to do with them, but I can review the code submitted to make sure
it doesn't break other functionality already included in Guix and rely
on others telling me that they've tested out the code and it works with
their chips.

> 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
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]