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

[David Larsson]

On Wed, 23 Aug 2023 10:25:58 -0600
Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

> Summary: for people who don't contribute to Guix a lot, each 
> contribution has
> very high cognitive overhead. Can we work to reduce that?

[..]
 
> * Encourage upstream communities like "Guix 'R Us" 
> (https://sr.ht/~whereiseveryone/guixrus/)
> 
>      Maybe Guix proper continues as is and we foster various upstream 
> communities
>      that utilize different styles and batch their contributions?
> 
> What do you all think? Does this affect anyone else?
> 

It affects me too.

I somewhat frequently end up fixing a broken package I use, adding a
package or package varieties in my private channel (or just locally
and installing with guix package -f <mypkg>), without contributing it to
guix. Sometimes I see someone else eventually contributing a package
I've also packaged which is ofc. wasteful dual effort. It's hard to find
the time to make it nice enough, walk through the steps and submit a
patch for it.


I think Guix 'R Us is a great initiative, and to me anything that's
"pre-release" with lesser standards sounds like a good idea, a place
more experienced Guixer's and committers can pick new packages from and
modify to suit the high standards of guix proper. It's also obvious that
"pre-release" has lesser promises. An official pre-release
channel wouldn't only be able to accept more patches, but can probably
make Guix master less prone to broken builds or packages that are
broken at runtime, and also perhaps fix broken packages faster (like
remote-viewer was broken for months, maybe still is) - easy to fix,
harder to bother walking through the patch submission process to do it
(for the less experienced). A barrier, albeit small, on that front is
that I have issues with package inherits and applying raw patches in a
separate guix channel, which might be a general problem not just me not
knowing how to do it.


For overhead issue with git messages, maybe the Guix manual could
suggest a few tools that are good at assisting with this. emacs-magit
is probably a class of it's own, but there's also vimagit and other GUI
based ones, that helps with rewriting git history and selecting even
specific lines - not just hunks - to add to a patch. Some end to end
contribution workflow example blog posts could help perhaps, if someone
feels up to it?


Best regards,
David