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

[Andreas Enge <andreas@enge.fr>]

Hello,

just a quick reply with what I do personally as one irrelevant data point :)

Am Fri, Aug 25, 2023 at 08:07:53AM +0000 schrieb Attila Lendvai:
> i couldn't even find out which tools are used by those who are comfortable with the email based workflow. i looked around once, even in the manual, but maybe i should look again.

No tools at all, I would say, which indeed may be a bit inefficient...
Or: terminal, mutt, vim, git
A bit of web for browsing the manuals (of Guix and Guile)
and issues.guix.gnu.org
But then I type much faster than I click.

> i'm pretty sure most maintainers have a setup where the emailed patches can be applied to a new branch with a single press of a button, otherwise it'd be hell of a time-waster.

mutt
save message to /tmp/x
git am /tmp/x
or something like this

or:
git clone https://git.guix-patches.cbaines.net/guix-patches/
git checkout issue-xxxxx
git format-patch ...
then in the development checkout of Guix:
git am ...; make; ./pre-inst-env guix build

> one fundamental issue with the email based workflow is that its underlying data model simply does not formally encode enough information to be able to implement a slick workflow and frontend. e.g. with a PR based model the obsolete versions of a PR is hidden until needed (rarely). the email based model is just a flat list of messages that includes all the past mistakes, and the by now irrelevant versions.

For this, I either go to issues.guix.gnu.org to download the newest patches,
in case the message is not in my inbox.
Otherwise I do not get your point: I keep untreated messages with the latest
patch version in my Guix inbox, and file away the others in a separate mbox.
So things are not flat, but have two levels: "to be treated" or "done".

Nothing to be documented, really, and I do not know whether these are just
personal habits or whether others work similarly. These might be the ways
of an aging non-emacs hacker...

> https://sourcehut.org/

This comes up a lot in the discussion and looks like an interesting
solution. It would be nice to be able to accomodate diverse styles
of working on Guix beyond (but including) emacs and vim.

Andreas