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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Vagrant Cascadian <vagrant@debian.org> writes:
>
>> The only thing clunky about this particular aspect of the workflow
>> described is the fact that the guix community (maintainers?) have
>> decided on a one patch per mail policy with a cover letter, rather than
>> submitting the patches as attachments in the initial mail.
>
> You are right.  When I started contributing I actually did attach all
> patches in one email.  I wonder why we stopped doing that.

It's still allowed as far as I know.  But due to missing out on
notifying team members automatically (handled by 'git send-email') and
sometimes causing issues for reviewers to apply patches, it's
understandable that 'git send-email' is the most recommended option.

> I’ll say that many of my gripes with (the GNU instance of) Debbugs are
> due to the fact that we can’t customize it to better suit our needs — it
> is a shared resource with a complicated maintenance story.  So all
> changes went into Mumi as crude workarounds.  I think this is a dead end
> and we’d be better off leaving the shared GNU instance of Debbugs
> behind.

I'd be sad to loose at least two good things from Debbugs:

1. It's hosted by the GNU/FSF for us.  It always work, and the rare
times it doesn't, the folks in #savannah are hard at work resolving the
problems. While hosting sourcehut is probably not too difficult, keeping
it up to date (Go...) and running would be yet another weigh on our
meager sysadmin team.

2. Integration with Emacs.  emacs-debbugs is useful.  I think it's the
only successful thing we have at keeping track of old tickets and
resuming discussion or acting on these.

I like how clean Mumi looks, compared to most forge issue trackers.  I'm
not convinced by its search results (perhaps I'd need to get to know
what Xapian is).

-- 
Thanks,
Maxim