{"thread":{"id":"34086","subject":"[PATCH] Documentation/CommunityGuidelines","startedAt":"2013-06-10T13:28:47Z","lastAt":"2013-06-14T09:48:10Z","messageCount":63,"participants":["Ramkumar Ramachandra","Célestin Matte","Matthieu Moy","Robin H. Johnson","Junio C Hamano","Jonathan Nieder","A Large Angry SCM","Michael Haggerty","Felipe Contreras","Thomas Rast","John Keeping","Philip Oakley","Brandon Casey","Jeff King","John Szakmeister","Theodore Ts'o","Jakub Narebski","Thomas Adam","Christian Couder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"220282","messageId":"CALkWK0mqk5sRPV8PHz8RqZH-Ln7TUtkHPVbvsJPKuVSXiUOiww@mail.gmail.com","threadId":"34086","inReplyTo":null,"subject":"[PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-10T13:28:47Z","receivedAt":"2013-06-10T13:28:47Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"I've tried to write down a bare minimum, without restating the obvious.\n\n0. You do not take offense, no matter what.  If someone attacks you\nirrationally, you do not respond.  This is a public mailing list, and\nwe are all rational people: the attacker has already humiliated\nherself in public, and everyone can see that.\n\n1. You do not take sides or vote.  Do not post emails under the\npretext of agreement: repeating what has already been said does not\nstrengthen the argument.  Post only if you have something unique to\nadd to the discussion.\n\n2. You stop pointing fingers.  Every heated discussion requires more\nthan one participant, and a flamewar requires many participants.  If\nyou participate, you have implicitly agreed to share the blame for\nwhatever happens on the thread.  People can judge for themselves who\nis to blame.\n\n3. Thou shalt not commit logical fallacies.  The ones that are most\ncommon on this list: strawman, ad hominem, burden of proof, false\ncause, the texas sharpshooter, and appeal to authority.\n\n4. Lead by example.  If you do not like how someone presents\nthemselves on the list, you counter it by presenting yourself nicely\non the list.  Others will follow your example, making that person's\nbehavior the minority.  It is far more powerful than explicitly\nstating what is \"acceptable\" behavior and what is not.\n\n5. We are a community of programmers, and we are here to collaborate\non code.  The argument that leads to higher efficiency and better code\nhas an automatic advantage over the argument that doesn't.\n\nIf someone breaks one of these rules, there's a very simple way to\ncommunicate this to them: you don't respond to their email.\nOptionally, respond to their email off-list calmly explaining what\nwent wrong.\n"},{"id":"220283","messageId":"51B5D9A1.1080900@ensimag.fr","threadId":"34086","inReplyTo":"CALkWK0mqk5sRPV8PHz8RqZH-Ln7TUtkHPVbvsJPKuVSXiUOiww@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Célestin Matte","fromEmail":"celestin.matte@ensimag.fr","sentAt":"2013-06-10T13:50:25Z","receivedAt":"2013-06-10T13:50:25Z","isPatch":true,"sender":{"key":"celestin.matte@ensimag.fr","avatar":"https://avatars.githubusercontent.com/u/2753554?v=4"},"body":"Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :\n> 0. You do not take offense, no matter what.  If someone attacks you\n> irrationally, you do not respond.  This is a public mailing list, and\n> we are all rational people: the attacker has already humiliated\n> herself in public, and everyone can see that.\n\n\"Herself\"?\nTypo I guess :)\n"},{"id":"220284","messageId":"vpqhah6hxjm.fsf@anie.imag.fr","threadId":"34086","inReplyTo":"51B5D9A1.1080900@ensimag.fr","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-10T14:04:29Z","receivedAt":"2013-06-10T14:04:29Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Célestin Matte <celestin.matte@ensimag.fr> writes:\n\n> Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :\n>> 0. You do not take offense, no matter what.  If someone attacks you\n>> irrationally, you do not respond.  This is a public mailing list, and\n>> we are all rational people: the attacker has already humiliated\n>> herself in public, and everyone can see that.\n>\n> \"Herself\"?\n> Typo I guess :)\n\nNot necessarily. It's quite common in english to use \"she\" when the\ngender is not known.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"220317","messageId":"robbat2-20130610T162316-152176477Z@orbis-terrarum.net","threadId":"34086","inReplyTo":"vpqhah6hxjm.fsf@anie.imag.fr","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2013-06-10T16:25:05Z","receivedAt":"2013-06-10T16:25:05Z","isPatch":true,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Mon, Jun 10, 2013 at 04:04:29PM +0200,  Matthieu Moy wrote:\n> Célestin Matte <celestin.matte@ensimag.fr> writes:\n> \n> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :\n> >> 0. You do not take offense, no matter what.  If someone attacks you\n> >> irrationally, you do not respond.  This is a public mailing list, and\n> >> we are all rational people: the attacker has already humiliated\n> >> herself in public, and everyone can see that.\n> >\n> > \"Herself\"?\n> > Typo I guess :)\n> \n> Not necessarily. It's quite common in english to use \"she\" when the\n> gender is not known.\nCould you please use \"themself\" instead?\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail     : robbat2@gentoo.org\nGnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\n"},{"id":"220332","messageId":"7vzjuxj21b.fsf@alter.siamese.dyndns.org","threadId":"34086","inReplyTo":"robbat2-20130610T162316-152176477Z@orbis-terrarum.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-10T17:42:08Z","receivedAt":"2013-06-10T17:42:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robin H. Johnson\" <robbat2@gentoo.org> writes:\n\n> On Mon, Jun 10, 2013 at 04:04:29PM +0200,  Matthieu Moy wrote:\n>> Célestin Matte <celestin.matte@ensimag.fr> writes:\n>> \n>> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :\n>> >> 0. You do not take offense, no matter what.  If someone attacks you\n>> >> irrationally, you do not respond.  This is a public mailing list, and\n>> >> we are all rational people: the attacker has already humiliated\n>> >> herself in public, and everyone can see that.\n>> >\n>> > \"Herself\"?\n>> > Typo I guess :)\n>> \n>> Not necessarily. It's quite common in english to use \"she\" when the\n>> gender is not known.\n> Could you please use \"themself\" instead?\n\nI think \"himself or herself\" is the politically correct form ;-)\n\nBut more seriously.\n\nThe intent behind the document might be a noble one, but I am afraid\nthat the text is too broad and vague and does not address the real\nissue to be of practical use.\n\nTaking one bullet point from the top for example:\n\n    0. You do not take offense, no matter what.  If someone attacks\n    you irrationally, you do not respond.  This is a public mailing\n    list, and we are all rational people: the attacker has already\n    humiliated herself in public, and everyone can see that.\n\nWhat does saying \"we are all rational people\" help when \"the\nattacker\" poses a risk to destroy the community?  What does \"we are\nall rational people\" even mean in this sentence?\n\nIt does not address the real cause of flamewars---why do rational\npeople feel the need to respond when an irrational comment is made,\ne.g. when a reasonable review comments were responded not with\neither \"Yeah, you are right, thanks.\" or \"Not really, because you\nmissed this case, I think...\"  but with nitpicks with immaterial\ndetails or repetition without justification that takes account that\nthe reviewer is in disagreement and there must be some reason behind\nit, i.e. a poisonous behaviour?\n\nI suspect it mostly has to do with the desire to make sure that\nbystanders do not get an impression that the one who speaks last\ngives the conclusion to the discussion, so stating \"The attacker\nbeing the one who speaks last in the discussion does not mean the\nconclusion is his.\" explicitly might be one way to make it more\npractically useful by alleviating the urge to respond, instead of\nsaying \"no matter what\".\n\nI dunno.\n"},{"id":"220358","messageId":"20130610190102.GF12924@google.com","threadId":"34086","inReplyTo":"7vzjuxj21b.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-10T19:01:02Z","receivedAt":"2013-06-10T19:01:02Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n>     0. You do not take offense, no matter what.  If someone attacks\n>     you irrationally, you do not respond.  This is a public mailing\n>     list, and we are all rational people: the attacker has already\n>     humiliated herself in public, and everyone can see that.\n[...]\n> I suspect it mostly has to do with the desire to make sure that\n> bystanders do not get an impression that the one who speaks last\n> gives the conclusion to the discussion, so stating \"The attacker\n> being the one who speaks last in the discussion does not mean the\n> conclusion is his.\" explicitly might be one way to make it more\n> practically useful by alleviating the urge to respond, instead of\n> saying \"no matter what\".\n>\n> I dunno.\n\nActually my motivation is worse than that in at least one of the cases\nI am assuming Ram is referring to.\n\nI don't think most bystanders would misunderstand if I let a certain\nperson alone instead of responding and saying \"You are being\nunproductive.  Please stop.\"  But that certain person seems to\nmisunderstand, whether I say that or not.  So when I lose patience I\nsay so, knowing that it will spark a discussion with others, knowing\nthat that discussion needs to happen and that if the problem is not\naddressed I will continue to lose motivation for regular work on-list.\n\nIs that an instance of taking offense and letting emotion overtake\nreason?  Is that against the rules?\n\nJonathan\n"},{"id":"220365","messageId":"CALkWK0neo-OF7P__T5u5oHrJgseJ-H5Zk=qbpDDYttdaaRu6gQ@mail.gmail.com","threadId":"34086","inReplyTo":"20130610190102.GF12924@google.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-10T19:45:15Z","receivedAt":"2013-06-10T19:45:15Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> I don't think most bystanders would misunderstand if I let a certain\n> person alone instead of responding and saying \"You are being\n> unproductive.  Please stop.\"  But that certain person seems to\n> misunderstand, whether I say that or not.  So when I lose patience I\n> say so, knowing that it will spark a discussion with others, knowing\n> that that discussion needs to happen and that if the problem is not\n> addressed I will continue to lose motivation for regular work on-list.\n>\n> Is that an instance of taking offense and letting emotion overtake\n> reason?  Is that against the rules?\n\nThe problem needs to be addressed, Jonathan.  Which is precisely why I\nwrote this patch: to calmly and rationally discuss the issue, and\ndampen the chances of repetition.  You do not do it by losing your\npatience, becoming emotional, and fueling a large ongoing fire.\nProlonging fires do not help prevent them from recurring, as evidenced\nby previous fires; this is because there is no takeaway from a fire.\nAll that's left are a few shreds and ashes.  From this very fire, we\ngained NOTHING, and lost Duy.\n\nIt is absolutely imperative to keep all our contributors productive,\nand maximize output.  If there is something troubling you, this is the\nright thread to speak on.\n"},{"id":"220373","messageId":"51B639FC.7030007@gmail.com","threadId":"34086","inReplyTo":"CALkWK0neo-OF7P__T5u5oHrJgseJ-H5Zk=qbpDDYttdaaRu6gQ@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2013-06-10T20:41:32Z","receivedAt":"2013-06-10T20:41:32Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 06/10/2013 03:45 PM, Ramkumar Ramachandra wrote:\n[...]\n>\n> It is absolutely imperative to keep all our contributors productive,\n> and maximize output.\n\nWhy?\n\nA useful \"product\" with a maintainable code base are what seems to be \nmore important to a successful open source effort.\n\n\nA Large Angry SCM\n"},{"id":"220378","messageId":"CALkWK0n5fVZ7t-5aAO6AXM5DpxqYfL_QLxkD48edK65rGsrX_g@mail.gmail.com","threadId":"34086","inReplyTo":"51B639FC.7030007@gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-10T20:56:38Z","receivedAt":"2013-06-10T20:56:38Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"A Large Angry SCM wrote:\n>> It is absolutely imperative to keep all our contributors productive,\n>> and maximize output.\n>\n>\n> Why?\n>\n> A useful \"product\" with a maintainable code base are what seems to be more\n> important to a successful open source effort.\n\nDoesn't a successful open source effort (with a good review process,\nwhich we already have) imply a maintainable product with lots of\nusers?  What am I missing, and what change do you propose?\n"},{"id":"220381","messageId":"51B64070.2080209@gmail.com","threadId":"34086","inReplyTo":"CALkWK0n5fVZ7t-5aAO6AXM5DpxqYfL_QLxkD48edK65rGsrX_g@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2013-06-10T21:09:04Z","receivedAt":"2013-06-10T21:09:04Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 06/10/2013 04:56 PM, Ramkumar Ramachandra wrote:\n> A Large Angry SCM wrote:\n>>> It is absolutely imperative to keep all our contributors productive,\n>>> and maximize output.\n>>\n>>\n>> Why?\n>>\n>> A useful \"product\" with a maintainable code base are what seems to be more\n>> important to a successful open source effort.\n>\n> Doesn't a successful open source effort (with a good review process,\n> which we already have) imply a maintainable product with lots of\n> users?  What am I missing, and what change do you propose?\n>\n\nIt's not about keeping all of the contributers productive or maximizing \noutput. It's about the result being useful.\n"},{"id":"220411","messageId":"51B6AA7F.1060505@alum.mit.edu","threadId":"34086","inReplyTo":"CALkWK0mqk5sRPV8PHz8RqZH-Ln7TUtkHPVbvsJPKuVSXiUOiww@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-11T04:41:35Z","receivedAt":"2013-06-11T04:41:35Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:\n> I've tried to write down a bare minimum, without restating the obvious.\n\nThank you for drafting a proposed CommunityGuidelines document; I think\nsuch a document would be helpful.  But I don't like the overall flavor\nof your proposal; frankly, it sounds to me more like\n\nDocumentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations\n\nand I don't think that is healthy.\n\n> 0. You do not take offense, no matter what.  If someone attacks you\n> irrationally, you do not respond.  This is a public mailing list, and\n> we are all rational people: the attacker has already humiliated\n> herself in public, and everyone can see that.\n\nThis is secondary to the more important rule, \"do not attack other\npeople on the mailing list\".  Not taking offense is at best a(n\nimportant) fallback position for those regrettable occasions when\nsomebody else has already violated the primary guideline.\n\n> 1. You do not take sides or vote.  Do not post emails under the\n> pretext of agreement: repeating what has already been said does not\n> strengthen the argument.  Post only if you have something unique to\n> add to the discussion.\n> \n> 2. You stop pointing fingers.  Every heated discussion requires more\n> than one participant, and a flamewar requires many participants.  If\n> you participate, you have implicitly agreed to share the blame for\n> whatever happens on the thread.  People can judge for themselves who\n> is to blame.\n\nHere your wording \"every heated discussion requires more than one\nparticipant\" seems to put more of the blame for heated discussions on\nparticipants 2..N and give a pass to participant number one.\n\n> 3. Thou shalt not commit logical fallacies.  The ones that are most\n> common on this list: strawman, ad hominem, burden of proof, false\n> cause, the texas sharpshooter, and appeal to authority.\n\nI think putting a rule like this in CommunityGuidelines puts too much\nweight on it.  In my recollection, pointing out other people's supposed\nlogical fallacies is far more often used on this list as a nitpicking\ndiversionary tactic that usually leads a conversation *further* away\nfrom the real issues.  I think it would be a mistake to encourage such\nformal and stylized argument on the ML.\n\n> 4. Lead by example.  If you do not like how someone presents\n> themselves on the list, you counter it by presenting yourself nicely\n> on the list.  Others will follow your example, making that person's\n> behavior the minority.  It is far more powerful than explicitly\n> stating what is \"acceptable\" behavior and what is not.\n\nLeading by example is a great approach, and has the effect that you\ndescribe on the majority of people.  But I also think it would be\nhelpful for the community to agree on a few very minimum standards of\nbehavior that we insist on, and to call people out (preferably in a\nprivate email) if they fall short of these standards.\n\n> 5. We are a community of programmers, and we are here to collaborate\n> on code.  The argument that leads to higher efficiency and better code\n> has an automatic advantage over the argument that doesn't.\n> \n> If someone breaks one of these rules, there's a very simple way to\n> communicate this to them: you don't respond to their email.\n> Optionally, respond to their email off-list calmly explaining what\n> went wrong.\n\nI would prefer a community standards document that looks more like this:\n\n* Treat other community members with courteousness and respect.\n\n* Conduct disagreements on a technical, not a personal, level.  It is\nunacceptable to attack another community member personally, even by\ninsinuation.\n\n* Keep in mind that email is a medium prone to misunderstandings, and\nthat many mailing list participants do not speak English as their first\nlanguage.  Interpret other people's emails charitably.  If you are not\nsure that you understand, ask for clarification.  Assume good intentions\non the part of others, and do not attribute technical disagreements to\nulterior motives.  Choose your words carefully to help other people\navoid misinterpreting them, and avoid hyperbole.\n\n* Strive to keep the mailing list a forum for effective collaboration.\nOnly post if you have something worthwhile to add to the discussion.  Be\nconcise and do not repeat what has already been said.  Code reviews,\ncontributions of patches, and concrete data such as bug reports are far\npreferable to philosophizing, vague suggestions, and whining.  Avoid\nbikeshedding and do not participate in flame wars.  Avoid revisiting\nsettled debates unless the facts have changed.\n\n* Accept reviewers' comments gratefully and take them very seriously.\nShow that you appreciate the help by giving the reviewer the benefit of\nthe doubt.  If, after careful consideration, you find that you cannot\nagree with a reviewer's suggestion, explain your reasoning carefully\nwithout taking or giving offense, and seek compromise.\n\n* When reviewing other peoples' code, be tactful and constructive.  Set\nhigh expectations, but do what you can to help the submitter achieve\nthem.  Don't demand changes based only on your personal preferences.\nDon't let the perfect be the enemy of the good.\n\n* Be welcoming to new community participants.  Help them get oriented,\nand be patient with their questions.  Gently introduce them to our\ncommunity standards, above all by setting a good example yourself.\n\n* It is not OK to use these guidelines as a stick with which to beat\nsupposed violators.  However, if you genuinely feel that another\ncommunity member is routinely behaving in ways that are detrimental to\nthe community, it might help to calmly express your concerns to that\nperson, preferably in a private email, and naming concrete and specific\nincidents rather than broad generalizations.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220413","messageId":"CAMP44s3ZSTZQ5juNnwRTC_tSSe68wvjvOi=MBwu3g9pTbPBNqA@mail.gmail.com","threadId":"34086","inReplyTo":"7vzjuxj21b.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T05:16:03Z","receivedAt":"2013-06-11T05:16:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 12:42 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Robin H. Johnson\" <robbat2@gentoo.org> writes:\n>\n>> On Mon, Jun 10, 2013 at 04:04:29PM +0200,  Matthieu Moy wrote:\n>>> Célestin Matte <celestin.matte@ensimag.fr> writes:\n>>>\n>>> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :\n>>> >> 0. You do not take offense, no matter what.  If someone attacks you\n>>> >> irrationally, you do not respond.  This is a public mailing list, and\n>>> >> we are all rational people: the attacker has already humiliated\n>>> >> herself in public, and everyone can see that.\n>>> >\n>>> > \"Herself\"?\n>>> > Typo I guess :)\n>>>\n>>> Not necessarily. It's quite common in english to use \"she\" when the\n>>> gender is not known.\n>> Could you please use \"themself\" instead?\n>\n> I think \"himself or herself\" is the politically correct form ;-)\n>\n> But more seriously.\n>\n> The intent behind the document might be a noble one, but I am afraid\n> that the text is too broad and vague and does not address the real\n> issue to be of practical use.\n>\n> Taking one bullet point from the top for example:\n>\n>     0. You do not take offense, no matter what.  If someone attacks\n>     you irrationally, you do not respond.  This is a public mailing\n>     list, and we are all rational people: the attacker has already\n>     humiliated herself in public, and everyone can see that.\n>\n> What does saying \"we are all rational people\" help when \"the\n> attacker\" poses a risk to destroy the community?  What does \"we are\n> all rational people\" even mean in this sentence?\n\nScience shows that humans are in fact, not rational people. It's\nsimply one of our countless limitations. We acknowledge we have\nphysical limitations, but we forget our mental limitations.\n\nWe should aim to be rational people, yes, but we are not.\n\n> It does not address the real cause of flamewars---why do rational\n> people feel the need to respond when an irrational comment is made,\n> e.g. when a reasonable review comments were responded not with\n> either \"Yeah, you are right, thanks.\" or \"Not really, because you\n> missed this case, I think...\"  but with nitpicks with immaterial\n> details or repetition without justification that takes account that\n> the reviewer is in disagreement and there must be some reason behind\n> it, i.e. a poisonous behaviour?\n\nFirst of all, you should not refer to it as \"poisonous behavior\".\nMaybe you think it's poisonous, maybe everyone else in the mailing\nlist agrees it's poisonous, but talk doesn't make things real,\notherwise there were a lot of real witches in the past.\n\nYou should refer to it as 'what could be considered poisonous\nbehavior'. That is accurate.\n\nCalling it \"poisonous behavior\" at best can be considered a logical\nfallacy, and at worst could even be described as a poisonous comment\nitself.\n\n> I suspect it mostly has to do with the desire to make sure that\n> bystanders do not get an impression that the one who speaks last\n> gives the conclusion to the discussion, so stating \"The attacker\n> being the one who speaks last in the discussion does not mean the\n> conclusion is his.\" explicitly might be one way to make it more\n> practically useful by alleviating the urge to respond, instead of\n> saying \"no matter what\".\n>\n> I dunno.\n\nI think we all know at some level why flame war arise, as XKCD makes\nit comically succinct[1].\n\nIf somebody wants to argue for the sake of arguing, they should go to\nsome forum, or reddit, or something else other than the mailing list.\n\nIn the mailing list you should avoid flamewars. If you have identified\na flamewar, don't poke it, and ask for others to do the same; don't\nthrow lumber unto the flames.\n\nI know you worry that somebody is wrong on the Internet, and you worry\nthat somebody else might read that, and think the person that is wrong\nis actually right. But you cannot fix that. Move on. If the reader is\nsmart, they'll understand the signal \"Don't throw lumber unto the\nflames.\" followed by silence from other members of the community.\n\nTrying to \"correct\" somebody often sends the wrong signal; you\nvalidate the other person's point of view as something worth arguing\nabout. If you truly think a flamewar is taking place, resist your urge\nto participate in it, and mute it.\n\nMaybe it's not really flamewar, and something important is being\ndiscussed, but you should leave the people that do not think a\nflamewar is taking place to argue with each other, and stay out of\nthat. If you think it's a flamewar, and you comment in it, you are\nmaking it worst, and perhaps turning it into a real flamewar if it\nwasn't.\n\nIn general; do not participate in a flamewar. Period.\n\n[1] http://xkcd.com/386/\n\n-- \nFelipe Contreras\n"},{"id":"220414","messageId":"CAMP44s0Ra1cEjLqX9iwoRWpO5wHjGFygK-MUw7z1q_d-DhcMNQ@mail.gmail.com","threadId":"34086","inReplyTo":"CALkWK0mqk5sRPV8PHz8RqZH-Ln7TUtkHPVbvsJPKuVSXiUOiww@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T05:38:07Z","receivedAt":"2013-06-11T05:38:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 8:28 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> I've tried to write down a bare minimum, without restating the obvious.\n\nI think there's an even more important number 0:\n\nAlways assume good faith. When discussing through digital mediums,\nit's very easy to misconstrue the tone and intentions of other\nparties, so it's better to err on the side of caution, and if one is\nmistaken, assuming good faith doesn't cause harm, while the contrary\ndoes irreparable damage. This does not mean that one should continue\nto assume good faith when there's evidence to the contrary.\n\n> 0. You do not take offense, no matter what.  If someone attacks you\n> irrationally, you do not respond.  This is a public mailing list, and\n> we are all rational people: the attacker has already humiliated\n> herself in public, and everyone can see that.\n\nI don't like the wording of this. \"Attacker\", \"humiliation\",\n\"everyone\"; it's very absolutist rhetoric. Yes, you see the other\nperson as an attacker, and yes you think she is humiliating herself in\nfront of everyone, but thinking so doesn't make it so.\n\nAn even better and less absolutist version would be:\n\nDo not participate in flamewars. It is very tempting to prove somebody\nelse wrong, but if you think a discussion is turning into a flamewar,\njust say so, and avoid it. Do not throw lumber to the flames. You\nmight feel you should correct the erroneous claims being made in\npublic, but by replying you are making things worst. Leave the\nerroneous (in your opinion) claims alone, the damage has been done,\nall that is left is what *you* can do, and the best you can do is\nignore them.\n\n> 3. Thou shalt not commit logical fallacies.  The ones that are most\n> common on this list: strawman, ad hominem, burden of proof, false\n> cause, the texas sharpshooter, and appeal to authority.\n\nIt might be better to turn this negative rule into a positive one:\n\"Discuss on the basis of logic and evidence\". Then you can describe\nthe common logical fallacies, and I would add \"If you make a claim, be\nprepared it to defend it with evidence, or add an appropriate\nqualifier; probably, most likely, I think, etc.\"\n\n> If someone breaks one of these rules, there's a very simple way to\n> communicate this to them: you don't respond to their email.\n> Optionally, respond to their email off-list calmly explaining what\n> went wrong.\n\nI think you should reply, but not to her, to the mailing list, asking\nfor others to don't reply. Then mute the thread. I already explained\nthat about in the comment about flamewars.\n\nThere's a corollary to that that works rather well in the LKML; you\nare permitted one flamewar per year. I'm not going to explain why this\nis a good thing, because unfortunately there's an irrational negative\nbias against me already, but there's a reason why this is a good rule.\nEven if you don't agree it's only one flamewar per year per person,\nit's not that much.\n\n-- \nFelipe Contreras\n"},{"id":"220415","messageId":"CAMP44s2Kwx+B27QUP2jO-Gc3oaGXiHx1ZLC1JqKiOCAhTWnTZA@mail.gmail.com","threadId":"34086","inReplyTo":"51B6AA7F.1060505@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T06:28:27Z","receivedAt":"2013-06-11T06:28:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 10, 2013 at 11:41 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:\n>> I've tried to write down a bare minimum, without restating the obvious.\n>\n> Thank you for drafting a proposed CommunityGuidelines document; I think\n> such a document would be helpful.  But I don't like the overall flavor\n> of your proposal; frankly, it sounds to me more like\n>\n> Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations\n>\n> and I don't think that is healthy.\n\nThe LKML would disagree with you, as this draft is rather similar to\nwhat they do. Have you ever heard the phrase \"don't feed the troll\"?\nWell, it's every similar.\n\nThis also happens in any civilized modern society. Maybe you don't\nagree with the Tea Party, or some other political group, but you\ndeport them? Do you squash their protests? No. You let them say what\nthey need to say, and you ignore them.\n\nIt's best for you, and it's best for the community. Ignore them and move on.\n\n>> 0. You do not take offense, no matter what.  If someone attacks you\n>> irrationally, you do not respond.  This is a public mailing list, and\n>> we are all rational people: the attacker has already humiliated\n>> herself in public, and everyone can see that.\n>\n> This is secondary to the more important rule, \"do not attack other\n> people on the mailing list\".  Not taking offense is at best a(n\n> important) fallback position for those regrettable occasions when\n> somebody else has any other already violated the primary guideline.\n\nYes but you can't control what other people do, only what you do.\nPresumably you think you are not going to violate any of the other\nrules, so it's all the more important that you do follow this one,\nbecause that's the one *you* are possibly going to need to remember.\n\nBut by you I really me \"we\", because we all think we are not going to\nviolate the other rules. We all think we don't commit logical\nfallacies, we all think our comments are right, productive, rational,\nand sensible.\n\nOf course that's not the case, what you think is a perfectly\nreasonable comment, somebody else might consider offensive. In fact,\nsomebody is bound to find something offensive, so when that someone\nhappens to be you, take a deep breath, and don't.\n\n>> 1. You do not take sides or vote.  Do not post emails under the\n>> pretext of agreement: repeating what has already been said does not\n>> strengthen the argument.  Post only if you have something unique to\n>> add to the discussion.\n>>\n>> 2. You stop pointing fingers.  Every heated discussion requires more\n>> than one participant, and a flamewar requires many participants.  If\n>> you participate, you have implicitly agreed to share the blame for\n>> whatever happens on the thread.  People can judge for themselves who\n>> is to blame.\n>\n> Here your wording \"every heated discussion requires more than one\n> participant\" seems to put more of the blame for heated discussions on\n> participants 2..N and give a pass to participant number one.\n\nWhich might actually be the case. If a drunk punches you in the face,\nand you fight back. Who do you think the police is going to find\nguilty of brawling?\n\n>> 3. Thou shalt not commit logical fallacies.  The ones that are most\n>> common on this list: strawman, ad hominem, burden of proof, false\n>> cause, the texas sharpshooter, and appeal to authority.\n>\n> I think putting a rule like this in CommunityGuidelines puts too much\n> weight on it.  In my recollection, pointing out other people's supposed\n> logical fallacies is far more often used on this list as a nitpicking\n> diversionary tactic that usually leads a conversation *further* away\n> from the real issues.  I think it would be a mistake to encourage such\n> formal and stylized argument on the ML.\n\nIf you are not going to argue on the basis of logic and reason, what\nare you going to argue on the basis of?\n\nBeing logical and reasonable is not finicky, it's a necessity. At\nleast if you want to stay close to the real world.\n\n>> 4. Lead by example.  If you do not like how someone presents\n>> themselves on the list, you counter it by presenting yourself nicely\n>> on the list.  Others will follow your example, making that person's\n>> behavior the minority.  It is far more powerful than explicitly\n>> stating what is \"acceptable\" behavior and what is not.\n>\n> Leading by example is a great approach, and has the effect that you\n> describe on the majority of people.  But I also think it would be\n> helpful for the community to agree on a few very minimum standards of\n> behavior that we insist on, and to call people out (preferably in a\n> private email) if they fall short of these standards.\n>\n>> 5. We are a community of programmers, and we are here to collaborate\n>> on code.  The argument that leads to higher efficiency and better code\n>> has an automatic advantage over the argument that doesn't.\n>>\n>> If someone breaks one of these rules, there's a very simple way to\n>> communicate this to them: you don't respond to their email.\n>> Optionally, respond to their email off-list calmly explaining what\n>> went wrong.\n>\n> I would prefer a community standards document that looks more like this:\n>\n> * Treat other community members with courteousness and respect.\n\nI disagree. Respect should be earned.\n\nMoreover, tolerance is what is needed, respect is not. You should be\ntolerant, even to the people who don't respect you.\n\n> * Conduct disagreements on a technical, not a personal, level.  It is\n> unacceptable to attack another community member personally, even by\n> insinuation.\n\nI believe this is obvious and hardly worth mentioning. But on the\nother hand, once could say I have been a victim of personal attacks,\nnot on a technical level. Perhaps it is worth mentioning.\n\n> * Keep in mind that email is a medium prone to misunderstandings, and\n> that many mailing list participants do not speak English as their first\n> language.  Interpret other people's emails charitably.  If you are not\n> sure that you understand, ask for clarification.  Assume good intentions\n> on the part of others, and do not attribute technical disagreements to\n> ulterior motives.  Choose your words carefully to help other people\n> avoid misinterpreting them, and avoid hyperbole.\n\nI agree, but I think my wording of assuming good faith is better.\n\n> * Strive to keep the mailing list a forum for effective collaboration.\n> Only post if you have something worthwhile to add to the discussion.  Be\n> concise and do not repeat what has already been said.  Code reviews,\n> contributions of patches, and concrete data such as bug reports are far\n> preferable to philosophizing, vague suggestions, and whining.  Avoid\n> bikeshedding and do not participate in flame wars.  Avoid revisiting\n> settled debates unless the facts have changed.\n\nMostly agree, but the flamewar part needs to be emphasized and in its own point.\n\n> * Accept reviewers' comments gratefully and take them very seriously.\n> Show that you appreciate the help by giving the reviewer the benefit of\n> the doubt.  If, after careful consideration, you find that you cannot\n> agree with a reviewer's suggestion, explain your reasoning carefully\n> without taking or giving offense, and seek compromise.\n\nAgreed. But I would say 'consider compromise'; often a compromise is\nin the project's best interest, but not always.\n\nBut it's missing the guideline for the reviewer.\n\n* Accept comments on your reviews gracefully. If the original patch\nsubmitter doesn't agree with your review, don't take offense. Don't\nassume the submitter has to automatically modify the patches according\nto your comments, or even necessarily seek a compromise. The submitter\nis entitled to his opinion, and so are you. Also, remember that each\nperson has their own priorities in life, and it might take time before\nthe submitter has time to implement the changes, if ever. The changes\nyou request might be beyond the time the submitter is willing to\nspend, and it's OK for him to decide to drop the patches as a result.\nYou can help by picking the patches yourself in those situations.\n\n> * It is not OK to use these guidelines as a stick with which to beat\n> supposed violators.  However, if you genuinely feel that another\n> community member is routinely behaving in ways that are detrimental to\n> the community, it might help to calmly express your concerns to that\n> person, preferably in a private email, and naming concrete and specific\n> incidents rather than broad generalizations.\n\nVery good. It's good to remember these are guidelines, not by-laws.\nOne should not focus on the transgressions of others, for which\nthere's no defined punishment, but rather; on what one can do oneself.\n\n-- \nFelipe Contreras\n"},{"id":"220420","messageId":"CALkWK0mWA_aWuWYYV8O5QKUMB_GWXRKB1X_TGuoG-ESgN5fjOg@mail.gmail.com","threadId":"34086","inReplyTo":"7vzjuxj21b.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T08:56:27Z","receivedAt":"2013-06-11T08:56:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> The intent behind the document might be a noble one, but I am afraid\n> that the text is too broad and vague and does not address the real\n> issue to be of practical use.\n\nDrafting something like this is shit work, which explains why nobody\nhas attempted it yet.  I have no intent of collecting feedback and\ndoing iterations: it's going to be an extraordinarily hard and boring\ntask; _much_ worse than any technical documentation.\n\nLet me be clear that I have no hopes of landing this \"patch\": I just\nwanted to create a calm and rational atmosphere for people to discuss\nthe problem, in the hopes of minimizing the chances of large frequent\nfires.  If you think we should put _something_ in our tree, I suggest\ndumping a few raw emails from this thread into\ncontrib/CommunityGuidelines/ (or something).\n\n> Taking one bullet point from the top for example:\n>\n>     0. You do not take offense, no matter what.  If someone attacks\n>     you irrationally, you do not respond.  This is a public mailing\n>     list, and we are all rational people: the attacker has already\n>     humiliated herself in public, and everyone can see that.\n>\n> What does saying \"we are all rational people\" help when \"the\n> attacker\" poses a risk to destroy the community?  What does \"we are\n> all rational people\" even mean in this sentence?\n\nI intended it as a way to reassure everyone that we will make\nunbiased, rational judgements to the extent possible.\n\n> It does not address the real cause of flamewars---why do rational\n> people feel the need to respond when an irrational comment is made,\n> e.g. when a reasonable review comments were responded not with\n> either \"Yeah, you are right, thanks.\" or \"Not really, because you\n> missed this case, I think...\"  but with nitpicks with immaterial\n> details or repetition without justification that takes account that\n> the reviewer is in disagreement and there must be some reason behind\n> it, i.e. a poisonous behaviour?\n\nThere is no great truth about some hidden \"real cause\" to be found.\nFor instance, in the one we just had, I would argue that it \"started\"\nwith your non-patch \"administriva\" email with a huge number of people\nmarked in the initial CC.  Disaster waiting to happen, if you ask me.\nI'm not \"blaming\" you, but the lesson to be learnt is: avoid non-patch\nemails, and CC conservatively; if you want to discuss some changes,\nsend a patch.  That would explain why this very email is disguised as\na \"[PATCH]\", with exactly one person in the initial CC.\n\nIn short, the \"reason\" is a complex mix of various people's\ninteractions under the current circumstances.  Fires happen, and that\nis a fact; we can only look for common patterns and attempt to avoid\nfires by documenting these patterns as violations.  Which is exactly\nwhat I have done (or attempted to do).\n\n> I suspect it mostly has to do with the desire to make sure that\n> bystanders do not get an impression that the one who speaks last\n> gives the conclusion to the discussion, so stating \"The attacker\n> being the one who speaks last in the discussion does not mean the\n> conclusion is his.\" explicitly might be one way to make it more\n> practically useful by alleviating the urge to respond, instead of\n> saying \"no matter what\".\n\nThat is one pattern, but by no means the only one or even the \"most\nimportant\" one.  I thought 0 was a nice generalization.\n"},{"id":"220423","messageId":"CALkWK0nNn8Rcu4JpV4r+0ct+_cuW3aUHXKV4bcB-Hn6Xg8Y+bA@mail.gmail.com","threadId":"34086","inReplyTo":"51B6AA7F.1060505@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T10:45:12Z","receivedAt":"2013-06-11T10:45:12Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Michael Haggerty wrote:\n> Thank you for drafting a proposed CommunityGuidelines document; I think\n> such a document would be helpful.  But I don't like the overall flavor\n> of your proposal; frankly, it sounds to me more like\n>\n> Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations\n\nIt has nothing to do with Felipe.  I've merely documented repeating\npatterns in fire threads as violations, in an attempt to avoid fires.\nI have not worked forward from axioms to derive \"transcendentally\ndesirable behavior\", but rather backwards from a disaster to derive\n\"patterns that have been shown to lead to large fires\".  Why?  Because\nit's easier to derive unambiguous statements using my approach; as I\nwill show shortly, there are various problems with your arguments.\n\nWhat gives you the impression that I documented everyone else's\nviolations, but not Felipe's? ;)\n\n>> 0. You do not take offense, no matter what.  If someone attacks you\n>> irrationally, you do not respond.  This is a public mailing list, and\n>> we are all rational people: the attacker has already humiliated\n>> herself in public, and everyone can see that.\n>\n> This is secondary to the more important rule, \"do not attack other\n> people on the mailing list\".  Not taking offense is at best a(n\n> important) fallback position for those regrettable occasions when\n> somebody else has already violated the primary guideline.\n\nThe problem with your guideline is that you now need to define some\nsort of objective basis to determine whether or not someone attacks.\nWhat is this transcendental notion of \"attack\"?  I say something, and\nyou take offense, while someone else does not.  Have I or have I not\nattacked you?  One possible solution to this dilemma is to use\n\"majority opinion\" as a basis.  This is a very dangerous road to go\ndown, as fringe behaviors will keep getting eliminated until we're\nleft with a bunch of yes-men on the list.  In other words, an\nextremely suffocating atmosphere.\n\nMy guideline does not suffer from this problem.  It only requires you\nto believe that you were personally offended, and act accordingly.\nWhether or not you were justified in being offended is nobody's\nbusiness.\n\n>> 2. You stop pointing fingers.  Every heated discussion requires more\n>> than one participant, and a flamewar requires many participants.  If\n>> you participate, you have implicitly agreed to share the blame for\n>> whatever happens on the thread.  People can judge for themselves who\n>> is to blame.\n>\n> Here your wording \"every heated discussion requires more than one\n> participant\" seems to put more of the blame for heated discussions on\n> participants 2..N and give a pass to participant number one.\n\nI'm not going to comment on the issue of wording, since I've already\nmade it clear that this \"patch\" is not for inclusion.\n\nIt is unclear who \"Participant #1\" is, but I'm not giving anyone a\npass; everyone must share the blame.\n\n>> 3. Thou shalt not commit logical fallacies.  The ones that are most\n>> common on this list: strawman, ad hominem, burden of proof, false\n>> cause, the texas sharpshooter, and appeal to authority.\n>\n> I think putting a rule like this in CommunityGuidelines puts too much\n> weight on it.  In my recollection, pointing out other people's supposed\n> logical fallacies is far more often used on this list as a nitpicking\n> diversionary tactic that usually leads a conversation *further* away\n> from the real issues.  I think it would be a mistake to encourage such\n> formal and stylized argument on the ML.\n\nThe guidelines serve as a means of educating people on the list about\nhow they can avoid fuelling fires, not for literally quoting and\nbeating up violators.  As I have already stated in the final\nparagraph, there needs to be no consensus on whether or not a rule has\nbeen violated: everyone can judge that for themselves.\n\n>> 4. Lead by example.  If you do not like how someone presents\n>> themselves on the list, you counter it by presenting yourself nicely\n>> on the list.  Others will follow your example, making that person's\n>> behavior the minority.  It is far more powerful than explicitly\n>> stating what is \"acceptable\" behavior and what is not.\n>\n> Leading by example is a great approach, and has the effect that you\n> describe on the majority of people.  But I also think it would be\n> helpful for the community to agree on a few very minimum standards of\n> behavior that we insist on, and to call people out (preferably in a\n> private email) if they fall short of these standards.\n\nLet's see what your guidelines look like.\n\n>> 5. We are a community of programmers, and we are here to collaborate\n>> on code.  The argument that leads to higher efficiency and better code\n>> has an automatic advantage over the argument that doesn't.\n>>\n>> If someone breaks one of these rules, there's a very simple way to\n>> communicate this to them: you don't respond to their email.\n>> Optionally, respond to their email off-list calmly explaining what\n>> went wrong.\n>\n> I would prefer a community standards document that looks more like this:\n> [...]\n\nSummary: be a \"nice\" person, said in a very gentle way.  How is it\nbetter than the documents various internet communities have spent\nyears writing and perfecting? [1]\n\n[1]: http://www.ubuntu.com/about/about-ubuntu/conduct\n"},{"id":"220424","messageId":"CALkWK0kzrQpCKc0tCOV-6Tkag4Zmckpt1zqFPR0nvcxQXPKcxA@mail.gmail.com","threadId":"34086","inReplyTo":"CAMP44s0Ra1cEjLqX9iwoRWpO5wHjGFygK-MUw7z1q_d-DhcMNQ@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T11:11:43Z","receivedAt":"2013-06-11T11:11:43Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> I think there's an even more important number 0:\n>\n> Always assume good faith. When discussing through digital mediums,\n> it's very easy to misconstrue the tone and intentions of other\n> parties, so it's better to err on the side of caution, and if one is\n> mistaken, assuming good faith doesn't cause harm, while the contrary\n> does irreparable damage. This does not mean that one should continue\n> to assume good faith when there's evidence to the contrary.\n\nAgreed.  \"Always assume good faith\" is a good rule of thumb.\n\n>> 0. You do not take offense, no matter what.  If someone attacks you\n>> irrationally, you do not respond.  This is a public mailing list, and\n>> we are all rational people: the attacker has already humiliated\n>> herself in public, and everyone can see that.\n>\n> An even better and less absolutist version would be:\n\nI went for the absolutist version because I felt that this point needs\nto be driven in harder.  This is the biggest problem, in my opinion.\n\nBut yeah, your version is more technically correct.\n\n>> 3. Thou shalt not commit logical fallacies.  The ones that are most\n>> common on this list: strawman, ad hominem, burden of proof, false\n>> cause, the texas sharpshooter, and appeal to authority.\n>\n> It might be better to turn this negative rule into a positive one:\n> \"Discuss on the basis of logic and evidence\". Then you can describe\n> the common logical fallacies, and I would add \"If you make a claim, be\n> prepared it to defend it with evidence, or add an appropriate\n> qualifier; probably, most likely, I think, etc.\"\n\nGood addition.\n\n>> If someone breaks one of these rules, there's a very simple way to\n>> communicate this to them: you don't respond to their email.\n>> Optionally, respond to their email off-list calmly explaining what\n>> went wrong.\n>\n> I think you should reply, but not to her, to the mailing list, asking\n> for others to don't reply. Then mute the thread. I already explained\n> that about in the comment about flamewars.\n\nI don't think \"neglect\" is the solution to anything.  We don't want\ncontributors to feel neglected; we want to make them understand that\ntheir behavior was undesirable because of reasons X, Y, and Z.  In a\nraging fire, they might not be able to see these reasons clearly.\n\n> There's a corollary to that that works rather well in the LKML; you\n> are permitted one flamewar per year. I'm not going to explain why this\n> is a good thing, because unfortunately there's an irrational negative\n> bias against me already, but there's a reason why this is a good rule.\n> Even if you don't agree it's only one flamewar per year per person,\n> it's not that much.\n\nI suppose it's a way for people to vent built-up emotion.  Flamewars\nwill happen, no matter what we do; we cannot control the actions of\nothers.  If too many people want to start a fire, we can do nothing: I\ndon't propose an iron hand of suffocation.  My objective is more\nrealistic: it is to make people realize the undesirable effects and\n\"minimize\" fires.\n"},{"id":"220425","messageId":"CAMP44s18LR7HjS0vaXrdDp0HnpHakEMoMpL3TPW1WXaCh+SKDQ@mail.gmail.com","threadId":"34086","inReplyTo":"CALkWK0nNn8Rcu4JpV4r+0ct+_cuW3aUHXKV4bcB-Hn6Xg8Y+bA@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T11:49:45Z","receivedAt":"2013-06-11T11:49:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 5:45 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n\n> Whether or not you were justified in being offended is nobody's\n> business.\n\nIn a parallel with law, there is no concept of \"justly\" offended,\nprecisely because there is no way to determine what that even means.\nPeople get offended by all sorts of things.\n\nWhat's wrong with being offended?\nhttp://www.dailymotion.com/video/xl2w7q_easily-offended-then-watch-this_fun\n\n-- \nFelipe Contreras\n"},{"id":"220427","messageId":"87li6g969j.fsf@linux-k42r.v.cablecom.net","threadId":"34086","inReplyTo":"CALkWK0nNn8Rcu4JpV4r+0ct+_cuW3aUHXKV4bcB-Hn6Xg8Y+bA@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-11T12:33:12Z","receivedAt":"2013-06-11T12:33:12Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Michael Haggerty wrote:\n>> Thank you for drafting a proposed CommunityGuidelines document; I think\n>> such a document would be helpful.  But I don't like the overall flavor\n>> of your proposal; frankly, it sounds to me more like\n>>\n>> Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations\n>\n> It has nothing to do with Felipe.  I've merely documented repeating\n> patterns in fire threads as violations, in an attempt to avoid fires.\n> I have not worked forward from axioms to derive \"transcendentally\n> desirable behavior\", but rather backwards from a disaster to derive\n> \"patterns that have been shown to lead to large fires\".  Why?  Because\n> it's easier to derive unambiguous statements using my approach; as I\n> will show shortly, there are various problems with your arguments.\n>\n> What gives you the impression that I documented everyone else's\n> violations, but not Felipe's? ;)\n\nIt has become clear, also in discussion on IRC, that your preferred\napproach is to fight the fires, attempting to extinguish flames as they\nhappen.\n\nMy approach -- and in my perception also that preferred by most of the\nregulars who have spoken in this whole mess -- is that since there is a\nfire hazard, it would be more effective firefighting to just remove the\nhazard, thus preventing future fires.\n\nI infer that in your view, there is an inalienable right for the fire\nhazard to remain part of the community that you are not willing to give\nup.  I for one no longer have such qualms in this instance.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220435","messageId":"CALkWK0kMvac7Sp3QwvEm+J_-Hj7JAn-AY-juDDw1HR3oQ+hamA@mail.gmail.com","threadId":"34086","inReplyTo":"87li6g969j.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T13:40:11Z","receivedAt":"2013-06-11T13:40:11Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> It has become clear, also in discussion on IRC, that your preferred\n> approach is to fight the fires, attempting to extinguish flames as they\n> happen.\n\nIncorrect.  I am interested in minimizing occurrences, which is why I\nstarted this thread: to calmly and rationally discuss how to achieve\nthat.  I have listed many concrete proposals, and justified them with\nreason.\n\n> My approach -- and in my perception also that preferred by most of the\n> regulars who have spoken in this whole mess -- is that since there is a\n> fire hazard, it would be more effective firefighting to just remove the\n> hazard, thus preventing future fires.\n\nPresumably, Felipe is the \"fire hazard\" that we are talking about, and\nnobody else is to blame.  He must be \"removed\" to prevent future\nfires.  This is the \"perception of the regulars\", correct?\n\nThen why haven't you removed him yet?  What are you waiting for?  You\ndon't need my \"approval\".\n\nIs it because you have realized deep down that you have absolutely no\nrational argument, and are arguing with an ill-formed \"majority\nopinion\"?  I have words, you have words.  Why are you incapable of\nusing your words to counter my arguments rationally?Are you so blind\nthat you cannot see the consequences of acting without reason?\nTomorrow the majority opinion will dictate that I am a fire hazard and\nmust be removed.  Soon, anybody who disagrees with the majority\nopinion will be removed, and the community will be reduced to a\nhandful of circlejerking yes-men.  The git project will die a sad\ndeath.  And the blood will be on your hands.\n\n> I infer that in your view, there is an inalienable right for the fire\n> hazard to remain part of the community that you are not willing to give\n> up.  I for one no longer have such qualms in this instance.\n\nIncorrect.  There is no \"transcendental inalienable right\" that\ndictates that \"fire hazards\" must remain part of the community.  I\nnever made such an irrational argument.  I already gave you the\nexample of the survivors on the boat with limited food/water on IRC:\nit is you who stupidly refused to throw anyone overboard, killing all\nthe survivors; I am the one who said that I would get them to draw\nsticks to \"fairly choose\" who to throw overboard, maximizing the\nchances of survival of the others.  I am making a pragmatic argument,\nbased on what is best for the community; not some stuck-up idealistic\nbullshit.  Further, I tried to help you think through the justice\nproblem, by recommending an accessible course.  You have either not\ngone through it, or have gone through it and learnt nothing.\n\nWhat should I \"give up\"?  My rationality?\n\nMan up, and stop hiding being the veils of \"majority opinion\".  _Your_\nopinion is that Felipe must be removed from the list without reason.\nDon't talk for the others.  I'm sick of you \"supporting\" another\nperson's opinion.  Stand up and speak for yourself; leave Haggerty out\nof it.\n\nYou have embarrassed yourself and the entire git community today.\n"},{"id":"220444","messageId":"51B736FA.5010407@alum.mit.edu","threadId":"34086","inReplyTo":"CALkWK0kMvac7Sp3QwvEm+J_-Hj7JAn-AY-juDDw1HR3oQ+hamA@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-11T14:40:58Z","receivedAt":"2013-06-11T14:40:58Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/11/2013 03:40 PM, Ramkumar Ramachandra wrote:\n> Is it because you have realized deep down that you have absolutely no\n> rational argument...Why are you incapable of\n> using your words to counter my arguments rationally?Are you so blind\n> that you cannot see the consequences of acting without reason?\n\nRam, you are insulting Thomas the human being rather than addressing his\npoints.  Please stop.\n\n> Tomorrow the majority opinion will dictate that I am a fire hazard and\n> must be removed.  Soon, anybody who disagrees with the majority\n> opinion will be removed, and the community will be reduced to a\n> handful of circlejerking yes-men.  The git project will die a sad\n> death.  And the blood will be on your hands.\n\nIt is not disagreement that is causing problems; it is the inflammatory\ntone of the discussion.  Civil and constructive disagreement is\ncompletely welcome here.  But hurtful and offensive discussion is not,\neven if it is in support of the \"party line\" (haha as if there were such\na thing).\n\nAnd yes, I know that the word \"offensive\" is subjective, but for the\nsake of this discussion let's take it to mean \"offensive to the vast\nmajority of a community\".  Not \"controversial\", not \"contrarian\", not\neven \"stupid\"; I don't think anybody is proposing to prohibit dissent or\nstupidity.  But there is no reason for discussion that is gratuitously\naggressive, insulting, or derogatory; such discussion is what I mean by\n\"offensive\".\n\n> [...]  I already gave you the\n> example of the survivors on the boat with limited food/water on IRC:\n> it is you who stupidly refused to throw anyone overboard, killing all\n> the survivors; I am the one who said that I would get them to draw\n> sticks to \"fairly choose\" who to throw overboard, maximizing the\n> chances of survival of the others.  I am making a pragmatic argument,\n> based on what is best for the community; not some stuck-up idealistic\n> bullshit.  Further, I tried to help you think through the justice\n> problem, by recommending an accessible course.  You have either not\n> gone through it, or have gone through it and learnt nothing.\n\nYour idea that you can assign Thomas \"homework\" in ethics and call him\nstupid for coming to a different conclusion than you is presumptuous in\nthe extreme.\n\n> [...]\n> You have embarrassed yourself and the entire git community today.\n\nThis is also presumptuous, not to mention extremely ironic.  In my\nopinion Thomas's email was calm and reasonable while yours is beyond the\npale.\n\nRam, don't just take my opinion on this matter.  At the risk of being\npresumptuous myself, I suggest that you show a copy of your email to\nsomebody whom you know and respect in the real world, somebody who is\nnot immersed in the Git community meltdown.  For example, somebody like\nyour mother or father, or a teacher whom you respect, or a member of\nclergy if you are so inclined.  Ask that person's opinion about your email.\n\nIt is so easy to lose perspective in the Internet.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220448","messageId":"CAMP44s2fZemrqrBQGwFduE3dYs6S_dBO1fwpbfyDPn+jovze-Q@mail.gmail.com","threadId":"34086","inReplyTo":"87li6g969j.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T15:06:07Z","receivedAt":"2013-06-11T15:06:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast <trast@inf.ethz.ch> wrote:\n\n> My approach -- and in my perception also that preferred by most of the\n> regulars who have spoken in this whole mess -- is that since there is a\n> fire hazard, it would be more effective firefighting to just remove the\n> hazard, thus preventing future fires.\n\nYou would make an excellent evil dictator.\n\nA benevolent dictator like Linus Torvalds knows better, in the LKML\n\"fire hazards\" are not removed, they are ignored before any flames go\nup. This achieves the best of both worlds; if the person is truly\nvicious, nothing happens, but if there's something to it, a person\nthat doesn't offend so easily might have a fruitful discussion, while\nthe rest ignore the thread.\n\nIn a flamewar everyone is guilty. Apparently you never learned that\n\"but he started it!\" is not a defense worthy of an adult, hell, even\nmost children know that.\n\n-- \nFelipe Contreras\n"},{"id":"220449","messageId":"CAMP44s3cks2USO3Lwen83s2q3iDSDnLxorJ6_krN0bP_1tK-yA@mail.gmail.com","threadId":"34086","inReplyTo":"51B736FA.5010407@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T15:34:36Z","receivedAt":"2013-06-11T15:34:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nBefore going to your arguments, can you stop conveniently *ignoring*\nmy argument and answer this questions?\n\nWhen two children fight, who has the blame? The one that threw the\nfirst punch? Or the one that returned it?\n\nOn Tue, Jun 11, 2013 at 9:40 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 06/11/2013 03:40 PM, Ramkumar Ramachandra wrote:\n>> Is it because you have realized deep down that you have absolutely no\n>> rational argument...Why are you incapable of\n>> using your words to counter my arguments rationally?Are you so blind\n>> that you cannot see the consequences of acting without reason?\n>\n> Ram, you are insulting Thomas the human being rather than addressing his\n> points.  Please stop.\n\nHow is Ram insulting Thomas? By implying that Thomas is a human being?\nThat he is imperfect and is making a mistake?\n\nMy gosh! How offensive!\n\n>> Tomorrow the majority opinion will dictate that I am a fire hazard and\n>> must be removed.  Soon, anybody who disagrees with the majority\n>> opinion will be removed, and the community will be reduced to a\n>> handful of circlejerking yes-men.  The git project will die a sad\n>> death.  And the blood will be on your hands.\n>\n> It is not disagreement that is causing problems; it is the inflammatory\n> tone of the discussion.  Civil and constructive disagreement is\n> completely welcome here.  But hurtful and offensive discussion is not,\n> even if it is in support of the \"party line\" (haha as if there were such\n> a thing).\n\nThe difference between the two is totally and completely subjective,\nand only a despot would be conformable parting judgment about which is\nwhich.\n\n> And yes, I know that the word \"offensive\" is subjective, but for the\n> sake of this discussion let's take it to mean \"offensive to the vast\n> majority of a community\".\n\nRule of the mob. How wise.\n\n>> [...]  I already gave you the\n>> example of the survivors on the boat with limited food/water on IRC:\n>> it is you who stupidly refused to throw anyone overboard, killing all\n>> the survivors; I am the one who said that I would get them to draw\n>> sticks to \"fairly choose\" who to throw overboard, maximizing the\n>> chances of survival of the others.  I am making a pragmatic argument,\n>> based on what is best for the community; not some stuck-up idealistic\n>> bullshit.  Further, I tried to help you think through the justice\n>> problem, by recommending an accessible course.  You have either not\n>> gone through it, or have gone through it and learnt nothing.\n>\n> Your idea that you can assign Thomas \"homework\" in ethics and call him\n> stupid for coming to a different conclusion than you is presumptuous in\n> the extreme.\n\nHe didn't call him stupid, he said he was acting stupidly, big difference.\n\n>> [...]\n>> You have embarrassed yourself and the entire git community today.\n>\n> This is also presumptuous, not to mention extremely ironic.  In my\n> opinion Thomas's email was calm and reasonable while yours is beyond the\n> pale.\n\nOf course it would be. In a witch hunt nobody sees what's wrong with\nburning the witch... until you become it.\n\nIt's fine for Thomas Rast to call me a fire hazard, which ironically\nis itself an inflammatory comment. But it's not OK for Ramkumar to say\nthat Thomas is acting stupidly *in this particular instance*.\n\nDouble standards much?\n\n> Ram, don't just take my opinion on this matter.  At the risk of being\n> presumptuous myself, I suggest that you show a copy of your email to\n> somebody whom you know and respect in the real world, somebody who is\n> not immersed in the Git community meltdown.  For example, somebody like\n> your mother or father, or a teacher whom you respect, or a member of\n> clergy if you are so inclined.  Ask that person's opinion about your email.\n\nI can offer my own perspective; I think Ramkumar's tone is not\nparticularly useful, but to concentrate on *how* he is saying things,\ninstead of *what* he is saying is an even bigger mistake, specially\nbecause it's *you* the one that is making it. You should concentrate\non what *you* do, not what others do. Otherwise you will be forever\nfrustrated.\n\nYou have chosen to ignore *all* of Ramkumar's arguments, and all your\narguments can be summarized as \"I don't like your tone\", and by doing\nthat, you have lost even more touch of the discussion than what you\naccused Ramkumar of doing.\n\nYou have even violated two your own guidelines:\n\n* Conduct disagreements on a technical, not a personal, level.\n* It is not OK to use these guidelines as a stick with which to beat\nsupposed violators.\n\nYou have also violated some of Ramkumar:\n\n0. You do not take offense, no matter what.\n\nIn this particular case, you are taking offense by proxy, which might\nbe even worst.\n\n1. You do not take sides or vote.\n2. You stop pointing fingers.\n\nI would also suggest another guideline based on Paul Graham's guide\nHow to Disagree[1].\n\n* Do not respond to tone. Concentrate on *what* is being said, not\n*how* it is being said. If the worst thing you can say about something\nis to criticize its tone, you're not saying much. A \"bad tone\" is\nhighly subjective, and it's not really relevant in a discussion, it\nmatters whether the author is right or wrong. Is the author flippant,\nbut correct? Better that than grave and wrong. Keep your eye on the\nball.\n\n[1] http://www.paulgraham.com/disagree.html\n\n-- \nFelipe Contreras\n"},{"id":"220450","messageId":"87obbc4pv7.fsf@linux-k42r.v.cablecom.net","threadId":"34086","inReplyTo":"CAMP44s2fZemrqrBQGwFduE3dYs6S_dBO1fwpbfyDPn+jovze-Q@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-11T15:41:00Z","receivedAt":"2013-06-11T15:41:00Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast <trast@inf.ethz.ch> wrote:\n>\n>> My approach -- and in my perception also that preferred by most of the\n>> regulars who have spoken in this whole mess -- is that since there is a\n>> fire hazard, it would be more effective firefighting to just remove the\n>> hazard, thus preventing future fires.\n>\n> You would make an excellent evil dictator.\n>\n> A benevolent dictator like Linus Torvalds knows better, in the LKML\n> \"fire hazards\" are not removed, they are ignored before any flames go\n> up. This achieves the best of both worlds; if the person is truly\n> vicious, nothing happens, but if there's something to it, a person\n> that doesn't offend so easily might have a fruitful discussion, while\n> the rest ignore the thread.\n>\n> In a flamewar everyone is guilty. Apparently you never learned that\n> \"but he started it!\" is not a defense worthy of an adult, hell, even\n> most children know that.\n\n[Yes, I should let this thread die, but you are offering me too good a\nchance to pass up.]\n\nIt's funny that you would mention Linus, considering there's at least\none instance on record where he broke almost every rule that Ram\nattempted to set out in the thread starter, calling you among other\nthings a \"fucking moron\" and telling you to \"go away\".\n\n  https://lkml.org/lkml/2012/4/12/434\n\nIn case our readers wonder why the flame war suddenly died out at a\ndepth of about 19 replies, fear not, for the story continued:\n\n  https://plus.google.com/108736516888538655285/posts/7QSVy8taWgC\n\n\nAnd before you try to shoot that down, please make sure your argument\nalso applies to the recurring situation of your repeatedly ignoring\nSubmittingPatches as far as commit messages go against explicit requests\nto stop that.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220452","messageId":"CAMP44s01BF6cGc6DM2JzifzyeLnd+q541rxx=BuaiTUBQM8ffA@mail.gmail.com","threadId":"34086","inReplyTo":"87obbc4pv7.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T15:52:53Z","receivedAt":"2013-06-11T15:52:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 10:41 AM, Thomas Rast <trast@inf.ethz.ch> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast <trast@inf.ethz.ch> wrote:\n>>\n>>> My approach -- and in my perception also that preferred by most of the\n>>> regulars who have spoken in this whole mess -- is that since there is a\n>>> fire hazard, it would be more effective firefighting to just remove the\n>>> hazard, thus preventing future fires.\n>>\n>> You would make an excellent evil dictator.\n>>\n>> A benevolent dictator like Linus Torvalds knows better, in the LKML\n>> \"fire hazards\" are not removed, they are ignored before any flames go\n>> up. This achieves the best of both worlds; if the person is truly\n>> vicious, nothing happens, but if there's something to it, a person\n>> that doesn't offend so easily might have a fruitful discussion, while\n>> the rest ignore the thread.\n>>\n>> In a flamewar everyone is guilty. Apparently you never learned that\n>> \"but he started it!\" is not a defense worthy of an adult, hell, even\n>> most children know that.\n>\n> [Yes, I should let this thread die, but you are offering me too good a\n> chance to pass up.]\n>\n> It's funny that you would mention Linus, considering there's at least\n> one instance on record where he broke almost every rule that Ram\n> attempted to set out in the thread starter, calling you among other\n> things a \"fucking moron\" and telling you to \"go away\".\n>\n>   https://lkml.org/lkml/2012/4/12/434\n\nYet, this \"fire hazzard\" was not removed, nor was there any threat of\ndoing so at any point in the discussion.\n\n> In case our readers wonder why the flame war suddenly died out at a\n> depth of about 19 replies, fear not, for the story continued:\n>\n>   https://plus.google.com/108736516888538655285/posts/7QSVy8taWgC\n\nYou sure like your ad hominem arguments. Perhaps it would be wise to\nget the timeline right. The Google+ discussion you are pointing to\nhappened *before* the thread ended, even Linus replied after that:\n\nhttp://article.gmane.org/gmane.linux.drivers.ath9k.devel/8675\n\n> And before you try to shoot that down, please make sure your argument\n> also applies to the recurring situation of your repeatedly ignoring\n> SubmittingPatches as far as commit messages go against explicit requests\n> to stop that.\n\nThere's nothing to shoot down, you are not making any argument. You\nare doing nothing but throwing personal attacks.\n\nIf what you are suggesting is that we should do what they did in the\nLKML; they did *exactly* what I'm suggesting you should do; *ignore*\nthe people that you think are vicious.\n\nIs that what you are suggesting?\n\n-- \nFelipe Contreras\n"},{"id":"220453","messageId":"87ppvszl0i.fsf@linux-k42r.v.cablecom.net","threadId":"34086","inReplyTo":"51B6AA7F.1060505@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-11T16:10:05Z","receivedAt":"2013-06-11T16:10:05Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> * Accept reviewers' comments gratefully and take them very seriously.\n> Show that you appreciate the help by giving the reviewer the benefit of\n> the doubt.  If, after careful consideration, you find that you cannot\n> agree with a reviewer's suggestion, explain your reasoning carefully\n> without taking or giving offense, and seek compromise.\n\nI'm not sure yet how to phrase it, but I have come to the conclusion\nthat the dual nature of reviews is part of the problem.\n\nOn the one hand, reviews are code criticism: they are extra work spent\nby the reviewer to try and help you improve your work.\n\nOn the other hand, they are also quality checks.  Reviews serve to spot\nbugs, misdesigns, noncompliance with project standards, etc. before they\never go into the code base.\n\nThe problems start when these start having a contradictory impact on the\ncorrect course of action in a discussion, or in the longer term in\ndealing with a person.  For example, I have attempted to deal with\nFelipe at one point by refusing to review, i.e., ignore the email.\n\nHowever, this must be weighed against the requirements of the second\nkind of review.  So while it is exceedingly easy for everyone to say\n\"just ignore the flamebait\", the flamewars keep recurring because this\n\"gatekeeper\" type of review continues to be necessary, and continues to\nelicit nonconstructive responses.\n\nThe \"easy\" solution is to simply stop taking patches from Felipe, but\nopens pandora's box w.r.t. the just application of such a measure, as\nRam has noted repeatedly.\n\nYet that is the only measure that I currently know that both keeps up\ncode review standards and has any hope of improving the current climate.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220455","messageId":"CAMP44s2r5DcG3KVfM79c-ZZZS0t_8pBp2TEtp2958JuB=Ne3Xw@mail.gmail.com","threadId":"34086","inReplyTo":"87ppvszl0i.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T16:17:46Z","receivedAt":"2013-06-11T16:17:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 11:10 AM, Thomas Rast <trast@inf.ethz.ch> wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>\n>> * Accept reviewers' comments gratefully and take them very seriously.\n>> Show that you appreciate the help by giving the reviewer the benefit of\n>> the doubt.  If, after careful consideration, you find that you cannot\n>> agree with a reviewer's suggestion, explain your reasoning carefully\n>> without taking or giving offense, and seek compromise.\n>\n> I'm not sure yet how to phrase it, but I have come to the conclusion\n> that the dual nature of reviews is part of the problem.\n>\n> On the one hand, reviews are code criticism: they are extra work spent\n> by the reviewer to try and help you improve your work.\n>\n> On the other hand, they are also quality checks.  Reviews serve to spot\n> bugs, misdesigns, noncompliance with project standards, etc. before they\n> ever go into the code base.\n>\n> The problems start when these start having a contradictory impact on the\n> correct course of action in a discussion, or in the longer term in\n> dealing with a person.  For example, I have attempted to deal with\n> Felipe at one point by refusing to review, i.e., ignore the email.\n>\n> However, this must be weighed against the requirements of the second\n> kind of review.  So while it is exceedingly easy for everyone to say\n> \"just ignore the flamebait\", the flamewars keep recurring because this\n> \"gatekeeper\" type of review continues to be necessary, and continues to\n> elicit nonconstructive responses.\n\nWhy do you assume the review is for the patch submitter? You can reply\nso your review is stored on the record, and the maintainer, Junio, can\nsee it. Then you can ignore the fallout.\n\nI think this type of review is hurtful, because the fact that you said\nsome words doesn't mean you are right, and you might be blocking a\nperfectly good patch by not following up the counter arguments.\n\nPresumably you are not worried about that, and you would be content\nwith simply blocking all my patches. Whatever floats your boat.\n\n-- \nFelipe Contreras\n"},{"id":"220459","messageId":"7v38sod1kn.fsf@alter.siamese.dyndns.org","threadId":"34086","inReplyTo":"51B6AA7F.1060505@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-11T17:00:56Z","receivedAt":"2013-06-11T17:00:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> I would prefer a community standards document that looks more like this:\n\nOK.\n\n> * Accept reviewers' comments gratefully and take them very seriously.\n> Show that you appreciate the help by giving the reviewer the benefit of\n> the doubt.  If, after careful consideration, you find that you cannot\n> agree with a reviewer's suggestion, explain your reasoning carefully\n> without taking or giving offense, and seek compromise.\n\nIn short, the only acceptable response to review comments are \"You\nare right. Here is a reroll\", or \"I think your suggestion will miss\nthese cases which I wanted to cover and that is why I did it this\nway\". There may be other small variants of the above two, but I\nthink I can agree with the general principle.\n\nIn cases, there are two or more equally valid approaches to solving\na problem.  I do not think I had to accept (or reject) many \"it can\nbe done better in different ways and this perhaps is not the best\none\" (or \"it could be argued that it is correct\") borderline topics\nin the recent past, but I suspect that \"a disagreement is healthy\"\nhas to be accompanied by how disagreements that do not resolve\nthemselves are resolved (I think I've heard somewhere that some\ncommunities break ties in favor of reviewers, for example).\n\n> * When reviewing other peoples' code, be tactful and constructive.  Set\n> high expectations, but do what you can to help the submitter achieve\n> them.  Don't demand changes based only on your personal preferences.\n> Don't let the perfect be the enemy of the good.\n\nI think this is 30% aimed at me (as I think I do about that much of\nthe reviews around here).  I fully agree with most of them, but the\nlast sentence is a bit too fuzzy to be a practically useful\nguideline.  Somebody's bare minimum is somebody else's perfection.\nAn unqualified \"perfect is the enemy of good\" is often incorrectly\nused to justify \"It works for me.\" and \"There already are other\ncodepaths that do it in the same wrong way.\", both of which make\nthings _worse_ for the long term project health.\n\n> * It is not OK to use these guidelines as a stick with which to beat\n> supposed violators.  However, if you genuinely feel that another\n> community member is routinely behaving in ways that are detrimental to\n> the community, it might help to calmly express your concerns to that\n> person, preferably in a private email, and naming concrete and specific\n> incidents rather than broad generalizations.\n\nI would think it is perfectly OK to say \"The way you are refusing to\nlisten to constructive comments is not how things work around here\"\nby pointing at a set of guidelines.\n\nWhy do you think is it not OK?  The \"beating\" part?\n"},{"id":"220480","messageId":"CALkWK0n=gbfeG87GCR0A=fZY5osjndLo9TPv1BH1uAf37eQ8=g@mail.gmail.com","threadId":"34086","inReplyTo":"51B736FA.5010407@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T18:16:59Z","receivedAt":"2013-06-11T18:16:59Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"This is an exercise.  I can easily be more tactful (as evidenced by\nother threads), but I'm choosing not to be.  I want you to focus on\nthe argument, and not the tone.\n\nMichael Haggerty wrote:\n> Ram, you are insulting Thomas the human being rather than addressing his\n> points.  Please stop.\n\nHe doesn't have a point!  He makes the assumption that the \"perception\nof the regulars\" is that a \"fire hazard\" must be \"removed\" from the\ncommunity.  There are absolutely no rational arguments in his email,\nhe violated virtually every rule that we were working towards, and he\nmade an inflammatory comment by calling Felipe a \"fire hazard\".  Yes I\nwas particularly harsh, because Rast was particularly irrational.  I\ndid not \"insult\" him as a human being; I \"criticized\" his email which\nwas completely devoid of reason.\n\nIn case you're wondering, this is what an ad hominem looks like:\n\nYou are studying a subject that requires extensive application of\nlogic: combinatorial structures and algorithms at ETH Zurich.  You\nlive in a well-to-do progressive society.  I live in this poor country\ncalled India, am much younger than you, and have studied nothing.\nYet, you make the irrational argument, while I make the rational\nargument.\n\nAs you can clearly see, I focused on his argument; not on him.\n\n> It is not disagreement that is causing problems; it is the inflammatory\n> tone of the discussion.  Civil and constructive disagreement is\n> completely welcome here.  But hurtful and offensive discussion is not,\n> even if it is in support of the \"party line\" (haha as if there were such\n> a thing).\n\nIncorrect.  The problem is that Rast is made an irrational argument,\nand that you are \"supporting\" him now.  If you were \"fair\" you would\nhave criticized Rast's inflammatory comment about classifying Felipe\nas a \"fire hazard\", without justification.  But you didn't.  _You_ are\nmaking my \"tone\" the subject of discussion now, and claim that I have\nbeen hurtful and offensive.  My email was very much \"constructive\ndisagreement\", in that I have laid out why one should not perform\nactions without reason; I even assigned him homework, because I _want_\nhim to understand justice and argue rationally.  How could I have been\nmore constructive?\n\nI do not \"support\" Felipe, or \"defend\" him.  I do not share his exact\nopinions, and often criticize him.  I am fair in that I praise\nrational arguments, and criticize irrational arguments.  I don't want\nto speak for him, but I believe that he gives me the same treatment,\nand I thank him for that.\n\nI do not appreciate this ganging-up one bit.  I'm one person arguing\nagainst an opaque \"majority opinion\" veil.  For the last time, stop\ntaking sides, and make a goddamn rational argument!\n\n> And yes, I know that the word \"offensive\" is subjective, but for the\n> sake of this discussion let's take it to mean \"offensive to the vast\n> majority of a community\".  Not \"controversial\", not \"contrarian\", not\n> even \"stupid\"; I don't think anybody is proposing to prohibit dissent or\n> stupidity.  But there is no reason for discussion that is gratuitously\n> aggressive, insulting, or derogatory; such discussion is what I mean by\n> \"offensive\".\n\nYou have made the same argument that I criticized over and over again:\n\"majority opinion\".  If you agree that tone is subjective, why are you\ntrying to objectively criticize it by using majority opinion as the\nbasis?  You might not like a piece of artwork personally, and the\nmajority of the git list might \"agree\" with you, but that does not\nmean you can authoritatively claim that the piece of art is junk.  You\nhave every right to dislike it personally, but that is an entirely\ndifferent matter.\n\n>> [...]  I already gave you the\n>> example of the survivors on the boat with limited food/water on IRC:\n>> it is you who stupidly refused to throw anyone overboard, killing all\n>> the survivors; I am the one who said that I would get them to draw\n>> sticks to \"fairly choose\" who to throw overboard, maximizing the\n>> chances of survival of the others.  I am making a pragmatic argument,\n>> based on what is best for the community; not some stuck-up idealistic\n>> bullshit.  Further, I tried to help you think through the justice\n>> problem, by recommending an accessible course.  You have either not\n>> gone through it, or have gone through it and learnt nothing.\n>\n> Your idea that you can assign Thomas \"homework\" in ethics and call him\n> stupid for coming to a different conclusion than you is presumptuous in\n> the extreme.\n\nIncorrect.  I used \"stupid\" to describe his solution to the\nsurvivors-in-the-boat problem.  I gave him homework (and this is\nHarvard Justice, by the way), in an attempt to get him to think\nclearly and come up with less \"stupid\" solutions to similar problems.\nIf you are defending throwing modern justice theories out the window,\nand replacing it with a crude irrational argument, I have nothing more\nto say.\n\n>> [...]\n>> You have embarrassed yourself and the entire git community today.\n>\n> This is also presumptuous, not to mention extremely ironic.  In my\n> opinion Thomas's email was calm and reasonable while yours is beyond the\n> pale.\n\nYes, I did exercise my freedom of expression.  And yes, I was\nperfectly calm.  Please do not suffocate me to death.\n\nLet us get two simple things straightened out first:\n1. Was Thomas being irrational or not?\n2. Are you being fair or not?\n\nThey're yes-or-no questions.  Hint: My \"tone\" has nothing to do with\nthe answers.\n\n> Ram, don't just take my opinion on this matter.  At the risk of being\n> presumptuous myself, I suggest that you show a copy of your email to\n> somebody whom you know and respect in the real world, somebody who is\n> not immersed in the Git community meltdown.  For example, somebody like\n> your mother or father, or a teacher whom you respect, or a member of\n> clergy if you are so inclined.  Ask that person's opinion about your email.\n\nI respect all of you on the Git list.  And yes, I have done what you\nasked: I showed it to several friends of mine on IRC and in real life.\n They were not at all surprised: they know me to be a very polite,\ngentle, and reasonable person.  My stern rational disagreement has\nnothing to do with any of those things.\n\nAnd yes, as Felipe pointed out: you entire email has complained about\nmy \"tone\" and _completely_ ignored content.\n"},{"id":"220481","messageId":"51B76B4F.4030504@alum.mit.edu","threadId":"34086","inReplyTo":"7v38sod1kn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-11T18:24:15Z","receivedAt":"2013-06-11T18:24:15Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/11/2013 07:00 PM, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n> [...]\n>> * When reviewing other peoples' code, be tactful and constructive.  Set\n>> high expectations, but do what you can to help the submitter achieve\n>> them.  Don't demand changes based only on your personal preferences.\n>> Don't let the perfect be the enemy of the good.\n> \n> I think this is 30% aimed at me (as I think I do about that much of\n> the reviews around here).  I fully agree with most of them, but the\n> last sentence is a bit too fuzzy to be a practically useful\n> guideline.  Somebody's bare minimum is somebody else's perfection.\n> An unqualified \"perfect is the enemy of good\" is often incorrectly\n> used to justify \"It works for me.\" and \"There already are other\n> codepaths that do it in the same wrong way.\", both of which make\n> things _worse_ for the long term project health.\n\nI agree that the last line is fuzzy.  And I don't think that I've\nobserved any cases where I thought that reviewers were being too strict,\nso in a way it's just trying to head off hypothetical future problems\nand to make sure that the balance between submitter and reviewer is not\n*entirely* one-sided.  Given our (proper, I think) strong deference to\nreviewers, one could imagine a reviewer abusing his/her authority to\nobstruct reasonable changes by (for example) making demands that the\nsubmitter also fix tangentially-related things that are beyond the scope\nof the patch.\n\nIn my own projects I have a rough policy of \"not worse than before\",\nmeaning that as long as a patch makes progress in at least one\ndimension, and doesn't make things worse in any other dimension, then it\nis acceptable.  (Of course \"worse\" can include internal quality issues\nlike copy-pasting code or even an increase in the amount of code\ndisproportionate to its benefit.)  A failure to make improvements in one\narea should not be a reason to block an improvement in another area, as\nlong as nothing is made worse.\n\nBut I can't right now think of a succinct way to express what I have in\nmind.\n\n>> * It is not OK to use these guidelines as a stick with which to beat\n>> supposed violators.  However, if you genuinely feel that another\n>> community member is routinely behaving in ways that are detrimental to\n>> the community, it might help to calmly express your concerns to that\n>> person, preferably in a private email, and naming concrete and specific\n>> incidents rather than broad generalizations.\n> \n> I would think it is perfectly OK to say \"The way you are refusing to\n> listen to constructive comments is not how things work around here\"\n> by pointing at a set of guidelines.\n\nI agree.\n\n> Why do you think is it not OK?  The \"beating\" part?\n\nI think it would be counterproductive for people to start saying things\nlike \"that is a violation of rule 3, section 2\" *in everyday\ndiscussions*.  This shouldn't be taken as a list of black-and-white\nlaws, with allegations of small \"infractions\" used to shut down\ndiscussions.  And on the other hand, if somebody shows a long history of\nacting contrary to the guidelines, and persists despite repeated\nrequests to stop, I don't want the discussion to turn into a lawyerly\nanalysis of the guidelines with point-by-point rebuttals and\ncounter-rebuttals of whether this or that guideline was violated.\n\nThe guidelines should just describe the expected tone of the community\nin a way that the vast majority of participants can agree on, and any\nkind of actions to enforce the guidelines should only be taken when an\noverwhelming majority of the community\n\nI think the CommunityGuidelines should have three main uses:\n\n1. An artifact documenting the community consensus about what kinds of\nbehaviors are encouraged and what kinds are considered unacceptable.  It\nshould only be accepted, and it only has value, if there is a strong\nconsensus in favor of it.\n\n2. A resource to help new community members get up to speed on our\npractices and expectations.\n\n3. As a point of reference in the direst meltdowns, such as IMO we are\nhaving right now.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220483","messageId":"20130611182936.GM22905@serenity.lan","threadId":"34086","inReplyTo":"7v38sod1kn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-11T18:29:36Z","receivedAt":"2013-06-11T18:29:36Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n> > * When reviewing other peoples' code, be tactful and constructive.  Set\n> > high expectations, but do what you can to help the submitter achieve\n> > them.  Don't demand changes based only on your personal preferences.\n> > Don't let the perfect be the enemy of the good.\n> \n> I think this is 30% aimed at me (as I think I do about that much of\n> the reviews around here).  I fully agree with most of them, but the\n> last sentence is a bit too fuzzy to be a practically useful\n> guideline.  Somebody's bare minimum is somebody else's perfection.\n> An unqualified \"perfect is the enemy of good\" is often incorrectly\n> used to justify \"It works for me.\" and \"There already are other\n> codepaths that do it in the same wrong way.\", both of which make\n> things _worse_ for the long term project health.\n\nOne thing that I think is missing from these proposals so far is some\nclear indication that a review should not be confrontational.  Consider\nthe following two review comments (taken from a recent example that\nhappened to stick in my mind, but I don't want to single out any one\nindividual here):\n\n    Ugh, why this roundabout-passive-past tone?  Use imperative tone\n    like this:\n\n        ...\n\nvs.\n\n    We normally use the imperative in commit messages, perhaps like\n    this?\n\n        ...\n\nBoth say the same thing but the first immediately puts the submitter on\nthe defensive.  If I see something like that on one of my patches I have\nto consciously resist the urge to reply immediately and instead review\nwhat I'm about to send once I've calmed down.\n\nI realise that we shouldn't take offence to review comments, but we are\nall human and it is sometimes hard not to take things personally.\n\nIn the examples above, the first makes it feel like the submitter is\nfighting to get a patch included, but the second feels like we're\ncollaborating to get to the best result for the project.\n\nAs my mother would say, \"politeness costs nothing\" ;-)\n"},{"id":"220489","messageId":"51B76FD6.7070304@alum.mit.edu","threadId":"34086","inReplyTo":"CALkWK0n=gbfeG87GCR0A=fZY5osjndLo9TPv1BH1uAf37eQ8=g@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-11T18:43:34Z","receivedAt":"2013-06-11T18:43:34Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/11/2013 08:16 PM, Ramkumar Ramachandra wrote:\n> This is an exercise.  I can easily be more tactful (as evidenced by\n> other threads), but I'm choosing not to be.  I want you to focus on\n> the argument, and not the tone.\n\nI stopped reading your email here.  I've read enough tactless emails\nover the last few days, but to be asked to read an email that was\n*intentionally* written tactlessly is too detrimental to my quality of life.\n\nIn German there is an expression \"Der Ton macht die Musik\": \"the tone\nmakes the music\", by which they mean that the *way* something is said is\nat least as important as what is said.  The tone *is* an integral part\nof the message and (1) the writer will be much more effective by making\nthe tone agree with the literal words of the message and (2) for this\nparticular reader, the effort of accommodating writers who are unwilling\nto do so has become too exhausting.\n\nI naively thought that I might be able to help calm the situation, but I\nhave concluded that nothing I can say or do will have that effect.\nTherefore I bow out of this part of the conversation and hope either\nthat it will fizzle out or that perhaps a deus ex machina will appear.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220490","messageId":"CALkWK0n9Ws6DRbKPRHcQPhFTFx533PZH6dg1=w-O1hQ06V66-A@mail.gmail.com","threadId":"34086","inReplyTo":"20130611182936.GM22905@serenity.lan","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T18:46:28Z","receivedAt":"2013-06-11T18:46:28Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"John Keeping wrote:\n>     Ugh, why this roundabout-passive-past tone?  Use imperative tone\n>     like this:\n>\n>         ...\n>\n> vs.\n>\n>     We normally use the imperative in commit messages, perhaps like\n>     this?\n>\n>         ...\n>\n> As my mother would say, \"politeness costs nothing\" ;-)\n\nThe review is being honest about her feelings in the first one, and\nbeing artificially diplomatic in the second one.  Both of them are\nconstructive and friendly, in that they provide an example for the\nsubmitter to follow.\n\nEither way, I'm not interested in problems that have no solutions.\nThe only \"solution\" I see here is to suffocate every contributor until\nthey are \"tactful enough\" for the majority's liking, and \"remove\" the\nones that don't conform.  If you do have an alternate solution, please\nshare it with us.\n"},{"id":"220492","messageId":"51B771D5.6030809@alum.mit.edu","threadId":"34086","inReplyTo":"20130611182936.GM22905@serenity.lan","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-11T18:52:05Z","receivedAt":"2013-06-11T18:52:05Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/11/2013 08:29 PM, John Keeping wrote:\n> On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:\n>> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>>> * When reviewing other peoples' code, be tactful and constructive.  Set\n>>> high expectations, but do what you can to help the submitter achieve\n>>> them.  Don't demand changes based only on your personal preferences.\n>>> Don't let the perfect be the enemy of the good.\n>>\n>> I think this is 30% aimed at me (as I think I do about that much of\n>> the reviews around here).  I fully agree with most of them, but the\n>> last sentence is a bit too fuzzy to be a practically useful\n>> guideline.  Somebody's bare minimum is somebody else's perfection.\n>> An unqualified \"perfect is the enemy of good\" is often incorrectly\n>> used to justify \"It works for me.\" and \"There already are other\n>> codepaths that do it in the same wrong way.\", both of which make\n>> things _worse_ for the long term project health.\n> \n> One thing that I think is missing from these proposals so far is some\n> clear indication that a review should not be confrontational.  Consider\n> the following two review comments (taken from a recent example that\n> happened to stick in my mind, but I don't want to single out any one\n> individual here):\n> \n>     Ugh, why this roundabout-passive-past tone?  Use imperative tone\n>     like this:\n> \n>         ...\n> \n> vs.\n> \n>     We normally use the imperative in commit messages, perhaps like\n>     this?\n> \n>         ...\n> \n> Both say the same thing but the first immediately puts the submitter on\n> the defensive.  If I see something like that on one of my patches I have\n> to consciously resist the urge to reply immediately and instead review\n> what I'm about to send once I've calmed down.\n\nThat's a very good point (and a good illustration, too).  How do you\nlike the new second and third sentences below?\n\n* When reviewing other peoples' code, be tactful and constructive.\nRemember that submitting patches for public critique can be very\nintimidating and when mistakes are found it can be embarrassing.  Do\nwhat you can to make it a positive and pleasant experience for the\nsubmitter.  Set high expectations, but do what you can to help the\nsubmitter achieve them.  Don't demand changes based only on your\npersonal preferences. Don't let the perfect be the enemy of the good.\n\n(As Junio pointed out, the last sentence is not so great and a better\nreplacement would be welcome.)\n\n> As my mother would say, \"politeness costs nothing\" ;-)\n\nDoes your mother program C?  We could use her around here :-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220493","messageId":"CALkWK0kAhB8mimKMrW9i8JJkz+L7-jMDaes_U8bzjWyNq88fEQ@mail.gmail.com","threadId":"34086","inReplyTo":"51B76FD6.7070304@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-11T18:55:52Z","receivedAt":"2013-06-11T18:55:52Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Michael Haggerty wrote:\n> I stopped reading your email here.  I've read enough tactless emails\n> over the last few days, but to be asked to read an email that was\n> *intentionally* written tactlessly is too detrimental to my quality of life.\n\nI'm sorry, but the problem has no solution then.\n\nThe \"problem\" we are dealing with is irrational and/or out-of-tone\nemails.  Unless you possess some mind-control mechanism that will get\nall contributors to write emails that conform to your standards, there\nis no solution.  If you feel strongly that everyone must conform to\nyour standards, you must \"remove\" the members that do not conform to\nthat standard.\n\nI have no desire to be suffocated to conform to your standard, so I'm\nready to leave.\n"},{"id":"220495","messageId":"7vsj0oa2m6.fsf@alter.siamese.dyndns.org","threadId":"34086","inReplyTo":"CALkWK0kAhB8mimKMrW9i8JJkz+L7-jMDaes_U8bzjWyNq88fEQ@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-11T19:06:41Z","receivedAt":"2013-06-11T19:06:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Michael Haggerty wrote:\n>> I stopped reading your email here.  I've read enough tactless emails\n>> over the last few days, but to be asked to read an email that was\n>> *intentionally* written tactlessly is too detrimental to my quality of life.\n>\n> I'm sorry, but the problem has no solution then.\n>\n> The \"problem\" we are dealing with is irrational and/or out-of-tone\n> emails.  Unless you possess some mind-control mechanism that will get\n> all contributors to write emails that conform to your standards, there\n> is no solution.\n\nActually there is.  Just ignore the troll.\n\nIn the past few days, I've learned to mostly skim mails from you and\nFelipe on this topic (and perhaps some other topics) just enough to\nsee if there is anything worth reading and/or responding to in them,\nand have ignored most of them.\n\nThat gave me some time back to do the real work.\n\nIf you argue that we should not punish \"people\" but \"bad behaviour\",\nthat is fine.  The \"From:\" field, combined with the \"Subject: \"\nfield, is often a pretty good indication to tell if a message is\nworth reading and/or responding to, so ignoring such messages and\nignoring troll senders practically amount to the same thing.\n"},{"id":"220497","messageId":"20130611191936.GN22905@serenity.lan","threadId":"34086","inReplyTo":"51B771D5.6030809@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-11T19:19:36Z","receivedAt":"2013-06-11T19:19:36Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 11, 2013 at 08:52:05PM +0200, Michael Haggerty wrote:\n> That's a very good point (and a good illustration, too).  How do you\n> like the new second and third sentences below?\n> \n> * When reviewing other peoples' code, be tactful and constructive.\n> Remember that submitting patches for public critique can be very\n> intimidating and when mistakes are found it can be embarrassing.  Do\n> what you can to make it a positive and pleasant experience for the\n> submitter.  Set high expectations, but do what you can to help the\n> submitter achieve them.  Don't demand changes based only on your\n> personal preferences. Don't let the perfect be the enemy of the good.\n\nI'm not sure.  I like the intent, but I'm not sure that it's clear\nenough that we're talking about the tone of comments rather than the\ntype of feedback to provide.\n\nHow about something like this?\n\n    * Having your code reviewed should feel like a collaboration aiming\n      for the best result for the project, not like a fight to get your\n      patch accepted.  Try to bear this in mind when reviewing other\n      peoples' code and consider how you would feel reading the same\n      comments if the review was the other way round.  We are only human\n      and the tone of a review can influence how the following\n      discussion progresses.\n      \n    * If you do feel that a review is aggressive, don't reply\n      immediately.  Contributors are spread around the world in\n      different timezones and it is often better to wait a few hours for\n      others to comment before rushing to defend your patch.\n"},{"id":"220499","messageId":"CAMP44s3T6pdETx-H=tWCVzoLEEXudH9doL1uAa5baGdBM70Wdw@mail.gmail.com","threadId":"34086","inReplyTo":"20130611182936.GM22905@serenity.lan","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T19:35:40Z","receivedAt":"2013-06-11T19:35:40Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 1:29 PM, John Keeping <john@keeping.me.uk> wrote:\n\n> I realise that we shouldn't take offence to review comments, but we are\n> all human and it is sometimes hard not to take things personally.\n>\n> In the examples above, the first makes it feel like the submitter is\n> fighting to get a patch included, but the second feels like we're\n> collaborating to get to the best result for the project.\n>\n> As my mother would say, \"politeness costs nothing\" ;-)\n\nThat's right, I agree with everything you said, but what would your\nmother say about the people are not polite towards you? I doubt it\nwould be \"fuck them then\".\n\nYou should be polite, you should not demand politeness. Being polite\ntowards the people that are polite to you barely has any merit,\nswallowing your pride, taking a deep breath, trying to understand that\nthe other side might be just having a bad day, or any number of\nreasons for the impoliteness... that's what takes effort.\n\nEscalating violence is easy, blaming the other side for starting is\nalso easy (as any toddler would tell you), being the side that puts\nthe other cheek is what's hard.\n\n-- \nFelipe Contreras\n"},{"id":"220501","messageId":"CAMP44s1nJCgEiHGf2t1C-Ptr5+ufLxRexb9dsh9FK98Scxs3ow@mail.gmail.com","threadId":"34086","inReplyTo":"7vsj0oa2m6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T19:39:33Z","receivedAt":"2013-06-11T19:39:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 2:06 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n>> I'm sorry, but the problem has no solution then.\n>>\n>> The \"problem\" we are dealing with is irrational and/or out-of-tone\n>> emails.  Unless you possess some mind-control mechanism that will get\n>> all contributors to write emails that conform to your standards, there\n>> is no solution.\n>\n> Actually there is.  Just ignore the troll.\n\nCongratulations Junio. You have followed our drafted guidelines by\nchoosing to lead by example how not to not propagate the violence,\nturn around, and take the high road.\n\nAfter kicking your opponent in the groin.\n\n-- \nFelipe Contreras\n"},{"id":"220500","messageId":"4F402D814F814EB19B8617BB31B3C473@PhilipOakley","threadId":"34086","inReplyTo":"51B771D5.6030809@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-06-11T19:46:58Z","receivedAt":"2013-06-11T19:46:58Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Michael Haggerty\" <mhagger@alum.mit.edu>\nSent: Tuesday, June 11, 2013 7:52 PM\n[...]\n>\n> That's a very good point (and a good illustration, too).  How do you\n> like the new second and third sentences below?\n>\n> * When reviewing other peoples' code, be tactful and constructive.\n> Remember that submitting patches for public critique can be very\n> intimidating\n\nI found this to be true. The tone on the list could at times feel \nun-helpful (to the new person). It is almost as if it is an initiation - \nthose on the list know the protocols, and new folk either arrive like a \nbull in a china shop, or more likely, timidly push the patch under the \ndoor and run away (and variations in between) - some never push out \ntheir (drafted) patch.\n\n>                   and when mistakes are found it can be embarrassing.\n\nSometimes it isn't 'mistakes', rather it is simply a lack of sufficient \nexplanation to communicate intent, which may not have been understood by \nthe reviewer/responder. In such cases it can be a frustration to know \nwhat was meant in the response, especially if the response is terse. \n[i.e. I think it would be reasonable to squeeze part of this in here \nsomewhere to guide new contributors about this step]\n\nThere is separately a need to note the role of the maintainer, who has a \nmore difficult role as gatekeeper who's higher standards in applying the \nprecautionary principle \nhttp://en.wikipedia.org/wiki/Precautionary_principle can feel like \nunhelpfulness, or worse if misunderstood.\n\n> Do\n> what you can to make it a positive and pleasant experience for the\n> submitter.  Set high expectations, but do what you can to help the\n> submitter achieve them.  Don't demand changes based only on your\n> personal preferences. Don't let the perfect be the enemy of the good.\n>\n> (As Junio pointed out, the last sentence is not so great and a better\n> replacement would be welcome.)\n>\n>> As my mother would say, \"politeness costs nothing\" ;-)\n>\n> Does your mother program C?  We could use her around here :-)\n\nI think she programmed in Smalltalk and CleanYourRoom. (sorry not my \nquestion ;-)\n\n>\n> Michael\n>\n> -- \n> Michael Haggerty\n> mhagger@alum.mit.edu\n> http://softwareswirl.blogspot.com/\n\nregards\nPhilip \n"},{"id":"220503","messageId":"20130611195452.GO22905@serenity.lan","threadId":"34086","inReplyTo":"CALkWK0n9Ws6DRbKPRHcQPhFTFx533PZH6dg1=w-O1hQ06V66-A@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-11T19:54:52Z","receivedAt":"2013-06-11T19:54:52Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:\n> John Keeping wrote:\n> >     Ugh, why this roundabout-passive-past tone?  Use imperative tone\n> >     like this:\n> >\n> >         ...\n> >\n> > vs.\n> >\n> >     We normally use the imperative in commit messages, perhaps like\n> >     this?\n> >\n> >         ...\n> >\n> > As my mother would say, \"politeness costs nothing\" ;-)\n> \n> The review is being honest about her feelings in the first one, and\n> being artificially diplomatic in the second one.\n\nI don't think it is artificially diplomatic, it's an attempt to convey a\nhelpful tone in an email.  As has been said elsewhere, it is easy to\nread an email in the wrong tone (there is an oft-cited statistic about\nthe percentage of communication that is non-verbal, and which cannot be\ninferred from written text).  For this reason I think it is important\nfor reviewers to make an effort to minimise the risk that what they\nwrite can be interpreted as being aggressive.\n\n>                                                   Both of them are\n> constructive and friendly, in that they provide an example for the\n> submitter to follow.\n\nBoth provide the same advice, yes.  But I disagree that they are both\nfriendly.  The top example reads (to me at least) as an attack on the\nsubmitter for not knowing better.  It may sometimes be necessary to\nresort to strong wording if someone appears to be wilfully ignoring\nsensible advice but we should not expect every submitter to know the\nexpectations of the project; the first message to someone should gently\nguide them in the right direction.\n\n> Either way, I'm not interested in problems that have no solutions.\n> The only \"solution\" I see here is to suffocate every contributor until\n> they are \"tactful enough\" for the majority's liking, and \"remove\" the\n> ones that don't conform.  If you do have an alternate solution, please\n> share it with us.\n\nI don't have a solution, only a hope that regular contributors will\nlearn from others how they can phrase review comments less aggressively.\n\nI expect different people will read the same statement differently;\npeople are from different cultures and what is considered acceptable in\none culture can be considered rude in another.  We should aim to\ncultivate our own culture where we try to minimise the risk that what we\nwrite will be misinterpreted by someone with a different cultural\nbackground.\n"},{"id":"220504","messageId":"CA+sFfMeN+kzjWx1BZW1jvgZr2GaXDLQkzxTrWx8f5=8LPjMb1g@mail.gmail.com","threadId":"34086","inReplyTo":"51B736FA.5010407@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-06-11T19:55:20Z","receivedAt":"2013-06-11T19:55:20Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Tue, Jun 11, 2013 at 7:40 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n\n> At the risk of being\n> presumptuous myself, I suggest that you show a copy of your email to\n> somebody whom you know and respect in the real world, somebody who is\n> not immersed in the Git community meltdown.  For example, somebody like\n> your mother or father, or a teacher whom you respect, or a member of\n> clergy if you are so inclined.  Ask that person's opinion about your email.\n>\n> It is so easy to lose perspective in the Internet.\n\nSuch excellent advice.  Even if the advice is not taken literally, it\nis probably enough to just imagine how that person whom you respect\nwould respond to the words in your emails.  I am sure I do not do this\nenough in my own communications.\n\nI just wanted to draw attention to this wonderful suggestion again.\nSometimes it is necessary to take a step back when discussions get\nheated, to regain perspective.\n\n-Brandon\n"},{"id":"220509","messageId":"20130611203303.GA14907@sigill.intra.peff.net","threadId":"34086","inReplyTo":"7v38sod1kn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-11T20:33:03Z","receivedAt":"2013-06-11T20:33:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:\n\n> > * Accept reviewers' comments gratefully and take them very seriously.\n> > Show that you appreciate the help by giving the reviewer the benefit of\n> > the doubt.  If, after careful consideration, you find that you cannot\n> > agree with a reviewer's suggestion, explain your reasoning carefully\n> > without taking or giving offense, and seek compromise.\n> \n> In short, the only acceptable response to review comments are \"You\n> are right. Here is a reroll\", or \"I think your suggestion will miss\n> these cases which I wanted to cover and that is why I did it this\n> way\". There may be other small variants of the above two, but I\n> think I can agree with the general principle.\n> \n> In cases, there are two or more equally valid approaches to solving\n> a problem.  I do not think I had to accept (or reject) many \"it can\n> be done better in different ways and this perhaps is not the best\n> one\" (or \"it could be argued that it is correct\") borderline topics\n> in the recent past, but I suspect that \"a disagreement is healthy\"\n> has to be accompanied by how disagreements that do not resolve\n> themselves are resolved (I think I've heard somewhere that some\n> communities break ties in favor of reviewers, for example).\n\nI more or less agree with what both of you have said above. The \"ties\ngoes to reviewers\" thing I would be very wary of, at least as a hard\nrule. We do not (and do not want to) put any restrictions on who is\nallowed to do review. That sometimes results in unhelpful or even wrong\nreviews by new people, but those reviews are a stepping stone to being a\nmore experienced and capable reviewer.\n\nMost of the time such reviews are resolved by other community members\njoining the discussion and coming to some agreement, but not always.\nAnd that is not even getting into the cases where long-time experienced\nreviewers are simply wrong or misguided, or the issue is legitimately a\ndifficult tradeoff to consider, and the discussion ends in a stalemate.\n\nAnd I think that is where the benevolent dictator role comes in. They\nweigh not just the points made in the discussion (or a summary of it),\nbut also use their judgement on who is making comments (how many people,\nthe utility of their past comments) and other factors (other things\nhappening in the project, being conservative because of recent mistakes\nmade, etc). They may break such a tie by applying or rejecting, even by\nputting off a decision to revisit later (which is a de facto reject, of\ncourse).\n\nSo there are no hard rules, and this is not a democracy[1]. For the most\npart the community runs itself in an open and collective fashion, and\nthe dictator's job is easy; but ultimately, he or she is in charge of\nwhat gets applied and what doesn't. Rules like \"break ties in favor of\nreviewers\" are just a guideline for the dictator to use in making\ndecisions.\n\nI do not think any of that is news to you, but I think the point needs\nto be made, as it applies to any concrete rules.\n\n-Peff\n\n[1] Note that I think a benevolent dictator is a _terrible_ way to run a\n    real government, but it works in an open source project. I think the\n    difference is that dictatorship is open to abuse of power. In the\n    real world, there is a lot of power to abuse, and it is hard for\n    people to opt out of it. In the open source world, there is not that\n    much power, and if there is a bad dictator everyone can go somewhere\n    else (another project, or even a fork). So while a dictator _can_\n    play favorites, or start deciding which patches to take based on\n    what they had for breakfast, there is a real incentive to remain\n    fair and reasonable.\n"},{"id":"220510","messageId":"7va9mw9xkb.fsf@alter.siamese.dyndns.org","threadId":"34086","inReplyTo":"20130611203303.GA14907@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-11T20:55:48Z","receivedAt":"2013-06-11T20:55:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> So there are no hard rules, and this is not a democracy[1]. For the most\n> part the community runs itself in an open and collective fashion, and\n> the dictator's job is easy; but ultimately, he or she is in charge of\n> what gets applied and what doesn't. Rules like \"break ties in favor of\n> reviewers\" are just a guideline for the dictator to use in making\n> decisions.\n>\n> I do not think any of that is news to you, but I think the point needs\n> to be made, as it applies to any concrete rules.\n\nMy original draft had \"I am hoping we do not have to come to that\"\nafter \"(I heard some communities break ties this way)\", but I\nremoved it by mistake.\n\nAnd I think you are right. I also am hoping that I am being fair to\ndictate ;-)\n\n\n> -Peff\n>\n> [1] Note that I think a benevolent dictator is a _terrible_ way to run a\n>     real government, but it works in an open source project. I think the\n>     difference is that dictatorship is open to abuse of power. In the\n>     real world, there is a lot of power to abuse, and it is hard for\n>     people to opt out of it. In the open source world, there is not that\n>     much power, and if there is a bad dictator everyone can go somewhere\n>     else (another project, or even a fork). So while a dictator _can_\n>     play favorites, or start deciding which patches to take based on\n>     what they had for breakfast, there is a real incentive to remain\n>     fair and reasonable.\n"},{"id":"220571","messageId":"CAMP44s10TVF9-uT5OtCLXBKrrXAspYnHM+go1zvu6ocMZwN14A@mail.gmail.com","threadId":"34086","inReplyTo":"7va9mw9xkb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T23:19:23Z","receivedAt":"2013-06-11T23:19:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 3:55 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> So there are no hard rules, and this is not a democracy[1]. For the most\n>> part the community runs itself in an open and collective fashion, and\n>> the dictator's job is easy; but ultimately, he or she is in charge of\n>> what gets applied and what doesn't. Rules like \"break ties in favor of\n>> reviewers\" are just a guideline for the dictator to use in making\n>> decisions.\n>>\n>> I do not think any of that is news to you, but I think the point needs\n>> to be made, as it applies to any concrete rules.\n>\n> My original draft had \"I am hoping we do not have to come to that\"\n> after \"(I heard some communities break ties this way)\", but I\n> removed it by mistake.\n>\n> And I think you are right. I also am hoping that I am being fair to\n> dictate ;-)\n\nFair? Fairness requires to judge each action without biases, nor\ndouble standards. In the case of an open source community it requires\nyou to listen to the arguments before dismissing them, and consider\nthe patches before dropping them on the floor. Fairness requires no\nfavoritism.\n\nYou think you are being fair? You have acted the equivalent of a judge\nthat says \"oh, you again? I don't need to look at the case, you are a\ndrunk and you go to jail\". I'm not saying that's wrong, I'm saying you\ncan't call that fair.\n\n-- \nFelipe Contreras\n"},{"id":"220574","messageId":"CAMP44s3F0VVWz4pYRcqeFhw1pScrk8Ufj9a2ZO+Wb7+_H3ww3w@mail.gmail.com","threadId":"34086","inReplyTo":"51B76FD6.7070304@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-11T23:48:09Z","receivedAt":"2013-06-11T23:48:09Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 11, 2013 at 1:43 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 06/11/2013 08:16 PM, Ramkumar Ramachandra wrote:\n>> This is an exercise.  I can easily be more tactful (as evidenced by\n>> other threads), but I'm choosing not to be.  I want you to focus on\n>> the argument, and not the tone.\n>\n> I stopped reading your email here.\n\nYeah, you are ignoring the arguments, what a surprise.\n\n> In German there is an expression \"Der Ton macht die Musik\": \"the tone\n> makes the music\", by which they mean that the *way* something is said is\n> at least as important as what is said.\n\nI know you don't care about reality, but you are committing the\nis-ought fallacy. You are describing the way things are, not the way\nthings should be.\n\nYes, most people can't handle rational arguments, or truth, and need\nhypocrites to hide things from them. That's why politics is surrounded\nby people who never say the truth.. not really.\n\nThat doesn't mean that's the way things _ought_ to be, specially not\nthe way *you* should act.\n\n-- \nFelipe Contreras\n"},{"id":"220575","messageId":"CAEBDL5WJ=thZ6oUUxJ=VuvX6J+FCyzKcX2XKz209A=cTnbStew@mail.gmail.com","threadId":"34086","inReplyTo":"4F402D814F814EB19B8617BB31B3C473@PhilipOakley","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-06-12T00:08:04Z","receivedAt":"2013-06-12T00:08:04Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Jun 11, 2013 at 3:46 PM, Philip Oakley <philipoakley@iee.org> wrote:\n> From: \"Michael Haggerty\" <mhagger@alum.mit.edu>\n> Sent: Tuesday, June 11, 2013 7:52 PM\n> [...]\n>\n>>\n>> That's a very good point (and a good illustration, too).  How do you\n>> like the new second and third sentences below?\n>>\n>> * When reviewing other peoples' code, be tactful and constructive.\n>> Remember that submitting patches for public critique can be very\n>> intimidating\n>\n>\n> I found this to be true. The tone on the list could at times feel un-helpful\n> (to the new person). It is almost as if it is an initiation - those on the\n> list know the protocols, and new folk either arrive like a bull in a china\n> shop, or more likely, timidly push the patch under the door and run away\n> (and variations in between) - some never push out their (drafted) patch.\n\nInteresting!  I've had the opposite opinion.  I've often been\nsurprised at how much constructive feedback has been given, and the\nthoughtfulness of the reviewers to offer up alternative solutions,\nshow examples, etc.  Junio, Jeff, and especially Jonathan have been\nparticularly good on that front--at least those are some of the\nregulars that stick out in my mind.  Overall, I've been pretty happy\nwith the community, and while I haven't contributed much, I generally\nenjoy reading the emails.  I feel like I learn something new all the\ntime. :-)\n\n-John\n"},{"id":"220594","messageId":"CALkWK0==egyiSsndy-JC9a-N2pw4j5Q7sg2mm1gUFq6hqxjWvg@mail.gmail.com","threadId":"34086","inReplyTo":"20130611195452.GO22905@serenity.lan","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-12T11:26:27Z","receivedAt":"2013-06-12T11:26:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"John Keeping wrote:\n> On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:\n>> John Keeping wrote:\n>> >     Ugh, why this roundabout-passive-past tone?  Use imperative tone\n>> >     like this:\n>> >\n>> >         ...\n>> >\n>> > vs.\n>> >\n>> >     We normally use the imperative in commit messages, perhaps like\n>> >     this?\n>> >\n>> >         ...\n>> >\n>> > As my mother would say, \"politeness costs nothing\" ;-)\n>>\n>> The review is being honest about her feelings in the first one, and\n>> being artificially diplomatic in the second one.\n>\n> I don't think it is artificially diplomatic, it's an attempt to convey a\n> helpful tone in an email.\n\nOkay, so answer this: Why did the reviewer deliberately use the\n\"unhelpful\" tone?  Was she trying to attack the new contributor, and\nintend to harm the community?  Or did she just say what came to her\nmind?\n\n> As has been said elsewhere, it is easy to\n> read an email in the wrong tone (there is an oft-cited statistic about\n> the percentage of communication that is non-verbal, and which cannot be\n> inferred from written text).\n\nYes, it is.\n\n> For this reason I think it is important\n> for reviewers to make an effort to minimise the risk that what they\n> write can be interpreted as being aggressive.\n\nCorrect.\n\n>> Either way, I'm not interested in problems that have no solutions.\n>> The only \"solution\" I see here is to suffocate every contributor until\n>> they are \"tactful enough\" for the majority's liking, and \"remove\" the\n>> ones that don't conform.  If you do have an alternate solution, please\n>> share it with us.\n>\n> I don't have a solution, only a hope that regular contributors will\n> learn from others how they can phrase review comments less aggressively.\n\nThe reviewer is not a thick-skinned bull that wants to harm the project.\n\n4. Lead by example.  If you do not like how someone presents\nthemselves on the list, you counter it by presenting yourself nicely\non the list.  Others will follow your example, making that person's\nbehavior the minority.  It is far more powerful than explicitly\nstating what is \"acceptable\" behavior and what is not.\n\n> I expect different people will read the same statement differently;\n> people are from different cultures and what is considered acceptable in\n> one culture can be considered rude in another.  We should aim to\n> cultivate our own culture where we try to minimise the risk that what we\n> write will be misinterpreted by someone with a different cultural\n> background.\n\nSo you have agreed that \"tone\" is subjective, and that attempting to\nobjectively state the \"right tone\" is a lost cause.\n\nThe solution to the problem, as I have already explained several times is to:\n- Define an objective basis for people to react.\n- Lead by example, and influence other contributors to follow your style.\n\nWhat everyone is doing differently:\n- Taking offense at every possible juncture.\n- Taking sides and voting.  Ganging up and playing politics.\n- Making bad irrational arguments in the \"right tone\".\n- Invalidating entire arguments, on the basis of tone.\n- Making tone the entire subject of discussion, ignoring content.\n- Bringing \"majority opinion\" to a rational argument.\n"},{"id":"220597","messageId":"20130612115641.GA8427@thunk.org","threadId":"34086","inReplyTo":"CALkWK0kMvac7Sp3QwvEm+J_-Hj7JAn-AY-juDDw1HR3oQ+hamA@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2013-06-12T11:56:41Z","receivedAt":"2013-06-12T11:56:41Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jun 11, 2013 at 07:10:11PM +0530, Ramkumar Ramachandra wrote:\n> \n> Presumably, Felipe is the \"fire hazard\" that we are talking about, and\n> nobody else is to blame.  He must be \"removed\" to prevent future\n> fires.  This is the \"perception of the regulars\", correct?\n> \n> Then why haven't you removed him yet?  What are you waiting for?  You\n> don't need my \"approval\".\n\nHe (and you) get \"removed\" when individuals who have decided the vast\nmajority of their e-mails shed more heat than light, and so people\ndecide that it's not worth reading their e-mails.  I have persionally\nmade this determination for both you and for Felipe; for you, your\nparticipation in this thread was what set the \"bozo bit\".\n\nNow, I'm not a major developer for git, so my personal decision\ndoesn't make a huge amount of difference.\n\nBut if people who *are* senior developers in the git community decide,\non their own, that someone isn't worth listening to, there's the\npunishment has been inflicted, and this happens without banning\nsomeone from posting or removing them from the mailing list.\n\nPlease stop.\n\nRegards,\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"220599","messageId":"CALkWK0=SjNE+_8EGhOsSZAMBPrHAj7-16rZFf2By6NttoQOa5w@mail.gmail.com","threadId":"34086","inReplyTo":"20130611203303.GA14907@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-12T12:03:51Z","receivedAt":"2013-06-12T12:03:51Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> And I think that is where the benevolent dictator role comes in. They\n> weigh not just the points made in the discussion (or a summary of it),\n> but also use their judgement on who is making comments (how many people,\n> the utility of their past comments) and other factors (other things\n> happening in the project, being conservative because of recent mistakes\n> made, etc). They may break such a tie by applying or rejecting, even by\n> putting off a decision to revisit later (which is a de facto reject, of\n> course).\n\nJunio has one of the hardest jobs of all: his sense of fairness plays\na major role in determining the health of the project.\n\nThat said, I'm quite happy with Junio's sensibilities.  He's not\ndevoid of shortcomings, but that is an unrealistic expectation.\n\n> So there are no hard rules, and this is not a democracy[1]. For the most\n> part the community runs itself in an open and collective fashion, and\n> the dictator's job is easy; but ultimately, he or she is in charge of\n> what gets applied and what doesn't. Rules like \"break ties in favor of\n> reviewers\" are just a guideline for the dictator to use in making\n> decisions.\n\nDo not confuse \"democracy\" with \"rule of the majority\" (not implying\nthat you are; just saying).  Governments have been voted out of power\nbecause they failed to protect minority interests.  When it comes to a\ndecision like \"whether or not to execute this rapist\", the government\ndoes not make a decision based on the votes of the common public.  It\nhas a constitution, and courts where it is interpreted and decisions\nare made.  Cases are often not won or lost on the basis of \"hard\nrules\", but on the force of the arguments that the two lawyers\npresent.  There are societies that use the jury system to lessen the\nburden on the judge; but again, a decision cannot be made on the basis\nof majority: the jury panel must reach a consensus.\n\nIt's not all that different from what happens in this community, I think.\n"},{"id":"220600","messageId":"20130612122723.GA26281@thunk.org","threadId":"34086","inReplyTo":"CAMP44s10TVF9-uT5OtCLXBKrrXAspYnHM+go1zvu6ocMZwN14A@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2013-06-12T12:27:23Z","receivedAt":"2013-06-12T12:27:23Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jun 11, 2013 at 06:19:23PM -0500, Felipe Contreras wrote:\n> Fair? Fairness requires to judge each action without biases, nor\n> double standards. In the case of an open source community it requires\n> you to listen to the arguments before dismissing them, and consider\n> the patches before dropping them on the floor. Fairness requires no\n> favoritism.\n\nAt least in development communities that *I* run, if someone were as\nrude to me as you have been in some previous exchanges to Junio, I\nwould have set the bozo bit a long time ago and reviewed your\nsubmissions with a very jaudiced eye, and treated your non-technical\narguments with same amount of attention as I give madmen and drunkards\nin the street.  Junio has given you *far* more latitude than I would\nhave.\n\nKeep in mind, the demands for respect go in both directions, and in\nnon-technical matters about style and \"good taste\", at the end of the\nday the maintainer does get to have the final say, because he or she\nis the one who applies the patches or accepts the pull request.  So if\nthe maintainer says something like, \"maintaining ABI backwards\ncompatibility for libext2fs (or for kernel syscalls) is critically\nimportant\", that's not up to you.  Sending me abusive e-mails about\nhow I'm not listening to your arguments isn't going to help.  You can\ntry to change my mind with reasoned arguments, but for questions like\nthat, or what functions do or don't belong in a library, the\nmaintainer is the benevolent dictator.\n\nThings a very different for things like \"this change causes a 30%\nperformance regression in a particular workload\".  For those sorts of\ntechnical questions, a much more collaborative discussion style is\nimportant.  But for questions of what is and isn't \"good taste\", it's\nnot a good idea to reply to a maintainer's e-mail with \"that's your\nopinion\" over and over again.  For things like that it *IS* his (or\nher) opinion, and if you can't live with it, you'll save a lot of\nbandwidth on the mailing list by moving on to some other project.\n\nRegards,\n\n\t\t\t\t\t- Ted\n"},{"id":"220602","messageId":"CALkWK0nwm_mZgpB-MJZTRE-2-T6OB4Lmhmk+gEdQqcOqUeWbeg@mail.gmail.com","threadId":"34086","inReplyTo":"20130612115641.GA8427@thunk.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-12T12:29:34Z","receivedAt":"2013-06-12T12:29:34Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Theodore Ts'o wrote:\n> But if people who *are* senior developers in the git community decide,\n> on their own, that someone isn't worth listening to, there's the\n> punishment has been inflicted, and this happens without banning\n> someone from posting or removing them from the mailing list.\n\nYes, I have already been punished by several people.  As a result of\nmy arguments on this thread, everyone will treat me like a troll in\nthe future.\n\nAs a rational person, why have I inflicted this upon myself?  To make\na point about how increased tolerance is the way to reduce fires?  No,\nit is not worth it.  Either way, I have failed miserably: by being\ndeliberately untactful, I have only aggravated the community.\n\n> Please stop.\n\nI have no desire to constantly exhibit deviant behavior that offends a\nlarge majority.\n\nSorry.\n"},{"id":"220608","messageId":"20130612131418.GA23890@serenity.lan","threadId":"34086","inReplyTo":"CALkWK0==egyiSsndy-JC9a-N2pw4j5Q7sg2mm1gUFq6hqxjWvg@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-12T13:14:18Z","receivedAt":"2013-06-12T13:14:18Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jun 12, 2013 at 04:56:27PM +0530, Ramkumar Ramachandra wrote:\n> John Keeping wrote:\n> >> Either way, I'm not interested in problems that have no solutions.\n> >> The only \"solution\" I see here is to suffocate every contributor until\n> >> they are \"tactful enough\" for the majority's liking, and \"remove\" the\n> >> ones that don't conform.  If you do have an alternate solution, please\n> >> share it with us.\n> >\n> > I don't have a solution, only a hope that regular contributors will\n> > learn from others how they can phrase review comments less aggressively.\n> \n> The reviewer is not a thick-skinned bull that wants to harm the project.\n> \n> 4. Lead by example.  If you do not like how someone presents\n> themselves on the list, you counter it by presenting yourself nicely\n> on the list.  Others will follow your example, making that person's\n> behavior the minority.\n\nI think that's what everyone is trying to do, the problem is when the\naxiom \"others will follow your example\" fails.  In that case it is\nimportant to address the issue.\n\nIt is equally important to do this in a way that does not assume malice\non the part of the reviewer. It is quite possible that when English is\nnot someone's first language then they may not realise how their words\nare being interpreted by some people.  In this case a friendly message\nsent off the mailing list may be appropriate.\n\n>                         It is far more powerful than explicitly\n> stating what is \"acceptable\" behavior and what is not.\n> \n> > I expect different people will read the same statement differently;\n> > people are from different cultures and what is considered acceptable in\n> > one culture can be considered rude in another.  We should aim to\n> > cultivate our own culture where we try to minimise the risk that what we\n> > write will be misinterpreted by someone with a different cultural\n> > background.\n> \n> So you have agreed that \"tone\" is subjective, and that attempting to\n> objectively state the \"right tone\" is a lost cause.\n\nIt is subjective *to some degree*.  If a reviewer takes care, then it is\npossible to write a message that minimises the risk that the words can\nbe interpreted in a way that is not what was intended.\n\nIf we do end up having community guidelines, then I think that point is\nvery important.  It is equally important that readers do not assume that\nthe tone in which they read an email is that in which it was intended\nbut I think that human nature makes that half harder.\n"},{"id":"220611","messageId":"CAMP44s2uR5dtRkgwWNJzCgGzbDVNHF_vZCbqCuYNVcRpg=UNgQ@mail.gmail.com","threadId":"34086","inReplyTo":"20130612115641.GA8427@thunk.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-12T13:58:06Z","receivedAt":"2013-06-12T13:58:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jun 12, 2013 at 6:56 AM, Theodore Ts'o <tytso@mit.edu> wrote:\n> On Tue, Jun 11, 2013 at 07:10:11PM +0530, Ramkumar Ramachandra wrote:\n>>\n>> Presumably, Felipe is the \"fire hazard\" that we are talking about, and\n>> nobody else is to blame.  He must be \"removed\" to prevent future\n>> fires.  This is the \"perception of the regulars\", correct?\n>>\n>> Then why haven't you removed him yet?  What are you waiting for?  You\n>> don't need my \"approval\".\n>\n> He (and you) get \"removed\" when individuals who have decided the vast\n> majority of their e-mails shed more heat than light, and so people\n> decide that it's not worth reading their e-mails.  I have persionally\n> made this determination for both you and for Felipe;\n\nOn what basis have you made that determination? Have you made that\ndetermination based on my contributions?\n\n% git shortlog -n -s --no-merges --since '3 months ago'\n   221\tFelipe Contreras\n    83\tJunio C Hamano\n    69\tJeff King\n    62\tMichael Haggerty\n    48\tRamkumar Ramachandra\n    35\tThomas Rast\n    33\tNguyễn Thái Ngọc Duy\n    32\tJohn Keeping\n    30\tRené Scharfe\n    21\tKevin Bracey\n\nHave you read each and every one of my 800 patches in the last three\nmonths? Plus all my replies?\n\nOr have you made that determination based on the tiny subset of those\nthat are controversial?\n\n-- \nFelipe Contreras\n"},{"id":"220613","messageId":"CAMP44s1CnNQH+rvammgXyiSux5Gzn6Jhm8D0H4brFDez52nLwg@mail.gmail.com","threadId":"34086","inReplyTo":"20130612122723.GA26281@thunk.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-12T14:06:31Z","receivedAt":"2013-06-12T14:06:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jun 12, 2013 at 7:27 AM, Theodore Ts'o <tytso@mit.edu> wrote:\n> On Tue, Jun 11, 2013 at 06:19:23PM -0500, Felipe Contreras wrote:\n>> Fair? Fairness requires to judge each action without biases, nor\n>> double standards. In the case of an open source community it requires\n>> you to listen to the arguments before dismissing them, and consider\n>> the patches before dropping them on the floor. Fairness requires no\n>> favoritism.\n>\n> At least in development communities that *I* run, if someone were as\n> rude to me as you have been in some previous exchanges to Junio, I\n> would have set the bozo bit a long time ago and reviewed your\n> submissions with a very jaudiced eye, and treated your non-technical\n> arguments with same amount of attention as I give madmen and drunkards\n> in the street.  Junio has given you *far* more latitude than I would\n> have.\n\nYeah, you certainly can do that, but a judge cannot do that, can he?\n\n> Keep in mind, the demands for respect go in both directions, and in\n> non-technical matters about style and \"good taste\", at the end of the\n> day the maintainer does get to have the final say, because he or she\n> is the one who applies the patches or accepts the pull request.  So if\n> the maintainer says something like, \"maintaining ABI backwards\n> compatibility for libext2fs (or for kernel syscalls) is critically\n> important\", that's not up to you.  Sending me abusive e-mails about\n> how I'm not listening to your arguments isn't going to help.\n\nI'm not abusing anyone. Junio is making the mistake of thinking he is\nbeing fair, I made the judge analogy so that he can see that he is not\nacting like a judge. A judge has an obligation of being fair, so he\nacts fairly, Junio don't have that obligation, yet he thinks he is\nbeing fair when he is not.\n\nThat is not abuse, that is pointing the truth.\n\n> You can\n> try to change my mind with reasoned arguments, but for questions like\n> that, or what functions do or don't belong in a library, the\n> maintainer is the benevolent dictator.\n\nYes, he makes the decision, that doesn't mean the rationale for the\ndecision is correct.\n\nHe is making the decision based on the idea that\ninit_copy_notes_for_rewrite() (and similar) will be used by binaries\nother than 'git'. He is wrong.\n\n> For things like that it *IS* his (or her) opinion,\n\nThe problem is he doesn't accept it's his opinion. He thinks it's a fact.\n\n-- \nFelipe Contreras\n"},{"id":"220615","messageId":"loom.20130612T164733-942@post.gmane.org","threadId":"34086","inReplyTo":"4F402D814F814EB19B8617BB31B3C473@PhilipOakley","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2013-06-12T14:49:11Z","receivedAt":"2013-06-12T14:49:11Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Philip Oakley <philipoakley <at> iee.org> writes: \n> From: \"Michael Haggerty\" <mhagger <at> alum.mit.edu>\n> Sent: Tuesday, June 11, 2013 7:52 PM\n\n> >> As my mother would say, \"politeness costs nothing\" \n> >\n> > Does your mother program C?  We could use her around here \n> \n> I think she programmed in Smalltalk and CleanYourRoom. (sorry not my \n> question \n\nNb. there is purely-objective programming language named Smalltalk\nhttps://en.wikipedia.org/wiki/Smalltalk\n\n-- \nJakub Narębski\n(via GMane)\n"},{"id":"220664","messageId":"7vehc72j46.fsf@alter.siamese.dyndns.org","threadId":"34086","inReplyTo":"51B6AA7F.1060505@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-12T20:02:01Z","receivedAt":"2013-06-12T20:02:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> I would prefer a community standards document that looks more like this:\n> ...\n>\n> * Be welcoming to new community participants.  Help them get oriented,\n> and be patient with their questions.  Gently introduce them to our\n> community standards, above all by setting a good example yourself.\n\nI agree that on-boarding is an important process.\n\nIn addition to the reviews I'd give to regulars, I personally try\nto do some of these things:\n\n - Even in a negative review, end the message with \"Thanks\".  More\n   important is to express that the particular patch is rejected but\n   contributor's future contribution (either a reroll or a separate\n   topic) is welcome.\n\n   This is free, and there is no reason not to be nice.\n\n - Point out problems in a milder way than usual.  Instead of saying\n   \"Why is this done like so?\", risking to be misinterpreted that I\n   am saying the patch did something wrong and the contributor was a\n   horrible programmer, rephrase it to \"Hmph, this may work in such\n   and such cases, but I wonder how well it would in this case?\",\n   followed by \"How about going this route instead, which would\n   cover all these cases?\"\n\n   Doing so is more time consuming at reviewers' end; once you know\n   the current design well enough, you can immediately smell a wrong\n   approach a lot faster by just looking at code and design in a\n   patch, without having to come up with a concrete example.\n\n - Instead of just pointing out minor nits and have the new\n   contributor reroll, point them out, and then show how the patch\n   should have looked like, often after \"-- >8 --\" and the \"From:\"\n   line that keeps attribution.\n\n   Again this is more work at reviewers' end.\n\nCoaching new contributors, like mentoring GSoC students, is often\nmore time consuming than scratching the same itch yourself for any\nreviewer, but it is an investment, which hopefully yields dividend\nin the longer term.\n"},{"id":"220671","messageId":"8C02334D90AB447D94A416B47C06D54F@PhilipOakley","threadId":"34086","inReplyTo":"loom.20130612T164733-942@post.gmane.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-06-12T20:54:44Z","receivedAt":"2013-06-12T20:54:44Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jakub Narebski\" <jnareb@gmail.com>\nSent: Wednesday, June 12, 2013 3:49 PM\n> Philip Oakley <philipoakley <at> iee.org> writes:\n>> From: \"Michael Haggerty\" <mhagger <at> alum.mit.edu>\n>> Sent: Tuesday, June 11, 2013 7:52 PM\n>\n>> >> As my mother would say, \"politeness costs nothing\"\n>> >\n>> > Does your mother program C?  We could use her around here\n>>\n>> I think she programmed in Smalltalk and CleanYourRoom. (sorry not my\n>> question\n>\n> Nb. there is purely-objective programming language named Smalltalk\n> https://en.wikipedia.org/wiki/Smalltalk\n\nYes, I knew that <smiles>. It was deliberate. Good to see someone \nspotted it.\n\n>\n> -- \n> Jakub Narębski\n> (via GMane)\n>\nPhilip \n"},{"id":"220688","messageId":"51B9406E.30104@alum.mit.edu","threadId":"34086","inReplyTo":"7vehc72j46.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-13T03:45:50Z","receivedAt":"2013-06-13T03:45:50Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/12/2013 10:02 PM, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n> \n>> I would prefer a community standards document that looks more like this:\n>> ...\n>>\n>> * Be welcoming to new community participants.  Help them get oriented,\n>> and be patient with their questions.  Gently introduce them to our\n>> community standards, above all by setting a good example yourself.\n> \n> I agree that on-boarding is an important process.\n> \n> In addition to the reviews I'd give to regulars, I personally try\n> to do some of these things:\n> \n>  - Even in a negative review, end the message with \"Thanks\".  More\n>    important is to express that the particular patch is rejected but\n>    contributor's future contribution (either a reroll or a separate\n>    topic) is welcome.\n> \n>    This is free, and there is no reason not to be nice.\n> \n>  - Point out problems in a milder way than usual.  Instead of saying\n>    \"Why is this done like so?\", risking to be misinterpreted that I\n>    am saying the patch did something wrong and the contributor was a\n>    horrible programmer, rephrase it to \"Hmph, this may work in such\n>    and such cases, but I wonder how well it would in this case?\",\n>    followed by \"How about going this route instead, which would\n>    cover all these cases?\"\n> \n>    Doing so is more time consuming at reviewers' end; once you know\n>    the current design well enough, you can immediately smell a wrong\n>    approach a lot faster by just looking at code and design in a\n>    patch, without having to come up with a concrete example.\n> \n>  - Instead of just pointing out minor nits and have the new\n>    contributor reroll, point them out, and then show how the patch\n>    should have looked like, often after \"-- >8 --\" and the \"From:\"\n>    line that keeps attribution.\n> \n>    Again this is more work at reviewers' end.\n> \n> Coaching new contributors, like mentoring GSoC students, is often\n> more time consuming than scratching the same itch yourself for any\n> reviewer, but it is an investment, which hopefully yields dividend\n> in the longer term.\n\nThanks for these concrete examples / suggestions for reviewers.  I\nremember especially that during my first contacts with the Git community\nI was very impressed by these very things in your code reviews and in\nthose of other reviewers.\n\nAre you proposing that your text should find its way into the\nCommunityGuidelines in some form?  I hesitate to make the document *so*\nlong, especially considering that the section for contributors would\nthen probably also be expanded by a similar amount.  But I think\ndistilling the advice into one or two sentences, also taking into\naccount the suggestions of others in this thread, would be a definite\nimprovement.\n\nWhen I have time I want to submit some form of CommunityGuidelines as an\nexplicit patch, and I will try to synthesize all of the suggestions that\nhave been made.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"220691","messageId":"7v38smy6zz.fsf@alter.siamese.dyndns.org","threadId":"34086","inReplyTo":"51B9406E.30104@alum.mit.edu","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T04:22:40Z","receivedAt":"2013-06-13T04:22:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> On 06/12/2013 10:02 PM, Junio C Hamano wrote:\n>> Coaching new contributors, like mentoring GSoC students, is often\n>> more time consuming than scratching the same itch yourself for any\n>> reviewer, but it is an investment, which hopefully yields dividend\n>> in the longer term.\n>\n> Thanks for these concrete examples / suggestions for reviewers.  I\n> remember especially that during my first contacts with the Git community\n> I was very impressed by these very things in your code reviews and in\n> those of other reviewers.\n>\n> Are you proposing that your text should find its way into the\n> CommunityGuidelines in some form?\n\nIt actually was the other way around ;-).\n\nAfter reading your message, I tried to think aloud by listing what I\ntry to do, and I was impressed that your three-line advice was a\nvery concise and very well written summary of that.  I agree that a\nguideline should be kept as concise and clear as possible.\n\nThe main point of my message was that reviewing and coaching may be\ncostly, but we have to do them as an investment.\n"},{"id":"220710","messageId":"20130613101856.GA11034@workstation.dev.smoothwall.net","threadId":"34086","inReplyTo":"CALkWK0mqk5sRPV8PHz8RqZH-Ln7TUtkHPVbvsJPKuVSXiUOiww@mail.gmail.com","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Thomas Adam","fromEmail":"thomas@xteddy.org","sentAt":"2013-06-13T10:19:01Z","receivedAt":"2013-06-13T10:19:01Z","isPatch":true,"sender":{"key":"thomas@xteddy.org","avatar":"https://gravatar.com/avatar/e7256db4738e501e5d2e84f00bb0bd99503165729573848a03330301fc2adc4a?d=mp&s=160"},"body":"Hello,\n\nOn Mon, Jun 10, 2013 at 06:58:47PM +0530, Ramkumar Ramachandra wrote:\n> I've tried to write down a bare minimum, without restating the obvious.\n\n[...]\n\nI often come across so-called \"community guidelines\" in other\nprojects---some of which adhere to them quite strictly, and others simply\ndocument something for the curious.  But usually the reason for their\nexistence in the first place are tell-tale signs of trying to fix a problem\nat the wrong end, and I believe this is what is about to happen if a\ndocument such as this ever becomes official.\n\nThere's no disputing the fact that over the last few weeks, FC's behaviour\nhas been called in to question.  He's managed to rub a lot of core people up\nthe wrong way, and in doing so has deliberately side-stepped that problem by\ndoing the one thing which puts anyone trying to raise that point muted; by\nassuming that he's right.\n\nIt's a point on which one is never going to win, because no matter what one\nsays, it'll just get twisted round in such a way that one then ends up\nquestioning their own words, and their own conduct, and that's bad, because\nthere never was anything wrong with them to begin with.\n\nSo when you realise this point, it becomes almost impossible to proceed\nfurther with any kind of discussion, because even the technical points of\ndiscussion then end up being lost in a tirade of needless side-stepping\ndiscussion.  It's a bullying tactic on the part of FC which means he'll do\nany, and everything, to get his own way.\n\nSo I say to all those seasoned reviewers out there on this list not to put\nup with it.\n\nThere comes a point, regardless of how useful someone's contribution may be,\nthat if the barrier to entry is so high that any kind of criticism or\ncomment made against code comes with a massive chance of having to defend\nyourself against innocence on the part of the reviewer, that those\ncontributions should be shelved.  I've seen also another yardstick used to\ndefend FC's behaviour, and that is one of \"commits within the last three\nmonths\".  That count is completely meaningless, since the review process is\nalways going to be the same.\n\nSo these guidelines gain the community nothing, and only serve to punish\nthose who are already following them, without them being written down,\nbecause the root-cause of the problem is still here, and isn't going to go\naway, no matter how much referring to these guidelines might help.\n\nThat is why I think this is the wrong thing to do.\n\n-- Thomas Adam\n"},{"id":"220728","messageId":"CAMP44s0aNVnxKLXMfyXN9CeJFkMha4bNUq1TVrgbph867mbR2g@mail.gmail.com","threadId":"34086","inReplyTo":"20130613101856.GA11034@workstation.dev.smoothwall.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-13T13:36:17Z","receivedAt":"2013-06-13T13:36:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 13, 2013 at 5:19 AM, Thomas Adam <thomas@xteddy.org> wrote:\n\n> It's a point on which one is never going to win, because no matter what one\n> says, it'll just get twisted round in such a way that one then ends up\n> questioning their own words, and their own conduct, and that's bad, because\n> there never was anything wrong with them to begin with.\n\nPerhaps because you are actually wrong.\n\nIn the words of Tyrion Lannister: \"Why do you want me to shut up? Am I\nstarting to make sense?\"\n\nQuestioning our own ideas is the hallmark of a rational person.\n\n> So when you realise this point, it becomes almost impossible to proceed\n> further with any kind of discussion, because even the technical points of\n> discussion then end up being lost in a tirade of needless side-stepping\n> discussion.\n\nYou start the side-stepping the moment you say \"I don't like your\ntone\", which is precisely why one should concentrate on the argument\nbeing made, and not *how* it's being made. I'm not the only one that\nthings that way, read the extremely useful article from Paul\nGraham[1].\n\nIt is you the one that is against concentrating on the technical\npoints of the discussion.\n\n> That is why I think this is the wrong thing to do.\n\nIf you are suggesting punitive measures, let me remind you that any\nmodern society follows principles established in the Magna Carta eight\nhundred years ago. Before being punished by the state, every person\nhas the right to a speedy trial, and the trial of course has to be\nbased on *the written law*.\n\nIf we don't have by-laws, you cannot be blamed to have violated them,\nand you are even against guidelines, so on what basis are you going to\ndetermine that somebody has acted in an illicit way? The opinion of a\nsingle dictator? Mob rule?\n\nIt doesn't matter how you cut it, that would not be the rule of\nlaw[2], a concept that has been in the civilized world even longer,\nfor thousands of years.\n\n[1] http://www.paulgraham.com/disagree.html\n[2] http://en.wikipedia.org/wiki/Rule_of_law\n\n-- \nFelipe Contreras\n"},{"id":"220794","messageId":"CAP8UFD2ebaS+POPxTcKZtZhnMRD9-nOT=zr6Q_WKk9Wc8JVtUQ@mail.gmail.com","threadId":"34086","inReplyTo":"20130613101856.GA11034@workstation.dev.smoothwall.net","subject":"Re: [PATCH] Documentation/CommunityGuidelines","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2013-06-14T09:48:10Z","receivedAt":"2013-06-14T09:48:10Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Thu, Jun 13, 2013 at 12:19 PM, Thomas Adam <thomas@xteddy.org> wrote:\n>\n> So these guidelines gain the community nothing, and only serve to punish\n> those who are already following them, without them being written down,\n> because the root-cause of the problem is still here, and isn't going to go\n> away, no matter how much referring to these guidelines might help.\n>\n> That is why I think this is the wrong thing to do.\n\nI don't know if some guidelines will gain the community anything, but\nthere might be another solution to the current problems in the\ncommunity along the following lines:\n\n- decide that later this year (for example next october or september)\nthere could be a developer\nmeeting/conference/merge/gittogether/whatever somewhere in North\nAmerica\n\n- ask many developers who contributed to Git significantly, including\nthose involved in the last flamewars, if they could come and if they\nwould need financial help to come\n\n- ask some companies to sponsor the meeting by providing money, space,\nfood, beer, accomodation, whatever they want\n\n- maybe ask Git developers or users living neer the meeting place if\nthe developers coming could crash at their place\n\n- announce the meeting, thanks the sponsors, by the way thanks a lot\nGitHub for the git merge 2013 last May in Berlin\n\n- meet, discuss stuff, have a lot of beers together, write stupid joke\npatches together and send them to the list\n\n- reimburse the developers who came for their travel and if needed\naccomodation expenses\n\n- thank everyone for coming and having a good time together and thank\nthe sponsors again, by the way thank you guys who came to the git\nmerge 2013 and thank you again Github, for organizing it and Uber and\nGoogle for sponsoring it\n\nIt might not work but it might be a nice try :-)\n\nThanks,\nChristian.\n"}]}