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

[Saku Laesvuori <saku@laesvuori.fi>]

[-- Attachment #1: Type: text/plain, Size: 3948 bytes --]

> > > 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
> 
> 
> not sure how most people consume their emails nowadays, but for me
> it's one flat list per thread, in a browser (i.e. it's not a tree).

The point is that the emails contain the information on how to construct
a tree out of them. It's just that most web clients (which most people
are unfortunately using nowadays) are so bad that they render the tree
as a flat list.

> i used to use emacs for emails for a while, but i stopped. the
> learning curve was too steep, and documentation was sparse, for little
> perceived benefit. at one point i noticed that it was saving
> unencrypted drafts of encrypted threads into my online mail account,
> and i decided to abandon it.
> 
> now i rely on webmail with Edit in Emacs browser extension. it's good
> enough for everything i do, except maybe for contributing to Guix.

Maybe having a proper tree representation of your emails is a sufficient
benefit to change your email client or maybe you don't care about it
that much. Anyway the email-based format gives the *option* to see the
discussion as a tree, while a forge either shows messages as a tree or
it doesn't. There is nothing that can be done to make it show them
differently.

By the way, I don't know what webmail you are using but I would be very
sceptical of it keeping your drafts any more secure. It probably either
stores the encryption keys on the server, sends data from the message
editor to the server for some computation or relies on random javascript
that could read your mails and send them directly to anyone who wants to
snoop on you.

> and all i'm trying to achieve here is to move the discussion away from
> email-is-superior-period, to look at what requiremenets we have and
> what tools satisfy them, if any.

I think that is a good discussion to have, but I think it would be
better to describe some of the requirements you think we should consider
instead of just saying email isn't superior. It might not be, but it
might also be. We should consider what we need and evaluate the
available tools based on that, and if the result is that email is
the best then it is.

> > 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.
> 
> but is a least-misery model appropriate here? how do you even account
> for the contributions that could have happened in a different
> environment, but did not happen?
> 
> similarly, e.g. demanding a dated ChangeLog format for commit messages
> has a filtering effect on who will contribute, and then who will stick
> around. most engineers have a hard time jumping through hoops that
> they find pointless (git automatically encodes that information), and
> i'd suggest considering what the effect are of such rules on Guix as
> an emergent order.

I agree on the ChangeLogs being a weird thing to require in commit
messages. I think of commit messages as the place where you record the
reasons behind the change in the commit. The ChangeLog seems to just
record the changes which the diff of the commit already automatically
records more accurately.

If someone has use cases for the ChangeLog commits, I'd like to hear
them. Maybe there is something that can't be achieved with git history
without ChangeLogs, but I can't think of anything. Someone mentioned
grepping the git log with them, but I think the same thing can be done
with git log and git blame regardless of the commit message format.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]