Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 8/24/23 12:33 AM, ( wrote:

> > * We could support a managed web-based workflow
>
> The problem with this is that it would not be possible without changing
> the git hosting entirely to something like Gitea.  I'm personally a fan
> of the email-based workflow; what, specifically, is it that bothers you
> about it?  If it's:

I can envision some kind of upstream branch that's blessed and merged 
daily. The web crowd commits to that, the email crowd commits to main.

> - Setting it up: Yes, this is annoying.  Sadly, our mighty oligarchal
>    masters have taken it upon themselves to make it as annoying as
>    possible to use email from anywhere but their web or mobile clients.

This isn't it at all, but I agree with your comment. I'm fond of email, 
and it's distressing how centralized it's become.

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

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

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

--
Katherine