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

[Ricardo Wurmus]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> In the simplest case, it can be as simple as:
>
> $ ./pre-inst-env guix refresh -u some-package
> [build it, try it, fix if needed]
> $ ./etc/committer.scm
> $ git send-email
>
> Since it's a single patch, there's no jumping through hoops to create
> the original issue, and the auto-configured git will CC teams people
> subscribed to the scope of your change (if there are any).

Sadly the not-so-simple case is much more annoying.

I like an email-based workflow, don’t get me wrong.  At the same time
I’m really not a fan of Debbugs.  It makes simple things more difficult
than they should be (send a cover letter, wait for your mail to pass the
anti-spam measures, remember that you wanted to send a couple of
patches, etc), and no amount of sugar coating (whether that be a
different frontend like Mumi or a hell of a lot of client-side
scripting) can overcome this inherent clunkiness.

I’m no stranger to clunky or quirky interfaces.  I put up with them
because they unlock workflows and features or flexibility that would
otherwise be unattainable.  Emacs and Guix are great examples of quirky
interfaces that brim with flexibility.  I just think that Debbugs
doesn’t make the cut.

If only we can find a suitable baby sieve, I’d be happy to see the
turbid bathwater drained.  If Mumi and Debbugs went down the drain to
reveal a new hassle-free web/email hybrid patch workflow I’d be
ecstatic.

-- 
Ricardo