Promoting Git developers (was: Bashing freelancers)

Promoting Git developers (was: Bashing freelancers)

[Christian Couder]

Hi,

On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup <dak@gnu.org> wrote:

> At some point of time I think it may be worth reevaluating the toxic
> atmosphere against freelancers doing Git development.

My opinion on this is that the Git community has not been good
especially lately at promoting its own developers.

Some facts:

* There used to be an AUTHORS section in each of the git man page.
They have been removed. The rational was that they were hard to
maintain and the information about authors was easily available
elsewhere.

* There used to be a nice page on git-scm.com, the main Git web site,
listing the authors and how many commits they had contributed. It has
been removed.

* In the "A note from the maintainer" emails that Junio regularly
sends, the last section about "Other people's trees, trusted
lieutenants and credits." seems to have been truncated for some time
and doesn't show anymore the nice "credits" words it used to show.
Maybe this is a bug.

* https://www.openhub.net/p/git/contributors/summary seems to give me a
"504 Gateway Time-out" right now :-(

* On the Git Merge web site, we can see that none of the speakers
seems to have been a very active contributor to git.git

None of these facts is a big issue in itself for me, but I think the
trend is very sad, and I would be happy if we could discuss here or at
the Git Merge (or both) about ways to improve in this area.

Best,
Christian.

Re: Promoting Git developers (was: Bashing freelancers)

[Michael J Gruber]

Christian Couder venit, vidit, dixit 07.03.2015 08:18:
> Hi,
> 
> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup <dak@gnu.org> wrote:
> 
>> At some point of time I think it may be worth reevaluating the toxic
>> atmosphere against freelancers doing Git development.
> 
> My opinion on this is that the Git community has not been good
> especially lately at promoting its own developers.
> 

I guess we have at least 3 kinds of people here:

A) Paid to do Git development, at least as part of their job.
B) Freelancers who don't get paid directly for "doing git" but hope to
profit from their git efforts directly or indirectly.
C) Doing it in their freetime (or as minor, inofficial part of their
non-programming job).

I'm in camp C and honestly wasn't aware of camp B until now.

I consider camp A to be beneficial for all of us, and I don't think
specific employer interests have pushed the project in specific
directions, or specific features (OK, maybe one, but not as a rule).

I do see that remuneration is an issue for camp B.

> Some facts:
> 
> * There used to be an AUTHORS section in each of the git man page.
> They have been removed. The rational was that they were hard to
> maintain and the information about authors was easily available
> elsewhere.

I'd say it's difficult to do this in a fair manner, since most pages are
a community effort now in the best sense.

> * There used to be a nice page on git-scm.com, the main Git web site,
> listing the authors and how many commits they had contributed. It has
> been removed.

It was out of date again and again, and pull-requests took forever. The
problem here still seems to be the old dis-connectedness between that
website and the developers' community. But it's the only one "we" have.

Since we're talking business: git-scm.com still looks a bit like a
ProGit/Github promotion site. I don't have anything against either, and
git-scm.com provides a lot of the information that users are looking
for, and that are hard to find anywhere else; it's a landing page. It
just does not look like a "project home".

> * In the "A note from the maintainer" emails that Junio regularly
> sends, the last section about "Other people's trees, trusted
> lieutenants and credits." seems to have been truncated for some time
> and doesn't show anymore the nice "credits" words it used to show.
> Maybe this is a bug.

Being in camp C, that entry in "credits" was my remuneration, so-to-say,
and I missed it when it was gone. OTOH, I do understand how tedious it
is to keep that up to date and fair. (And if, I should probably have
been removed at some point...)

There still is "git rev-list --count --author=Mickey origin/master" :)

> * https://www.openhub.net/p/git/contributors/summary seems to give me a
> "504 Gateway Time-out" right now :-(

I thought there is ohloh, but that one is the new ohloh... Anyways,
Junio's repo on github is "official" in a sense and has this:

https://github.com/git/git/graphs/contributors

> * On the Git Merge web site, we can see that none of the speakers
> seems to have been a very active contributor to git.git

Yeah, that's more an "outside business window into git". In fact, while
that doesn't quite intrigue me, I would think it's a great chance for
freelancers to get in touch with people doing business with git.

And maybe they'll be talking about what they're using git for, and which
technical and non-technical challenges they meet in doing so? Edward was
fun to listen to in Berlin :)

Git merge itself is organized and sponsored by businesses with business
interests. But there's also the contributors summit. Git merge Berlin
was great and generous in that respect.

> None of these facts is a big issue in itself for me, but I think the
> trend is very sad, and I would be happy if we could discuss here or at
> the Git Merge (or both) about ways to improve in this area.

There should be a good occasion, after we see how it went, and hopefully
also to sort out any apparent misunderstandings from the past that have
resurfaced in this thread.

Maybe, all we need is badges? [1]

Michael

[1] https://badges.fedoraproject.org/

Re: Promoting Git developers

[David Kastrup]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Christian Couder venit, vidit, dixit 07.03.2015 08:18:
>> Hi,
>> 
>> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup <dak@gnu.org> wrote:
>> 
>>> At some point of time I think it may be worth reevaluating the toxic
>>> atmosphere against freelancers doing Git development.
>> 
>> My opinion on this is that the Git community has not been good
>> especially lately at promoting its own developers.
>> 
>
> I guess we have at least 3 kinds of people here:
>
> A) Paid to do Git development, at least as part of their job.
> B) Freelancers who don't get paid directly for "doing git" but hope to
> profit from their git efforts directly or indirectly.
> C) Doing it in their freetime (or as minor, inofficial part of their
> non-programming job).
>
> I'm in camp C and honestly wasn't aware of camp B until now.

My guess is that camp B is dead and intentionally so.  For the
rationale, see for example
<URL:http://article.gmane.org/gmane.comp.version-control.git/247165/>.
It is considered tasteless to even mention camp B.

-- 
David Kastrup

Re: Promoting Git developers

[Philip Oakley]

From: "David Kastrup" <dak@gnu.org>
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Christian Couder venit, vidit, dixit 07.03.2015 08:18:
>>> Hi,
>>>
>>> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup <dak@gnu.org> wrote:
>>>
>>>> At some point of time I think it may be worth reevaluating the 
>>>> toxic
>>>> atmosphere against freelancers doing Git development.
>>>
>>> My opinion on this is that the Git community has not been good
>>> especially lately at promoting its own developers.
>>>
>>
>> I guess we have at least 3 kinds of people here:
>>
>> A) Paid to do Git development, at least as part of their job.
>> B) Freelancers who don't get paid directly for "doing git" but hope 
>> to
>> profit from their git efforts directly or indirectly.
>> C) Doing it in their freetime (or as minor, inofficial part of their
>> non-programming job).
>>
>> I'm in camp C and honestly wasn't aware of camp B until now.
>
> My guess is that camp B is dead and intentionally so.  For the
> rationale, see for example
> <URL:http://article.gmane.org/gmane.comp.version-control.git/247165/>.
> It is considered tasteless to even mention camp B.
>

There seems to be some talking past each other going on.

A common problem [1] is that the apparent middle ground "B" is actually 
split two ways, (because A and C are not opposites but embed different 
ethos)

There maybe those B's who are well paid independent programmers, who are 
able to choose how to use their spare time in the same manner as those 
in "C".

And there are those who, like some of the "A"s , need some payment to 
use their hours to the benefit of Git. This will be particularly true of 
those who are not well remunerated from their independent work. If they 
are giving up precious work time then they would at least hope for a 
little acknowledgment.

To me it sounds as if Junio is thinking more of the former while David 
is thinking of the latter. These misunderstandings are difficult to 
resolve, or at least reconcile, without a proper understanding of the 
root causes of the differences.


--
Philip
[1] This common problem is summarised in the Competing Values Framework 
(CVF), which is usually applied to management philosophies, but is a 
common styling in many disputes and misunderstandings.

Re: Promoting Git developers

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> I guess we have at least 3 kinds of people here:
>
> A) Paid to do Git development, at least as part of their job.
> B) Freelancers who don't get paid directly for "doing git" but hope to
> profit from their git efforts directly or indirectly.
> C) Doing it in their freetime (or as minor, inofficial part of their
> non-programming job).
>
> I'm in camp C and honestly wasn't aware of camp B until now.
>
> I consider camp A to be beneficial for all of us, and I don't think
> specific employer interests have pushed the project in specific
> directions, or specific features (OK, maybe one, but not as a rule).
>
> I do see that remuneration is an issue for camp B.

As one of the four things you are not supposed to talk about in a
polite society, it is indeed hard to talk about money.

Let me digress a bit before coming back to your 3 classes, because
money is hard not only for those who want to receive, but is also
hard for those who want to pay. I remember having a brief discussion
during one of the GitTogether meetings with this person who managed
Git users at his company. I think it was one of the chip makers
whose association with Git was through its involvement with Android,
but don't hold me to this, as I do not exactly remember. The
conversation started with "How do you get changes to Git?" and what
he ultimately wanted to learn was how a company can enhance Git to
make the life of his engineers easier by hiring some Git experts and
have them work on missing features.

As you can guess, the conversation did not get to a satisfactory and
clear "here is how you would go about it". Sure, a company can pay a
developer to do a feature, but it is impossible to predict if the
end result will be used by us. For a usual work for hire, the hiring
company can set the evaluation criteria itself, which would be that
the end result works with the given version of the base software and
produces desired result for the specific workflow the company
needs. But the evaluation criteria for a "contribution" to us is not
under the control of the paying company and the bar the person who
does the work for hire has to cross is different. It of course needs
to fill the needs of the sponsoring company, but also it needs to be
cleanly done, maintainable, and it must not harm workflows other
people employ, which the sponsoring company may not care about at
all. That makes it hard for companies to pay a developer to work on
Git to benefit themselves. It is the same deal for an enterprising
soul who would start a crowdfunding campaign "I'll add this feature
to Git---if you guys raise this much money".

This also makes the involvement of employers in category (A) a
nuanced one. Because money is not an effective currency to buy
"inclusion", "Paid to do Git development" does not equate
"Companies pay developers to develop Git in a way to benefit the
sponsoring companies". When it comes to working on Git, I, Shawn
or Jonathan do not get orders from Google management to add funky
features nobody outside Google would use to help Android [*1*],
and I doubt that Peff and Michael's job description are to push
GitHub specific enhancement into our codebase, either [*2*].

There are different schools of thought on how to support open source
development [*3*]. I heard some people dream of "free software tax"
and have public support our endeavor, just like public purse supports
academia. We do not live in such world. Some projects pay for bugs
with bounty program; I think that would be the closest thing to
support your category (B), and that form of support does not have to
be limited to bugs. Projects could buy features in addition to bugs.

But we are not structured that way, at least so far. If we start to
buy features, that would make it even more difficult than the "My
company wants to fund somebody to add features to Git---how do we go
about it?" case. How do we decide an effort was successful? Would
that decision be affected by the fact that we paid for it in the
first place (i.e. declaring a failure would mean we admit that we
made a mistake when approving to fund the effort)? When other
developers think that a feature we bought shouldn't have been bought
in the first place, what happens? How should conflicts in such
decisions be resolved? How would that payment affect people who are
in category (C), or category (A) for that matter? Faced with two
reasonable implementations by a bounty hunter and a hobbyist, does
it enter the equation that one costs and the other is free? Do we
pay everybody to sidestep that issue? Where does the money come
from? Do we want to become a project that employ some developers but
not others? Who makes hiring decision and how?

In short, I agree with you that we are not set up to support bounty
hunters very well. That might be something we want to change, but I
am not sure what the endgame would be, if I would like that endgame
when I see it, or what the first step to reach that endgame would
be. My gut feeling is that there can be many "reasonable" answers to
all the question marks in the previous paragraph, but I have a vague
apprehension that taken together the answers would lead to a community
that is rather uncomfortable to live in, for hobbists and aspiring
hackers who want to be a part of category (A) alike, but that is
merely a vague apprehension at this point.


[Footnote]

*1* We however do get inspirations by being in a company that uses
Git in a way that may be different from the outside world, noticing
pitfalls common to in-house users, their pain points, etc. But we
know enough to think about the issues to see if they are common with
the outside world before considering to tweak the public version of
Git.

*2* I started Git from its early days as a category (C) participant,
but in later years before I came to Google I was doing Git
effectively out of my pocket, as I was paid only for the non-Git
days and by that time Git maintainership has grown to consume about
half my time. I however do not think I would throw me during those
days in category (B) myself. To me, I was still (C) with reduced
income. As you would expect, eventually that arragement became
untenable. There was a company who benefited from having a healthy
open source ecosystem that are supported by Git in the wider world,
and appreciated that I was not driving the project into ground, and
it was fortunate that they wanted me to continue. That is how I came
to be in category (A).

*3* I personally feel that good open source developers should be
like court painters. They may paint their employer's children to
earn their keep even if they did not like doing so, but their output
eventually enriched the wider public. Their employers might have
been leeches who exploited serfs, just like evil corporations in the
modern day, and I understand those who oppose my simplistic world
view.

Re: Promoting Git developers (was: Bashing freelancers)

[Christian Couder]

On Mon, Mar 9, 2015 at 2:57 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Christian Couder venit, vidit, dixit 07.03.2015 08:18:
>> Hi,
>>
>> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup <dak@gnu.org> wrote:
>>
>>> At some point of time I think it may be worth reevaluating the toxic
>>> atmosphere against freelancers doing Git development.
>>
>> My opinion on this is that the Git community has not been good
>> especially lately at promoting its own developers.
>>
>
> I guess we have at least 3 kinds of people here:
>
> A) Paid to do Git development, at least as part of their job.
> B) Freelancers who don't get paid directly for "doing git" but hope to
> profit from their git efforts directly or indirectly.
> C) Doing it in their freetime (or as minor, inofficial part of their
> non-programming job).
>
> I'm in camp C and honestly wasn't aware of camp B until now.
>
> I consider camp A to be beneficial for all of us, and I don't think
> specific employer interests have pushed the project in specific
> directions, or specific features (OK, maybe one, but not as a rule).
>
> I do see that remuneration is an issue for camp B.

First thank you for responding to my email. It is great to see that
some developers are interested in talking about this.

I am in camp C and I think the people in all the camps are beneficial
for all of us.

>> Some facts:

[...]

I don't want to write again about each of these points now. I am more
interested in discussing a good strategy to try to revert the sad
trend of Git developers being promoted less and less, because I think
that it is really very important.

>> None of these facts is a big issue in itself for me, but I think the
>> trend is very sad, and I would be happy if we could discuss here or at
>> the Git Merge (or both) about ways to improve in this area.
>
> There should be a good occasion, after we see how it went, and hopefully
> also to sort out any apparent misunderstandings from the past that have
> resurfaced in this thread.
>
> Maybe, all we need is badges? [1]
>
> [1] https://badges.fedoraproject.org/

My opinion is that the big issue is that we should all realize how
important it is to promote the Git developers.

There are people who say out there that GitHub succeeded mostly
because they easily allowed developers to build a portfolio. I think
there is some truth in that. And I think GitHub also says to
developers that it's good for them to have a nice GitHub portfolio and
to employers that it's good for them to hire people who have a nice
GitHub portfolio.

This shows that the success of GitHub (and so of Git too) is based in
part on promoting Open Source / Free Software developers.

So why don't we try to do it more (instead of less) and how could we
do it more (instead of less) for the Git developers?

Yesterday evening I attended a Docker meeting in Paris [1] where
Jérôme Petazzoni a Docker developer working for Docker gave a talk
about Docker storage drivers. In the middle of his talk there were at
least 2 slides dedicated to thank some developers who helped make
Docker work with different filesystems or operating systems. And
Jérôme did stop at least twice to thank these people in the middle of
his talk.

Wouldn't his talk have been smoother if he had not done that? So why
did he do that?

This reminded me about the following great talk by Julien Barbier the
Community and Marketing guy at Docker:

http://www.slideshare.net/julienbarbier42/community-marketing-42674728

I had seen this talk last december at another Docker meetup in Paris
(and I think it really worth reading the slides or attending the talk
if Julien gives it again and you can go).

The slides and the talk keep repeating some sentences because they are
worth repeating. Some of these sentences are:

* It is about what you can do for your community
* Belonging, recognition, respect, love
* Add more links to your community
* Your product is not what you say it is, it is what THEY say it is
* It's all about people

It is especially interesting to have a look at slide 5 where they say
that "Community is the new marketing" and that Community is 80+% of
their marketing.

And it's true that they are really doing a lot for their community.
For example the meeting yesterday evening was the 19th docker meeting
in Paris in two years.

And then there is slide 20 about "Content Strategy" where there is:

* Encourage your community to build content
  - Say thank you, repost, post, upvote, RT, include them in your
newsletter, itw them, …
  - Belonging, Recognition, Respect, Love

* Your team is your community too!
  - Say thank you, gamify, hall of fame, tweet, post, recycle, etc…
  - Belonging, Recognition, Respect, Love

So we can see that "saying thank you" is a big part of their content strategy.

And are they successful? Yes, they are very successful as an open
source project [2] and as a company.

Now it's up to us, either we keep coming up with excuses not to
promote developers, or we decide to do something about it.

Best,
Christian.

[1] http://www.meetup.com/Docker-Paris/events/220891955/
[2] http://stackshare.io/posts/how-docker-manages-its-massive-open-source-project

Re: Promoting Git developers

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> I don't want to write again about each of these points now. I am more
> interested in discussing a good strategy to try to revert the sad
> trend of Git developers being promoted less and less, because I think
> that it is really very important.

I would suspect that those who agree with you would appreciate if
you or somebody volunteered to act as our CKDO (chief kudos
distribution officer).  I do not think I have enough time to do that
well.  One good place to start might be to scan the list and
summarize something like the following on weekly or monthly basis,
as these are not something you can get by pointing people to "git
shortlog" output.

 - Those who gave helpful review comments, "how about going this
   way" illustration patches, etc.  Bonus points to those who helped
   onboarding newcomers.

 - Those who asked pertinent questions on common pain points, and
   those who answered them helpfully.

If you are more ambitious, the source of the kudos may want to cover
activities outside of this mailing list (e.g. giving talks and
tutorials at conferences, etc.).

Re: Promoting Git developers

[Jason St. John]

On Tue, Mar 10, 2015 at 1:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> I don't want to write again about each of these points now. I am more
>> interested in discussing a good strategy to try to revert the sad
>> trend of Git developers being promoted less and less, because I think
>> that it is really very important.
>
> I would suspect that those who agree with you would appreciate if
> you or somebody volunteered to act as our CKDO (chief kudos
> distribution officer).  I do not think I have enough time to do that
> well.  One good place to start might be to scan the list and
> summarize something like the following on weekly or monthly basis,
> as these are not something you can get by pointing people to "git
> shortlog" output.
>
>  - Those who gave helpful review comments, "how about going this
>    way" illustration patches, etc.  Bonus points to those who helped
>    onboarding newcomers.
>
>  - Those who asked pertinent questions on common pain points, and
>    those who answered them helpfully.
>
> If you are more ambitious, the source of the kudos may want to cover
> activities outside of this mailing list (e.g. giving talks and
> tutorials at conferences, etc.).
>

I don't know how feasible or desirable this would be, but I'll offer
it anyway. 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".

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.

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Promoting Git developers

[Duy Nguyen]

On Wed, Mar 11, 2015 at 8:04 AM, Jason St. John <jstjohn@purdue.edu> wrote:
> 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.

Gnome projects do this too. They also separate translators from other
contributions, but I don't think if we need to do that. I think the
reason behind is translations go through the translator coordinator in
gnome, who does the committing, so "git shortlog" does not really list
translators. We may want to acknowledge review efforts as well, by
grepping Helped-by:, Reviewed-by:...
-- 
Duy

Re: Promoting Git developers

[Junio C Hamano]

"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

Re: Promoting Git developers

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> ... We may want to acknowledge review efforts as well, by
> grepping Helped-by:, Reviewed-by:...

Agreed. Something along the lines of 

    $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0..
       6  4  0  Michael Haggerty
       3  0  1  Jeff King
       3  2  1  Junio C Hamano
       1  0  0  Anders Kaseorg
       1  0  0  Ben Walton
       1  0  0  Jean-Noel Avila
       1  0  0  Michael J Gruber
       1  0  0  Michal Sojka
       1  0  0  Mikko Rapeli
       1  0  0  Mårten Kongstad
       1  0  0  Nguyễn Thái Ngọc Duy
       1  0  7  Stefan Beller

that gives the number of trailer entries specified with -t in the
order specified when doing the short/abbreviated form may be a good
thing to have. The output can be piped to "sort -k" and "cut" to be
cooked in any way.

For completeness, in the long form, the extra numbers probably would
come next to names of the individual:

    $ git shortlog --no-merges -n -t Helped-by -t Reviewed-by v2.3.0..
    Michael Haggerty (6, 4, 0):
          write_ref_sha1(): remove check for lock == NULL
          write_ref_sha1(): move write elision test to callers
          lock_ref_sha1_basic(): do not set force_write for missing references
          reflog: improve and update documentation
          reflog_expire(): ignore --updateref for symbolic references
          reflog_expire(): never update a reference to null_sha1

    Jeff King (3, 0, 1):
          gettext.c: move get_preferred_languages() from http.c
          diffcore-rename: split locate_rename_dst into two functions
          diffcore-rename: avoid processing duplicate destinations
    ...

The long format needs to be careful not to drop those who helped
others without any commit under their own names.

Re: Promoting Git developers

[Jeff King]

On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote:

> > 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*].

I somehow thought you already did this, but it looks like you just do
shortlog (without the "-ns") for the "maint" release announcement. This
does seem like a very simple thing we could to promote visibility of
contributors, and one would that would not require any ongoing effort
once it is initially scripted. It may even be a nice place to
specifically call out contributors who are new in this release.

I spent many years as a "type C" contributor, and I remember how nice it
was to see my name mentioned occasionally as a useful person.

-Peff

Re: Promoting Git developers

[Junio C Hamano]

On Wed, Mar 11, 2015 at 12:31 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote:
>
>> > 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*].
>
> I somehow thought you already did this, but it looks like you just do
> shortlog (without the "-ns") for the "maint" release announcement.

That is because (a) it is scripted in Meta/Announce, and (b) I strip it
out for feature releases, as the plain shortlog output with full feature
list is usually ends up being just too long for the announce message.

Perhaps I'll add "shortlog -s | pr -3" or something at the end for both
maintenance track and feature releases. Names only, unordered and
hopefully not overly long.

Re: Promoting Git developers

[Jeff King]

On Wed, Mar 11, 2015 at 12:38:21AM -0700, Junio C Hamano wrote:

> >> 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*].
> >
> > I somehow thought you already did this, but it looks like you just do
> > shortlog (without the "-ns") for the "maint" release announcement.
> 
> That is because (a) it is scripted in Meta/Announce, and (b) I strip it
> out for feature releases, as the plain shortlog output with full feature
> list is usually ends up being just too long for the announce message.

Yeah, I figured the length was the reason.

> Perhaps I'll add "shortlog -s | pr -3" or something at the end for both
> maintenance track and feature releases. Names only, unordered and
> hopefully not overly long.

Yes, I was thinking something along those lines. Maybe:

  # example
  old=v2.2.0
  new=v2.3.0

  # like "shortlog -s", but we do not even care about the numbers
  shortlog () {
	git log --format=%aN "$@" | sort -u
  }

  compact () {
	perl -lne 'push @x, $_; END { print join(", ", @x) }' |
	fold -s
  }

  count () {
	shortlog $old..$new | wc -l
  }

  newbies () {
	comm -23 <(shortlog $old..$new) <(shortlog $old) | compact
  }

  oldtimers () {
	comm -12 <(shortlog $old..$new) <(shortlog $old) | compact
  }

  cat <<EOF
  Git $new was developed with commits from $(count) people. Thanks very
  much to our returning developers:

  $(oldtimers)

  and welcome to new contributors in this release:

  $(newbies)
  EOF

Or something along those lines. The wording and indentation of the
message could probably use tweaking. And there is a bash-ism in the
script. :)

-Peff

Re: Promoting Git developers

[Christian Couder]

On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> I don't want to write again about each of these points now. I am more
>> interested in discussing a good strategy to try to revert the sad
>> trend of Git developers being promoted less and less, because I think
>> that it is really very important.
>
> I would suspect that those who agree with you would appreciate if
> you or somebody volunteered to act as our CKDO (chief kudos
> distribution officer).  I do not think I have enough time to do that
> well.  One good place to start might be to scan the list and
> summarize something like the following on weekly or monthly basis,
> as these are not something you can get by pointing people to "git
> shortlog" output.
>
>  - Those who gave helpful review comments, "how about going this
>    way" illustration patches, etc.  Bonus points to those who helped
>    onboarding newcomers.
>
>  - Those who asked pertinent questions on common pain points, and
>    those who answered them helpfully.

Ok, I can start something about this two points every week or every
few week. It would be best if I could get help from at least one
person as I think it is a lot of work.

We can perhaps use the Git Developer Site at
https://github.com/git/git.github.io to edit a new page
collaboratively that would be published on http://git.github.io/ and
after that send an email to the mailing list.

> If you are more ambitious, the source of the kudos may want to cover
> activities outside of this mailing list (e.g. giving talks and
> tutorials at conferences, etc.).

First I don't know if we should really give kudos (or badges) or have
something more like the former Git Traffic you talk about in another
email (or perhaps both).

And then I expect that if people give talks or tutorials at
conferences or publish a blog post or have other news they want to
share, they could edit the web page themselves on GitHub (or fork it
and send a pull request if they don't have the rights).

I also appreciate very much that you are willing to improve the
release notes by adding a summary with people's names.

It would be nice if we could also have somewhere on a web page at
least a good listing of the authors and how many commits they had
contributed (since the beginning and maybe also during the last year).
We could also add other listings made using the Helped-by and
Reviewed-by trailers.

I don't think we should rely on an external web site like OpenHub
(which is still giving me a 504 Gateway Time-out on the contributor
page) or even the (broken) contributor graph on GitHub for that. If
Scott and Peff don't want it on git-scm.com then it is of course
better on git.github.io than nowhere.

Thanks,
Christian.

Re: Promoting Git developers

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> I would suspect that those who agree with you would appreciate if
>> you or somebody volunteered to act as our CKDO (chief kudos
>> distribution officer).  I do not think I have enough time to do that
>> well.  One good place to start might be to scan the list and
>> summarize something like the following on weekly or monthly basis,
>> as these are not something you can get by pointing people to "git
>> shortlog" output.
>>
>>  - Those who gave helpful review comments, "how about going this
>>    way" illustration patches, etc.  Bonus points to those who helped
>>    onboarding newcomers.
>>
>>  - Those who asked pertinent questions on common pain points, and
>>    those who answered them helpfully.
>
> Ok, I can start something about this two points every week or every
> few week. It would be best if I could get help from at least one
> person as I think it is a lot of work.

No kidding; even though it may no longer be an impossibly large task
as in the infrationary epoch reported in the Git Traffic, this forum
is still a high traffic place.

> I also appreciate very much that you are willing to improve the
> release notes by adding a summary with people's names.

Just in case you misunderstood, I do not think it is a good idea to
add names to release notes and I will not do so.

I was and am planning add the list of contributors at the end of the
e-mail when the release notes is sent out, i.e. in the "Announce"
message that is sent to the list (and CC'ed to lwn.net).

Re: Promoting Git developers

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Or something along those lines. The wording and indentation of the
> message could probably use tweaking. And there is a bash-ism in the
> script. :)

OK, I've updated the Announce script on the 'todo' branch.  The
announcement for 2.3.2 I sent out earlier as $gmane/264975 would
have looked like this.

-- >8 --
To: git@vger.kernel.org
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Bcc: lwn@lwn.net
Subject: [ANNOUNCE] Git v2.3.2

The latest maintenance release Git v2.3.2 is now available at the
usual places.  It comprises of 41 non-merge commits since v2.3.1,
contributed by 19 people, 5 of which are new faces.

The tarballs are found at:

    https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.3.2'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors who made this release possible are as follows.
Welcome to the Git development community!

  Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt,
  Ryuichi Kokubo, and Tom G. Christensen.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  Alexander Kuleshov, Eric Sunshine, Jeff King, Jonathon Mah,
  Junio C Hamano, Kirill A. Shutemov, Kyle J. McKay, Matthieu Moy,
  Mike Hommey, Ramsay Allan Jones, René Scharfe, Stefan Beller,
  Torsten Bögershausen, and Дилян Палаузов.

----------------------------------------------------------------

Git v2.3.2 Release Notes
========================

Fixes since v2.3.1
------------------

 * "update-index --refresh" used to leak when an entry cannot be
   refreshed for whatever reason.

 ...

 * Even though we officially haven't dropped Perl 5.8 support, the
   Getopt::Long package that came with it does not support "--no-"
   prefix to negate a boolean option; manually add support to help
   people with older Getopt::Long package.

Also contains typofixes, documentation updates and trivial code clean-ups.

----------------------------------------------------------------

Changes since v2.3.1 are as follows:

Aleksander Boruch-Gruszecki (1):
      merge-file: correctly open files when in a subdir

Aleksey Vasenev (1):
      wincred: fix get credential if username has "@"

...

Дилян Палаузов (1):
      do not include the same header twice

Re: Promoting Git developers

[Andrew Ardill]

On 12 March 2015 at 08:28, Junio C Hamano <gitster@pobox.com> wrote:
> OK, I've updated the Announce script on the 'todo' branch.  The
> announcement for 2.3.2 I sent out earlier as $gmane/264975 would
> have looked like this.

I think the changes are excellent, and think they add a lot of value
regardless of any other measures that might be introduced, such as Git
Traffic.

At the least it gives long time lurkers, and people who skim the list,
an easy way to put 'names to code', and it promotes the very people
who should be promoted.

Thanks to everyone involved in making this happen.

Regards,

Andrew Ardill

Re: Promoting Git developers

[Duy Nguyen]

On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> ... We may want to acknowledge review efforts as well, by
>> grepping Helped-by:, Reviewed-by:...
>
> Agreed. Something along the lines of
>
>     $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0..

A quick grep/uniq/sort gives this

   1512     Acked-by
    537     Reviewed-by
    389     Reported-by
    317     Helped-by
    147     Tested-by
    143     Suggested-by
     97     Noticed-by
     78     Improved-by
     49     Thanks-to
     40     Mentored-by
     23     Requested-by
     21     Acked-By
     20     Inspired-by
     18     Based-on-patch-by
      9     Explained-by
      9     Contributions-by

It looks like people are quite creative. I think all these "*-by" (so
-t supports wildcards) and Thanks-to: could be also considered as
contribution.
-- 
Duy

Re: Promoting Git developers

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> ... We may want to acknowledge review efforts as well, by
>>> grepping Helped-by:, Reviewed-by:...
>>
>> Agreed. Something along the lines of
>>
>>     $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0..
>
> A quick grep/uniq/sort gives this
>
>    1512     Acked-by
>     537     Reviewed-by
>     389     Reported-by
>     317     Helped-by
>     147     Tested-by
>     143     Suggested-by
>      97     Noticed-by
>      78     Improved-by
>      49     Thanks-to
>      40     Mentored-by
>      23     Requested-by
>      21     Acked-By
>      20     Inspired-by
>      18     Based-on-patch-by
>       9     Explained-by
>       9     Contributions-by
>
> It looks like people are quite creative. I think all these "*-by" (so
> -t supports wildcards) and Thanks-to: could be also considered as
> contribution.

I'd first suggest to employ "icase" to unify *-By and *-by.  Perhaps
we would want a recommended list somewhere in SubmittingPatches to
discourage people from getting too creative?

"Acked" and "Reviewed" would be part of the normal review process.

"Reported", "Requested", "Noticed", "Suggested", "Inspired", and
"Based-on-patch-by" are about where the motivation to make the
change came from.  They try to express modes of communication and
degree of involvement of the named person in the process of
germinating an idea, and the nature of the change (is it a bug or is
it an improvement?), but I wonder if we can standardize these into
just a few (or just one) by shedding the various nuances.  If the
difference these various phrases try to convey is so important, it
probably deserves to be in the log message proper (e.g. instead of
"Inspired-by", say "In his blog at $URL, ... expressed frustration
in doing ...; this will solve that issue in such and such way" in
the log, and use the standard trailer that designates where the idea
came from).

People named by these trailers are the ones that connect us to end
users by noticing and relaying their pain points, and by working
with us to improve Git.  We would want to credit them no less than
we do an author of a casual "here is a typofix in a comment" patch.

And everything else above looks "Helped-by" to me.  Again, the
different phrases try to convey what kind of help in polishing the
change was, but if that is worth expressing, it probably belongs to
the log message itself (e.g. instead of "Explained-by", say "The
above explanation was given by ... in $gmane/1369525" in the log
message and use "Helped-by").

Re: Promoting Git developers

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I spent many years as a "type C" contributor, and I remember how nice it
> was to see my name mentioned occasionally as a useful person.

I guess that everybody is different ;-)

After throwing a small patch at ROCKbox (git.rockbox.org) back when
they were still hosted on Subversion, I felt somewhat ashamed to see
my name appear in their CREDITS file because the change I made was
so insignificant. In such a flat list like that, you cannot tell who
made significant contributions over time and who are just a casual
drive-by contributor like me, unless you know the community and who
are important in the community.

Re: Promoting Git developers

[Fredrik Gustafsson]

On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote:
> I'd first suggest to employ "icase" to unify *-By and *-by.  Perhaps
> we would want a recommended list somewhere in SubmittingPatches to
> discourage people from getting too creative?

There's already such list in SubmittingPatches, so there's already quite
a few to choose from:

Also notice that a real name is used in the Signed-off-by: line. Please
don't hide your real name.

If you like, you can put extra tags at the end:

1. "Reported-by:" is used to credit someone who found the bug that
	the patch attempts to fix.
2. "Acked-by:" says that the person who is more familiar with the
	area the patch attempts to modify liked the patch.
3. "Reviewed-by:", unlike the other tags, can only be offered by
	the reviewer and means that she is completely satisfied that the
	patch is ready for application.  It is usually offered only after
	a detailed review.
4. "Tested-by:" is used to indicate that the person
	applied the patch and found it to have the desired effect.

You can also create your own tag or use one that's in common usage such as
"Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".

-- 
Fredrik Gustafsson

phone: +46 733-608274
e-mail: iveqy@iveqy.com
website: http://www.iveqy.com

Re: Promoting Git developers

[Junio C Hamano]

Fredrik Gustafsson <iveqy@iveqy.com> writes:

> On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote:
>> I'd first suggest to employ "icase" to unify *-By and *-by.  Perhaps
>> we would want a recommended list somewhere in SubmittingPatches to
>> discourage people from getting too creative?
>
> There's already such list in SubmittingPatches, so there's already quite
> a few to choose from:
>
> Also notice that a real name is used in the Signed-off-by: line. Please
> don't hide your real name.
>
> If you like, you can put extra tags at the end:
>
> 1. "Reported-by:" is used to credit someone who found the bug that
> 	the patch attempts to fix.
> 2. "Acked-by:" says that the person who is more familiar with the
> 	area the patch attempts to modify liked the patch.
> 3. "Reviewed-by:", unlike the other tags, can only be offered by
> 	the reviewer and means that she is completely satisfied that the
> 	patch is ready for application.  It is usually offered only after
> 	a detailed review.
> 4. "Tested-by:" is used to indicate that the person
> 	applied the patch and found it to have the desired effect.
>
> You can also create your own tag or use one that's in common usage such as
> "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".

Hmph, the first step might be to drop that last sentence, I guess,
if we consider this a "mess" and if we want to clean it up.

Re: Promoting Git developers

[Jeff King]

On Wed, Mar 11, 2015 at 02:28:03PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Or something along those lines. The wording and indentation of the
> > message could probably use tweaking. And there is a bash-ism in the
> > script. :)
> 
> OK, I've updated the Announce script on the 'todo' branch.  The
> announcement for 2.3.2 I sent out earlier as $gmane/264975 would
> have looked like this.

Thanks, I think the organization and wording you chose look nice. One
minor nit, though:

> The latest maintenance release Git v2.3.2 is now available at the
> usual places.  It comprises of 41 non-merge commits since v2.3.1,
> contributed by 19 people, 5 of which are new faces.

It's not generally considered correct to use "of" with the active tense
of "comprise". So either:

  It comprises 41 non-merge commits...

or:

  It is comprised of 41 non-merge commits...

is fine.  The latter is much more common, at least in American English,
though I imagine it gives some prescriptivists headaches.

> New contributors who made this release possible are as follows.
> Welcome to the Git development community!
> 
>   Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt,
>   Ryuichi Kokubo, and Tom G. Christensen.

I hadn't thought about it when I originally suggested this, but of
course "new" is not strictly meaningful in a world with branches. If you
contribute a bugfix on top of v2.0.0 that goes to "maint", do you get to
be new in v2.0.1 _and_ in v2.2.0?

I do not think it matters too much either way in practice, but I guess
it would depend on your approach (picking the "old" base manually, or by
using all tags prior to the released version).

-Peff

Re: Promoting Git developers

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>   It is comprised of 41 non-merge commits...
>
> is fine.

Thanks; very much appreciated.

>> New contributors who made this release possible are as follows.
>> Welcome to the Git development community!
>> 
>>   Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt,
>>   Ryuichi Kokubo, and Tom G. Christensen.
>
> I hadn't thought about it when I originally suggested this, but of
> course "new" is not strictly meaningful in a world with branches. If you
> contribute a bugfix on top of v2.0.0 that goes to "maint", do you get to
> be new in v2.0.1 _and_ in v2.2.0?

Yeah, tricky.  How about

    New contributors whose contributions weren't in $previous are as follows.
    Welcome to the Git development community!

Then after merging a topic to 'master' and then 'maint' and when
cutting v2.3.3, a new person will be listed as "not in v2.3.2" and
then again in the announcement for v2.4.0, as "not in v2.3.0".

Yes, it is cheating, but that would match the story the shortlog at
the end would tell.

Re: Promoting Git developers

[Jeff King]

On Wed, Mar 11, 2015 at 10:05:43PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I spent many years as a "type C" contributor, and I remember how nice it
> > was to see my name mentioned occasionally as a useful person.
> 
> I guess that everybody is different ;-)
> 
> After throwing a small patch at ROCKbox (git.rockbox.org) back when
> they were still hosted on Subversion, I felt somewhat ashamed to see
> my name appear in their CREDITS file because the change I made was
> so insignificant. In such a flat list like that, you cannot tell who
> made significant contributions over time and who are just a casual
> drive-by contributor like me, unless you know the community and who
> are important in the community.

Heh. Actually, after writing that, I almost clarified, but did not think
anybody was that interested. But since you replied...:)

Seeing my name in "shortlog" was nice, but not that exciting. I
submitted a patch, it was taken, and of course it ends up in any
automated lists of authors. What was much more rewarding was being
mentioned specifically in "A note from the maintainer" as a helpful
person. That had much more value because:

  1. It was one of a handful of names.

  2. It was picked by a human.

So in that sense, it is quite the opposite of including shortlog output
in the release announcements (I still think the shortlog thing we have
been discussing is a good thing, but not at the same level). I do not
know that it is worth having a "Best of 2015" Git awards ceremony, but
it is sometimes nice to thank people personally when you appreciate
their efforts. I sometimes mail people off-list to do so.

-Peff

Re: Promoting Git developers

[Jeff King]

On Thu, Mar 12, 2015 at 03:36:46PM -0700, Junio C Hamano wrote:

> > I hadn't thought about it when I originally suggested this, but of
> > course "new" is not strictly meaningful in a world with branches. If you
> > contribute a bugfix on top of v2.0.0 that goes to "maint", do you get to
> > be new in v2.0.1 _and_ in v2.2.0?
> 
> Yeah, tricky.  How about
> 
>     New contributors whose contributions weren't in $previous are as follows.
>     Welcome to the Git development community!

Yeah, that makes a lot of sense to me, and then we can have it in both
places. I suspect the releases from "master" get a lot more readers, but
if we had to pick only one, people with bugfixes would generally be
mentioned in "maint" announcements.

-Peff

Re: Promoting Git developers

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Seeing my name in "shortlog" was nice, but not that exciting. I
> submitted a patch, it was taken, and of course it ends up in any
> automated lists of authors. What was much more rewarding was being
> mentioned specifically in "A note from the maintainer" as a helpful
> person. That had much more value because:
>
>   1. It was one of a handful of names.
>
>   2. It was picked by a human.
>
> So in that sense, it is quite the opposite of including shortlog output
> in the release announcements (I still think the shortlog thing we have
> been discussing is a good thing, but not at the same level).

Yes, and that cuts both ways, unfortunately. There always will be "I
am doing more reviews than X and my reviews are higher quality. Why
was X singled out and got thanked but not me?", "X is really doing a
good job reviewing in this cycle, but could other people who send
reviews of lessor quality (to my mind) feel that it is unjustified
if I thanked X and nobody else?", etc. A mechanically generated list
avoids these issues, but the satisfaction you get from being on the
list is not very high, exactly because it is not hand picked.

> I do not know that it is worth having a "Best of 2015" Git awards
> ceremony, but it is sometimes nice to thank people personally when
> you appreciate their efforts. I sometimes mail people off-list to
> do so.

Yeah, I do the same, but revealing that we do so would defeat what
we tried to achieve by doing so off-list in the first place. Now
those who haven't got such a piece of e-mail for a while can start
to suspect that they have fallen out of favour or something ;-(.

Re: Promoting Git developers

[Christian Couder]

On Wed, Mar 11, 2015 at 9:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> I would suspect that those who agree with you would appreciate if
>>> you or somebody volunteered to act as our CKDO (chief kudos
>>> distribution officer).  I do not think I have enough time to do that
>>> well.  One good place to start might be to scan the list and
>>> summarize something like the following on weekly or monthly basis,
>>> as these are not something you can get by pointing people to "git
>>> shortlog" output.
>>>
>>>  - Those who gave helpful review comments, "how about going this
>>>    way" illustration patches, etc.  Bonus points to those who helped
>>>    onboarding newcomers.
>>>
>>>  - Those who asked pertinent questions on common pain points, and
>>>    those who answered them helpfully.
>>
>> Ok, I can start something about this two points every week or every
>> few week. It would be best if I could get help from at least one
>> person as I think it is a lot of work.
>
> No kidding; even though it may no longer be an impossibly large task
> as in the infrationary epoch reported in the Git Traffic, this forum
> is still a high traffic place.

I wrote something about a potential Git Rev News news letter:

https://github.com/git/git.github.io/pull/15

Peff, could you give me write access so that I don't need to send pull requests?
If some people are interested to contribute even if it is only
sporadically, I would suggest they ask for write access too.

>> I also appreciate very much that you are willing to improve the
>> release notes by adding a summary with people's names.
>
> Just in case you misunderstood, I do not think it is a good idea to
> add names to release notes and I will not do so.
>
> I was and am planning add the list of contributors at the end of the
> e-mail when the release notes is sent out, i.e. in the "Announce"
> message that is sent to the list (and CC'ed to lwn.net).

Ok, that is already very nice.

Thanks,
Christian.

Re: Promoting Git developers

[Christian Couder]

On Thu, Mar 12, 2015 at 11:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> Seeing my name in "shortlog" was nice, but not that exciting. I
>> submitted a patch, it was taken, and of course it ends up in any
>> automated lists of authors. What was much more rewarding was being
>> mentioned specifically in "A note from the maintainer" as a helpful
>> person. That had much more value because:
>>
>>   1. It was one of a handful of names.
>>
>>   2. It was picked by a human.
>>
>> So in that sense, it is quite the opposite of including shortlog output
>> in the release announcements (I still think the shortlog thing we have
>> been discussing is a good thing, but not at the same level).
>
> Yes, and that cuts both ways, unfortunately. There always will be "I
> am doing more reviews than X and my reviews are higher quality. Why
> was X singled out and got thanked but not me?", "X is really doing a
> good job reviewing in this cycle, but could other people who send
> reviews of lessor quality (to my mind) feel that it is unjustified
> if I thanked X and nobody else?", etc. A mechanically generated list
> avoids these issues, but the satisfaction you get from being on the
> list is not very high, exactly because it is not hand picked.

I think it is still much better to have some people positively hand
picked than nothing.
People who have not been hand picked despite having done something
they think is of the same or higher quality can always ask privately
about the reason they haven't been hand picked or they can try again
expecting that the outcome will be different next time.

Anyway if some people are positively hand picked you can always hope
that it will happen to you, while otherwise there is no hope at all.

>> I do not know that it is worth having a "Best of 2015" Git awards
>> ceremony, but it is sometimes nice to thank people personally when
>> you appreciate their efforts. I sometimes mail people off-list to
>> do so.
>
> Yeah, I do the same, but revealing that we do so would defeat what
> we tried to achieve by doing so off-list in the first place. Now
> those who haven't got such a piece of e-mail for a while can start
> to suspect that they have fallen out of favour or something ;-(.

I don't think it defeat anything. I think you could even do it more online.

Best,
Christian.

Re: Promoting Git developers

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> I wrote something about a potential Git Rev News news letter:

I read it.  Sounds promising.

Just one suggestion on the name and half a comment.

How would "Git Review" (or "Git Monthly Review", or replace your
favourite "how-often-per-period-ly" in its name) sound?  I meant it
to sound similar to academic journals that summarize and review
contemporary works in the field and keeps your original "pun" about
our culture around "patch reviews".

I obviously do not know how the actual contents would look like at
this point, but depending on the quality of the publication I might
be able to steal some descriptions when keeping the notes on topics
in flight that appear in my "What's cooking" report.  And it can go
the other way around, too.  The publication may want to peek my
"What's cooking" report for hints on how to characterize each topic
and assess its impact to the evolution of Git.

RE: Promoting Git developers

[Randall S. Becker]

> On March 15, 2015 6:19 PM Christian Couder wrote:
<snip>
> Just one suggestion on the name and half a comment.
> 
> How would "Git Review" (or "Git Monthly Review", or replace your favourite
> "how-often-per-period-ly" in its name) sound?  I meant it to sound similar
to
> academic journals that summarize and review contemporary works in the
field
> and keeps your original "pun" about our culture around "patch reviews".

If I may humbly offer the suggestion that "Git Blame" would be a far more
appropriate pun as a name :)

Re: Promoting Git developers

[Christian Couder]

On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker
<rsbecker@nexbridge.com> wrote:
>> On March 15, 2015 6:19 PM Christian Couder wrote:
> <snip>
>> Just one suggestion on the name and half a comment.
>>
>> How would "Git Review" (or "Git Monthly Review", or replace your favourite
>> "how-often-per-period-ly" in its name) sound?  I meant it to sound similar
> to
>> academic journals that summarize and review contemporary works in the
> field
>> and keeps your original "pun" about our culture around "patch reviews".

I would be ok for that but there is already this Gerrit related command:

http://www.mediawiki.org/wiki/Gerrit/git-review

Maybe I can just use "Git Rev", but it doesn't tell that it is about news?

> If I may humbly offer the suggestion that "Git Blame" would be a far more
> appropriate pun as a name :)

You don't want me to steal Junio's blog title:

http://git-blame.blogspot.fr/

don't you?

Re: Promoting Git developers

[David Kastrup]

Christian Couder <christian.couder@gmail.com> writes:

> On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker
> <rsbecker@nexbridge.com> wrote:
>>> On March 15, 2015 6:19 PM Christian Couder wrote:
>> <snip>
>>> Just one suggestion on the name and half a comment.
>>>
>>> How would "Git Review" (or "Git Monthly Review", or replace your favourite
>>> "how-often-per-period-ly" in its name) sound?  I meant it to sound similar
>> to
>>> academic journals that summarize and review contemporary works in the
>> field
>>> and keeps your original "pun" about our culture around "patch reviews".
>
> I would be ok for that but there is already this Gerrit related command:
>
> http://www.mediawiki.org/wiki/Gerrit/git-review
>
> Maybe I can just use "Git Rev", but it doesn't tell that it is about news?
>
>> If I may humbly offer the suggestion that "Git Blame" would be a far more
>> appropriate pun as a name :)
>
> You don't want me to steal Junio's blog title:
>
> http://git-blame.blogspot.fr/
>
> don't you?

"Git Annotate"?

-- 
David Kastrup

Re: Promoting Git developers

[Stefan Beller]

On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup <dak@gnu.org> wrote:
>
> "Git Annotate"?
>

"Git Praise" as opposed to blame?
"Git Who" as a pun on the subcommand structure which doesn't always
follows grammar?

Re: Promoting Git developers

[David Lang]

On Sun, 15 Mar 2015, Junio C Hamano wrote:

> Christian Couder <christian.couder@gmail.com> writes:
>
>> I wrote something about a potential Git Rev News news letter:
>
> I read it.  Sounds promising.
>
> Just one suggestion on the name and half a comment.
>
> How would "Git Review" (or "Git Monthly Review", or replace your
> favourite "how-often-per-period-ly" in its name) sound?  I meant it
> to sound similar to academic journals that summarize and review
> contemporary works in the field and keeps your original "pun" about
> our culture around "patch reviews".
>
> I obviously do not know how the actual contents would look like at
> this point, but depending on the quality of the publication I might
> be able to steal some descriptions when keeping the notes on topics
> in flight that appear in my "What's cooking" report.  And it can go
> the other way around, too.  The publication may want to peek my
> "What's cooking" report for hints on how to characterize each topic
> and assess its impact to the evolution of Git.

I'll bet that LWN would publish, or at least link to, such articles on a regular 
basis, and if you end up doing an in-depth writeup on a particularly discussed 
topic, they would probably give it pretty good visibility.

David Lang

Re: Promoting Git developers

[Junio C Hamano]

David Lang <david@lang.hm> writes:

> On Sun, 15 Mar 2015, Junio C Hamano wrote:
>
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>>> I wrote something about a potential Git Rev News news letter:
>>
>> I read it.  Sounds promising.
>>
>> Just one suggestion on the name and half a comment.
>>
>> How would "Git Review" (or "Git Monthly Review", or replace your
>> favourite "how-often-per-period-ly" in its name) sound?  I meant it
>> to sound similar to academic journals that summarize and review
>> contemporary works in the field and keeps your original "pun" about
>> our culture around "patch reviews".
> ...
> I'll bet that LWN would publish, or at least link to, such articles on
> a regular basis, and if you end up doing an in-depth writeup on a
> particularly discussed topic, they would probably give it pretty good
> visibility.

I hope you are right, but my observation of our coverage by lwn.net
is somewhat pessimistic.  In our early days, our progress often used
to appear on the "Kernel Development" page, which I presume is the
most important page of the weekly for the kernel developers, but in
several months, the mention of us has moved two pages back to
"Development" and listed together with folks like OCaml Weekly,
PostgreSQL Weekly, etc.  I would not count that as "pretty good
visibility" particularly.

I am taking it as a positive change, though.  Once we got stable
enough not to be a roadblock for the kernel folks and proven
ourselves not to regress, our progress probably ceased to be
newsworthy to them ;-)

Re: Promoting Git developers

[David Lang]

On Mon, 16 Mar 2015, Junio C Hamano wrote:

> David Lang <david@lang.hm> writes:
>
>> On Sun, 15 Mar 2015, Junio C Hamano wrote:
>>
>>> Christian Couder <christian.couder@gmail.com> writes:
>>>
>>>> I wrote something about a potential Git Rev News news letter:
>>>
>>> I read it.  Sounds promising.
>>>
>>> Just one suggestion on the name and half a comment.
>>>
>>> How would "Git Review" (or "Git Monthly Review", or replace your
>>> favourite "how-often-per-period-ly" in its name) sound?  I meant it
>>> to sound similar to academic journals that summarize and review
>>> contemporary works in the field and keeps your original "pun" about
>>> our culture around "patch reviews".
>> ...
>> I'll bet that LWN would publish, or at least link to, such articles on
>> a regular basis, and if you end up doing an in-depth writeup on a
>> particularly discussed topic, they would probably give it pretty good
>> visibility.
>
> I hope you are right, but my observation of our coverage by lwn.net
> is somewhat pessimistic.  In our early days, our progress often used
> to appear on the "Kernel Development" page, which I presume is the
> most important page of the weekly for the kernel developers, but in
> several months, the mention of us has moved two pages back to
> "Development" and listed together with folks like OCaml Weekly,
> PostgreSQL Weekly, etc.  I would not count that as "pretty good
> visibility" particularly.
>
> I am taking it as a positive change, though.  Once we got stable
> enough not to be a roadblock for the kernel folks and proven
> ourselves not to regress, our progress probably ceased to be
> newsworthy to them ;-)

It ceased to be about kernel development, and fell into the normal development 
bucket :-)

Routine release notes (like your notes from the maintainer) do end up just 
getting links to them as you have seen. But if someone is summarizing the 
discussions on the mailing list, those will be a bit more interesting, and if 
there is a particularly hot topic, the summary of that discussion can be a full 
fledged article on it's own.

David Lang

Re: Promoting Git developers

[Thomas Ferris Nicolaisen]

On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder
<christian.couder@gmail.com> wrote:
>
> I wrote something about a potential Git Rev News news letter:
>
> https://github.com/git/git.github.io/pull/15
>

I would love to have/use something like this in the GitMinutes
podcast. Perhaps in addition to the very random interview format that
I have now, I could do a more regular episodes about Git news, where I
incorporate this.

I also volunteer to help with the production, if you'll allow list
lurkers like myself to contribute ;)

Re: Promoting Git developers

[Christian Couder]

On Tue, Mar 17, 2015 at 10:43 AM, Thomas Ferris Nicolaisen
<tfnico@gmail.com> wrote:
> On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>>
>> I wrote something about a potential Git Rev News news letter:
>>
>> https://github.com/git/git.github.io/pull/15
>>
>
> I would love to have/use something like this in the GitMinutes
> podcast. Perhaps in addition to the very random interview format that
> I have now, I could do a more regular episodes about Git news, where I
> incorporate this.

Yeah, no problem.

> I also volunteer to help with the production, if you'll allow list
> lurkers like myself to contribute ;)

Yes of course, you are very welcome!

Peff, could you also give the rights on the repo to Thomas?

Thanks both,
Christian.

Re: Promoting Git developers

[Christian Couder]

On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller <sbeller@google.com> wrote:
> On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup <dak@gnu.org> wrote:
>>
>> "Git Annotate"?
>
> "Git Praise" as opposed to blame?
> "Git Who" as a pun on the subcommand structure which doesn't always
> follows grammar?

Yeah these suggestions above are nice, thanks for them, but "Git Rev News"
also look a bit like "git rev-list" and "git rev-parse" which are plumbing Git
commands, so it gives a somewhat "hardcore" look to the news letter which
I like.

Thanks,
Christian.

Re: Promoting Git developers

[Christian Couder]

On Sun, Mar 15, 2015 at 11:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> I wrote something about a potential Git Rev News news letter:
>
> I read it.  Sounds promising.

Thanks!

[...]

> I obviously do not know how the actual contents would look like at
> this point, but depending on the quality of the publication I might
> be able to steal some descriptions when keeping the notes on topics
> in flight that appear in my "What's cooking" report.  And it can go
> the other way around, too.  The publication may want to peek my
> "What's cooking" report for hints on how to characterize each topic
> and assess its impact to the evolution of Git.

Yeah, it would be a very nice thing if we could steal these kind of
things from each other's work!

Thanks,
Christian.

Re: Promoting Git developers

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup <dak@gnu.org> wrote:
>>>
>>> "Git Annotate"?
>>
>> "Git Praise" as opposed to blame?
>> "Git Who" as a pun on the subcommand structure which doesn't always
>> follows grammar?
>
> Yeah these suggestions above are nice, thanks for them, but "Git Rev News"
> also look a bit like "git rev-list" and "git rev-parse" which are plumbing Git
> commands, so it gives a somewhat "hardcore" look to the news letter which
> I like.

Call that "Git Rev List" then to be more direct?

I myself liked the "Review" (spelled in full word) as its non-nerdy
sound, as a suitable name for a publication that bridges between
hard-core developers and slightly-more-serious-than-casual
observers, but its not my call (and as I often say, I am not good at
naming things) ;-).