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 <[email protected]> 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: <https://yhetil.org/guix/[email protected]> > > 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/[email protected]/> > > > > > > *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. > > >
