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

[Attila Lendvai]

> To second this, I'd like to note for the record that on fedi at least
> 1-2 people told me that they chose Nix over Guix because they don't want
> to deal with the email based workflow. At least one of these people is
> a highly skilled programmer with decades of experience.


FWIW,

i'm 46, programming since my childhood. i have 10+ years of Common Lisp 
experience using Emacs, most of it on opensource projects.

here's an approximate list of what's consuming/training my 
frustration-tolerance with Guix:

 - debbugs and related tooling. i could live with an email based
   workflow, but whatever is documented, or at least whatever i have
   put together locally, is very inefficient. the chore vs. coding
   ratio is low.

 - large backlog. contributions somtimes even fall through the cracks.

 - strict adherence to changelog style commit messages without a
   clearly worded and documented argument about why it's worth the
   effort in 2023. whenever 'C' fails to add an entry to the commit
   message in Emacs, i groan out loud.

i came to Guix from a couple of years of NixOS (also contributing), being 
frustrated by the way they use Nix, the language, to describe OS services. it 
felt an uphill battle for no good reason that Guix liberated. Guix has much 
more flexibility and common sense in the coding domain (that compensates for 
the increased frustration in the social domain).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Toxic people will not be changed by the alchemy of your kindness. Yes, be 
kind, but move on swiftly and let life be their educator.”
        — Brendon Burchard