{"thread":{"id":"38740","subject":"Promoting Git developers (was: Bashing freelancers)","startedAt":"2015-03-07T07:18:37Z","lastAt":"2015-03-17T20:16:25Z","messageCount":43,"participants":["Christian Couder","Michael J Gruber","David Kastrup","Philip Oakley","Junio C Hamano","Jason St. John","Duy Nguyen","Jeff King","Andrew Ardill","Fredrik Gustafsson","Randall S. Becker","Stefan Beller","David Lang","Thomas Ferris Nicolaisen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"257228","messageId":"CAP8UFD1+rC0FjisSddDcyn1E_75wtBU9pEpUcQX5zNtd4zKYFQ@mail.gmail.com","threadId":"38740","inReplyTo":null,"subject":"Promoting Git developers (was: Bashing freelancers)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-07T07:18:37Z","receivedAt":"2015-03-07T07:18:37Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Fri, Mar 6, 2015 at 6:41 PM, David Kastrup wrote:\n\n> At some point of time I think it may be worth reevaluating the toxic\n> atmosphere against freelancers doing Git development.\n\nMy opinion on this is that the Git community has not been good\nespecially lately at promoting its own developers.\n\nSome facts:\n\n* There used to be an AUTHORS section in each of the git man page.\nThey have been removed. The rational was that they were hard to\nmaintain and the information about authors was easily available\nelsewhere.\n\n* There used to be a nice page on git-scm.com, the main Git web site,\nlisting the authors and how many commits they had contributed. It has\nbeen removed.\n\n* In the \"A note from the maintainer\" emails that Junio regularly\nsends, the last section about \"Other people's trees, trusted\nlieutenants and credits.\" seems to have been truncated for some time\nand doesn't show anymore the nice \"credits\" words it used to show.\nMaybe this is a bug.\n\n* https://www.openhub.net/p/git/contributors/summary seems to give me a\n\"504 Gateway Time-out\" right now :-(\n\n* On the Git Merge web site, we can see that none of the speakers\nseems to have been a very active contributor to git.git\n\nNone of these facts is a big issue in itself for me, but I think the\ntrend is very sad, and I would be happy if we could discuss here or at\nthe Git Merge (or both) about ways to improve in this area.\n\nBest,\nChristian.\n"},{"id":"257399","messageId":"54FDA6B5.8050505@drmicha.warpmail.net","threadId":"38740","inReplyTo":"CAP8UFD1+rC0FjisSddDcyn1E_75wtBU9pEpUcQX5zNtd4zKYFQ@mail.gmail.com","subject":"Re: Promoting Git developers (was: Bashing freelancers)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-09T13:57:09Z","receivedAt":"2015-03-09T13:57:09Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Christian Couder venit, vidit, dixit 07.03.2015 08:18:\n> Hi,\n> \n> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup wrote:\n> \n>> At some point of time I think it may be worth reevaluating the toxic\n>> atmosphere against freelancers doing Git development.\n> \n> My opinion on this is that the Git community has not been good\n> especially lately at promoting its own developers.\n> \n\nI guess we have at least 3 kinds of people here:\n\nA) Paid to do Git development, at least as part of their job.\nB) Freelancers who don't get paid directly for \"doing git\" but hope to\nprofit from their git efforts directly or indirectly.\nC) Doing it in their freetime (or as minor, inofficial part of their\nnon-programming job).\n\nI'm in camp C and honestly wasn't aware of camp B until now.\n\nI consider camp A to be beneficial for all of us, and I don't think\nspecific employer interests have pushed the project in specific\ndirections, or specific features (OK, maybe one, but not as a rule).\n\nI do see that remuneration is an issue for camp B.\n\n> Some facts:\n> \n> * There used to be an AUTHORS section in each of the git man page.\n> They have been removed. The rational was that they were hard to\n> maintain and the information about authors was easily available\n> elsewhere.\n\nI'd say it's difficult to do this in a fair manner, since most pages are\na community effort now in the best sense.\n\n> * There used to be a nice page on git-scm.com, the main Git web site,\n> listing the authors and how many commits they had contributed. It has\n> been removed.\n\nIt was out of date again and again, and pull-requests took forever. The\nproblem here still seems to be the old dis-connectedness between that\nwebsite and the developers' community. But it's the only one \"we\" have.\n\nSince we're talking business: git-scm.com still looks a bit like a\nProGit/Github promotion site. I don't have anything against either, and\ngit-scm.com provides a lot of the information that users are looking\nfor, and that are hard to find anywhere else; it's a landing page. It\njust does not look like a \"project home\".\n\n> * In the \"A note from the maintainer\" emails that Junio regularly\n> sends, the last section about \"Other people's trees, trusted\n> lieutenants and credits.\" seems to have been truncated for some time\n> and doesn't show anymore the nice \"credits\" words it used to show.\n> Maybe this is a bug.\n\nBeing in camp C, that entry in \"credits\" was my remuneration, so-to-say,\nand I missed it when it was gone. OTOH, I do understand how tedious it\nis to keep that up to date and fair. (And if, I should probably have\nbeen removed at some point...)\n\nThere still is \"git rev-list --count --author=Mickey origin/master\" :)\n\n> * https://www.openhub.net/p/git/contributors/summary seems to give me a\n> \"504 Gateway Time-out\" right now :-(\n\nI thought there is ohloh, but that one is the new ohloh... Anyways,\nJunio's repo on github is \"official\" in a sense and has this:\n\nhttps://github.com/git/git/graphs/contributors\n\n> * On the Git Merge web site, we can see that none of the speakers\n> seems to have been a very active contributor to git.git\n\nYeah, that's more an \"outside business window into git\". In fact, while\nthat doesn't quite intrigue me, I would think it's a great chance for\nfreelancers to get in touch with people doing business with git.\n\nAnd maybe they'll be talking about what they're using git for, and which\ntechnical and non-technical challenges they meet in doing so? Edward was\nfun to listen to in Berlin :)\n\nGit merge itself is organized and sponsored by businesses with business\ninterests. But there's also the contributors summit. Git merge Berlin\nwas great and generous in that respect.\n\n> None of these facts is a big issue in itself for me, but I think the\n> trend is very sad, and I would be happy if we could discuss here or at\n> the Git Merge (or both) about ways to improve in this area.\n\nThere should be a good occasion, after we see how it went, and hopefully\nalso to sort out any apparent misunderstandings from the past that have\nresurfaced in this thread.\n\nMaybe, all we need is badges? [1]\n\nMichael\n\n[1] https://badges.fedoraproject.org/\n"},{"id":"257403","messageId":"87385emedc.fsf@fencepost.gnu.org","threadId":"38740","inReplyTo":"54FDA6B5.8050505@drmicha.warpmail.net","subject":"Re: Promoting Git developers","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2015-03-09T14:31:27Z","receivedAt":"2015-03-09T14:31:27Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Michael J Gruber writes:\n\n> Christian Couder venit, vidit, dixit 07.03.2015 08:18:\n>> Hi,\n>> \n>> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup wrote:\n>> \n>>> At some point of time I think it may be worth reevaluating the toxic\n>>> atmosphere against freelancers doing Git development.\n>> \n>> My opinion on this is that the Git community has not been good\n>> especially lately at promoting its own developers.\n>> \n>\n> I guess we have at least 3 kinds of people here:\n>\n> A) Paid to do Git development, at least as part of their job.\n> B) Freelancers who don't get paid directly for \"doing git\" but hope to\n> profit from their git efforts directly or indirectly.\n> C) Doing it in their freetime (or as minor, inofficial part of their\n> non-programming job).\n>\n> I'm in camp C and honestly wasn't aware of camp B until now.\n\nMy guess is that camp B is dead and intentionally so. For the\nrationale, see for example\n.\nIt is considered tasteless to even mention camp B.\n\n-- \nDavid Kastrup\n"},{"id":"257422","messageId":"57996D0058AA4535AA2B61662D7B3051@PhilipOakley","threadId":"38740","inReplyTo":"87385emedc.fsf@fencepost.gnu.org","subject":"Re: Promoting Git developers","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-03-09T18:02:49Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"David Kastrup\" \n> Michael J Gruber writes:\n>\n>> Christian Couder venit, vidit, dixit 07.03.2015 08:18:\n>>> Hi,\n>>>\n>>> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup wrote:\n>>>\n>>>> At some point of time I think it may be worth reevaluating the \n>>>> toxic\n>>>> atmosphere against freelancers doing Git development.\n>>>\n>>> My opinion on this is that the Git community has not been good\n>>> especially lately at promoting its own developers.\n>>>\n>>\n>> I guess we have at least 3 kinds of people here:\n>>\n>> A) Paid to do Git development, at least as part of their job.\n>> B) Freelancers who don't get paid directly for \"doing git\" but hope \n>> to\n>> profit from their git efforts directly or indirectly.\n>> C) Doing it in their freetime (or as minor, inofficial part of their\n>> non-programming job).\n>>\n>> I'm in camp C and honestly wasn't aware of camp B until now.\n>\n> My guess is that camp B is dead and intentionally so. For the\n> rationale, see for example\n> .\n> It is considered tasteless to even mention camp B.\n>\n\nThere seems to be some talking past each other going on.\n\nA common problem [1] is that the apparent middle ground \"B\" is actually \nsplit two ways, (because A and C are not opposites but embed different \nethos)\n\nThere maybe those B's who are well paid independent programmers, who are \nable to choose how to use their spare time in the same manner as those \nin \"C\".\n\nAnd there are those who, like some of the \"A\"s , need some payment to \nuse their hours to the benefit of Git. This will be particularly true of \nthose who are not well remunerated from their independent work. If they \nare giving up precious work time then they would at least hope for a \nlittle acknowledgment.\n\nTo me it sounds as if Junio is thinking more of the former while David \nis thinking of the latter. These misunderstandings are difficult to \nresolve, or at least reconcile, without a proper understanding of the \nroot causes of the differences.\n\n\n--\nPhilip\n[1] This common problem is summarised in the Competing Values Framework \n(CVF), which is usually applied to management philosophies, but is a \ncommon styling in many disputes and misunderstandings.\n"},{"id":"257449","messageId":"xmqqzj7l1eje.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"54FDA6B5.8050505@drmicha.warpmail.net","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-10T07:45:41Z","receivedAt":"2015-03-10T07:45:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> I guess we have at least 3 kinds of people here:\n>\n> A) Paid to do Git development, at least as part of their job.\n> B) Freelancers who don't get paid directly for \"doing git\" but hope to\n> profit from their git efforts directly or indirectly.\n> C) Doing it in their freetime (or as minor, inofficial part of their\n> non-programming job).\n>\n> I'm in camp C and honestly wasn't aware of camp B until now.\n>\n> I consider camp A to be beneficial for all of us, and I don't think\n> specific employer interests have pushed the project in specific\n> directions, or specific features (OK, maybe one, but not as a rule).\n>\n> I do see that remuneration is an issue for camp B.\n\nAs one of the four things you are not supposed to talk about in a\npolite society, it is indeed hard to talk about money.\n\nLet me digress a bit before coming back to your 3 classes, because\nmoney is hard not only for those who want to receive, but is also\nhard for those who want to pay. I remember having a brief discussion\nduring one of the GitTogether meetings with this person who managed\nGit users at his company. I think it was one of the chip makers\nwhose association with Git was through its involvement with Android,\nbut don't hold me to this, as I do not exactly remember. The\nconversation started with \"How do you get changes to Git?\" and what\nhe ultimately wanted to learn was how a company can enhance Git to\nmake the life of his engineers easier by hiring some Git experts and\nhave them work on missing features.\n\nAs you can guess, the conversation did not get to a satisfactory and\nclear \"here is how you would go about it\". Sure, a company can pay a\ndeveloper to do a feature, but it is impossible to predict if the\nend result will be used by us. For a usual work for hire, the hiring\ncompany can set the evaluation criteria itself, which would be that\nthe end result works with the given version of the base software and\nproduces desired result for the specific workflow the company\nneeds. But the evaluation criteria for a \"contribution\" to us is not\nunder the control of the paying company and the bar the person who\ndoes the work for hire has to cross is different. It of course needs\nto fill the needs of the sponsoring company, but also it needs to be\ncleanly done, maintainable, and it must not harm workflows other\npeople employ, which the sponsoring company may not care about at\nall. That makes it hard for companies to pay a developer to work on\nGit to benefit themselves. It is the same deal for an enterprising\nsoul who would start a crowdfunding campaign \"I'll add this feature\nto Git---if you guys raise this much money\".\n\nThis also makes the involvement of employers in category (A) a\nnuanced one. Because money is not an effective currency to buy\n\"inclusion\", \"Paid to do Git development\" does not equate\n\"Companies pay developers to develop Git in a way to benefit the\nsponsoring companies\". When it comes to working on Git, I, Shawn\nor Jonathan do not get orders from Google management to add funky\nfeatures nobody outside Google would use to help Android [*1*],\nand I doubt that Peff and Michael's job description are to push\nGitHub specific enhancement into our codebase, either [*2*].\n\nThere are different schools of thought on how to support open source\ndevelopment [*3*]. I heard some people dream of \"free software tax\"\nand have public support our endeavor, just like public purse supports\nacademia. We do not live in such world. Some projects pay for bugs\nwith bounty program; I think that would be the closest thing to\nsupport your category (B), and that form of support does not have to\nbe limited to bugs. Projects could buy features in addition to bugs.\n\nBut we are not structured that way, at least so far. If we start to\nbuy features, that would make it even more difficult than the \"My\ncompany wants to fund somebody to add features to Git---how do we go\nabout it?\" case. How do we decide an effort was successful? Would\nthat decision be affected by the fact that we paid for it in the\nfirst place (i.e. declaring a failure would mean we admit that we\nmade a mistake when approving to fund the effort)? When other\ndevelopers think that a feature we bought shouldn't have been bought\nin the first place, what happens? How should conflicts in such\ndecisions be resolved? How would that payment affect people who are\nin category (C), or category (A) for that matter? Faced with two\nreasonable implementations by a bounty hunter and a hobbyist, does\nit enter the equation that one costs and the other is free? Do we\npay everybody to sidestep that issue? Where does the money come\nfrom? Do we want to become a project that employ some developers but\nnot others? Who makes hiring decision and how?\n\nIn short, I agree with you that we are not set up to support bounty\nhunters very well. That might be something we want to change, but I\nam not sure what the endgame would be, if I would like that endgame\nwhen I see it, or what the first step to reach that endgame would\nbe. My gut feeling is that there can be many \"reasonable\" answers to\nall the question marks in the previous paragraph, but I have a vague\napprehension that taken together the answers would lead to a community\nthat is rather uncomfortable to live in, for hobbists and aspiring\nhackers who want to be a part of category (A) alike, but that is\nmerely a vague apprehension at this point.\n\n\n[Footnote]\n\n*1* We however do get inspirations by being in a company that uses\nGit in a way that may be different from the outside world, noticing\npitfalls common to in-house users, their pain points, etc. But we\nknow enough to think about the issues to see if they are common with\nthe outside world before considering to tweak the public version of\nGit.\n\n*2* I started Git from its early days as a category (C) participant,\nbut in later years before I came to Google I was doing Git\neffectively out of my pocket, as I was paid only for the non-Git\ndays and by that time Git maintainership has grown to consume about\nhalf my time. I however do not think I would throw me during those\ndays in category (B) myself. To me, I was still (C) with reduced\nincome. As you would expect, eventually that arragement became\nuntenable. There was a company who benefited from having a healthy\nopen source ecosystem that are supported by Git in the wider world,\nand appreciated that I was not driving the project into ground, and\nit was fortunate that they wanted me to continue. That is how I came\nto be in category (A).\n\n*3* I personally feel that good open source developers should be\nlike court painters. They may paint their employer's children to\nearn their keep even if they did not like doing so, but their output\neventually enriched the wider public. Their employers might have\nbeen leeches who exploited serfs, just like evil corporations in the\nmodern day, and I understand those who oppose my simplistic world\nview.\n"},{"id":"257464","messageId":"CAP8UFD0KNbPBB_dOzw_dAj+ws190_cO8g7_jb_V33x1jxgvnqQ@mail.gmail.com","threadId":"38740","inReplyTo":"54FDA6B5.8050505@drmicha.warpmail.net","subject":"Re: Promoting Git developers (was: Bashing freelancers)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-10T11:51:32Z","receivedAt":"2015-03-10T11:51:32Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Mar 9, 2015 at 2:57 PM, Michael J Gruber\n wrote:\n> Christian Couder venit, vidit, dixit 07.03.2015 08:18:\n>> Hi,\n>>\n>> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup wrote:\n>>\n>>> At some point of time I think it may be worth reevaluating the toxic\n>>> atmosphere against freelancers doing Git development.\n>>\n>> My opinion on this is that the Git community has not been good\n>> especially lately at promoting its own developers.\n>>\n>\n> I guess we have at least 3 kinds of people here:\n>\n> A) Paid to do Git development, at least as part of their job.\n> B) Freelancers who don't get paid directly for \"doing git\" but hope to\n> profit from their git efforts directly or indirectly.\n> C) Doing it in their freetime (or as minor, inofficial part of their\n> non-programming job).\n>\n> I'm in camp C and honestly wasn't aware of camp B until now.\n>\n> I consider camp A to be beneficial for all of us, and I don't think\n> specific employer interests have pushed the project in specific\n> directions, or specific features (OK, maybe one, but not as a rule).\n>\n> I do see that remuneration is an issue for camp B.\n\nFirst thank you for responding to my email. It is great to see that\nsome developers are interested in talking about this.\n\nI am in camp C and I think the people in all the camps are beneficial\nfor all of us.\n\n>> Some facts:\n\n[...]\n\nI don't want to write again about each of these points now. I am more\ninterested in discussing a good strategy to try to revert the sad\ntrend of Git developers being promoted less and less, because I think\nthat it is really very important.\n\n>> None of these facts is a big issue in itself for me, but I think the\n>> trend is very sad, and I would be happy if we could discuss here or at\n>> the Git Merge (or both) about ways to improve in this area.\n>\n> There should be a good occasion, after we see how it went, and hopefully\n> also to sort out any apparent misunderstandings from the past that have\n> resurfaced in this thread.\n>\n> Maybe, all we need is badges? [1]\n>\n> [1] https://badges.fedoraproject.org/\n\nMy opinion is that the big issue is that we should all realize how\nimportant it is to promote the Git developers.\n\nThere are people who say out there that GitHub succeeded mostly\nbecause they easily allowed developers to build a portfolio. I think\nthere is some truth in that. And I think GitHub also says to\ndevelopers that it's good for them to have a nice GitHub portfolio and\nto employers that it's good for them to hire people who have a nice\nGitHub portfolio.\n\nThis shows that the success of GitHub (and so of Git too) is based in\npart on promoting Open Source / Free Software developers.\n\nSo why don't we try to do it more (instead of less) and how could we\ndo it more (instead of less) for the Git developers?\n\nYesterday evening I attended a Docker meeting in Paris [1] where\nJérôme Petazzoni a Docker developer working for Docker gave a talk\nabout Docker storage drivers. In the middle of his talk there were at\nleast 2 slides dedicated to thank some developers who helped make\nDocker work with different filesystems or operating systems. And\nJérôme did stop at least twice to thank these people in the middle of\nhis talk.\n\nWouldn't his talk have been smoother if he had not done that? So why\ndid he do that?\n\nThis reminded me about the following great talk by Julien Barbier the\nCommunity and Marketing guy at Docker:\n\nhttp://www.slideshare.net/julienbarbier42/community-marketing-42674728\n\nI had seen this talk last december at another Docker meetup in Paris\n(and I think it really worth reading the slides or attending the talk\nif Julien gives it again and you can go).\n\nThe slides and the talk keep repeating some sentences because they are\nworth repeating. Some of these sentences are:\n\n* It is about what you can do for your community\n* Belonging, recognition, respect, love\n* Add more links to your community\n* Your product is not what you say it is, it is what THEY say it is\n* It's all about people\n\nIt is especially interesting to have a look at slide 5 where they say\nthat \"Community is the new marketing\" and that Community is 80+% of\ntheir marketing.\n\nAnd it's true that they are really doing a lot for their community.\nFor example the meeting yesterday evening was the 19th docker meeting\nin Paris in two years.\n\nAnd then there is slide 20 about \"Content Strategy\" where there is:\n\n* Encourage your community to build content\n - Say thank you, repost, post, upvote, RT, include them in your\nnewsletter, itw them, …\n - Belonging, Recognition, Respect, Love\n\n* Your team is your community too!\n - Say thank you, gamify, hall of fame, tweet, post, recycle, etc…\n - Belonging, Recognition, Respect, Love\n\nSo we can see that \"saying thank you\" is a big part of their content strategy.\n\nAnd are they successful? Yes, they are very successful as an open\nsource project [2] and as a company.\n\nNow it's up to us, either we keep coming up with excuses not to\npromote developers, or we decide to do something about it.\n\nBest,\nChristian.\n\n[1] http://www.meetup.com/Docker-Paris/events/220891955/\n[2] http://stackshare.io/posts/how-docker-manages-its-massive-open-source-project\n"},{"id":"257479","messageId":"xmqqk2yo22ce.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CAP8UFD0KNbPBB_dOzw_dAj+ws190_cO8g7_jb_V33x1jxgvnqQ@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-10T17:23:45Z","receivedAt":"2015-03-10T17:23:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> I don't want to write again about each of these points now. I am more\n> interested in discussing a good strategy to try to revert the sad\n> trend of Git developers being promoted less and less, because I think\n> that it is really very important.\n\nI would suspect that those who agree with you would appreciate if\nyou or somebody volunteered to act as our CKDO (chief kudos\ndistribution officer). I do not think I have enough time to do that\nwell. One good place to start might be to scan the list and\nsummarize something like the following on weekly or monthly basis,\nas these are not something you can get by pointing people to \"git\nshortlog\" output.\n\n - Those who gave helpful review comments, \"how about going this\n way\" illustration patches, etc. Bonus points to those who helped\n onboarding newcomers.\n\n - Those who asked pertinent questions on common pain points, and\n those who answered them helpfully.\n\nIf you are more ambitious, the source of the kudos may want to cover\nactivities outside of this mailing list (e.g. giving talks and\ntutorials at conferences, etc.).\n"},{"id":"257522","messageId":"CAEjxke-6DuTW0-ZyDtUUdCWhEtuw6x3X6LuM_Fj22QztUvFfjQ@mail.gmail.com","threadId":"38740","inReplyTo":"xmqqk2yo22ce.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Jason St. John","fromEmail":"jstjohn@purdue.edu","sentAt":"2015-03-11T01:04:33Z","receivedAt":"2015-03-11T01:04:33Z","isPatch":false,"sender":{"key":"jstjohn@purdue.edu","avatar":"https://avatars.githubusercontent.com/u/1393510?v=4"},"body":"On Tue, Mar 10, 2015 at 1:23 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>> I don't want to write again about each of these points now. I am more\n>> interested in discussing a good strategy to try to revert the sad\n>> trend of Git developers being promoted less and less, because I think\n>> that it is really very important.\n>\n> I would suspect that those who agree with you would appreciate if\n> you or somebody volunteered to act as our CKDO (chief kudos\n> distribution officer). I do not think I have enough time to do that\n> well. One good place to start might be to scan the list and\n> summarize something like the following on weekly or monthly basis,\n> as these are not something you can get by pointing people to \"git\n> shortlog\" output.\n>\n> - Those who gave helpful review comments, \"how about going this\n> way\" illustration patches, etc. Bonus points to those who helped\n> onboarding newcomers.\n>\n> - Those who asked pertinent questions on common pain points, and\n> those who answered them helpfully.\n>\n> If you are more ambitious, the source of the kudos may want to cover\n> activities outside of this mailing list (e.g. giving talks and\n> tutorials at conferences, etc.).\n>\n\nI don't know how feasible or desirable this would be, but I'll offer\nit anyway. In the Git release notes for something like \"git foo\nlearned a new option --bar\", a simple \"(Thanks|Kudos) to John Smith\"\nat the end of each bullet point may be a good way to recognize\ndevelopers in a concise manner without needing to dig through the\noutput of \"git log\" or \"git shortlog\".\n\nOr if that would make the release notes too cumbersome to review, what\nabout using systemd's method? systemd's release notes include a\n\"contributions from\" section at the very end that lists everyone with\na patch included in the release.\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"257523","messageId":"CACsJy8CHmdSRTfspKfSqtg7VXT7D6uxqr49KQQe8dhE5popakg@mail.gmail.com","threadId":"38740","inReplyTo":"CAEjxke-6DuTW0-ZyDtUUdCWhEtuw6x3X6LuM_Fj22QztUvFfjQ@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-11T02:13:40Z","receivedAt":"2015-03-11T02:13:40Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 11, 2015 at 8:04 AM, Jason St. John wrote:\n> Or if that would make the release notes too cumbersome to review, what\n> about using systemd's method? systemd's release notes include a\n> \"contributions from\" section at the very end that lists everyone with\n> a patch included in the release.\n\nGnome projects do this too. They also separate translators from other\ncontributions, but I don't think if we need to do that. I think the\nreason behind is translations go through the translator coordinator in\ngnome, who does the committing, so \"git shortlog\" does not really list\ntranslators. We may want to acknowledge review efforts as well, by\ngrepping Helped-by:, Reviewed-by:...\n-- \nDuy\n"},{"id":"257524","messageId":"xmqqmw3kuuod.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CAEjxke-6DuTW0-ZyDtUUdCWhEtuw6x3X6LuM_Fj22QztUvFfjQ@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T02:36:34Z","receivedAt":"2015-03-11T02:36:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jason St. John\" writes:\n\n> In the Git release notes for something like \"git foo\n> learned a new option --bar\", a simple \"(Thanks|Kudos) to John Smith\"\n> at the end of each bullet point may be a good way to recognize\n> developers in a concise manner without needing to dig through the\n> output of \"git log\" or \"git shortlog\".\n\nI doubt cluttering the list of features and fixes with peoples'\nnames is such a good idea. Earlier we did not have any detailed\nrelease notes and instead said \"you can go read 'git log'\", which\ndid not help the end users who need to know what changed before or\nafter updating their Git, and I started doing the release notes in\nthe current format to help them. We must not forget that the primary\naudience of this list of features and fixes is the end user. They\nneed a brief birds-eye summary, and the briefer and the cleaner we\nkeep it, the better.\n\nBesides, it will be a lot of work to dig \"log\" for topics and then\ngo back to list archives to see who originally raised the issue\nbefore even the first edition of the patch was written and who\ncontributed the ideas to help the author during the review\ncycles. Doing that for a topic that needed to get rerolled multiple\ntimes will take a lot of work, as the backlinks to previous round of\ndiscussions are often available only in human-readable form. And\nthe list of people who helped will have to be updated when a\nfollow-up bugfix topics are merged [*1*].\n\nAll of the above would add too much busywork on my plate [*2*].\n\nDo people want to see me doing busywork, or spending that time on\nreviewing, suggesting improvements, rejecting crap and applying\npatches [*3*]?\n\n> Or if that would make the release notes too cumbersome to review, what\n> about using systemd's method? systemd's release notes include a\n> \"contributions from\" section at the very end that lists everyone with\n> a patch included in the release.\n\nI can add \"shortlog --no-merges -s -n v2.3.0..v2.4.0\" at the end of\nthe e-mail when the release notes is sent out. That might be a good\nenough balance between the usefulness of the release notes to its\ncustomers and giving credits to individuals in a way a bit more\nvisible than \"if you are interested, run shortlog yourself\" [*4*].\n\nThanks.\n\n\n[Footnote]\n\n*1* Anybody remember \"Git traffic\" [*5*]? There was this great guy\nwho have been summarizing the kernel traffic and soon after Git\nproject started he did one edition of \"Git traffic\", summarizing a\nfew weeks' worth of Git mailing list discussions, who came up with\nwhat idea, how that idea was discarded, what decisions were made, in\nreadble form. Unfortunately, there was only a single edition of \"Git\ntraffic\" ever published---and I can understand why. During that\n\"inflation\" age of Git, we discussed so many topics and so much was\nachieved in a very short period of time. It would have been\nimpossible for any single person to follow and report on all that\nwas happening in the Git land, unless that person wasn't Linus or me\nor a handful of other people---but all of us were too busy with the\ndiscussion and programming to do a summary. I really wished the\npublication continued, but that was wishing for an impossible.\n\nIf you want the point-by-point kudos, you do need somebody who can\ninvest time to do a good job at this, and that person cannot be me\nor anybody who commits text to the release notes but an attentive\nand devoted reporter. An algorithm would not cut it. I suspect that\na workflow \"improvement\" to help a dumb tool to automatically\nproduce it would be too constricting and will slow me down.\n\n*2* What we need is a group of people who are interested in this\nenough to volunteer themselves to keep helping whatever kudo-giving\nthat is needed in an ongoing basis. We do not need people who pile\nmore on _my_ plate telling _me_ how to make the world better for\nthem and then go away without doing anything themselves. We can find\nthem dozen a dime and they won't help this project run any smoother.\n\n*3* Rhetorical question. I have long learned that the key to make\nsure the project runs smoothly is to push as much work off of my\nplate to make sure I won't become the bottleneck.\n\n*4* Note that it does not capture anything but \"these people did the\nfinal versions of the patches\". We would not be giving credit to\nothers who may have offered crucial insights to help these people.\nBut that would give the same amount of rough estimate as the old\ncontributors' list Christian misses from git-scm.com, and it might\nbe good enough for somebody to see his name on it and feel good\nabout it.\n\n*5* The site is gone, but wayback machine has a copy.\n\nhttps://web.archive.org/web/20050514083018/http://www.kerneltraffic.org/git/gt20050502_1.html\n"},{"id":"257531","messageId":"xmqqd24g6uf1.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CACsJy8CHmdSRTfspKfSqtg7VXT7D6uxqr49KQQe8dhE5popakg@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T04:16:02Z","receivedAt":"2015-03-11T04:16:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> ... We may want to acknowledge review efforts as well, by\n> grepping Helped-by:, Reviewed-by:...\n\nAgreed. Something along the lines of \n\n $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0..\n 6 4 0 Michael Haggerty\n 3 0 1 Jeff King\n 3 2 1 Junio C Hamano\n 1 0 0 Anders Kaseorg\n 1 0 0 Ben Walton\n 1 0 0 Jean-Noel Avila\n 1 0 0 Michael J Gruber\n 1 0 0 Michal Sojka\n 1 0 0 Mikko Rapeli\n 1 0 0 Mårten Kongstad\n 1 0 0 Nguyễn Thái Ngọc Duy\n 1 0 7 Stefan Beller\n\nthat gives the number of trailer entries specified with -t in the\norder specified when doing the short/abbreviated form may be a good\nthing to have. The output can be piped to \"sort -k\" and \"cut\" to be\ncooked in any way.\n\nFor completeness, in the long form, the extra numbers probably would\ncome next to names of the individual:\n\n $ git shortlog --no-merges -n -t Helped-by -t Reviewed-by v2.3.0..\n Michael Haggerty (6, 4, 0):\n write_ref_sha1(): remove check for lock == NULL\n write_ref_sha1(): move write elision test to callers\n lock_ref_sha1_basic(): do not set force_write for missing references\n reflog: improve and update documentation\n reflog_expire(): ignore --updateref for symbolic references\n reflog_expire(): never update a reference to null_sha1\n\n Jeff King (3, 0, 1):\n gettext.c: move get_preferred_languages() from http.c\n diffcore-rename: split locate_rename_dst into two functions\n diffcore-rename: avoid processing duplicate destinations\n ...\n\nThe long format needs to be careful not to drop those who helped\nothers without any commit under their own names.\n"},{"id":"257543","messageId":"20150311073129.GA5947@peff.net","threadId":"38740","inReplyTo":"xmqqmw3kuuod.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-11T07:31:29Z","receivedAt":"2015-03-11T07:31:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote:\n\n> > Or if that would make the release notes too cumbersome to review, what\n> > about using systemd's method? systemd's release notes include a\n> > \"contributions from\" section at the very end that lists everyone with\n> > a patch included in the release.\n> \n> I can add \"shortlog --no-merges -s -n v2.3.0..v2.4.0\" at the end of\n> the e-mail when the release notes is sent out. That might be a good\n> enough balance between the usefulness of the release notes to its\n> customers and giving credits to individuals in a way a bit more\n> visible than \"if you are interested, run shortlog yourself\" [*4*].\n\nI somehow thought you already did this, but it looks like you just do\nshortlog (without the \"-ns\") for the \"maint\" release announcement. This\ndoes seem like a very simple thing we could to promote visibility of\ncontributors, and one would that would not require any ongoing effort\nonce it is initially scripted. It may even be a nice place to\nspecifically call out contributors who are new in this release.\n\nI spent many years as a \"type C\" contributor, and I remember how nice it\nwas to see my name mentioned occasionally as a useful person.\n\n-Peff\n"},{"id":"257544","messageId":"CAPc5daUVVk+SYgwCj9JftzXgV7=9kPprdBPCWHS5XQOa5uF69Q@mail.gmail.com","threadId":"38740","inReplyTo":"20150311073129.GA5947@peff.net","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T07:38:21Z","receivedAt":"2015-03-11T07:38:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Wed, Mar 11, 2015 at 12:31 AM, Jeff King wrote:\n> On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote:\n>\n>> > Or if that would make the release notes too cumbersome to review, what\n>> > about using systemd's method? systemd's release notes include a\n>> > \"contributions from\" section at the very end that lists everyone with\n>> > a patch included in the release.\n>>\n>> I can add \"shortlog --no-merges -s -n v2.3.0..v2.4.0\" at the end of\n>> the e-mail when the release notes is sent out. That might be a good\n>> enough balance between the usefulness of the release notes to its\n>> customers and giving credits to individuals in a way a bit more\n>> visible than \"if you are interested, run shortlog yourself\" [*4*].\n>\n> I somehow thought you already did this, but it looks like you just do\n> shortlog (without the \"-ns\") for the \"maint\" release announcement.\n\nThat is because (a) it is scripted in Meta/Announce, and (b) I strip it\nout for feature releases, as the plain shortlog output with full feature\nlist is usually ends up being just too long for the announce message.\n\nPerhaps I'll add \"shortlog -s | pr -3\" or something at the end for both\nmaintenance track and feature releases. Names only, unordered and\nhopefully not overly long.\n"},{"id":"257546","messageId":"20150311075429.GA10300@peff.net","threadId":"38740","inReplyTo":"CAPc5daUVVk+SYgwCj9JftzXgV7=9kPprdBPCWHS5XQOa5uF69Q@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-11T07:54:29Z","receivedAt":"2015-03-11T07:54:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2015 at 12:38:21AM -0700, Junio C Hamano wrote:\n\n> >> I can add \"shortlog --no-merges -s -n v2.3.0..v2.4.0\" at the end of\n> >> the e-mail when the release notes is sent out. That might be a good\n> >> enough balance between the usefulness of the release notes to its\n> >> customers and giving credits to individuals in a way a bit more\n> >> visible than \"if you are interested, run shortlog yourself\" [*4*].\n> >\n> > I somehow thought you already did this, but it looks like you just do\n> > shortlog (without the \"-ns\") for the \"maint\" release announcement.\n> \n> That is because (a) it is scripted in Meta/Announce, and (b) I strip it\n> out for feature releases, as the plain shortlog output with full feature\n> list is usually ends up being just too long for the announce message.\n\nYeah, I figured the length was the reason.\n\n> Perhaps I'll add \"shortlog -s | pr -3\" or something at the end for both\n> maintenance track and feature releases. Names only, unordered and\n> hopefully not overly long.\n\nYes, I was thinking something along those lines. Maybe:\n\n # example\n old=v2.2.0\n new=v2.3.0\n\n # like \"shortlog -s\", but we do not even care about the numbers\n shortlog () {\n\tgit log --format=%aN \"$@\" | sort -u\n }\n\n compact () {\n\tperl -lne 'push @x, $_; END { print join(\", \", @x) }' |\n\tfold -s\n }\n\n count () {\n\tshortlog $old..$new | wc -l\n }\n\n newbies () {\n\tcomm -23 <(shortlog $old..$new) <(shortlog $old) | compact\n }\n\n oldtimers () {\n\tcomm -12 <(shortlog $old..$new) <(shortlog $old) | compact\n }\n\n cat < wrote:\n> Christian Couder writes:\n>\n>> I don't want to write again about each of these points now. I am more\n>> interested in discussing a good strategy to try to revert the sad\n>> trend of Git developers being promoted less and less, because I think\n>> that it is really very important.\n>\n> I would suspect that those who agree with you would appreciate if\n> you or somebody volunteered to act as our CKDO (chief kudos\n> distribution officer). I do not think I have enough time to do that\n> well. One good place to start might be to scan the list and\n> summarize something like the following on weekly or monthly basis,\n> as these are not something you can get by pointing people to \"git\n> shortlog\" output.\n>\n> - Those who gave helpful review comments, \"how about going this\n> way\" illustration patches, etc. Bonus points to those who helped\n> onboarding newcomers.\n>\n> - Those who asked pertinent questions on common pain points, and\n> those who answered them helpfully.\n\nOk, I can start something about this two points every week or every\nfew week. It would be best if I could get help from at least one\nperson as I think it is a lot of work.\n\nWe can perhaps use the Git Developer Site at\nhttps://github.com/git/git.github.io to edit a new page\ncollaboratively that would be published on http://git.github.io/ and\nafter that send an email to the mailing list.\n\n> If you are more ambitious, the source of the kudos may want to cover\n> activities outside of this mailing list (e.g. giving talks and\n> tutorials at conferences, etc.).\n\nFirst I don't know if we should really give kudos (or badges) or have\nsomething more like the former Git Traffic you talk about in another\nemail (or perhaps both).\n\nAnd then I expect that if people give talks or tutorials at\nconferences or publish a blog post or have other news they want to\nshare, they could edit the web page themselves on GitHub (or fork it\nand send a pull request if they don't have the rights).\n\nI also appreciate very much that you are willing to improve the\nrelease notes by adding a summary with people's names.\n\nIt would be nice if we could also have somewhere on a web page at\nleast a good listing of the authors and how many commits they had\ncontributed (since the beginning and maybe also during the last year).\nWe could also add other listings made using the Helped-by and\nReviewed-by trailers.\n\nI don't think we should rely on an external web site like OpenHub\n(which is still giving me a 504 Gateway Time-out on the contributor\npage) or even the (broken) contributor graph on GitHub for that. If\nScott and Peff don't want it on git-scm.com then it is of course\nbetter on git.github.io than nowhere.\n\nThanks,\nChristian.\n"},{"id":"257569","messageId":"xmqqfv9b5krc.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CAP8UFD37v_zOjRkUPLy-ChDs=+NetsDY7Q14-4rYA-WhnTRYyA@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T20:42:15Z","receivedAt":"2015-03-11T20:42:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano wrote:\n>>\n>> I would suspect that those who agree with you would appreciate if\n>> you or somebody volunteered to act as our CKDO (chief kudos\n>> distribution officer). I do not think I have enough time to do that\n>> well. One good place to start might be to scan the list and\n>> summarize something like the following on weekly or monthly basis,\n>> as these are not something you can get by pointing people to \"git\n>> shortlog\" output.\n>>\n>> - Those who gave helpful review comments, \"how about going this\n>> way\" illustration patches, etc. Bonus points to those who helped\n>> onboarding newcomers.\n>>\n>> - Those who asked pertinent questions on common pain points, and\n>> those who answered them helpfully.\n>\n> Ok, I can start something about this two points every week or every\n> few week. It would be best if I could get help from at least one\n> person as I think it is a lot of work.\n\nNo kidding; even though it may no longer be an impossibly large task\nas in the infrationary epoch reported in the Git Traffic, this forum\nis still a high traffic place.\n\n> I also appreciate very much that you are willing to improve the\n> release notes by adding a summary with people's names.\n\nJust in case you misunderstood, I do not think it is a good idea to\nadd names to release notes and I will not do so.\n\nI was and am planning add the list of contributors at the end of the\ne-mail when the release notes is sent out, i.e. in the \"Announce\"\nmessage that is sent to the list (and CC'ed to lwn.net).\n"},{"id":"257570","messageId":"xmqqbnjz5in0.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"20150311075429.GA10300@peff.net","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T21:28:03Z","receivedAt":"2015-03-11T21:28:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Or something along those lines. The wording and indentation of the\n> message could probably use tweaking. And there is a bash-ism in the\n> script. :)\n\nOK, I've updated the Announce script on the 'todo' branch. The\nannouncement for 2.3.2 I sent out earlier as $gmane/264975 would\nhave looked like this.\n\n-- >8 --\nTo: git@vger.kernel.org\nCc: Linux Kernel \nBcc: lwn@lwn.net\nSubject: [ANNOUNCE] Git v2.3.2\n\nThe latest maintenance release Git v2.3.2 is now available at the\nusual places. It comprises of 41 non-merge commits since v2.3.1,\ncontributed by 19 people, 5 of which are new faces.\n\nThe tarballs are found at:\n\n https://www.kernel.org/pub/software/scm/git/\n\nThe following public repositories all have a copy of the 'v2.3.2'\ntag and the 'maint' branch that the tag points at:\n\n url = https://kernel.googlesource.com/pub/scm/git/git\n url = git://repo.or.cz/alt-git.git\n url = https://code.google.com/p/git-core/\n url = git://git.sourceforge.jp/gitroot/git-core/git.git\n url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n url = https://github.com/gitster/git\n\nNew contributors who made this release possible are as follows.\nWelcome to the Git development community!\n\n Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt,\n Ryuichi Kokubo, and Tom G. Christensen.\n\nReturning contributors who helped this release are as follows.\nThanks for your continued support.\n\n Alexander Kuleshov, Eric Sunshine, Jeff King, Jonathon Mah,\n Junio C Hamano, Kirill A. Shutemov, Kyle J. McKay, Matthieu Moy,\n Mike Hommey, Ramsay Allan Jones, René Scharfe, Stefan Beller,\n Torsten Bögershausen, and Дилян Палаузов.\n\n----------------------------------------------------------------\n\nGit v2.3.2 Release Notes\n========================\n\nFixes since v2.3.1\n------------------\n\n * \"update-index --refresh\" used to leak when an entry cannot be\n refreshed for whatever reason.\n\n ...\n\n * Even though we officially haven't dropped Perl 5.8 support, the\n Getopt::Long package that came with it does not support \"--no-\"\n prefix to negate a boolean option; manually add support to help\n people with older Getopt::Long package.\n\nAlso contains typofixes, documentation updates and trivial code clean-ups.\n\n----------------------------------------------------------------\n\nChanges since v2.3.1 are as follows:\n\nAleksander Boruch-Gruszecki (1):\n merge-file: correctly open files when in a subdir\n\nAleksey Vasenev (1):\n wincred: fix get credential if username has \"@\"\n\n...\n\nДилян Палаузов (1):\n do not include the same header twice\n"},{"id":"257576","messageId":"CAH5451=S-1ybt6g0tvVjQFZW4-PCK7i_5x09sbJ95109PFZGmw@mail.gmail.com","threadId":"38740","inReplyTo":"xmqqbnjz5in0.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2015-03-11T23:17:59Z","receivedAt":"2015-03-11T23:17:59Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 12 March 2015 at 08:28, Junio C Hamano wrote:\n> OK, I've updated the Announce script on the 'todo' branch. The\n> announcement for 2.3.2 I sent out earlier as $gmane/264975 would\n> have looked like this.\n\nI think the changes are excellent, and think they add a lot of value\nregardless of any other measures that might be introduced, such as Git\nTraffic.\n\nAt the least it gives long time lurkers, and people who skim the list,\nan easy way to put 'names to code', and it promotes the very people\nwho should be promoted.\n\nThanks to everyone involved in making this happen.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"257581","messageId":"CACsJy8D38Lx5zvpOGPvnYVNXh4EYbF+rLL8kwb9pwP7EqCqfxQ@mail.gmail.com","threadId":"38740","inReplyTo":"xmqqd24g6uf1.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-12T02:15:43Z","receivedAt":"2015-03-12T02:15:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> ... We may want to acknowledge review efforts as well, by\n>> grepping Helped-by:, Reviewed-by:...\n>\n> Agreed. Something along the lines of\n>\n> $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0..\n\nA quick grep/uniq/sort gives this\n\n 1512 Acked-by\n 537 Reviewed-by\n 389 Reported-by\n 317 Helped-by\n 147 Tested-by\n 143 Suggested-by\n 97 Noticed-by\n 78 Improved-by\n 49 Thanks-to\n 40 Mentored-by\n 23 Requested-by\n 21 Acked-By\n 20 Inspired-by\n 18 Based-on-patch-by\n 9 Explained-by\n 9 Contributions-by\n\nIt looks like people are quite creative. I think all these \"*-by\" (so\n-t supports wildcards) and Thanks-to: could be also considered as\ncontribution.\n-- \nDuy\n"},{"id":"257582","messageId":"xmqqbnjy4y0t.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CACsJy8D38Lx5zvpOGPvnYVNXh4EYbF+rLL8kwb9pwP7EqCqfxQ@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-12T04:53:22Z","receivedAt":"2015-03-12T04:53:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano wrote:\n>> Duy Nguyen writes:\n>>\n>>> ... We may want to acknowledge review efforts as well, by\n>>> grepping Helped-by:, Reviewed-by:...\n>>\n>> Agreed. Something along the lines of\n>>\n>> $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0..\n>\n> A quick grep/uniq/sort gives this\n>\n> 1512 Acked-by\n> 537 Reviewed-by\n> 389 Reported-by\n> 317 Helped-by\n> 147 Tested-by\n> 143 Suggested-by\n> 97 Noticed-by\n> 78 Improved-by\n> 49 Thanks-to\n> 40 Mentored-by\n> 23 Requested-by\n> 21 Acked-By\n> 20 Inspired-by\n> 18 Based-on-patch-by\n> 9 Explained-by\n> 9 Contributions-by\n>\n> It looks like people are quite creative. I think all these \"*-by\" (so\n> -t supports wildcards) and Thanks-to: could be also considered as\n> contribution.\n\nI'd first suggest to employ \"icase\" to unify *-By and *-by. Perhaps\nwe would want a recommended list somewhere in SubmittingPatches to\ndiscourage people from getting too creative?\n\n\"Acked\" and \"Reviewed\" would be part of the normal review process.\n\n\"Reported\", \"Requested\", \"Noticed\", \"Suggested\", \"Inspired\", and\n\"Based-on-patch-by\" are about where the motivation to make the\nchange came from. They try to express modes of communication and\ndegree of involvement of the named person in the process of\ngerminating an idea, and the nature of the change (is it a bug or is\nit an improvement?), but I wonder if we can standardize these into\njust a few (or just one) by shedding the various nuances. If the\ndifference these various phrases try to convey is so important, it\nprobably deserves to be in the log message proper (e.g. instead of\n\"Inspired-by\", say \"In his blog at $URL, ... expressed frustration\nin doing ...; this will solve that issue in such and such way\" in\nthe log, and use the standard trailer that designates where the idea\ncame from).\n\nPeople named by these trailers are the ones that connect us to end\nusers by noticing and relaying their pain points, and by working\nwith us to improve Git. We would want to credit them no less than\nwe do an author of a casual \"here is a typofix in a comment\" patch.\n\nAnd everything else above looks \"Helped-by\" to me. Again, the\ndifferent phrases try to convey what kind of help in polishing the\nchange was, but if that is worth expressing, it probably belongs to\nthe log message itself (e.g. instead of \"Explained-by\", say \"The\nabove explanation was given by ... in $gmane/1369525\" in the log\nmessage and use \"Helped-by\").\n"},{"id":"257583","messageId":"xmqq61a64xg8.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"20150311073129.GA5947@peff.net","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-12T05:05:43Z","receivedAt":"2015-03-12T05:05:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I spent many years as a \"type C\" contributor, and I remember how nice it\n> was to see my name mentioned occasionally as a useful person.\n\nI guess that everybody is different ;-)\n\nAfter throwing a small patch at ROCKbox (git.rockbox.org) back when\nthey were still hosted on Subversion, I felt somewhat ashamed to see\nmy name appear in their CREDITS file because the change I made was\nso insignificant. In such a flat list like that, you cannot tell who\nmade significant contributions over time and who are just a casual\ndrive-by contributor like me, unless you know the community and who\nare important in the community.\n"},{"id":"257584","messageId":"20150312074511.GB12418@paksenarrion.iveqy.com","threadId":"38740","inReplyTo":"xmqqbnjy4y0t.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2015-03-12T07:45:11Z","receivedAt":"2015-03-12T07:45:11Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote:\n> I'd first suggest to employ \"icase\" to unify *-By and *-by. Perhaps\n> we would want a recommended list somewhere in SubmittingPatches to\n> discourage people from getting too creative?\n\nThere's already such list in SubmittingPatches, so there's already quite\na few to choose from:\n\nAlso notice that a real name is used in the Signed-off-by: line. Please\ndon't hide your real name.\n\nIf you like, you can put extra tags at the end:\n\n1. \"Reported-by:\" is used to credit someone who found the bug that\n\tthe patch attempts to fix.\n2. \"Acked-by:\" says that the person who is more familiar with the\n\tarea the patch attempts to modify liked the patch.\n3. \"Reviewed-by:\", unlike the other tags, can only be offered by\n\tthe reviewer and means that she is completely satisfied that the\n\tpatch is ready for application. It is usually offered only after\n\ta detailed review.\n4. \"Tested-by:\" is used to indicate that the person\n\tapplied the patch and found it to have the desired effect.\n\nYou can also create your own tag or use one that's in common usage such as\n\"Thanks-to:\", \"Based-on-patch-by:\", or \"Mentored-by:\".\n\n-- \nFredrik Gustafsson\n\nphone: +46 733-608274\ne-mail: iveqy@iveqy.com\nwebsite: http://www.iveqy.com\n"},{"id":"257597","messageId":"xmqqegou2h1n.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"20150312074511.GB12418@paksenarrion.iveqy.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-12T18:43:00Z","receivedAt":"2015-03-12T18:43:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Gustafsson writes:\n\n> On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote:\n>> I'd first suggest to employ \"icase\" to unify *-By and *-by. Perhaps\n>> we would want a recommended list somewhere in SubmittingPatches to\n>> discourage people from getting too creative?\n>\n> There's already such list in SubmittingPatches, so there's already quite\n> a few to choose from:\n>\n> Also notice that a real name is used in the Signed-off-by: line. Please\n> don't hide your real name.\n>\n> If you like, you can put extra tags at the end:\n>\n> 1. \"Reported-by:\" is used to credit someone who found the bug that\n> \tthe patch attempts to fix.\n> 2. \"Acked-by:\" says that the person who is more familiar with the\n> \tarea the patch attempts to modify liked the patch.\n> 3. \"Reviewed-by:\", unlike the other tags, can only be offered by\n> \tthe reviewer and means that she is completely satisfied that the\n> \tpatch is ready for application. It is usually offered only after\n> \ta detailed review.\n> 4. \"Tested-by:\" is used to indicate that the person\n> \tapplied the patch and found it to have the desired effect.\n>\n> You can also create your own tag or use one that's in common usage such as\n> \"Thanks-to:\", \"Based-on-patch-by:\", or \"Mentored-by:\".\n\nHmph, the first step might be to drop that last sentence, I guess,\nif we consider this a \"mess\" and if we want to clean it up.\n"},{"id":"257607","messageId":"20150312223131.GA24492@peff.net","threadId":"38740","inReplyTo":"xmqqbnjz5in0.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-12T22:31:31Z","receivedAt":"2015-03-12T22:31:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2015 at 02:28:03PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Or something along those lines. The wording and indentation of the\n> > message could probably use tweaking. And there is a bash-ism in the\n> > script. :)\n> \n> OK, I've updated the Announce script on the 'todo' branch. The\n> announcement for 2.3.2 I sent out earlier as $gmane/264975 would\n> have looked like this.\n\nThanks, I think the organization and wording you chose look nice. One\nminor nit, though:\n\n> The latest maintenance release Git v2.3.2 is now available at the\n> usual places. It comprises of 41 non-merge commits since v2.3.1,\n> contributed by 19 people, 5 of which are new faces.\n\nIt's not generally considered correct to use \"of\" with the active tense\nof \"comprise\". So either:\n\n It comprises 41 non-merge commits...\n\nor:\n\n It is comprised of 41 non-merge commits...\n\nis fine. The latter is much more common, at least in American English,\nthough I imagine it gives some prescriptivists headaches.\n\n> New contributors who made this release possible are as follows.\n> Welcome to the Git development community!\n> \n> Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt,\n> Ryuichi Kokubo, and Tom G. Christensen.\n\nI hadn't thought about it when I originally suggested this, but of\ncourse \"new\" is not strictly meaningful in a world with branches. If you\ncontribute a bugfix on top of v2.0.0 that goes to \"maint\", do you get to\nbe new in v2.0.1 _and_ in v2.2.0?\n\nI do not think it matters too much either way in practice, but I guess\nit would depend on your approach (picking the \"old\" base manually, or by\nusing all tags prior to the released version).\n\n-Peff\n"},{"id":"257608","messageId":"xmqqd24d2681.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"20150312223131.GA24492@peff.net","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-12T22:36:46Z","receivedAt":"2015-03-12T22:36:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> It is comprised of 41 non-merge commits...\n>\n> is fine.\n\nThanks; very much appreciated.\n\n>> New contributors who made this release possible are as follows.\n>> Welcome to the Git development community!\n>> \n>> Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt,\n>> Ryuichi Kokubo, and Tom G. Christensen.\n>\n> I hadn't thought about it when I originally suggested this, but of\n> course \"new\" is not strictly meaningful in a world with branches. If you\n> contribute a bugfix on top of v2.0.0 that goes to \"maint\", do you get to\n> be new in v2.0.1 _and_ in v2.2.0?\n\nYeah, tricky. How about\n\n New contributors whose contributions weren't in $previous are as follows.\n Welcome to the Git development community!\n\nThen after merging a topic to 'master' and then 'maint' and when\ncutting v2.3.3, a new person will be listed as \"not in v2.3.2\" and\nthen again in the announcement for v2.4.0, as \"not in v2.3.0\".\n\nYes, it is cheating, but that would match the story the shortlog at\nthe end would tell.\n"},{"id":"257609","messageId":"20150312223836.GB24492@peff.net","threadId":"38740","inReplyTo":"xmqq61a64xg8.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-12T22:38:36Z","receivedAt":"2015-03-12T22:38:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2015 at 10:05:43PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I spent many years as a \"type C\" contributor, and I remember how nice it\n> > was to see my name mentioned occasionally as a useful person.\n> \n> I guess that everybody is different ;-)\n> \n> After throwing a small patch at ROCKbox (git.rockbox.org) back when\n> they were still hosted on Subversion, I felt somewhat ashamed to see\n> my name appear in their CREDITS file because the change I made was\n> so insignificant. In such a flat list like that, you cannot tell who\n> made significant contributions over time and who are just a casual\n> drive-by contributor like me, unless you know the community and who\n> are important in the community.\n\nHeh. Actually, after writing that, I almost clarified, but did not think\nanybody was that interested. But since you replied...:)\n\nSeeing my name in \"shortlog\" was nice, but not that exciting. I\nsubmitted a patch, it was taken, and of course it ends up in any\nautomated lists of authors. What was much more rewarding was being\nmentioned specifically in \"A note from the maintainer\" as a helpful\nperson. That had much more value because:\n\n 1. It was one of a handful of names.\n\n 2. It was picked by a human.\n\nSo in that sense, it is quite the opposite of including shortlog output\nin the release announcements (I still think the shortlog thing we have\nbeen discussing is a good thing, but not at the same level). I do not\nknow that it is worth having a \"Best of 2015\" Git awards ceremony, but\nit is sometimes nice to thank people personally when you appreciate\ntheir efforts. I sometimes mail people off-list to do so.\n\n-Peff\n"},{"id":"257610","messageId":"20150312224351.GC24492@peff.net","threadId":"38740","inReplyTo":"xmqqd24d2681.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-12T22:43:51Z","receivedAt":"2015-03-12T22:43:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 12, 2015 at 03:36:46PM -0700, Junio C Hamano wrote:\n\n> > I hadn't thought about it when I originally suggested this, but of\n> > course \"new\" is not strictly meaningful in a world with branches. If you\n> > contribute a bugfix on top of v2.0.0 that goes to \"maint\", do you get to\n> > be new in v2.0.1 _and_ in v2.2.0?\n> \n> Yeah, tricky. How about\n> \n> New contributors whose contributions weren't in $previous are as follows.\n> Welcome to the Git development community!\n\nYeah, that makes a lot of sense to me, and then we can have it in both\nplaces. I suspect the releases from \"master\" get a lot more readers, but\nif we had to pick only one, people with bugfixes would generally be\nmentioned in \"maint\" announcements.\n\n-Peff\n"},{"id":"257611","messageId":"xmqq7ful257z.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"20150312223836.GB24492@peff.net","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-12T22:58:24Z","receivedAt":"2015-03-12T22:58:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Seeing my name in \"shortlog\" was nice, but not that exciting. I\n> submitted a patch, it was taken, and of course it ends up in any\n> automated lists of authors. What was much more rewarding was being\n> mentioned specifically in \"A note from the maintainer\" as a helpful\n> person. That had much more value because:\n>\n> 1. It was one of a handful of names.\n>\n> 2. It was picked by a human.\n>\n> So in that sense, it is quite the opposite of including shortlog output\n> in the release announcements (I still think the shortlog thing we have\n> been discussing is a good thing, but not at the same level).\n\nYes, and that cuts both ways, unfortunately. There always will be \"I\nam doing more reviews than X and my reviews are higher quality. Why\nwas X singled out and got thanked but not me?\", \"X is really doing a\ngood job reviewing in this cycle, but could other people who send\nreviews of lessor quality (to my mind) feel that it is unjustified\nif I thanked X and nobody else?\", etc. A mechanically generated list\navoids these issues, but the satisfaction you get from being on the\nlist is not very high, exactly because it is not hand picked.\n\n> I do not know that it is worth having a \"Best of 2015\" Git awards\n> ceremony, but it is sometimes nice to thank people personally when\n> you appreciate their efforts. I sometimes mail people off-list to\n> do so.\n\nYeah, I do the same, but revealing that we do so would defeat what\nwe tried to achieve by doing so off-list in the first place. Now\nthose who haven't got such a piece of e-mail for a while can start\nto suspect that they have fallen out of favour or something ;-(.\n"},{"id":"257712","messageId":"CAP8UFD2ba3jQSsQrGGWM-8HTfGR+zZhmbkxiEBhSR+Ho=B0MuA@mail.gmail.com","threadId":"38740","inReplyTo":"xmqqfv9b5krc.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-15T08:46:28Z","receivedAt":"2015-03-15T08:46:28Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Mar 11, 2015 at 9:42 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>> On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano wrote:\n>>>\n>>> I would suspect that those who agree with you would appreciate if\n>>> you or somebody volunteered to act as our CKDO (chief kudos\n>>> distribution officer). I do not think I have enough time to do that\n>>> well. One good place to start might be to scan the list and\n>>> summarize something like the following on weekly or monthly basis,\n>>> as these are not something you can get by pointing people to \"git\n>>> shortlog\" output.\n>>>\n>>> - Those who gave helpful review comments, \"how about going this\n>>> way\" illustration patches, etc. Bonus points to those who helped\n>>> onboarding newcomers.\n>>>\n>>> - Those who asked pertinent questions on common pain points, and\n>>> those who answered them helpfully.\n>>\n>> Ok, I can start something about this two points every week or every\n>> few week. It would be best if I could get help from at least one\n>> person as I think it is a lot of work.\n>\n> No kidding; even though it may no longer be an impossibly large task\n> as in the infrationary epoch reported in the Git Traffic, this forum\n> is still a high traffic place.\n\nI wrote something about a potential Git Rev News news letter:\n\nhttps://github.com/git/git.github.io/pull/15\n\nPeff, could you give me write access so that I don't need to send pull requests?\nIf some people are interested to contribute even if it is only\nsporadically, I would suggest they ask for write access too.\n\n>> I also appreciate very much that you are willing to improve the\n>> release notes by adding a summary with people's names.\n>\n> Just in case you misunderstood, I do not think it is a good idea to\n> add names to release notes and I will not do so.\n>\n> I was and am planning add the list of contributors at the end of the\n> e-mail when the release notes is sent out, i.e. in the \"Announce\"\n> message that is sent to the list (and CC'ed to lwn.net).\n\nOk, that is already very nice.\n\nThanks,\nChristian.\n"},{"id":"257713","messageId":"CAP8UFD2s4e7D1vRKtvB8JcqoDs=VdVW-HV0PfY6g37u_9zU6Dw@mail.gmail.com","threadId":"38740","inReplyTo":"xmqq7ful257z.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-15T09:12:00Z","receivedAt":"2015-03-15T09:12:00Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Mar 12, 2015 at 11:58 PM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> Seeing my name in \"shortlog\" was nice, but not that exciting. I\n>> submitted a patch, it was taken, and of course it ends up in any\n>> automated lists of authors. What was much more rewarding was being\n>> mentioned specifically in \"A note from the maintainer\" as a helpful\n>> person. That had much more value because:\n>>\n>> 1. It was one of a handful of names.\n>>\n>> 2. It was picked by a human.\n>>\n>> So in that sense, it is quite the opposite of including shortlog output\n>> in the release announcements (I still think the shortlog thing we have\n>> been discussing is a good thing, but not at the same level).\n>\n> Yes, and that cuts both ways, unfortunately. There always will be \"I\n> am doing more reviews than X and my reviews are higher quality. Why\n> was X singled out and got thanked but not me?\", \"X is really doing a\n> good job reviewing in this cycle, but could other people who send\n> reviews of lessor quality (to my mind) feel that it is unjustified\n> if I thanked X and nobody else?\", etc. A mechanically generated list\n> avoids these issues, but the satisfaction you get from being on the\n> list is not very high, exactly because it is not hand picked.\n\nI think it is still much better to have some people positively hand\npicked than nothing.\nPeople who have not been hand picked despite having done something\nthey think is of the same or higher quality can always ask privately\nabout the reason they haven't been hand picked or they can try again\nexpecting that the outcome will be different next time.\n\nAnyway if some people are positively hand picked you can always hope\nthat it will happen to you, while otherwise there is no hope at all.\n\n>> I do not know that it is worth having a \"Best of 2015\" Git awards\n>> ceremony, but it is sometimes nice to thank people personally when\n>> you appreciate their efforts. I sometimes mail people off-list to\n>> do so.\n>\n> Yeah, I do the same, but revealing that we do so would defeat what\n> we tried to achieve by doing so off-list in the first place. Now\n> those who haven't got such a piece of e-mail for a while can start\n> to suspect that they have fallen out of favour or something ;-(.\n\nI don't think it defeat anything. I think you could even do it more online.\n\nBest,\nChristian.\n"},{"id":"257755","messageId":"xmqqvbi1sy4h.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CAP8UFD2ba3jQSsQrGGWM-8HTfGR+zZhmbkxiEBhSR+Ho=B0MuA@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-15T22:18:38Z","receivedAt":"2015-03-15T22:18:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> I wrote something about a potential Git Rev News news letter:\n\nI read it. Sounds promising.\n\nJust one suggestion on the name and half a comment.\n\nHow would \"Git Review\" (or \"Git Monthly Review\", or replace your\nfavourite \"how-often-per-period-ly\" in its name) sound? I meant it\nto sound similar to academic journals that summarize and review\ncontemporary works in the field and keeps your original \"pun\" about\nour culture around \"patch reviews\".\n\nI obviously do not know how the actual contents would look like at\nthis point, but depending on the quality of the publication I might\nbe able to steal some descriptions when keeping the notes on topics\nin flight that appear in my \"What's cooking\" report. And it can go\nthe other way around, too. The publication may want to peek my\n\"What's cooking\" report for hints on how to characterize each topic\nand assess its impact to the evolution of Git.\n"},{"id":"257757","messageId":"003001d05f71$81845160$848cf420$@nexbridge.com","threadId":"38740","inReplyTo":"xmqqvbi1sy4h.fsf@gitster.dls.corp.google.com","subject":"RE: Promoting Git developers","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-03-15T22:43:49Z","receivedAt":"2015-03-15T22:43:49Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"> On March 15, 2015 6:19 PM Christian Couder wrote:\n\n> Just one suggestion on the name and half a comment.\n> \n> How would \"Git Review\" (or \"Git Monthly Review\", or replace your favourite\n> \"how-often-per-period-ly\" in its name) sound? I meant it to sound similar\nto\n> academic journals that summarize and review contemporary works in the\nfield\n> and keeps your original \"pun\" about our culture around \"patch reviews\".\n\nIf I may humbly offer the suggestion that \"Git Blame\" would be a far more\nappropriate pun as a name :)\n"},{"id":"257775","messageId":"CAP8UFD08xoJ2H8XgfDbPfHddX9YFpFgbrY+PZ5Tphuot7JwGvw@mail.gmail.com","threadId":"38740","inReplyTo":"003001d05f71$81845160$848cf420$@nexbridge.com","subject":"Re: Promoting Git developers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-16T09:10:28Z","receivedAt":"2015-03-16T09:10:28Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker\n wrote:\n>> On March 15, 2015 6:19 PM Christian Couder wrote:\n> \n>> Just one suggestion on the name and half a comment.\n>>\n>> How would \"Git Review\" (or \"Git Monthly Review\", or replace your favourite\n>> \"how-often-per-period-ly\" in its name) sound? I meant it to sound similar\n> to\n>> academic journals that summarize and review contemporary works in the\n> field\n>> and keeps your original \"pun\" about our culture around \"patch reviews\".\n\nI would be ok for that but there is already this Gerrit related command:\n\nhttp://www.mediawiki.org/wiki/Gerrit/git-review\n\nMaybe I can just use \"Git Rev\", but it doesn't tell that it is about news?\n\n> If I may humbly offer the suggestion that \"Git Blame\" would be a far more\n> appropriate pun as a name :)\n\nYou don't want me to steal Junio's blog title:\n\nhttp://git-blame.blogspot.fr/\n\ndon't you?\n"},{"id":"257776","messageId":"87a8zdguxp.fsf@fencepost.gnu.org","threadId":"38740","inReplyTo":"CAP8UFD08xoJ2H8XgfDbPfHddX9YFpFgbrY+PZ5Tphuot7JwGvw@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2015-03-16T09:20:34Z","receivedAt":"2015-03-16T09:20:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Christian Couder writes:\n\n> On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker\n> wrote:\n>>> On March 15, 2015 6:19 PM Christian Couder wrote:\n>> \n>>> Just one suggestion on the name and half a comment.\n>>>\n>>> How would \"Git Review\" (or \"Git Monthly Review\", or replace your favourite\n>>> \"how-often-per-period-ly\" in its name) sound? I meant it to sound similar\n>> to\n>>> academic journals that summarize and review contemporary works in the\n>> field\n>>> and keeps your original \"pun\" about our culture around \"patch reviews\".\n>\n> I would be ok for that but there is already this Gerrit related command:\n>\n> http://www.mediawiki.org/wiki/Gerrit/git-review\n>\n> Maybe I can just use \"Git Rev\", but it doesn't tell that it is about news?\n>\n>> If I may humbly offer the suggestion that \"Git Blame\" would be a far more\n>> appropriate pun as a name :)\n>\n> You don't want me to steal Junio's blog title:\n>\n> http://git-blame.blogspot.fr/\n>\n> don't you?\n\n\"Git Annotate\"?\n\n-- \nDavid Kastrup\n"},{"id":"257800","messageId":"CAGZ79kbOkgA2pfsh3Av-iuHe4qRz2XWDu6Onm9QTXJRtAoABXg@mail.gmail.com","threadId":"38740","inReplyTo":"87a8zdguxp.fsf@fencepost.gnu.org","subject":"Re: Promoting Git developers","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-03-16T17:06:36Z","receivedAt":"2015-03-16T17:06:36Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup wrote:\n>\n> \"Git Annotate\"?\n>\n\n\"Git Praise\" as opposed to blame?\n\"Git Who\" as a pun on the subcommand structure which doesn't always\nfollows grammar?\n"},{"id":"257823","messageId":"alpine.DEB.2.02.1503161637210.31344@nftneq.ynat.uz","threadId":"38740","inReplyTo":"xmqqvbi1sy4h.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2015-03-16T23:39:12Z","receivedAt":"2015-03-16T23:39:12Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 15 Mar 2015, Junio C Hamano wrote:\n\n> Christian Couder writes:\n>\n>> I wrote something about a potential Git Rev News news letter:\n>\n> I read it. Sounds promising.\n>\n> Just one suggestion on the name and half a comment.\n>\n> How would \"Git Review\" (or \"Git Monthly Review\", or replace your\n> favourite \"how-often-per-period-ly\" in its name) sound? I meant it\n> to sound similar to academic journals that summarize and review\n> contemporary works in the field and keeps your original \"pun\" about\n> our culture around \"patch reviews\".\n>\n> I obviously do not know how the actual contents would look like at\n> this point, but depending on the quality of the publication I might\n> be able to steal some descriptions when keeping the notes on topics\n> in flight that appear in my \"What's cooking\" report. And it can go\n> the other way around, too. The publication may want to peek my\n> \"What's cooking\" report for hints on how to characterize each topic\n> and assess its impact to the evolution of Git.\n\nI'll bet that LWN would publish, or at least link to, such articles on a regular \nbasis, and if you end up doing an in-depth writeup on a particularly discussed \ntopic, they would probably give it pretty good visibility.\n\nDavid Lang\n"},{"id":"257831","messageId":"xmqqh9tkp54u.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"alpine.DEB.2.02.1503161637210.31344@nftneq.ynat.uz","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-17T05:25:21Z","receivedAt":"2015-03-17T05:25:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang writes:\n\n> On Sun, 15 Mar 2015, Junio C Hamano wrote:\n>\n>> Christian Couder writes:\n>>\n>>> I wrote something about a potential Git Rev News news letter:\n>>\n>> I read it. Sounds promising.\n>>\n>> Just one suggestion on the name and half a comment.\n>>\n>> How would \"Git Review\" (or \"Git Monthly Review\", or replace your\n>> favourite \"how-often-per-period-ly\" in its name) sound? I meant it\n>> to sound similar to academic journals that summarize and review\n>> contemporary works in the field and keeps your original \"pun\" about\n>> our culture around \"patch reviews\".\n> ...\n> I'll bet that LWN would publish, or at least link to, such articles on\n> a regular basis, and if you end up doing an in-depth writeup on a\n> particularly discussed topic, they would probably give it pretty good\n> visibility.\n\nI hope you are right, but my observation of our coverage by lwn.net\nis somewhat pessimistic. In our early days, our progress often used\nto appear on the \"Kernel Development\" page, which I presume is the\nmost important page of the weekly for the kernel developers, but in\nseveral months, the mention of us has moved two pages back to\n\"Development\" and listed together with folks like OCaml Weekly,\nPostgreSQL Weekly, etc. I would not count that as \"pretty good\nvisibility\" particularly.\n\nI am taking it as a positive change, though. Once we got stable\nenough not to be a roadblock for the kernel folks and proven\nourselves not to regress, our progress probably ceased to be\nnewsworthy to them ;-)\n"},{"id":"257834","messageId":"alpine.DEB.2.02.1503162254080.22474@nftneq.ynat.uz","threadId":"38740","inReplyTo":"xmqqh9tkp54u.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2015-03-17T05:56:18Z","receivedAt":"2015-03-17T05:56:18Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 16 Mar 2015, Junio C Hamano wrote:\n\n> David Lang writes:\n>\n>> On Sun, 15 Mar 2015, Junio C Hamano wrote:\n>>\n>>> Christian Couder writes:\n>>>\n>>>> I wrote something about a potential Git Rev News news letter:\n>>>\n>>> I read it. Sounds promising.\n>>>\n>>> Just one suggestion on the name and half a comment.\n>>>\n>>> How would \"Git Review\" (or \"Git Monthly Review\", or replace your\n>>> favourite \"how-often-per-period-ly\" in its name) sound? I meant it\n>>> to sound similar to academic journals that summarize and review\n>>> contemporary works in the field and keeps your original \"pun\" about\n>>> our culture around \"patch reviews\".\n>> ...\n>> I'll bet that LWN would publish, or at least link to, such articles on\n>> a regular basis, and if you end up doing an in-depth writeup on a\n>> particularly discussed topic, they would probably give it pretty good\n>> visibility.\n>\n> I hope you are right, but my observation of our coverage by lwn.net\n> is somewhat pessimistic. In our early days, our progress often used\n> to appear on the \"Kernel Development\" page, which I presume is the\n> most important page of the weekly for the kernel developers, but in\n> several months, the mention of us has moved two pages back to\n> \"Development\" and listed together with folks like OCaml Weekly,\n> PostgreSQL Weekly, etc. I would not count that as \"pretty good\n> visibility\" particularly.\n>\n> I am taking it as a positive change, though. Once we got stable\n> enough not to be a roadblock for the kernel folks and proven\n> ourselves not to regress, our progress probably ceased to be\n> newsworthy to them ;-)\n\nIt ceased to be about kernel development, and fell into the normal development \nbucket :-)\n\nRoutine release notes (like your notes from the maintainer) do end up just \ngetting links to them as you have seen. But if someone is summarizing the \ndiscussions on the mailing list, those will be a bit more interesting, and if \nthere is a particularly hot topic, the summary of that discussion can be a full \nfledged article on it's own.\n\nDavid Lang\n"},{"id":"257847","messageId":"CAEcj5uX_v2PUkTAR9xr-i-D-pmf+8EBLhu7FMkA+RKxc6vye5w@mail.gmail.com","threadId":"38740","inReplyTo":"CAP8UFD2ba3jQSsQrGGWM-8HTfGR+zZhmbkxiEBhSR+Ho=B0MuA@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Thomas Ferris Nicolaisen","fromEmail":"tfnico@gmail.com","sentAt":"2015-03-17T09:43:32Z","receivedAt":"2015-03-17T09:43:32Z","isPatch":false,"sender":{"key":"tfnico@gmail.com","avatar":"https://gravatar.com/avatar/628cf28a25ca4c596c7284562100f70f0ef908bcbfadd4da1eb3d48c23658d01?d=mp&s=160"},"body":"On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder\n wrote:\n>\n> I wrote something about a potential Git Rev News news letter:\n>\n> https://github.com/git/git.github.io/pull/15\n>\n\nI would love to have/use something like this in the GitMinutes\npodcast. Perhaps in addition to the very random interview format that\nI have now, I could do a more regular episodes about Git news, where I\nincorporate this.\n\nI also volunteer to help with the production, if you'll allow list\nlurkers like myself to contribute ;)\n"},{"id":"257883","messageId":"CAP8UFD0iuTJ8g4O5j8PfxdENwY92BR--gcAdTDy2mt74ovfYog@mail.gmail.com","threadId":"38740","inReplyTo":"CAEcj5uX_v2PUkTAR9xr-i-D-pmf+8EBLhu7FMkA+RKxc6vye5w@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-17T19:51:54Z","receivedAt":"2015-03-17T19:51:54Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Mar 17, 2015 at 10:43 AM, Thomas Ferris Nicolaisen\n wrote:\n> On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder\n> wrote:\n>>\n>> I wrote something about a potential Git Rev News news letter:\n>>\n>> https://github.com/git/git.github.io/pull/15\n>>\n>\n> I would love to have/use something like this in the GitMinutes\n> podcast. Perhaps in addition to the very random interview format that\n> I have now, I could do a more regular episodes about Git news, where I\n> incorporate this.\n\nYeah, no problem.\n\n> I also volunteer to help with the production, if you'll allow list\n> lurkers like myself to contribute ;)\n\nYes of course, you are very welcome!\n\nPeff, could you also give the rights on the repo to Thomas?\n\nThanks both,\nChristian.\n"},{"id":"257884","messageId":"CAP8UFD0NPLF1o8h8hqBfiG76qF1HU9DOCfHqi5-z9DkrV+aEvw@mail.gmail.com","threadId":"38740","inReplyTo":"CAGZ79kbOkgA2pfsh3Av-iuHe4qRz2XWDu6Onm9QTXJRtAoABXg@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-17T20:08:57Z","receivedAt":"2015-03-17T20:08:57Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller wrote:\n> On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup wrote:\n>>\n>> \"Git Annotate\"?\n>\n> \"Git Praise\" as opposed to blame?\n> \"Git Who\" as a pun on the subcommand structure which doesn't always\n> follows grammar?\n\nYeah these suggestions above are nice, thanks for them, but \"Git Rev News\"\nalso look a bit like \"git rev-list\" and \"git rev-parse\" which are plumbing Git\ncommands, so it gives a somewhat \"hardcore\" look to the news letter which\nI like.\n\nThanks,\nChristian.\n"},{"id":"257886","messageId":"CAP8UFD2+xfyziW+j=p02jBVMJZSFiSkKVCtzLxgkrBHds_rqLA@mail.gmail.com","threadId":"38740","inReplyTo":"xmqqvbi1sy4h.fsf@gitster.dls.corp.google.com","subject":"Re: Promoting Git developers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-03-17T20:15:12Z","receivedAt":"2015-03-17T20:15:12Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Mar 15, 2015 at 11:18 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>> I wrote something about a potential Git Rev News news letter:\n>\n> I read it. Sounds promising.\n\nThanks!\n\n[...]\n\n> I obviously do not know how the actual contents would look like at\n> this point, but depending on the quality of the publication I might\n> be able to steal some descriptions when keeping the notes on topics\n> in flight that appear in my \"What's cooking\" report. And it can go\n> the other way around, too. The publication may want to peek my\n> \"What's cooking\" report for hints on how to characterize each topic\n> and assess its impact to the evolution of Git.\n\nYeah, it would be a very nice thing if we could steal these kind of\nthings from each other's work!\n\nThanks,\nChristian.\n"},{"id":"257887","messageId":"xmqq7fufnzvq.fsf@gitster.dls.corp.google.com","threadId":"38740","inReplyTo":"CAP8UFD0NPLF1o8h8hqBfiG76qF1HU9DOCfHqi5-z9DkrV+aEvw@mail.gmail.com","subject":"Re: Promoting Git developers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-17T20:16:25Z","receivedAt":"2015-03-17T20:16:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller wrote:\n>> On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup wrote:\n>>>\n>>> \"Git Annotate\"?\n>>\n>> \"Git Praise\" as opposed to blame?\n>> \"Git Who\" as a pun on the subcommand structure which doesn't always\n>> follows grammar?\n>\n> Yeah these suggestions above are nice, thanks for them, but \"Git Rev News\"\n> also look a bit like \"git rev-list\" and \"git rev-parse\" which are plumbing Git\n> commands, so it gives a somewhat \"hardcore\" look to the news letter which\n> I like.\n\nCall that \"Git Rev List\" then to be more direct?\n\nI myself liked the \"Review\" (spelled in full word) as its non-nerdy\nsound, as a suitable name for a publication that bridges between\nhard-core developers and slightly-more-serious-than-casual\nobservers, but its not my call (and as I often say, I am not good at\nnaming things) ;-).\n"}]}