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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Mittwoch, dem 06.09.2023 um 00:04 +0200 schrieb wolf:
> 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?
Our snippets cover the most common cases, and editing the .dir-locals
happens quite rarely :)

> 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 ...').
Regarding only the ChangeLog, I see 1.5 styles – that is
"* .dir-locals.el:"
and
"* .dir-locals.el (some specifier):"

Both are okay.  Regarding the header, you are free in what to type,
since it's at the top directory anyway.

> 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?
To be completely honest, mumi recalling everything at 0 precision is my
biggest pet peeve at the moment, but I don't think it's solely
responsible for the lack of reviews.  Even back when it did produce
reasonable results, patches were overlooked, which people often worked
around by asking for attention e.g. on IRC.

I don't think we should make things harder for contributors, but having
an interface where e.g. patches that have been unnoticed for about a
week or longer can easily be retrieved would definitely make things
easier.  Also, stuff like finding issues where CI lights green and
(non-committer) reviewers have said LGTM would be a big help.  I don't
see how we could implement this without rolling out a big knowledge
graph, though ;)