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

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

On 9/8/23 2:37 PM, Ricardo Wurmus wrote:
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
>> Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
>>> I have the same positive view on our faux ChangeLogs commit messages,
>>> though I also would like to have them generated.  The benefit is
>>> still there: I still get to *review* an effective summary of the
>>> changes before pushing or sending them off for review.  But at least
>>> I don’t have to write them myself.
>>>
>>> Now, this is no longer a problem for me because I’ve been writing so
>>> many commit messages over the years (and because I no longer try to
>>> adhere to some poorly specified format), but it *is* a problem for
>>> people that I’ve mentored.
>>>
>>> etc/committer.scm and the yasnippets are supposed to alleviate some
>>> of the pain, but I don’t need to think for a long time to come up
>>> with a number of improvements in this area.
>> Can I assume this to mean it'd take you some short time to think of
>> snippets that we're currently lacking?  If so, please do contribute
>> them.  If not, what do you mean then?
> 
> I mean that they have plenty of defects.
> 
> When I wrote the first few iterations of etc/committer.scm it was only
> really meant and good for bulk package updates (= lots of changes across
> files, all upgrades).  It couldn’t (and maybe still can’t) reliably
> detect added or removed package definitions.  It doesn’t handle changes
> to the arguments field.  It’s also terribly slow because it naively
> recomputes information for every hunk in the diff, reading package
> definitions from the old vs the changed file after every commit.
> 
> The update yasnippet repeatedly gets the order of lines wrong when
> adding a patch to dist_patch_DATA in gnu/local.mk; it also doesn’t do
> what etc/committer.scm is already able to do: detecting changes to
> inputs.  Configuring yasnippet is also not trivial for people who don’t
> regularly use Emacs (the snippets are tied to modes set by magit).
> 
> I think in light of these defects “Uhm, we have snippets?” isn’t a
> satisfying response.

Also, from my original message:

        I use the templates provided, but those don't cover all cases, 
and I've
        even gotten feedback in a review to change a message it created.