all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Katherine Cox-Buday <cox.katherine.e@gmail.com>
To: Simon Tournier <zimon.toutoune@gmail.com>,
	Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	Saku Laesvuori <saku@laesvuori.fi>
Cc: Attila Lendvai <attila@lendvai.name>,
	Liliana Marie Prikler <liliana.prikler@gmail.com>,
	Andreas Enge <andreas@enge.fr>,
	"Felix Lechner via Development of GNU Guix and the GNU
	Systemtdistribution." <guix-devel@gnu.org>
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Tue, 5 Sep 2023 20:34:08 -0600	[thread overview]
Message-ID: <c41940ee-5d05-143b-99de-5a54ba935bf2@gmail.com> (raw)
In-Reply-To: <86v8cop6sy.fsf@gmail.com>

On 9/5/23 4:57 PM, Simon Tournier wrote:
> Hi,
>
> On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:
>
>>> Well, somehow, I consider the commit message format similarly as coding
>>> style.  We can discuss which one is better than the other when at the
>>> end it only reflects some artificial preferences and for the sake of any
>>> project one needs to be arbitrarily picked.  Why not ChangeLog?
>> The distinction I draw is that I can usually run a linter against a
>> coding style.
>>
>> I don't care very much what the standard for commit messages is other
>> than if it has an expectation of structure, I be able to run a tool to
>> tell me if it's wrong.
>>
>> In other words, the overhead isn't "I don't like this standard", it's "I
>> can't find a way to reliably adhere to the standard".
> Well, I am not sure to fully understand what you have in mind with the
> term “standard“.

I'm sorry if I've not explained this well, Simon. Thank you for trying 
to understand.

By "standard" I mean the GNU Changelog format 
(https://www.gnu.org/prep/standards/standards.html#Change-Logs). As in: 
it's expected that commit messages use this format.

>    To me, coding style or similarly commit message format
> are about standard or norm, meaning they respect a set of rules.
>
> The question is then: is it possible to explicitly write down all the
> rules?  Are all the rules all well-defined or are some ambiguous?  etc.
>
> For some norm or standard, it is possible to have a checker because all
> the rules are explicitly well-defined.  For many norms/standards, we do
> not have any checker.

This is my point. There is an expectation, but no way to check against 
that expectation, and the expectation is complicated enough that it's 
easy to get wrong. The Changelog format is like a little language with 
conditionals about how "simple" the change is, and line length, and 
blank lines.

In my response I was trying to point out a flaw in your comparison: that 
with style guidelines, which are also complicated, there is usually a 
formatter that will do it for me, or a linter that will tell me that 
something is not meeting the standard. This is because languages have 
grammars, and linters have higher-order system grammars.

> Now, I have read the thread and I hear the comments about the commit
> message format as ChangeLog.  To be honest, I am somehow surprised.  If
> after being enough annoyed by something that then one clones the Guix
> repository, finds how to improve and last drops all because writing the
> commit message is too “complex” or because one does not know if the
> commit message correctly adhere to the standard… Sorry, I do not buy.

I don't think anyone has said this. To be explicit: I am not saying 
this. What my original message said, and what others have said, is that 
in aggregate, the steps to contribute produce enough friction so as to 
keep contributions from being proposed and merged. The commit messages 
are part of that aggregate.

Here are others saying this in this thread:

     - https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00040.html

     - https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00051.html

Here is my channel with things I intend to upstream, but haven't, 
largely because of this friction. It includes services and packages.

https://github.com/kat-co/guix-channels/tree/upstream-staging/upstream

For whatever else has been brought up in this thread, I started with this:

     I have given a list of issues to a group of people who are presumably
     analytical, and I think the natural inclination is to go 
point-by-point and
     make arguments for/against. Instead of that[*], I invite you to 
address the
     more abstract issue: (should/how do) we reduce friction for making
     contributions?

> And I do not buy either an issue when resuming after an interruption
> because writing commit message can be done from the diff.  More than
> often, I tweak stuff, then commit with the oneline subject ’DRAFT foo’,
> continue to tweak, commit ’DRAFT bar’.  Days or weeks (or months) later,
> I resume my work and run “git rebase” for polishing the commit ’DRAFT
> foo’ and preparing it for submission.
>
> Again I hear all the comments and I am trying hard to understand.  From
> my point of view and from where I stand, my understanding is that the
> core point of commit message format is about 1. discipline – the quality
> of being able to behave and work in a controlled way which involves
> obeying particular rules or standards – and 2. confidence – the willing
> to send the perfect message on the first try.  And there is no tool for
> fixing these both issues.

In the US, the phrase "I don't buy it" is usually the response to 
someone trying to trick you into something. This is a little hurtful 
because it's either saying:

"You have an ulterior motive and are trying to trick me into doing 
something."

or

"I don't have the same experience as you, so you must be lying."

The only thing I know to do is to respond with my experiences, and try 
to make plain statements about them. So I'll try and do that again here:

For me at least, the overhead isn't remembering what the commit message 
should contain, it's remembering what the format should be. It's another 
step in a very long list of steps in which I need to open the GNU 
Changelog page side-by-side and try and meet its requirements.

A common argument I'm seeing is: "The committers will fix it for you." 
Well, at some point I want to be a committer, so what then? I'd be happy 
to get second reviews from other committers to make sure the commit 
messages are correct, but it seems like addressing the fact that capable 
people struggle to get this correct is more sensible.

> Yeah, commit messages are boring to write.

At no point have I made this argument. I will use whatever the standard 
is. I'm trying to frame the conversation around how to make it easier to 
follow the standard, not how to get out of following the standard.

> Well, I share various points that had been raised in this thread about
> smoothing the contribution requirements.  However, I am still puzzled by
> the comments about the commit message format.  Again, my inability to
> understand the issue does not mean I am not hearing.

Communication is so hard. My only advice is to remain aware that 
everyone in the world is different, and that even when we don't 
understand something, or don't experience it ourselves, that doesn't 
make it less real, especially if there's a plurality of people agreeing 
with one another. And to always choose kindness.

Here is a great talk by Rich Hickey called "Simple Made Easy". Although 
I recommend watching the entire thing, I'd like to draw your attention 
to a few points:

- Easy is relative: https://youtu.be/SxdOUGdseq4?t=497

- Differentiating the types of complexity (importantly defining 
incidental complexity): https://youtu.be/SxdOUGdseq4?t=1173

The crucial point of this talk for me is when Rich draws an analogy to 
juggling (https://youtu.be/SxdOUGdseq4?t=1353). He poses the question: 
you can juggle a finite number of balls; how many of those do you want 
to be incidental complexity balls vs. problem complexity balls. In the 
Guix world, how many of our balls do we want to be the meta of 
contributing vs. actual code checked into Guix?

> All the rules are not explicitly written, IIRC, so the most reliable way
> to adhere about the standard is probably to internalize these questions:
>
>      What changes affected a particular source file?
>      Was a particular source file renamed or moved, and if so, as part of what change?
>      What changes affected a given function or macro or definition of a data structure?
>      Was a function (or a macro or the definition of a data structure) renamed or moved from another file, and if so, as part of which change?
>      What changes deleted a function (or macro or data structure)?
>      What was the rationale for a given change, and what were its main ideas?
>      Is there any additional information regarding the change, and if so, where can it be found?
>
>      https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs
>
> All in all, my only proposal would to have a Git pre-commit hook or some
> template pasting these questions and recalling the generic ChangeLog
> format, when writing the commit message.  Maybe it would help…

A kind of wizard? I'm not sure if that addresses the overhead or not. 
Maybe that combined with a templating system that everyone can use? I 
don't have a lot of useful suggestions here other than to repeat 
something "(" said:

     I do think that there's a problem if the commit format is so complex that
     it's not trivial for anyone new to the project to write them out manually.

I think it's complex because it's trying to replicate the kinds of things a SCM tool can now track, but in free-form text blocks. I'm sorry I don't have suggestions for this specific thing, other than to drop it.

Above all, thanks for the dialogue.



  reply	other threads:[~2023-09-06  2:34 UTC|newest]

Thread overview: 267+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-23 16:25 How can we decrease the cognitive overhead for contributors? Katherine Cox-Buday
2023-08-23 17:27 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-08-23 18:03   ` Andreas Enge
2023-08-25  8:07     ` Attila Lendvai
2023-08-25  9:16       ` Andreas Enge
2023-08-25  9:57         ` Attila Lendvai
2023-08-25 23:56           ` Katherine Cox-Buday
2023-08-25 14:44       ` Wilko Meyer
2023-08-26 14:37       ` Liliana Marie Prikler
2023-08-27 12:07         ` Attila Lendvai
2023-08-27 13:57           ` Saku Laesvuori
2023-08-27 17:08             ` Liliana Marie Prikler
2023-08-29 10:04               ` MSavoritias
2023-08-29 11:05                 ` Giovanni Biscuolo
2023-09-05 15:33                   ` Simon Tournier
2023-09-05 19:16                     ` Csepp
2023-09-05 20:43                       ` Simon Tournier
2023-08-29  3:00             ` Maxim Cournoyer
2023-09-05 16:01               ` Simon Tournier
2023-09-05 17:01                 ` Katherine Cox-Buday
2023-09-05 18:18                   ` Liliana Marie Prikler
2023-09-05 18:40                     ` (
2023-09-05 20:43                       ` Liliana Marie Prikler
2023-09-05 22:04                         ` wolf
2023-09-06 18:42                           ` Liliana Marie Prikler
2023-09-08 15:39                             ` Ricardo Wurmus
2023-09-08 22:56                               ` Liliana Marie Prikler
2023-09-06  9:41                         ` Josselin Poiret
2023-09-08 14:20                           ` Ricardo Wurmus
2023-09-10  9:35                             ` Efraim Flashner
2023-09-11 10:34                               ` Giovanni Biscuolo
2023-09-06 20:10                         ` Wojtek Kosior via Development of GNU Guix and the GNU System distribution.
2023-09-17  8:01                           ` MSavoritias
2023-09-07 20:38                         ` Katherine Cox-Buday
2023-09-07 20:52                           ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-09-17  8:07                           ` MSavoritias
2023-09-05 23:41                       ` brian via Development of GNU Guix and the GNU System distribution.
2023-09-06 16:53                         ` Liliana Marie Prikler
2023-09-06 17:52                           ` Vagrant Cascadian
2023-09-06 18:27                             ` Maxim Cournoyer
2023-09-06 18:49                               ` Christopher Baines
2023-09-08  9:16                               ` Giovanni Biscuolo
2023-09-08 16:56                                 ` Liliana Marie Prikler
2023-09-06 19:11                             ` Liliana Marie Prikler
2023-09-05 22:57                   ` Simon Tournier
2023-09-06  2:34                     ` Katherine Cox-Buday [this message]
2023-09-06  9:07                       ` Simon Tournier
2023-09-07 20:39                         ` Katherine Cox-Buday
2023-09-09 12:32                           ` Simon Tournier
2023-09-11 12:19                             ` Giovanni Biscuolo
2023-09-12 15:35                               ` Katherine Cox-Buday
2023-09-12 15:35                                 ` Katherine Cox-Buday
2023-09-09 17:14                           ` Liliana Marie Prikler
2023-09-11 12:37                             ` Giovanni Biscuolo
2023-09-11 21:25                               ` Csepp
2023-09-12  9:09                                 ` Giovanni Biscuolo
2023-09-12 11:09                                   ` Csepp
2023-09-12 14:51                                     ` Maxim Cournoyer
2023-09-17 12:39                                       ` MSavoritias
2023-09-08 10:25                         ` Giovanni Biscuolo
2023-09-06 19:01                       ` Liliana Marie Prikler
2023-09-08  9:53                       ` Giovanni Biscuolo
2023-09-08 11:28                         ` Ricardo Wurmus
2023-09-08 12:40                           ` Giovanni Biscuolo
2023-09-12 16:05                             ` Katherine Cox-Buday
2023-09-12 16:05                               ` Katherine Cox-Buday
2023-09-13  7:57                               ` Simon Tournier
2023-09-13  9:28                                 ` Simon Tournier
2023-09-12 16:08                           ` Katherine Cox-Buday
2023-09-12 16:08                             ` Katherine Cox-Buday
2023-09-08 12:09                         ` Efraim Flashner
2023-09-08 16:54                           ` Giovanni Biscuolo
2023-09-06  2:49                   ` Maxim Cournoyer
2023-09-06 22:16                     ` kiasoc5
2023-09-08 15:27               ` Ricardo Wurmus
2023-09-08 19:22                 ` Liliana Marie Prikler
2023-09-08 20:37                   ` Ricardo Wurmus
2023-09-12 16:18                     ` Katherine Cox-Buday
2023-09-12 16:18                       ` Katherine Cox-Buday
2023-09-09 10:01                 ` Simon Tournier
2023-09-09 19:45                   ` Ricardo Wurmus
2023-08-28  8:15         ` Giovanni Biscuolo
2023-08-28 17:00           ` Liliana Marie Prikler
2023-08-30  7:37             ` Giovanni Biscuolo
2023-08-29  9:29         ` MSavoritias
2023-08-29 19:29           ` Liliana Marie Prikler
2023-09-08 14:44         ` Ricardo Wurmus
2023-09-08 18:50           ` Liliana Marie Prikler
2023-09-08 20:24             ` Ricardo Wurmus
2023-09-08 23:26               ` Liliana Marie Prikler
2023-09-09 19:40                 ` Ricardo Wurmus
2023-09-09 22:20                   ` Liliana Marie Prikler
2023-09-11 10:36                     ` Simon Tournier
2023-09-11 17:53                       ` Liliana Marie Prikler
2023-09-11 18:50                         ` Simon Tournier
2023-09-12 14:42                           ` Maxim Cournoyer
2023-09-12 16:57                             ` Simon Tournier
2023-09-13 15:31                               ` to PR or not to PR, is /that/ the question? Giovanni Biscuolo
2023-09-13 22:02                                 ` Simon Tournier
2023-09-14  6:53                                   ` Giovanni Biscuolo
2023-09-14  7:30                                     ` Simon Tournier
2023-09-17 16:20                     ` How can we decrease the cognitive overhead for contributors? MSavoritias
2023-09-17 16:35                       ` Liliana Marie Prikler
2023-09-18  9:37                       ` Simon Tournier
2023-09-18 16:35                         ` MSavoritias
2023-09-18 17:13                           ` Simon Tournier
2023-09-18 17:39                             ` MSavoritias
2023-09-18 19:20                               ` Simon Tournier
2023-09-18 20:28                                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-09-18 19:47                               ` Liliana Marie Prikler
2023-09-17 15:50             ` MSavoritias
2023-08-25 23:48     ` Katherine Cox-Buday
2023-08-27  8:35       ` Josselin Poiret
2023-08-25 23:31   ` Katherine Cox-Buday
2023-08-23 20:48 ` Liliana Marie Prikler
2023-08-25  9:03   ` Attila Lendvai
2023-08-27  3:27     ` Maxim Cournoyer
2023-09-02 22:11       ` Ricardo Wurmus
2023-09-03  1:05         ` Vagrant Cascadian
2023-09-04  8:56           ` Ricardo Wurmus
2023-09-04 15:10             ` Efraim Flashner
2023-09-05  2:18             ` Maxim Cournoyer
2023-09-05  7:21               ` Replacing Mumi+Debbugs? Ricardo Wurmus
2023-09-05 13:12               ` How can we decrease the cognitive overhead for contributors? Csepp
2023-09-05 20:30                 ` Wilko Meyer
2023-08-23 22:04 ` Ricardo Wurmus
2023-08-23 22:37   ` Jack Hill
2023-08-24  0:18 ` Csepp
2023-08-25  0:10   ` Ekaitz Zarraga
2023-08-26  0:16     ` Katherine Cox-Buday
2023-08-28 21:46     ` paul
2023-08-26  0:06   ` Katherine Cox-Buday
2023-08-27  3:00     ` Maxim Cournoyer
2023-08-27  8:37       ` Josselin Poiret
2023-08-28  9:44         ` Giovanni Biscuolo
2023-08-27  2:50   ` Maxim Cournoyer
2023-08-29 22:40     ` Csepp
2023-08-30  2:46       ` Maxim Cournoyer
2023-08-28  8:52   ` Simon Tournier
2023-08-24  3:33 ` Ahmed Khanzada via Development of GNU Guix and the GNU System distribution.
2023-08-26  0:25   ` Katherine Cox-Buday
2023-08-24  6:33 ` (
2023-08-26  0:39   ` Katherine Cox-Buday
2023-08-27  3:22     ` Maxim Cournoyer
2023-08-27  7:39       ` 宋文武
2023-08-28 11:42         ` Giovanni Biscuolo
2023-09-01 19:12           ` Imran Iqbal
2023-09-03 17:45             ` Ekaitz Zarraga
2023-09-03 21:05               ` indieterminacy
2023-09-03 21:16                 ` Ekaitz Zarraga
2023-09-13 12:20                   ` Fannys
2023-09-13 15:42                     ` Maxim Cournoyer
2023-09-13 23:13                       ` Ekaitz Zarraga
2023-09-17 11:29                       ` MSavoritias
2023-09-18 10:09                         ` Simon Tournier
2023-09-19 10:33                           ` contribute with content in our official help pages? Giovanni Biscuolo
2023-09-19 16:35                           ` The elephant in the room and the Guix Bang Giovanni Biscuolo
2023-09-19 20:41                             ` Simon Tournier
2023-09-20 20:52                               ` Giovanni Biscuolo
2023-09-20  8:21                             ` Csepp
2023-09-20  8:45                               ` The e(macs)lephant " Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.
2023-09-20  9:28                                 ` MSavoritias
2023-09-20 14:03                                   ` Ricardo Wurmus
2023-09-20 14:09                                     ` MSavoritias
2023-09-14  8:24                     ` How can we decrease the cognitive overhead for contributors? Ricardo Wurmus
2023-09-18 16:40                       ` MSavoritias
2023-09-14 17:49                     ` Sarthak Shah
2023-09-15 10:18                       ` Simon Tournier
2023-09-13 12:25                   ` MSavoritias
2023-09-22 15:14               ` Imran Iqbal
2023-09-22 15:30                 ` Katherine Cox-Buday
2023-09-22 16:17                 ` Ekaitz Zarraga
2023-09-22 16:35                 ` MSavoritias
2023-09-22 17:28                   ` Ekaitz Zarraga
2023-09-25 15:13                     ` Enabling contribution through documentation Samuel Christie via Development of GNU Guix and the GNU System distribution.
2023-10-16 20:18                       ` Matt
2023-11-06 22:43                         ` Samuel Christie via Development of GNU Guix and the GNU System distribution.
2023-11-11  1:14                           ` Matt
2023-08-28  6:12     ` How can we decrease the cognitive overhead for contributors? (
2023-08-28  9:14     ` Simon Tournier
2023-08-29  9:53       ` MSavoritias
2023-09-05  7:54         ` Simon Tournier
2023-09-13 12:59           ` MSavoritias
2023-09-14  8:18             ` Ricardo Wurmus
2023-08-26 17:40   ` kiasoc5
2023-08-24  9:06 ` Wilko Meyer
2023-08-25  9:31   ` Attila Lendvai
2023-08-26 17:42     ` kiasoc5
2023-08-26 18:53       ` Liliana Marie Prikler
2023-08-26 21:35         ` Attila Lendvai
2023-08-27  8:26       ` Non-committer comments on patches Andreas Enge
2023-08-28  6:17       ` How can we decrease the cognitive overhead for contributors? (
2023-08-28 10:01       ` Simon Tournier
2023-08-28  9:26     ` Simon Tournier
2023-08-24 18:53 ` Simon Tournier
2023-08-26  1:02   ` Katherine Cox-Buday
2023-08-28 10:17     ` Simon Tournier
2023-08-30 16:11       ` Katherine Cox-Buday
2023-08-30 16:53         ` Andreas Enge
2023-08-30 19:02         ` MSavoritias
2023-09-02 11:16         ` Giovanni Biscuolo
2023-09-02 13:48           ` paul
2023-09-02 19:08             ` Csepp
2023-09-02 20:23               ` wolf
2023-09-02 23:08                 ` Csepp
2023-09-04 10:23               ` Attila Lendvai
2023-09-04 12:44                 ` brian via Development of GNU Guix and the GNU System distribution.
2023-09-04 14:35                   ` Attila Lendvai
2023-09-04 18:13                   ` Andreas Enge
2023-09-05  9:58                     ` pinoaffe
2023-09-05 14:22                       ` brian via Development of GNU Guix and the GNU System distribution.
2023-09-05 15:25                         ` Maxim Cournoyer
2023-09-05 13:19                     ` Csepp
2023-09-05 15:30                       ` Maxim Cournoyer
2023-09-05 19:08                         ` Csepp
2023-09-06 12:14                         ` Attila Lendvai
2023-09-06 12:56                           ` Ekaitz Zarraga
2023-09-06 16:03                           ` Maxim Cournoyer
2023-09-04 19:16                   ` phil
2023-09-04 18:22                 ` Andreas Enge
2023-09-02 16:08           ` Csepp
2023-09-02 18:27             ` Mumi search broken? (was: Re: How can we decrease the cognitive overhead for contributors?) Liliana Marie Prikler
2023-09-03  7:36             ` How can we decrease the cognitive overhead for contributors? Ricardo Wurmus
2023-09-03  8:53               ` paul
2023-09-03 10:31                 ` Ricardo Wurmus
2023-09-03 14:53                   ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-09-04  9:40                     ` Giovanni Biscuolo
2023-09-03 18:18                   ` Csepp
2023-09-03 20:32                     ` Ricardo Wurmus
2023-09-05  8:43                   ` Simon Tournier
2023-09-05 18:04               ` Katherine Cox-Buday
2023-09-05 19:15           ` Katherine Cox-Buday
2023-09-13 13:24           ` MSavoritias
2023-09-05  1:32         ` Maxim Cournoyer
2023-09-05 17:19           ` Katherine Cox-Buday
2023-09-05 14:01         ` Simon Tournier
2023-09-05 18:00           ` Katherine Cox-Buday
2023-09-05 20:39             ` Guix User Survey? Wilko Meyer
2023-09-05 23:55             ` How can we decrease the cognitive overhead for contributors? Simon Tournier
2023-09-06  2:58               ` Katherine Cox-Buday
2023-09-06  9:34                 ` Next action, survey? Simon Tournier
2023-09-07 20:39                   ` Katherine Cox-Buday
2023-09-08  6:31               ` How can we decrease the cognitive overhead for contributors? (
2023-09-05 22:11           ` wolf
2023-09-05 23:02             ` Simon Tournier
2023-09-13 13:59           ` MSavoritias
2023-08-28 21:41 ` paul
2023-08-29  8:32   ` Giovanni Biscuolo
2023-08-29  9:31   ` Giovanni Biscuolo
2023-08-29 11:28     ` git interfaces (was Re: How can we decrease the cognitive overhead for contributors?) Giovanni Biscuolo
2023-08-29 23:11     ` How can we decrease the cognitive overhead for contributors? Csepp
2023-08-30  8:39     ` Attila Lendvai
2023-08-30  9:33       ` Andreas Enge
2023-08-30  0:22 ` Danny Milosavljevic
2023-08-30  9:41   ` Andreas Enge
2023-08-30 12:33     ` commit message helpers (was Re: How can we decrease the cognitive overhead for contributors?) Giovanni Biscuolo
2023-09-04 13:36   ` How can we decrease the cognitive overhead for contributors? Ricardo Wurmus
2023-09-05  3:25     ` Maxim Cournoyer
2023-09-05  7:48       ` Ricardo Wurmus
2023-09-04 11:09 ` David Larsson
2023-09-04 22:06 ` Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?) Arun Isaac
2023-09-05  8:58   ` Debbugs CLI client (was Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?))) Simon Tournier
2023-09-05 10:37   ` Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?) Giovanni Biscuolo
2023-09-08 16:49     ` Ricardo Wurmus
2023-09-12 14:55       ` Giovanni Biscuolo
2023-09-13  8:52         ` Ricardo Wurmus
2023-09-13 10:26           ` Commenting bug reports via mumi web interface " Giovanni Biscuolo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c41940ee-5d05-143b-99de-5a54ba935bf2@gmail.com \
    --to=cox.katherine.e@gmail.com \
    --cc=andreas@enge.fr \
    --cc=attila@lendvai.name \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=maxim.cournoyer@gmail.com \
    --cc=saku@laesvuori.fi \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.