From: MSavoritias <email@msavoritias.me>
To: Katherine Cox-Buday <cox.katherine.e@gmail.com>
Cc: Simon Tournier <zimon.toutoune@gmail.com>, guix-devel@gnu.org
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Wed, 30 Aug 2023 22:02:41 +0300 [thread overview]
Message-ID: <87zg28l57d.fsf@fannys.me> (raw)
In-Reply-To: <e47299e8-43f8-aac8-61ba-420daeb88bdd@gmail.com>
Yep completely agree with all of this.
Personally I dont think its necessery to move to sourcehut but from the
discussions I saw debbugs does seem to become a burden the more time
passes on.
One of the weirdest things for me in guix is how its based on scheme
which is designed to be hacked in place and instead we have so many
complicated steps to do it.
A much more logical thing as bare minimmum is like you said: Have it as
a subcommand in guix. The first thing i tried to do to contribute
personally was to just do a 'guix edit' and edit the package but turns
out not only i cant do it as easy as that but I also need to clone a
repo and run multiple scripts inside a container(?). We should work on
moving as close to a 'guix edit' and 'mumi push' contribution as
possible.
MSavoritias
Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
> Summary of my conclusions:
>
> 1. We should use sourcehut or continue to improve mumi
> - QA status should be visable from a patch's page
> - It should be possible to interact with the issue through the page
>
> 2. We should create scripts/sub-commands to lift contribution
> activities into
> higher-order concepts:
> - Prepare a new submission
> - Run pre-checks on a submission
> - Submit a patch
> - Status of patch
>
> 3. We should reify a way for Guix, the project, to measure, and track
> progress,
> against long-term goals. Particularly when they're social and not
> strictly
> technical.
>
> On 8/28/23 4:17 AM, Simon Tournier wrote:
>> Hi Katherine,
>>
>> On Fri, 25 Aug 2023 at 19:02, Katherine Cox-Buday
> <cox.katherine.e@gmail.com> wrote:
>>
>>> I think there's utility in distinguishing between familiarity and
>>> eliminating toil. I think it was incorrect of me to suggest forming
>>> habits in my original message. I think it's better to focus on
>>> eliminating toil so that whatever workflow remains can more easily be
>>> habituated.
>>
>> Since I am French, I am good as moaner and I would like to avoid the
>> ramblings of some grumble party. :-)
>>
>> I agree with you that it is important to reflect ourselves about our
>> practises and we need to be critical about what does not suit us.
>>
>> In order to be pragmatical and list actionable items, could you
>> specifically list what you consider as a toil or cognitive overhead?
>> Maybe you could share your script helping you.
>
> Yes, great point! Let's try to distill all this conversation down into the
> salient points and see if we can't agree on some actionable items.
>
> Here's my understanding of the process to contribute a patch:
>
> 1. Check out main, and run `./bootstrap`, then `./configure
> --localstatedir=/var --sysconfdir=/etc`
> 2. Run `make`
> 3. You need to determine whether the change can be targeted against
> main or
> needs to target a feature branch, so you go read about that.
>
> [I'm usually starting here]
>
> 4. Run `./pre-inst-env guix refresh --list-dependent <package>`
> 5. Create a git worktree for your patch
> 6. Run `./bootstrap`, then `./configure --localstatedir=/var
> --sysconfdir=/etc`
> 7. Run `make`
> 8. Make your changes
> 9. Build to ensure your changes are workable.
> 10. Try and determine how your changes should be factored into individual
> commits (sometimes it's not always so clear when changing two
> things might
> need to be done atomically).
> 11. Try and get each commit message close to correct and commit.
> 12. Run `guix lint`
> 13. Run `guix style` (this is still in the manual although I have since
> learned this is not actually advisable).
> 14. Review the changes these tools have made, and fix things.
> 15. Run `guix build --rounds=2 <package>` to check for idempotency.
> 16. Run `make` to ensure you didn't break anything elsewhere in Guix.
> 17. Run `guix size` to ensure the closure isn't becoming bloated.
> 18. Build all the packages that depend on this package.
> 19. Run `guix pull --url=/path/to/your/checkout
> --profile=/tmp/guix.master` to
> ensure you didn't break Guix in a different way.
> 20. Run `git format-patch -1 --cover-letter [--reroll-count]`
> 21. Run `./pre-inst-env ./etc/teams.scm cc-members <patch>` to get
> the CC flags for Git
> 22. Remember that if you're sending multiple patches, an email first
> has to be
> sent to `guix-patches@gnu.org` to get an ID, and then...
> 23. Run `git send-email --to guix-patches <patches> <CC flags>`
>
> I view steps 1-10 as pretty standard "development" steps common to most
> projects, although 11 compounds the effort in 10.
>
> In other projects I've worked with, steps 12-19 are commonly done in a CI
> pipeline, and courteous people will try to save CI resources by
> running these
> steps locally first using some kind of environment identical to what CI runs
> (sometimes a container is used for this. I think Guix has better options!).
> Sometimes this is not feasible due to asymmetric resources. But having the
> option to let CI manage this process is very nice.
>
> For me, steps 20-23 are bothersome. There's a lot of "if" statements
> that lead
> to branching operations, and a lot of commands and flags to get
> right. The extra
> step to get a debbugs ID is annoying.
>
> If I compare this workflow to the workflow of other contributions I make:
>
> 1-10 as usual
> 11. Write a more commonly accepted commit message with no special
> formatting.
> 12. Run `git push` (subsequent changes are still just `git push`).
> 13. Go to forge website, click button to open a pull-request.
> 14. Wait for CI to tell you if anything is wrong.
>
> So now that I've enumerated the steps, compared them to contributing
> to projects
> I don't find difficult, and reflected on the difference for awhile, I
> think, at
> least for me, the highest friction comes from:
>
> - Steps 11-19, or (to assign it a name for easier reference) the "CI steps".
>
> As I understand it, we're continuing to make progress in having a nice CI
> pipeline (i.e. https://qa.guix.gnu.org), so maybe I need to read
> more about
> that. If we wanted to encourage contributors to run "CI steps"
> locally before
> submitting, maybe this should be another `guix` sub-command? `guix
> pre-check`
> or something? I know there is a potential contributor who had this
> idea first
> who would want to hack on this.
>
> - Steps 19-23, or the "manage patch" steps.
>
> I think an insight here is that the big button on forges is actually
> a program
> removing the mental overhead for you. It (1) notices you've pushed a
> branch
> when you visit the website and suggests opening a PR with a
> link. (2) Submits
> the PR with appropriate settings (3) Recommends reviewers which you
> can add
> after the fact.
>
> Also, this workflow doesn't change whether you have one commit or
> two in your
> branch, and it doesn't doesn't change when you need to submit
> follow-ups (e.g.
> changing flags on `git format-patch`).
>
> I also don't usually have to worry nearly as much about crafting a commit
> message. So long as the title is under a character limit, and the body is
> helpful, it's OK. I think what bothers me most about the GNU changelog
> messages is that it's the worst of both spoken language and programming
> languages: there's an expectation of structure, but no grammar I can
> parse
> against, and it's free-form.
>
> I would probably have to learn more about it before making this
> assertion, but
> it also seems like any information it provides can be fetched from
> git. And
> when it comes to the steps to contributing, the answer is "memorize these
> flags", but when it comes to retrieving this information, the answer
> is "this
> is easier". I'm not sure about this is a fair comparison, but it might be
> something to collectively reflect on.
>
> - Having multiple places to manage aspects of my patch
>
> In a web-forge, I generally have a URL I can go to and see
> everything about my
> patch. I think we have that with https://issues.guix.gnu.org with two
> exceptions: (1) QA is a click away, or if you're using email, you're
> not even
> aware that there's a QA process failing (2) If you're not using email,
> context-switching between this page and email to respond.
>
>> It could be a starting point for something going to etc/ similarly as
>> etc/committer.scm or etc/teams.scm. Well, etc/guix-install.sh somehow
>> started as a script for eliminating toil – it looks similar as the
>> situation: all the steps are described in the manual but they are too
>> many effort for installing and most newcomer were dropping before
>> completing.
>
> Yeah, after sitting with this a bit, I think this, or new Guix
> sub-commands, is
> probably a good path forward. The way I'm thinking about this is that
> we need to
> lift the individual steps into higher-order activities and have the
> higher-order
> activities encapsulate flags and whatnot.
>
> Thinking about all of this, I am reminded of this[1] picture. If we
> want more
> contributions to Guix, we have to do better at providing equitable
> ways to work.
> Focusing on this benefits everyone because it makes contributing easier for
> everyone.
>
> If you're so inclined, for a bit of fun, and as a crude way of simulating
> compromised executive functioning, imagine that between each of the
> steps above,
> a year passes. And reflect on what it would be like to gather the energy to
> start the process of starting a contribution of some kind, let alone
> follow it
> through to completion.
>
> And finally, I'm wondering how Guix, the project, tracks metrics on
> these kinds
> of things? If we wanted to make contributing easier, that's something
> we have to
> create a metric for and track over time. Is there a precedent for this
> in Guix?
>
> [1]
> https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.lrhsd.org%2Fcms%2Flib%2FNJ01000316%2FCentricity%2FDomain%2F1239%2FEquity%2520graphic.jpg&f=1&nofb=1&ipt=507d2c18cd2643bcb9ba2a67a13dc86d1926301212aaf04bcefc3d17571f982e&ipo=images
next prev parent reply other threads:[~2023-08-30 19:07 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
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 [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zg28l57d.fsf@fannys.me \
--to=email@msavoritias.me \
--cc=cox.katherine.e@gmail.com \
--cc=guix-devel@gnu.org \
--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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).