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

[wolf <wolf@wolfsden.cz>]

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

On 2023-09-05 22:43:04 +0200, Liliana Marie Prikler wrote:
> Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
> > Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > > Uhm, we have snippets?
> > 
> > Well, those are exclusive to Emacs :)  And without regard to /that/
> > issue, I do think that there's a problem if the commit format is so
> > complex that it's not trivial for anyone new to the project to write
> > them out manually.
> By definition, no amount of typing is non-trivial, safe for the empty
> amount, which good luck trying to commit your changes by pure mouse
> movements, I guess?
> 
> Now, if you excuse my French, I think the problem isn't really as much
> that people struggle to type out the perfect ChangeLog on the first
> try, which also makes it odd to request a linter.  Bear in mind that
> committers will sign off anything that appears convincing enough, even
> if there are smaller mistakes in the message.  Trust me, I've been
> there and seen that; and also done it myself.
> 
> Instead, we have seen in this thread appeals to age, appeals to
> perceived lack of personal benefit, and now appeals to typing effort,
> none of which really make that great of an argument against the
> ChangeLog style, especially when they come in combination with a
> refusal to make use of already provided tools.

I went through the snippets, and through the GNU documentation[0] and I am still
not clear on how exactly should the commit message for a change in
.dir-locals.el look like.  Maybe I did miss some tools or documentation?

The "you can check the commit history for example" advice from the 22.6 page of
documentations gives me 4 different styles in last 4 commits.  Ok, just joking,
3 styles, the 4th is a typo (`* .dir-localsl.el: Add ...').

0: https://www.gnu.org/prep/standards/html_node/Change-Logs.html

> I think we're starting to see the moving of the goal post as the actual game
> here. 
> 
> Maybe it's time to take a step back and instead of asking “How can we
> decrease the cognitive overhead for contributors?”, we should perhaps
> ask “For which contributors do we want to/can we decrease the cognitive
> overhead?”

While I do risk taking this slightly more off topic, I personally am more
interested in what can be done to help the committers, not contributors.  My
biggest grievance with trying to contribute is not the process nor the tools,
but the lack of reviews.  Having a patch sitting there without any reaction nor
feedback is frustrating.  Do you see any process/tooling changes that could help
on this front, even if they would make life harder for the contributors?

> We have drifted much from the original post that discussed moms with full-time
> jobs, who struggle to do “difficult” tasks (simplified wording; may change the
> meaning of the OP a little).  Now, I personally struggle to see how your
> personal preference for communication media, commit message style, and other
> things that were discussed in any of the preceding threads actually correlate
> with being a parent.  However, I do know that with its 150 million users, most
> people of the world don't have a Github account.  Being one of the 4 billion
> email users out there is a comparably low barrier of entry imho.  So, whose
> cognitive overhead do you want to reduce (besides the obvious "my own", which
> everyone always tries)?
>

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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