> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
>     ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

This feature would be very welcome. Perhaps we need an emacs interface
to mumi just as debbugs has an emacs interface. We could implement this
emacs interface by first implementing a HTTP API for mumi and then
making emacs interact with that HTTP API. But, I think it would be
better to simply run mumi locally. That is, we first pull all the latest
bug reports using something like `mumi pull` and then operate on the
local copy of bug reports. WDYT?

Also, the "download" link in mumi doesn't correctly download the patch
when the patch is sent using `git send-email`. This is because it
truncates the headers of the email that is required by `git am` to
correctly apply the patch. For example, see the second email in
https://issues.guix.info/issue/34948 Due to this bug, I often find
myself having to fall back to the debbugs web interface.

> I would also like to see neglected issues in the web interface

It would be nice to have the "Recent activity" and "Priority bugs" lists
on the home page load without javascript.

> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

I agree completely.