GNU bug report logs - #74736
[PATCH v2 0/1] Add Request-For-Comment process.

Previous Next

Full log

Message #120 received at 74736 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: pukkamustard <pukkamustard <at> posteo.net>, 74736 <at> debbugs.gnu.org
Subject: Re: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
Date: Thu, 09 Jan 2025 18:18:40 +0100

Hi,

On Wed, 08 Jan 2025 at 16:26, "pukkamustard" <pukkamustard <at> posteo.net> wrote:

> - I had to think if I am a _team member_ or not. The term is not defined in the
>   document. I think this is mostly due to there not being a RFC on teams (yet).
>   Still, to make the Process RFC understandable, I'd add a brief explanation of
>   what team members are (i.e. members in etc/teams.scm). 

Yes, that’s the idea.  Ludo pointed that teams.scm file and it was in v5
but not in v6.  Maybe something lost in translation. :-)

>   Likewise, I think the Process RFC would be simpler to understand if feedback
>   is required from a fixed number of team members instead of a percentage. I
>   believe there has been some discussion on this, that I have not been able to
>   follow completely, so ignore if already discussed and agreed upon.

What do you suggest?

Well, FWIW, some explanations, maybe it could help to find a better way.

It appears to me easier to know if the quorum is reached or not, I
guess.

    ./etc/teams.scm list-teams | recsel -CP members | sort | uniq | wc -l

I think that the input of some team members might happen on the
Discussion Period and not specifically on the Deliberation Period.

Well, then you would tell me: I cannot have an opinion on any topic. :-)
Or I do not have the bandwidth to follow all the discussion.  Maybe.
But then, if we are not able to express an opinion on such topic, does
we consent?

From my point of view, the idea is to be sure we – as a community –
consent about significant changes.

And if I – as a deliberating member – do not feel confident enough, I
have two options: (a) Disapprove, for instance because I estimate we
have not discussed enough the topic at hand and the topic deserves more
discussion or another counter proposal or (b) Silent (no reply),
although it would mean to me something is wrong.

On this, the danger is the “social pressure” because the Deliberation
Period is public.  But if it’s a real issue, improvement on that could
be part of an amendment for the next version. :-)

Please keep in mind (1) the “social pressure” would mean it’s not a safe
place hence it would raise more than the potential RFC and (2) consent
does not mean being 100% in agreement with all the details but it means
“it’s a good direction, not perfect but I can live with the
imperfections”.  Somehow. :-)

> - The term "supporter" is used for two things where it's not clear if
>   it's the same:
>
>     1. People listed as supporters in the RFC metadata.
>     2. Team members that respond with "I support" during the Deliberation
>        Period.

Ah.  Hum.  The idea of the process is:

    + author sends
(*) + one or more people reply “I support”
    + it becomes a submitted RFC
    + all the dance…
    + Deliberation Period:
(**)  . I support
      . I approve
      . I disapprove

Ah indeed (*) and (**) are not the same:

  1. “Supporter” means (*)
  2. Team members replying “I support” means (**)

Thanks.  Maybe (1)(*) should be renamed.


>   I'd suggest renaming the RFC state "Final" to "Accepted".

I agree.

> - In Section "Deliberation Period" the team member response is "I disapprove"
>   but in the next section the term "disagree" is used. I'd use the same term for
>   clarity.

I agree.

> - The "I disapprove" reply is only allowed if member actively proposed
>   alternative solutions during the "Discussion Period". I feel that might be a
>   bit of a strong requirement as that means you can not disapprove a RFC if you
>   only see it after the "Deliberation Period" has started. Maybe that's ok as
>   RFCs need to be announced to guix-devel. Still it might be a bit strong. Maybe
>   something along the lines: "A team member sending this reply must explain
>   their disapproval and should suggest constructive changes to the proposal that
>   would make it approvable."

If you do not see the RFC after the long Discussion Period of 60 days,
then why do you see it in the short Deliberation Period? ;-)

Somehow, we need to bound, else it becomes hard to move forward, IMHO.

Well, I assume good faith, I would like to counter the behaviour: I
sleep during all the discussion where people took the time to polish and
end up with something all agree, and me, I awake up in the last minute
and bang!  That’s unfair, IMHO.

It’s not explicitly mentioned (maybe it should be): I think that any
“submitted” RFC must be advertised via info-guix <at> gnu.org.

> - I think the name "Guix Consensus Documents (GCD)" would be slightly
>   funnier - a play on greatest common divisor (as mentioned by Simon).
>   But I think RFC is a term that is more widely understood and that's
>   fine.

I agree.  I remember your suggestion at the last Guix Days.  And I lost
it among other stuff during the year 2024… Arf!

> I'm not quite clear what this means, but: I support. :) 
>
> I will be afk during the Deliberation Period (and not present in
> Brussels) but I think this is an important step for Guix and am fine
> with being added to the `supporters` field.

Thank you.

Ah what a pity to not see you in Brussels!

Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.