Time for a request-for-comments process?

Time for a request-for-comments process?

[Ludovic Courtès]

Hello Guix!

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?

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.

Thoughts?  Anyone with experience with such a process?

Ludo’.

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

[Katherine Cox-Buday]

Ludovic Courtès <ludo@gnu.org> writes:

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

I think it's a good idea. The only contribution I can give is that I would not have known =guix shell= was coming had I not been watching the patches list. So in addition to formalizing what you've mentioned, I suggest we also formalize a location to watch (guix-devel seems logical?).

-- 
Katherine

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

[Thiago Jung Bauermann]

Hello,

Em quarta-feira, 27 de outubro de 2021, às 19:28:14 -03, Katherine Cox-
Buday escreveu:
> Ludovic Courtès <ludo@gnu.org> writes:
> > 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.
> 
> I think it's a good idea.

Me too.

> The only contribution I can give is that I
> would not have known =guix shell= was coming had I not been watching the
> patches list. So in addition to formalizing what you've mentioned, I
> suggest we also formalize a location to watch (guix-devel seems
> logical?).

I agree that guix-devel is a good place to announce new RFCs, probably 
using an eye-catching subject prefix so that we can more easily see and 
filter them.

For RFCs where users are also stakeholders, we should also announce in 
places where users are likely to see them, such as the info-guix and help-
guix mailing lists, and possibly even the Guix blog (how far out do we want 
to spread the word?).

“guix shell” would have been an RFC with users as stakeholders, but I can 
imagine others where that isn’t the case, such as some significant but 
internal code reorganization.
-- 
Thanks,
Thiago

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

[Ludovic Courtès]

Hello!

Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:

> I agree that guix-devel is a good place to announce new RFCs, probably 
> using an eye-catching subject prefix so that we can more easily see and 
> filter them.
>
> For RFCs where users are also stakeholders, we should also announce in 
> places where users are likely to see them, such as the info-guix and help-
> guix mailing lists, and possibly even the Guix blog (how far out do we want 
> to spread the word?).
>
> “guix shell” would have been an RFC with users as stakeholders, but I can 
> imagine others where that isn’t the case, such as some significant but 
> internal code reorganization.

Yes, that makes sense to me.  We have to make RFCs visible to users when
they have a direct effect on them, as is the case with ‘guix shell’.

So I suppose RFCs would be at least announced on guix-devel as everyone
suggests, but additionally on info-guix or the blog when we think users
need to have the opportunity to chime in.

As zimoun wrote, a big question is formalization.  I haven’t yet taken
the time to look at those other project RFC processes I mentioned, but
we should do that.  Important questions are: how do we determine whether
a change is important enough to be RFC-worthy?  How do we determine
whether it’s accepted or withdrawn?  Perhaps that will unfold broader
questions about structuring and decision-making.

If anyone feels like giving a hand of this formalization effort, please
feel empowered to do so!

Ludo’.

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

[zimoun]

Hi Ludo,

On Fri, 29 Oct 2021 at 17:08, Ludovic Courtès <ludo@gnu.org> wrote:

> As zimoun wrote, a big question is formalization.  I haven’t yet taken
> the time to look at those other project RFC processes I mentioned, but
> we should do that.  Important questions are: how do we determine whether
> a change is important enough to be RFC-worthy?  How do we determine
> whether it’s accepted or withdrawn?  Perhaps that will unfold broader
> questions about structuring and decision-making.
>
> If anyone feels like giving a hand of this formalization effort, please
> feel empowered to do so!

I could volunteer for being part of the formalization effort.  However,
as I said elsewhere, this effort should start be collecting what do we
consider as changes requiring formal process?

For example, “guix shell” is one instance.  The recent “input label” is
another one.  Authentication another.  Without such list – even rough –
it seems hard to think about a process grounded on our past practises
for improving them and becoming applicable by our community – for what
my opinion is worth. :-)


Cheers,
simon

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

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Fri, 29 Oct 2021 at 17:08, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> As zimoun wrote, a big question is formalization.  I haven’t yet taken
>> the time to look at those other project RFC processes I mentioned, but
>> we should do that.  Important questions are: how do we determine whether
>> a change is important enough to be RFC-worthy?  How do we determine
>> whether it’s accepted or withdrawn?  Perhaps that will unfold broader
>> questions about structuring and decision-making.
>>
>> If anyone feels like giving a hand of this formalization effort, please
>> feel empowered to do so!
>
> I could volunteer for being part of the formalization effort.

Yay!  :-)

> However, as I said elsewhere, this effort should start be collecting
> what do we consider as changes requiring formal process?

Agreed, that’s what I meant above.

I don’t have an answer, but I think we should look at what others are
doing, what criteria they use, etc.  The Nix RFC process is probably the
closest match in terms of application domain, but maybe others are
closer to the way we practice decision-making in Guix.

Thanks,
Ludo’.

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

[zimoun]

Hi Ludo,

On Tue, 09 Nov 2021 at 17:52, Ludovic Courtès <ludo@gnu.org> wrote:
> zimoun <zimon.toutoune@gmail.com> skribis:

>> However, as I said elsewhere, this effort should start be collecting
>> what do we consider as changes requiring formal process?
>
> Agreed, that’s what I meant above.

I meant, based on changed already merged.  For instance, on the top of
my head, some changes that *I* consider requiring a RFC:

 - new inputs style
 - guix shell
 - authentication
 - GUIX_EXTENSIONS_PATH (not finished and not documented)

And it would be nice if we could come with a list of such changes.  It
would help for finding patterns – if they are :-) – for examples,
numbers of people involved in the discussion, time between each reply,
structure of the cover letters, etc.


> I don’t have an answer, but I think we should look at what others are
> doing, what criteria they use, etc.  The Nix RFC process is probably the
> closest match in terms of application domain, but maybe others are
> closer to the way we practice decision-making in Guix.

Yeah, for sure, several items need definitions. ;-)

 - which kind of change requires a RFC?
 - what is the process?
 - how to decide?  Accept or reject?
 - who decide?
 - etc.


Cheers,
simon

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

[Julien Lepiller]

Le 9 novembre 2021 13:01:46 GMT-05:00, zimoun <zimon.toutoune@gmail.com> a écrit :
>Hi Ludo,
>
>On Tue, 09 Nov 2021 at 17:52, Ludovic Courtès <ludo@gnu.org> wrote:
>> zimoun <zimon.toutoune@gmail.com> skribis:
>
>>> However, as I said elsewhere, this effort should start be collecting
>>> what do we consider as changes requiring formal process?
>>
>> Agreed, that’s what I meant above.
>
>I meant, based on changed already merged.  For instance, on the top of
>my head, some changes that *I* consider requiring a RFC:
>
> - new inputs style
> - guix shell
> - authentication
> - GUIX_EXTENSIONS_PATH (not finished and not documented)
>
>And it would be nice if we could come with a list of such changes.  It
>would help for finding patterns – if they are :-) – for examples,
>numbers of people involved in the discussion, time between each reply,
>structure of the cover letters, etc.
>
>
>> I don’t have an answer, but I think we should look at what others are
>> doing, what criteria they use, etc.  The Nix RFC process is probably the
>> closest match in terms of application domain, but maybe others are
>> closer to the way we practice decision-making in Guix.
>
>Yeah, for sure, several items need definitions. ;-)
>
> - which kind of change requires a RFC?

At the very least those changes we thought were important enough to add them to the news entries.

> - what is the process?
> - how to decide?  Accept or reject?

I think the process could allow for some time to discuss various options and arrive at a concensus. The final implementation might be different from the initial idea.

I suppose this is where we have to look at other project's processes :)

> - who decide?
> - etc.
>
>
>Cheers,
>simon
>

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

[jbranso]

October 27, 2021 5:23 PM, "Ludovic Courtès" <ludo@gnu.org> wrote:

> Hello Guix!
> 
> 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?

I absolutely love the new guix shell! "-ad-hoc" was a bit confusing to
understand.  I know more about guix shell in 5 minutes than I did with
a few years of guix environment!  

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

I'm all for a RFC!  Somehow I missed any communication about this new
guix shell, and I normally follow the mailing lists like a 11th grade
stalker (not that I have any experience with stalking...I can't really
discuss it until the lawsuit is over...).

But then again my comments are perhaps not as weighty as others?  I have
only really been the occasional guix documentation writer.  

> Thoughts? Anyone with experience with such a process?
> 
> Ludo’.

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

[jbranso]

October 27, 2021 6:51 PM, "Katherine Cox-Buday" <cox.katherine.e@gmail.com> wrote:

> Ludovic Courtès <ludo@gnu.org> writes:
> 
>> 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.
> 
> I think it's a good idea. The only contribution I can give is that I would not have known =guix
> shell= was coming had I not been watching the patches list. So in addition to formalizing what
> you've mentioned, I suggest we also formalize a location to watch (guix-devel seems logical?).
 
That's why I didn't see guix shell coming.  I don't follow guix patches...

> --
> Katherine

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

[zimoun]

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

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.

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

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