guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Tournier
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Wed, 13 Sep 2023 09:57:34 +0200

Hi Katherine,

On Tue, 12 Sep 2023 at 10:05, Katherine Cox-Buday <cox.katherine.e@gmail.com> 
wrote:

> And these are subjective statements, which are bad to rest decisions on. 
> I have the opinion that this style of commit message is difficult and 
> doesn't have a lot of value; others think it's easy and find a lot of 
> value in it.

About commit message format, I think this is the knot.  Because the
discussion is focused on “easy vs difficult“ and there is no “real”
answer on this frame.

Instead, the question appears to me about “complexity vs value”.

The questions are not about pros and cons for some non well-defined
ChangeLog-like commit format message, but what are the values of the
commit messages for the project?

Could you explain what are the values, from your perspective, about the
commit message for the Guix project?  Whatever the message format.

The next question is then: does the current ChangeLog-like format
capture these values?  Or is another format that captures these values?

The ChangeLog-like format is a mean for an end.  As it is noticed
elsewhere in the thread, this ChangeLog-like format fills an historical
end.  Here you say the ChangeLog-like «doesn't have a lot of value» but,
if I have read correctly this thread, no one has explicitly said what is
this end that the project wants?  It is only with this angle of a more
or less defined end that the mean can be scrutinized, IMHO.

WDYT?


> I don't place much emphasis on my opinion or others' on this, but I 
> place an enormous emphasis on the existence of the two groups. We should 
> be curious why the two groups hold their opinions, and curious about a 
> mutual path forward.

I agree that the thread draws a line with two groups.  However, this
line is set using some personal preferences comparing apple to orange.

For example, I also find “boring” the kind of strictness of the
ChangeLog-like format so my personal preference would be tempted to
belong to group A.  In the same time, I recognize that this
ChangeLog-like format provides helpful structure so my personal
preference would be tempted to belong to group B.

However, if I first list what I consider as the values for the commit
messages at the project level, then the ChangeLog-like format appears to
me filling the needs.

Somehow, the line is drawn using a two-axis plot of “easy vs boring”
when instead we should draw a two-axis plot of “complexity vs capture
the values”.

Bah, I do not know.  Maybe, what I am saying makes no sense. :-)

Cheers,
simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]