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

[MSavoritias <email@msavoritias.me>]

Just some remarks here,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> 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.
>
That is a subjective thing and its posed as something that is not. We
should all be open to being wrong.

>> 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.
>
Using Emacs with mu4e its also bad to deal with lots of patches here too
:) Now having worked with Gitlab for example the UI is not as chaotic.
Aside from the "Gitlab is proprietary" argument which is NOT the
point. The point is how do we make it as easy as that for the people
that dont want to customize their email clients for optimal "threading"
capabilities?

>> > 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.
>
Also this is sounds like you think the other person just follows fashion
and you are the one that follows the "enlightened" way because you use
email. This is not the discussion we are having and we don't treat
people as less if they dont use terminal, emails or emacs or whatever
else you find amazing or whatever.

MSavoritias
> Cheers