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

[Tobias Platen]

GNUnet has something similar called the GANA (GNUnet Assigned Numbers
Authority)

https://git.gnunet.org/gana.git/


On Thu, 2021-10-28 at 12:33 +0200, Bengt Richter wrote:
> 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.
> > 
>