[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How can we decrease the cognitive overhead for contributors?
From: |
( |
Subject: |
Re: How can we decrease the cognitive overhead for contributors? |
Date: |
Mon, 28 Aug 2023 07:12:24 +0100 |
Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>> - Sending the emails: This isn't that bad once you get used to it;
>> sadly most Git clients (magit sadly included) don't support send-email
>> well or at all. But on the command line, all you need to do is:
>> # for a single commit
>> $ git send-email --to=guix-patches@gnu.org -1 --base=master -a
>> # for several commits
>> $ git send-email --to=guix-patches@gnu.org -$N_COMMITS --base=master
>> --cover-letter -a
>> Or, if sending an amended series:
>> $ git send-email --to=$BUG_NUM@debbugs.gnu.org -$N_COMMITS --base=master
>> -a -v$VERSION
>
> It's this. Having to:
>
> 1. Remember the flags and their values
> 2. Remember the email address (it might seem silly unless you have forms of
> dyslexia. is it guix-patches? or patches-guix? Wait, what was I doing?)
> 3. And then the whole deal with what to do with follow ups.
>
> I feel like I know my way around git pretty well, but I struggle with how
> those
> concepts map onto sending emails.
>
> I have only been able to surmount this by lifting these concepts through
> scripts
> into higher-order concepts with less cognitive overhead.
Ah, okay. This might be solvable with the `mumi` command...
>> - Switching between branches: The best way to handle this is with
>> subtrees; see `git subtree --help`.
>
> Interesting! I use worktrees, but maybe subtrees are easier? I'll have to read
> up on this. Thank you!
Oops, sorry, I did mean worktrees :) I ran 'git subtree --help'
forgetting that it's actually 'git worktree', but it turns out subtrees
are a thing too; so I saw that the command worked and assumed I'd got
the correct name for the command...
>
>> - Applying patches: This is a bit annoying. Most email clients won't
>> let you set up commands to pipe mailboxes to, unlike aerc. Perhaps we
>> could have a `mumi apply` command to fetch a patch series from debbugs
>> and apply it to the checkout.
>
> I wrote some elisp to one-key apply patches from GNUS, but I guess my point
> is:
> not everyone can do that. How are we to expect more contributors if that, or
> something similar, is the barrier to entry?
That's very true.
I think possibly the best way to deal with this would be to invest
effort in improving `mumi`, with a `mumi apply` and better
`mumi send-email` functionality.
-- (
- Re: How can we decrease the cognitive overhead for contributors?, (continued)
- Re: How can we decrease the cognitive overhead for contributors?, Ricardo Wurmus, 2023/08/23
- Re: How can we decrease the cognitive overhead for contributors?, Ahmed Khanzada, 2023/08/23
- Re: How can we decrease the cognitive overhead for contributors?, (, 2023/08/24
- Re: How can we decrease the cognitive overhead for contributors?,
( <=
- Re: How can we decrease the cognitive overhead for contributors?, Simon Tournier, 2023/08/28
- Re: How can we decrease the cognitive overhead for contributors?, MSavoritias, 2023/08/29
Re: How can we decrease the cognitive overhead for contributors?, kiasoc5, 2023/08/26
Re: How can we decrease the cognitive overhead for contributors?, Wilko Meyer, 2023/08/24