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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Freitag, dem 25.08.2023 um 08:07 +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.
Users who have tried curlbash also looked at
  wget https://issues.guix.gnu.org/issue/N/patch-set/M | git am -3

> 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.
Well, it's several keys, actually, but as others have already pointed
out, keyboard > mouse.

> 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.
What the?  If anything, emails are like a tree and discussions in most
forges are a single long list that's rarely well organized.  Virtually
every mail client supports threads, whereas a certain one of the more
popular forges still refuses to do so.  Hiding obsolete versions of a
pull request is in practice implemented either by pushing more commits
on top of the existing one, often with dubious commit messages or by
force-pushing a branch, neither of which is an acceptable solution for
Guix.

> > But someone would have to write and maintain them...
> 
> 
> there are some that have already been written. here's an ad-hoc list
> of references:
> 
> #github #gitlab #alternative
> https://codeberg.org/
> https://notabug.org/
> https://sourcehut.org/
> https://sr.ht/projects
> https://builds.sr.ht/
> https://git.lepiller.eu/gitile
> codeberg.org is gitea and sr.ht is sourcehut
Gitile is (as far as I'm aware) not yet a full forge.  It also hasn't
loaded for me in ages, but I digress.

It doesn't suffice if you just integrate any of those forges into the
pre-existing workflow somehow.  You must also make it a pleasant
experience for everyone involved.  This is similar to the issue that
already bugs our Matrix<->IRC bridge.  

Other implicit assumptions include that people will be happy to switch
for the particular fork you've chosen (they won't) and will not demand
$new_hot_thing within the next five years (they likely will, just look
at the ChatGPT-related stuff that has been submitted).  There sadly is
no pleasing everyone here and unless these tools are incredibly simple
to maintain, the utilitarian approach of least misery leads you to
plain email.

Cheers