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

[Attila Lendvai]

> > 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).

and i haven't used any forges where there's not at least a flat timeline per PR.

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.


> 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.


are you by any chance mixing the standards that we set out for the Guix repo, 
with the means of communication while a patchset is being forged into mergeable 
quality?

and even if you are not, we could simply add an entry to the requirement list 
that the commit history of a PR must be retained even when a PR is 
force-pushed. it's not that emails are inherently superior.


> 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


my implicit assumption is that a project is ready to switch communication 
technologies every few years, *if* it's justified. 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.


> 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.

what makes it even more tricky is that it's a self-perpetuating meme, because 
the more such conservative policies are enforced, the fewer people will stick 
around who would advocate for change.

yes, the balance between change and conservatism is tricky, but i think we have 
moved on from CVS long enough ago to e.g. abandon the ChangeLog format... (or 
alternatively, i'm blind to the use-cases that it is crucial for).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“I sincerely believe that banking establishments are more dangerous than 
standing armies, and that the principle of spending money to be paid by 
posterity, under the name of funding, is but swindling futurity on a large 
scale.”
        — Thomas Jefferson (1743–1826)