Re: Time for a request-for-comments process?

[Bengt Richter]

Hi Zimoun, Ludo,

On +2021-10-28 10:42:02 +0200, zimoun wrote:
> Hi Ludo,
> 
> On Wed, 27 Oct 2021 at 23:22, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > The recent ‘guix shell’ addition is almost anecdotal technically yet
> > important for the project because users interact with Guix primarily
> > through the CLI.  Adding a new command is a commitment (our users must
> > trust it won’t change overnight), and getting the details wrong could
> > make us fail to honor that commitment.
> >
> > For ‘guix shell’ I left time for comments and repeatedly asked people to
> > comment; yet pushing it was a bit stressful: Did I make a mistake?  Did
> > everyone with a stake in this really have a chance to comment?
> 
> Note that the patch received many comments; especially v1.  Then, only
> two people commented for v2.  And v3 did not receive any general LGTM –
> I sent one for the two trivial parts I reviewed.
> 
> For me, one important root of the issue is the review process.  I feel
> the balance described in thread «Incentives for review» [1],
> 
>         There’s a balance to be found between no formal commitment on
>         behalf of committers, and a strict and codified commitment
>         similar to what is required for participation in the distros
>         list¹.
> 
> is hard to found.  Because, on one hand, the project has to honor
> commitments, and on the other hand, no one as team is committed to do
> it.
> 
> From my understanding, your message here is interesting because somehow
> you did a similar experience as maintainer of what is an usual
> non-committer contributor experience; somehow explained by some of my
> soft ramblings from the thread «Incentives for review» [1]. :-) Another
> meaningful because similar, IMHO, failure of the review process is
> patch#45692 [4].
> 
> As you know, I did some stats in order to find, or at least discuss, how
> to improve the situation grounded on current facts.  Aside, Debbugs
> already provides insightful numbers [2], especially this one [3]:
> 
>     <https://debbugs.gnu.org/rrd/guix-patches-oc.png>
> 
> The traffic on guix-patches is quite high and I do not know how many
> people subscribe – I guess few.  I hope the discussed improvements of
> Mumi will help.  Or perhaps if someone is willing to setup a Guix
> official public-inbox; for example, the instance https://yhetil.org/guix
> is providing helpful tools for easily filtering, IMHO.
> 
> 1: <87mtn56mzg.fsf_-_@inria.fr">https://yhetil.org/guix/87mtn56mzg.fsf_-_@inria.fr>
> 2: <https://debbugs.gnu.org/rrd/guix-patches.html>
> 3: <https://debbugs.gnu.org/rrd/guix-patches-oc.png>
> 4: <http://issues.guix.gnu.org/issue/45692>
> 
> Closing parenthesis, back to your question. :-)
> 
> > That makes me think it’s perhaps time for a formalized
> > request-for-comments (RFC) kind of process for such “major changes”.  We
> > could draw inspiration from one of the many existing processes: Python’s
> > PEPs, Scheme’s SRFIs, Nix’s RFCs, Rust’s MCPs, etc.  I think a major
> > goal of the process would be to formalize a minimum and a maximum
> > duration under which an RFC is under evaluation, and a mechanism to
> > determine whether it’s accepted or withdrawn.
> 
> Aside the usual review process, at least my understanding what the
> review process should be, you are asking for a special flag then expose
> materials to various channels of communication, IIUC.
> 
> For sure, it appears a good idea. :-)
> 
> Concretely, what does it mean “major changes”?  How many of these do you
> consider that happened in the recent two past years?
> 
> For example, the recent label-less input style [5] is one instance,
> IMHO.  However, I do not remember* if it was discussed outside
> guix-patches.
> 
> In addition to the change itself sent to guix-patches with an associated
> number, it could be worth to send that information elsewhere.
> 
> What would be this elsewhere?  Create another dedicated (low-traffic)
> list would scatter the information and I am not convinced it would help
> to gain attraction at the moment.  However, it would ease digging in the
> future because all would be in only one archive.

 Wherever "elsewhere" might be, I'd like notification when there is something
 new to read.

I'm visualizing a screensaver hook where the screen is restored after being 
locked,
like logging in the first or subsequent times, to show an intermediate popup
before going on as usual. Sort of a dynamic motd (message of the day).

What I'd like then, to find out details, is access (CLI or Web browser) to a 
relational DB
like the ones supporting online shopping, but in this case I am shopping for 
info, and filtering
by e.g. zimoun or ludo instead of Asus or Lenovo, and similarly to narrow or 
widen context
for OS or achitecture etc. (I am obviously suggesting something broader than 
just "shopping"
for RFC info :)

The shopping interface could be used to select what info to subscribe for,
to get notifications about different info "products" or categories.

> Maybe info-guix could be used.  But it would mean that everybody would
> be allowed to this list, when currently the messages landing there are
> somehow “highly filtered”.  However, an announce there pointing where
> and how to comment could be something helping to get more attention.
> Adding a section under Contributing about the process too.
> 
> Last, the core question is formalization.  Formalize the process (min,
> max duration, expectations of evaluation, mechanism to accept or
> withdraw, i.e., how to revolve different points of views, etc.) strongly
> depends on what “major changes” means and how often that happens.  Could
> you provide examples of such “major changes”?  It would help for drawing
> a sketch of such formalization grounded on concrete examples.
> 
> 
> Cheers,
> simon
> 
> 5: <https://yhetil.org/guix/20210716155009.32118-1-ludo@gnu.org/>
> 
> 
> *remember discussion: Personally, I receive all emails to all lists. All
> in my Inbox.  Thus, the channel does not mind for my workflow. :-)
> However, dealing with Guix traffic is a daily task – if I am off for a
> couple of days or holidays or busy by day job, then I skip some based on
> dates or interest.  My trick to deal with such traffic is “just” to
> quickly be able to determine if it is worth, for my interests, to jump
> into the details.  If it requires less than 10min to answer, then I do
> it (obviously, it always take more time than expected :-)), else if I am
> interested in, I mark the email to revisit it later – coupled with
> Org-capture and scheduled TODO tasks.  On the top of that, I use a
> “structured procrastination” approach: do what I am interested in at the
> moment, not what it is important or urgent.
> 

-- 
Regards,
Bengt Richter