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

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 29.08.2023 um 12:29 +0300 schrieb MSavoritias:
> 
> 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.
I mean, my comment was meant to be tongue-in-cheek and I'm not a UX
expert, so you might want to consult those, but there appears to be a
shared experience of many hackers that the keyboard is often better at
getting the things you want done done.

> > > 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?
To be fair, Gitlab is on the better forges out there, also allowing you
to interact with issues via email for one.  It also has decent support
for threads.  However, apart from being proprietary and thus not likely
adopted by any GNU project serious about software freedom, 

> > > > 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.
There is no singular "other person" here.  There is people, a plural,
and people as a group are very well influenced through fashion.  Of
course, there's some stochastics involved; people wearing adidas from
head to toe don't tend to frequent the same places as elegant gothic
lolita aristocrat vampires.  Indeed, the people now choosing sourcehut
may still do so in five years (though some might choose something
else).  However, the people demanding any other interface in those five
years will undoubtedly be influenced by whatever will be popular then.

I also don't necessarily blame the people making these demands for
doing so; from their perspective it makes sense to demand something
that's "easier to work with".  However, there is some shortsightedness 
to their demand and it has nothing to do with the enlightenment that
one achieves or doesn't achieve when using email (ironic, considering
that most people out of necessity have an email even if they prefer
$hot_instant_messaging_trend or $"outdated"_instant_messaging_niche or
whatever it is that they actually prefer).  Thus, I ask you to consider
that catering to the whims of fashion, even if it doesn't appear to be
catering on the surface, is perhaps not the best strategy.

Cheers