Re: Promoting Git developers

[Junio C Hamano <gitster@pobox.com>]

"Jason St. John" <jstjohn@purdue.edu> writes:

> In the Git release notes for something like "git foo
> learned a new option --bar", a simple "(Thanks|Kudos) to John Smith"
> at the end of each bullet point may be a good way to recognize
> developers in a concise manner without needing to dig through the
> output of "git log" or "git shortlog".

I doubt cluttering the list of features and fixes with peoples'
names is such a good idea. Earlier we did not have any detailed
release notes and instead said "you can go read 'git log'", which
did not help the end users who need to know what changed before or
after updating their Git, and I started doing the release notes in
the current format to help them. We must not forget that the primary
audience of this list of features and fixes is the end user. They
need a brief birds-eye summary, and the briefer and the cleaner we
keep it, the better.

Besides, it will be a lot of work to dig "log" for topics and then
go back to list archives to see who originally raised the issue
before even the first edition of the patch was written and who
contributed the ideas to help the author during the review
cycles. Doing that for a topic that needed to get rerolled multiple
times will take a lot of work, as the backlinks to previous round of
discussions are often available only in human-readable form.  And
the list of people who helped will have to be updated when a
follow-up bugfix topics are merged [*1*].

All of the above would add too much busywork on my plate [*2*].

Do people want to see me doing busywork, or spending that time on
reviewing, suggesting improvements, rejecting crap and applying
patches [*3*]?

> Or if that would make the release notes too cumbersome to review, what
> about using systemd's method? systemd's release notes include a
> "contributions from" section at the very end that lists everyone with
> a patch included in the release.

I can add "shortlog --no-merges -s -n v2.3.0..v2.4.0" at the end of
the e-mail when the release notes is sent out. That might be a good
enough balance between the usefulness of the release notes to its
customers and giving credits to individuals in a way a bit more
visible than "if you are interested, run shortlog yourself" [*4*].

Thanks.


[Footnote]

*1* Anybody remember "Git traffic" [*5*]? There was this great guy
who have been summarizing the kernel traffic and soon after Git
project started he did one edition of "Git traffic", summarizing a
few weeks' worth of Git mailing list discussions, who came up with
what idea, how that idea was discarded, what decisions were made, in
readble form. Unfortunately, there was only a single edition of "Git
traffic" ever published---and I can understand why. During that
"inflation" age of Git, we discussed so many topics and so much was
achieved in a very short period of time. It would have been
impossible for any single person to follow and report on all that
was happening in the Git land, unless that person wasn't Linus or me
or a handful of other people---but all of us were too busy with the
discussion and programming to do a summary. I really wished the
publication continued, but that was wishing for an impossible.

If you want the point-by-point kudos, you do need somebody who can
invest time to do a good job at this, and that person cannot be me
or anybody who commits text to the release notes but an attentive
and devoted reporter. An algorithm would not cut it. I suspect that
a workflow "improvement" to help a dumb tool to automatically
produce it would be too constricting and will slow me down.

*2* What we need is a group of people who are interested in this
enough to volunteer themselves to keep helping whatever kudo-giving
that is needed in an ongoing basis. We do not need people who pile
more on _my_ plate telling _me_ how to make the world better for
them and then go away without doing anything themselves. We can find
them dozen a dime and they won't help this project run any smoother.

*3* Rhetorical question. I have long learned that the key to make
sure the project runs smoothly is to push as much work off of my
plate to make sure I won't become the bottleneck.

*4* Note that it does not capture anything but "these people did the
final versions of the patches". We would not be giving credit to
others who may have offered crucial insights to help these people.
But that would give the same amount of rough estimate as the old
contributors' list Christian misses from git-scm.com, and it might
be good enough for somebody to see his name on it and feel good
about it.

*5* The site is gone, but wayback machine has a copy.

https://web.archive.org/web/20050514083018/http://www.kerneltraffic.org/git/gt20050502_1.html