* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 4:41 ` Michael Haggerty
@ 2013-06-11 6:28 ` Felipe Contreras
2013-06-11 10:45 ` Ramkumar Ramachandra
` (3 subsequent siblings)
4 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 6:28 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ramkumar Ramachandra, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
On Mon, Jun 10, 2013 at 11:41 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:
>> I've tried to write down a bare minimum, without restating the obvious.
>
> Thank you for drafting a proposed CommunityGuidelines document; I think
> such a document would be helpful. But I don't like the overall flavor
> of your proposal; frankly, it sounds to me more like
>
> Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations
>
> and I don't think that is healthy.
The LKML would disagree with you, as this draft is rather similar to
what they do. Have you ever heard the phrase "don't feed the troll"?
Well, it's every similar.
This also happens in any civilized modern society. Maybe you don't
agree with the Tea Party, or some other political group, but you
deport them? Do you squash their protests? No. You let them say what
they need to say, and you ignore them.
It's best for you, and it's best for the community. Ignore them and move on.
>> 0. You do not take offense, no matter what. If someone attacks you
>> irrationally, you do not respond. This is a public mailing list, and
>> we are all rational people: the attacker has already humiliated
>> herself in public, and everyone can see that.
>
> This is secondary to the more important rule, "do not attack other
> people on the mailing list". Not taking offense is at best a(n
> important) fallback position for those regrettable occasions when
> somebody else has any other already violated the primary guideline.
Yes but you can't control what other people do, only what you do.
Presumably you think you are not going to violate any of the other
rules, so it's all the more important that you do follow this one,
because that's the one *you* are possibly going to need to remember.
But by you I really me "we", because we all think we are not going to
violate the other rules. We all think we don't commit logical
fallacies, we all think our comments are right, productive, rational,
and sensible.
Of course that's not the case, what you think is a perfectly
reasonable comment, somebody else might consider offensive. In fact,
somebody is bound to find something offensive, so when that someone
happens to be you, take a deep breath, and don't.
>> 1. You do not take sides or vote. Do not post emails under the
>> pretext of agreement: repeating what has already been said does not
>> strengthen the argument. Post only if you have something unique to
>> add to the discussion.
>>
>> 2. You stop pointing fingers. Every heated discussion requires more
>> than one participant, and a flamewar requires many participants. If
>> you participate, you have implicitly agreed to share the blame for
>> whatever happens on the thread. People can judge for themselves who
>> is to blame.
>
> Here your wording "every heated discussion requires more than one
> participant" seems to put more of the blame for heated discussions on
> participants 2..N and give a pass to participant number one.
Which might actually be the case. If a drunk punches you in the face,
and you fight back. Who do you think the police is going to find
guilty of brawling?
>> 3. Thou shalt not commit logical fallacies. The ones that are most
>> common on this list: strawman, ad hominem, burden of proof, false
>> cause, the texas sharpshooter, and appeal to authority.
>
> I think putting a rule like this in CommunityGuidelines puts too much
> weight on it. In my recollection, pointing out other people's supposed
> logical fallacies is far more often used on this list as a nitpicking
> diversionary tactic that usually leads a conversation *further* away
> from the real issues. I think it would be a mistake to encourage such
> formal and stylized argument on the ML.
If you are not going to argue on the basis of logic and reason, what
are you going to argue on the basis of?
Being logical and reasonable is not finicky, it's a necessity. At
least if you want to stay close to the real world.
>> 4. Lead by example. If you do not like how someone presents
>> themselves on the list, you counter it by presenting yourself nicely
>> on the list. Others will follow your example, making that person's
>> behavior the minority. It is far more powerful than explicitly
>> stating what is "acceptable" behavior and what is not.
>
> Leading by example is a great approach, and has the effect that you
> describe on the majority of people. But I also think it would be
> helpful for the community to agree on a few very minimum standards of
> behavior that we insist on, and to call people out (preferably in a
> private email) if they fall short of these standards.
>
>> 5. We are a community of programmers, and we are here to collaborate
>> on code. The argument that leads to higher efficiency and better code
>> has an automatic advantage over the argument that doesn't.
>>
>> If someone breaks one of these rules, there's a very simple way to
>> communicate this to them: you don't respond to their email.
>> Optionally, respond to their email off-list calmly explaining what
>> went wrong.
>
> I would prefer a community standards document that looks more like this:
>
> * Treat other community members with courteousness and respect.
I disagree. Respect should be earned.
Moreover, tolerance is what is needed, respect is not. You should be
tolerant, even to the people who don't respect you.
> * Conduct disagreements on a technical, not a personal, level. It is
> unacceptable to attack another community member personally, even by
> insinuation.
I believe this is obvious and hardly worth mentioning. But on the
other hand, once could say I have been a victim of personal attacks,
not on a technical level. Perhaps it is worth mentioning.
> * Keep in mind that email is a medium prone to misunderstandings, and
> that many mailing list participants do not speak English as their first
> language. Interpret other people's emails charitably. If you are not
> sure that you understand, ask for clarification. Assume good intentions
> on the part of others, and do not attribute technical disagreements to
> ulterior motives. Choose your words carefully to help other people
> avoid misinterpreting them, and avoid hyperbole.
I agree, but I think my wording of assuming good faith is better.
> * Strive to keep the mailing list a forum for effective collaboration.
> Only post if you have something worthwhile to add to the discussion. Be
> concise and do not repeat what has already been said. Code reviews,
> contributions of patches, and concrete data such as bug reports are far
> preferable to philosophizing, vague suggestions, and whining. Avoid
> bikeshedding and do not participate in flame wars. Avoid revisiting
> settled debates unless the facts have changed.
Mostly agree, but the flamewar part needs to be emphasized and in its own point.
> * Accept reviewers' comments gratefully and take them very seriously.
> Show that you appreciate the help by giving the reviewer the benefit of
> the doubt. If, after careful consideration, you find that you cannot
> agree with a reviewer's suggestion, explain your reasoning carefully
> without taking or giving offense, and seek compromise.
Agreed. But I would say 'consider compromise'; often a compromise is
in the project's best interest, but not always.
But it's missing the guideline for the reviewer.
* Accept comments on your reviews gracefully. If the original patch
submitter doesn't agree with your review, don't take offense. Don't
assume the submitter has to automatically modify the patches according
to your comments, or even necessarily seek a compromise. The submitter
is entitled to his opinion, and so are you. Also, remember that each
person has their own priorities in life, and it might take time before
the submitter has time to implement the changes, if ever. The changes
you request might be beyond the time the submitter is willing to
spend, and it's OK for him to decide to drop the patches as a result.
You can help by picking the patches yourself in those situations.
> * It is not OK to use these guidelines as a stick with which to beat
> supposed violators. However, if you genuinely feel that another
> community member is routinely behaving in ways that are detrimental to
> the community, it might help to calmly express your concerns to that
> person, preferably in a private email, and naming concrete and specific
> incidents rather than broad generalizations.
Very good. It's good to remember these are guidelines, not by-laws.
One should not focus on the transgressions of others, for which
there's no defined punishment, but rather; on what one can do oneself.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 4:41 ` Michael Haggerty
2013-06-11 6:28 ` Felipe Contreras
@ 2013-06-11 10:45 ` Ramkumar Ramachandra
2013-06-11 11:49 ` Felipe Contreras
2013-06-11 12:33 ` Thomas Rast
2013-06-11 16:10 ` Thomas Rast
` (2 subsequent siblings)
4 siblings, 2 replies; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-11 10:45 UTC (permalink / raw)
To: Michael Haggerty
Cc: Git List, Junio C Hamano, Jonathan Nieder, A Large Angry SCM
Michael Haggerty wrote:
> Thank you for drafting a proposed CommunityGuidelines document; I think
> such a document would be helpful. But I don't like the overall flavor
> of your proposal; frankly, it sounds to me more like
>
> Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations
It has nothing to do with Felipe. I've merely documented repeating
patterns in fire threads as violations, in an attempt to avoid fires.
I have not worked forward from axioms to derive "transcendentally
desirable behavior", but rather backwards from a disaster to derive
"patterns that have been shown to lead to large fires". Why? Because
it's easier to derive unambiguous statements using my approach; as I
will show shortly, there are various problems with your arguments.
What gives you the impression that I documented everyone else's
violations, but not Felipe's? ;)
>> 0. You do not take offense, no matter what. If someone attacks you
>> irrationally, you do not respond. This is a public mailing list, and
>> we are all rational people: the attacker has already humiliated
>> herself in public, and everyone can see that.
>
> This is secondary to the more important rule, "do not attack other
> people on the mailing list". Not taking offense is at best a(n
> important) fallback position for those regrettable occasions when
> somebody else has already violated the primary guideline.
The problem with your guideline is that you now need to define some
sort of objective basis to determine whether or not someone attacks.
What is this transcendental notion of "attack"? I say something, and
you take offense, while someone else does not. Have I or have I not
attacked you? One possible solution to this dilemma is to use
"majority opinion" as a basis. This is a very dangerous road to go
down, as fringe behaviors will keep getting eliminated until we're
left with a bunch of yes-men on the list. In other words, an
extremely suffocating atmosphere.
My guideline does not suffer from this problem. It only requires you
to believe that you were personally offended, and act accordingly.
Whether or not you were justified in being offended is nobody's
business.
>> 2. You stop pointing fingers. Every heated discussion requires more
>> than one participant, and a flamewar requires many participants. If
>> you participate, you have implicitly agreed to share the blame for
>> whatever happens on the thread. People can judge for themselves who
>> is to blame.
>
> Here your wording "every heated discussion requires more than one
> participant" seems to put more of the blame for heated discussions on
> participants 2..N and give a pass to participant number one.
I'm not going to comment on the issue of wording, since I've already
made it clear that this "patch" is not for inclusion.
It is unclear who "Participant #1" is, but I'm not giving anyone a
pass; everyone must share the blame.
>> 3. Thou shalt not commit logical fallacies. The ones that are most
>> common on this list: strawman, ad hominem, burden of proof, false
>> cause, the texas sharpshooter, and appeal to authority.
>
> I think putting a rule like this in CommunityGuidelines puts too much
> weight on it. In my recollection, pointing out other people's supposed
> logical fallacies is far more often used on this list as a nitpicking
> diversionary tactic that usually leads a conversation *further* away
> from the real issues. I think it would be a mistake to encourage such
> formal and stylized argument on the ML.
The guidelines serve as a means of educating people on the list about
how they can avoid fuelling fires, not for literally quoting and
beating up violators. As I have already stated in the final
paragraph, there needs to be no consensus on whether or not a rule has
been violated: everyone can judge that for themselves.
>> 4. Lead by example. If you do not like how someone presents
>> themselves on the list, you counter it by presenting yourself nicely
>> on the list. Others will follow your example, making that person's
>> behavior the minority. It is far more powerful than explicitly
>> stating what is "acceptable" behavior and what is not.
>
> Leading by example is a great approach, and has the effect that you
> describe on the majority of people. But I also think it would be
> helpful for the community to agree on a few very minimum standards of
> behavior that we insist on, and to call people out (preferably in a
> private email) if they fall short of these standards.
Let's see what your guidelines look like.
>> 5. We are a community of programmers, and we are here to collaborate
>> on code. The argument that leads to higher efficiency and better code
>> has an automatic advantage over the argument that doesn't.
>>
>> If someone breaks one of these rules, there's a very simple way to
>> communicate this to them: you don't respond to their email.
>> Optionally, respond to their email off-list calmly explaining what
>> went wrong.
>
> I would prefer a community standards document that looks more like this:
> [...]
Summary: be a "nice" person, said in a very gentle way. How is it
better than the documents various internet communities have spent
years writing and perfecting? [1]
[1]: http://www.ubuntu.com/about/about-ubuntu/conduct
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 10:45 ` Ramkumar Ramachandra
@ 2013-06-11 11:49 ` Felipe Contreras
2013-06-11 12:33 ` Thomas Rast
1 sibling, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 11:49 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Michael Haggerty, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
On Tue, Jun 11, 2013 at 5:45 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Whether or not you were justified in being offended is nobody's
> business.
In a parallel with law, there is no concept of "justly" offended,
precisely because there is no way to determine what that even means.
People get offended by all sorts of things.
What's wrong with being offended?
http://www.dailymotion.com/video/xl2w7q_easily-offended-then-watch-this_fun
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 10:45 ` Ramkumar Ramachandra
2013-06-11 11:49 ` Felipe Contreras
@ 2013-06-11 12:33 ` Thomas Rast
2013-06-11 13:40 ` Ramkumar Ramachandra
2013-06-11 15:06 ` Felipe Contreras
1 sibling, 2 replies; 63+ messages in thread
From: Thomas Rast @ 2013-06-11 12:33 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Michael Haggerty, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Michael Haggerty wrote:
>> Thank you for drafting a proposed CommunityGuidelines document; I think
>> such a document would be helpful. But I don't like the overall flavor
>> of your proposal; frankly, it sounds to me more like
>>
>> Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations
>
> It has nothing to do with Felipe. I've merely documented repeating
> patterns in fire threads as violations, in an attempt to avoid fires.
> I have not worked forward from axioms to derive "transcendentally
> desirable behavior", but rather backwards from a disaster to derive
> "patterns that have been shown to lead to large fires". Why? Because
> it's easier to derive unambiguous statements using my approach; as I
> will show shortly, there are various problems with your arguments.
>
> What gives you the impression that I documented everyone else's
> violations, but not Felipe's? ;)
It has become clear, also in discussion on IRC, that your preferred
approach is to fight the fires, attempting to extinguish flames as they
happen.
My approach -- and in my perception also that preferred by most of the
regulars who have spoken in this whole mess -- is that since there is a
fire hazard, it would be more effective firefighting to just remove the
hazard, thus preventing future fires.
I infer that in your view, there is an inalienable right for the fire
hazard to remain part of the community that you are not willing to give
up. I for one no longer have such qualms in this instance.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 12:33 ` Thomas Rast
@ 2013-06-11 13:40 ` Ramkumar Ramachandra
2013-06-11 14:40 ` Michael Haggerty
2013-06-12 11:56 ` Theodore Ts'o
2013-06-11 15:06 ` Felipe Contreras
1 sibling, 2 replies; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-11 13:40 UTC (permalink / raw)
To: Thomas Rast
Cc: Michael Haggerty, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
Thomas Rast wrote:
> It has become clear, also in discussion on IRC, that your preferred
> approach is to fight the fires, attempting to extinguish flames as they
> happen.
Incorrect. I am interested in minimizing occurrences, which is why I
started this thread: to calmly and rationally discuss how to achieve
that. I have listed many concrete proposals, and justified them with
reason.
> My approach -- and in my perception also that preferred by most of the
> regulars who have spoken in this whole mess -- is that since there is a
> fire hazard, it would be more effective firefighting to just remove the
> hazard, thus preventing future fires.
Presumably, Felipe is the "fire hazard" that we are talking about, and
nobody else is to blame. He must be "removed" to prevent future
fires. This is the "perception of the regulars", correct?
Then why haven't you removed him yet? What are you waiting for? You
don't need my "approval".
Is it because you have realized deep down that you have absolutely no
rational argument, and are arguing with an ill-formed "majority
opinion"? I have words, you have words. Why are you incapable of
using your words to counter my arguments rationally?Are you so blind
that you cannot see the consequences of acting without reason?
Tomorrow the majority opinion will dictate that I am a fire hazard and
must be removed. Soon, anybody who disagrees with the majority
opinion will be removed, and the community will be reduced to a
handful of circlejerking yes-men. The git project will die a sad
death. And the blood will be on your hands.
> I infer that in your view, there is an inalienable right for the fire
> hazard to remain part of the community that you are not willing to give
> up. I for one no longer have such qualms in this instance.
Incorrect. There is no "transcendental inalienable right" that
dictates that "fire hazards" must remain part of the community. I
never made such an irrational argument. I already gave you the
example of the survivors on the boat with limited food/water on IRC:
it is you who stupidly refused to throw anyone overboard, killing all
the survivors; I am the one who said that I would get them to draw
sticks to "fairly choose" who to throw overboard, maximizing the
chances of survival of the others. I am making a pragmatic argument,
based on what is best for the community; not some stuck-up idealistic
bullshit. Further, I tried to help you think through the justice
problem, by recommending an accessible course. You have either not
gone through it, or have gone through it and learnt nothing.
What should I "give up"? My rationality?
Man up, and stop hiding being the veils of "majority opinion". _Your_
opinion is that Felipe must be removed from the list without reason.
Don't talk for the others. I'm sick of you "supporting" another
person's opinion. Stand up and speak for yourself; leave Haggerty out
of it.
You have embarrassed yourself and the entire git community today.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 13:40 ` Ramkumar Ramachandra
@ 2013-06-11 14:40 ` Michael Haggerty
2013-06-11 15:34 ` Felipe Contreras
` (2 more replies)
2013-06-12 11:56 ` Theodore Ts'o
1 sibling, 3 replies; 63+ messages in thread
From: Michael Haggerty @ 2013-06-11 14:40 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thomas Rast, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
On 06/11/2013 03:40 PM, Ramkumar Ramachandra wrote:
> Is it because you have realized deep down that you have absolutely no
> rational argument...Why are you incapable of
> using your words to counter my arguments rationally?Are you so blind
> that you cannot see the consequences of acting without reason?
Ram, you are insulting Thomas the human being rather than addressing his
points. Please stop.
> Tomorrow the majority opinion will dictate that I am a fire hazard and
> must be removed. Soon, anybody who disagrees with the majority
> opinion will be removed, and the community will be reduced to a
> handful of circlejerking yes-men. The git project will die a sad
> death. And the blood will be on your hands.
It is not disagreement that is causing problems; it is the inflammatory
tone of the discussion. Civil and constructive disagreement is
completely welcome here. But hurtful and offensive discussion is not,
even if it is in support of the "party line" (haha as if there were such
a thing).
And yes, I know that the word "offensive" is subjective, but for the
sake of this discussion let's take it to mean "offensive to the vast
majority of a community". Not "controversial", not "contrarian", not
even "stupid"; I don't think anybody is proposing to prohibit dissent or
stupidity. But there is no reason for discussion that is gratuitously
aggressive, insulting, or derogatory; such discussion is what I mean by
"offensive".
> [...] I already gave you the
> example of the survivors on the boat with limited food/water on IRC:
> it is you who stupidly refused to throw anyone overboard, killing all
> the survivors; I am the one who said that I would get them to draw
> sticks to "fairly choose" who to throw overboard, maximizing the
> chances of survival of the others. I am making a pragmatic argument,
> based on what is best for the community; not some stuck-up idealistic
> bullshit. Further, I tried to help you think through the justice
> problem, by recommending an accessible course. You have either not
> gone through it, or have gone through it and learnt nothing.
Your idea that you can assign Thomas "homework" in ethics and call him
stupid for coming to a different conclusion than you is presumptuous in
the extreme.
> [...]
> You have embarrassed yourself and the entire git community today.
This is also presumptuous, not to mention extremely ironic. In my
opinion Thomas's email was calm and reasonable while yours is beyond the
pale.
Ram, don't just take my opinion on this matter. At the risk of being
presumptuous myself, I suggest that you show a copy of your email to
somebody whom you know and respect in the real world, somebody who is
not immersed in the Git community meltdown. For example, somebody like
your mother or father, or a teacher whom you respect, or a member of
clergy if you are so inclined. Ask that person's opinion about your email.
It is so easy to lose perspective in the Internet.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 14:40 ` Michael Haggerty
@ 2013-06-11 15:34 ` Felipe Contreras
2013-06-11 18:16 ` Ramkumar Ramachandra
2013-06-11 19:55 ` Brandon Casey
2 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 15:34 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ramkumar Ramachandra, Thomas Rast, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
Hi,
Before going to your arguments, can you stop conveniently *ignoring*
my argument and answer this questions?
When two children fight, who has the blame? The one that threw the
first punch? Or the one that returned it?
On Tue, Jun 11, 2013 at 9:40 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 06/11/2013 03:40 PM, Ramkumar Ramachandra wrote:
>> Is it because you have realized deep down that you have absolutely no
>> rational argument...Why are you incapable of
>> using your words to counter my arguments rationally?Are you so blind
>> that you cannot see the consequences of acting without reason?
>
> Ram, you are insulting Thomas the human being rather than addressing his
> points. Please stop.
How is Ram insulting Thomas? By implying that Thomas is a human being?
That he is imperfect and is making a mistake?
My gosh! How offensive!
>> Tomorrow the majority opinion will dictate that I am a fire hazard and
>> must be removed. Soon, anybody who disagrees with the majority
>> opinion will be removed, and the community will be reduced to a
>> handful of circlejerking yes-men. The git project will die a sad
>> death. And the blood will be on your hands.
>
> It is not disagreement that is causing problems; it is the inflammatory
> tone of the discussion. Civil and constructive disagreement is
> completely welcome here. But hurtful and offensive discussion is not,
> even if it is in support of the "party line" (haha as if there were such
> a thing).
The difference between the two is totally and completely subjective,
and only a despot would be conformable parting judgment about which is
which.
> And yes, I know that the word "offensive" is subjective, but for the
> sake of this discussion let's take it to mean "offensive to the vast
> majority of a community".
Rule of the mob. How wise.
>> [...] I already gave you the
>> example of the survivors on the boat with limited food/water on IRC:
>> it is you who stupidly refused to throw anyone overboard, killing all
>> the survivors; I am the one who said that I would get them to draw
>> sticks to "fairly choose" who to throw overboard, maximizing the
>> chances of survival of the others. I am making a pragmatic argument,
>> based on what is best for the community; not some stuck-up idealistic
>> bullshit. Further, I tried to help you think through the justice
>> problem, by recommending an accessible course. You have either not
>> gone through it, or have gone through it and learnt nothing.
>
> Your idea that you can assign Thomas "homework" in ethics and call him
> stupid for coming to a different conclusion than you is presumptuous in
> the extreme.
He didn't call him stupid, he said he was acting stupidly, big difference.
>> [...]
>> You have embarrassed yourself and the entire git community today.
>
> This is also presumptuous, not to mention extremely ironic. In my
> opinion Thomas's email was calm and reasonable while yours is beyond the
> pale.
Of course it would be. In a witch hunt nobody sees what's wrong with
burning the witch... until you become it.
It's fine for Thomas Rast to call me a fire hazard, which ironically
is itself an inflammatory comment. But it's not OK for Ramkumar to say
that Thomas is acting stupidly *in this particular instance*.
Double standards much?
> Ram, don't just take my opinion on this matter. At the risk of being
> presumptuous myself, I suggest that you show a copy of your email to
> somebody whom you know and respect in the real world, somebody who is
> not immersed in the Git community meltdown. For example, somebody like
> your mother or father, or a teacher whom you respect, or a member of
> clergy if you are so inclined. Ask that person's opinion about your email.
I can offer my own perspective; I think Ramkumar's tone is not
particularly useful, but to concentrate on *how* he is saying things,
instead of *what* he is saying is an even bigger mistake, specially
because it's *you* the one that is making it. You should concentrate
on what *you* do, not what others do. Otherwise you will be forever
frustrated.
You have chosen to ignore *all* of Ramkumar's arguments, and all your
arguments can be summarized as "I don't like your tone", and by doing
that, you have lost even more touch of the discussion than what you
accused Ramkumar of doing.
You have even violated two your own guidelines:
* Conduct disagreements on a technical, not a personal, level.
* It is not OK to use these guidelines as a stick with which to beat
supposed violators.
You have also violated some of Ramkumar:
0. You do not take offense, no matter what.
In this particular case, you are taking offense by proxy, which might
be even worst.
1. You do not take sides or vote.
2. You stop pointing fingers.
I would also suggest another guideline based on Paul Graham's guide
How to Disagree[1].
* Do not respond to tone. Concentrate on *what* is being said, not
*how* it is being said. If the worst thing you can say about something
is to criticize its tone, you're not saying much. A "bad tone" is
highly subjective, and it's not really relevant in a discussion, it
matters whether the author is right or wrong. Is the author flippant,
but correct? Better that than grave and wrong. Keep your eye on the
ball.
[1] http://www.paulgraham.com/disagree.html
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 14:40 ` Michael Haggerty
2013-06-11 15:34 ` Felipe Contreras
@ 2013-06-11 18:16 ` Ramkumar Ramachandra
2013-06-11 18:43 ` Michael Haggerty
2013-06-11 19:55 ` Brandon Casey
2 siblings, 1 reply; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-11 18:16 UTC (permalink / raw)
To: Michael Haggerty
Cc: Thomas Rast, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
This is an exercise. I can easily be more tactful (as evidenced by
other threads), but I'm choosing not to be. I want you to focus on
the argument, and not the tone.
Michael Haggerty wrote:
> Ram, you are insulting Thomas the human being rather than addressing his
> points. Please stop.
He doesn't have a point! He makes the assumption that the "perception
of the regulars" is that a "fire hazard" must be "removed" from the
community. There are absolutely no rational arguments in his email,
he violated virtually every rule that we were working towards, and he
made an inflammatory comment by calling Felipe a "fire hazard". Yes I
was particularly harsh, because Rast was particularly irrational. I
did not "insult" him as a human being; I "criticized" his email which
was completely devoid of reason.
In case you're wondering, this is what an ad hominem looks like:
You are studying a subject that requires extensive application of
logic: combinatorial structures and algorithms at ETH Zurich. You
live in a well-to-do progressive society. I live in this poor country
called India, am much younger than you, and have studied nothing.
Yet, you make the irrational argument, while I make the rational
argument.
As you can clearly see, I focused on his argument; not on him.
> It is not disagreement that is causing problems; it is the inflammatory
> tone of the discussion. Civil and constructive disagreement is
> completely welcome here. But hurtful and offensive discussion is not,
> even if it is in support of the "party line" (haha as if there were such
> a thing).
Incorrect. The problem is that Rast is made an irrational argument,
and that you are "supporting" him now. If you were "fair" you would
have criticized Rast's inflammatory comment about classifying Felipe
as a "fire hazard", without justification. But you didn't. _You_ are
making my "tone" the subject of discussion now, and claim that I have
been hurtful and offensive. My email was very much "constructive
disagreement", in that I have laid out why one should not perform
actions without reason; I even assigned him homework, because I _want_
him to understand justice and argue rationally. How could I have been
more constructive?
I do not "support" Felipe, or "defend" him. I do not share his exact
opinions, and often criticize him. I am fair in that I praise
rational arguments, and criticize irrational arguments. I don't want
to speak for him, but I believe that he gives me the same treatment,
and I thank him for that.
I do not appreciate this ganging-up one bit. I'm one person arguing
against an opaque "majority opinion" veil. For the last time, stop
taking sides, and make a goddamn rational argument!
> And yes, I know that the word "offensive" is subjective, but for the
> sake of this discussion let's take it to mean "offensive to the vast
> majority of a community". Not "controversial", not "contrarian", not
> even "stupid"; I don't think anybody is proposing to prohibit dissent or
> stupidity. But there is no reason for discussion that is gratuitously
> aggressive, insulting, or derogatory; such discussion is what I mean by
> "offensive".
You have made the same argument that I criticized over and over again:
"majority opinion". If you agree that tone is subjective, why are you
trying to objectively criticize it by using majority opinion as the
basis? You might not like a piece of artwork personally, and the
majority of the git list might "agree" with you, but that does not
mean you can authoritatively claim that the piece of art is junk. You
have every right to dislike it personally, but that is an entirely
different matter.
>> [...] I already gave you the
>> example of the survivors on the boat with limited food/water on IRC:
>> it is you who stupidly refused to throw anyone overboard, killing all
>> the survivors; I am the one who said that I would get them to draw
>> sticks to "fairly choose" who to throw overboard, maximizing the
>> chances of survival of the others. I am making a pragmatic argument,
>> based on what is best for the community; not some stuck-up idealistic
>> bullshit. Further, I tried to help you think through the justice
>> problem, by recommending an accessible course. You have either not
>> gone through it, or have gone through it and learnt nothing.
>
> Your idea that you can assign Thomas "homework" in ethics and call him
> stupid for coming to a different conclusion than you is presumptuous in
> the extreme.
Incorrect. I used "stupid" to describe his solution to the
survivors-in-the-boat problem. I gave him homework (and this is
Harvard Justice, by the way), in an attempt to get him to think
clearly and come up with less "stupid" solutions to similar problems.
If you are defending throwing modern justice theories out the window,
and replacing it with a crude irrational argument, I have nothing more
to say.
>> [...]
>> You have embarrassed yourself and the entire git community today.
>
> This is also presumptuous, not to mention extremely ironic. In my
> opinion Thomas's email was calm and reasonable while yours is beyond the
> pale.
Yes, I did exercise my freedom of expression. And yes, I was
perfectly calm. Please do not suffocate me to death.
Let us get two simple things straightened out first:
1. Was Thomas being irrational or not?
2. Are you being fair or not?
They're yes-or-no questions. Hint: My "tone" has nothing to do with
the answers.
> Ram, don't just take my opinion on this matter. At the risk of being
> presumptuous myself, I suggest that you show a copy of your email to
> somebody whom you know and respect in the real world, somebody who is
> not immersed in the Git community meltdown. For example, somebody like
> your mother or father, or a teacher whom you respect, or a member of
> clergy if you are so inclined. Ask that person's opinion about your email.
I respect all of you on the Git list. And yes, I have done what you
asked: I showed it to several friends of mine on IRC and in real life.
They were not at all surprised: they know me to be a very polite,
gentle, and reasonable person. My stern rational disagreement has
nothing to do with any of those things.
And yes, as Felipe pointed out: you entire email has complained about
my "tone" and _completely_ ignored content.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:16 ` Ramkumar Ramachandra
@ 2013-06-11 18:43 ` Michael Haggerty
2013-06-11 18:55 ` Ramkumar Ramachandra
2013-06-11 23:48 ` Felipe Contreras
0 siblings, 2 replies; 63+ messages in thread
From: Michael Haggerty @ 2013-06-11 18:43 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thomas Rast, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
On 06/11/2013 08:16 PM, Ramkumar Ramachandra wrote:
> This is an exercise. I can easily be more tactful (as evidenced by
> other threads), but I'm choosing not to be. I want you to focus on
> the argument, and not the tone.
I stopped reading your email here. I've read enough tactless emails
over the last few days, but to be asked to read an email that was
*intentionally* written tactlessly is too detrimental to my quality of life.
In German there is an expression "Der Ton macht die Musik": "the tone
makes the music", by which they mean that the *way* something is said is
at least as important as what is said. The tone *is* an integral part
of the message and (1) the writer will be much more effective by making
the tone agree with the literal words of the message and (2) for this
particular reader, the effort of accommodating writers who are unwilling
to do so has become too exhausting.
I naively thought that I might be able to help calm the situation, but I
have concluded that nothing I can say or do will have that effect.
Therefore I bow out of this part of the conversation and hope either
that it will fizzle out or that perhaps a deus ex machina will appear.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:43 ` Michael Haggerty
@ 2013-06-11 18:55 ` Ramkumar Ramachandra
2013-06-11 19:06 ` Junio C Hamano
2013-06-11 23:48 ` Felipe Contreras
1 sibling, 1 reply; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-11 18:55 UTC (permalink / raw)
To: Michael Haggerty
Cc: Thomas Rast, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
Michael Haggerty wrote:
> I stopped reading your email here. I've read enough tactless emails
> over the last few days, but to be asked to read an email that was
> *intentionally* written tactlessly is too detrimental to my quality of life.
I'm sorry, but the problem has no solution then.
The "problem" we are dealing with is irrational and/or out-of-tone
emails. Unless you possess some mind-control mechanism that will get
all contributors to write emails that conform to your standards, there
is no solution. If you feel strongly that everyone must conform to
your standards, you must "remove" the members that do not conform to
that standard.
I have no desire to be suffocated to conform to your standard, so I'm
ready to leave.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:55 ` Ramkumar Ramachandra
@ 2013-06-11 19:06 ` Junio C Hamano
2013-06-11 19:39 ` Felipe Contreras
0 siblings, 1 reply; 63+ messages in thread
From: Junio C Hamano @ 2013-06-11 19:06 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Michael Haggerty, Thomas Rast, Git List, Jonathan Nieder,
A Large Angry SCM
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Michael Haggerty wrote:
>> I stopped reading your email here. I've read enough tactless emails
>> over the last few days, but to be asked to read an email that was
>> *intentionally* written tactlessly is too detrimental to my quality of life.
>
> I'm sorry, but the problem has no solution then.
>
> The "problem" we are dealing with is irrational and/or out-of-tone
> emails. Unless you possess some mind-control mechanism that will get
> all contributors to write emails that conform to your standards, there
> is no solution.
Actually there is. Just ignore the troll.
In the past few days, I've learned to mostly skim mails from you and
Felipe on this topic (and perhaps some other topics) just enough to
see if there is anything worth reading and/or responding to in them,
and have ignored most of them.
That gave me some time back to do the real work.
If you argue that we should not punish "people" but "bad behaviour",
that is fine. The "From:" field, combined with the "Subject: "
field, is often a pretty good indication to tell if a message is
worth reading and/or responding to, so ignoring such messages and
ignoring troll senders practically amount to the same thing.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 19:06 ` Junio C Hamano
@ 2013-06-11 19:39 ` Felipe Contreras
0 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 19:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Michael Haggerty, Thomas Rast, Git List,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 2:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> I'm sorry, but the problem has no solution then.
>>
>> The "problem" we are dealing with is irrational and/or out-of-tone
>> emails. Unless you possess some mind-control mechanism that will get
>> all contributors to write emails that conform to your standards, there
>> is no solution.
>
> Actually there is. Just ignore the troll.
Congratulations Junio. You have followed our drafted guidelines by
choosing to lead by example how not to not propagate the violence,
turn around, and take the high road.
After kicking your opponent in the groin.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:43 ` Michael Haggerty
2013-06-11 18:55 ` Ramkumar Ramachandra
@ 2013-06-11 23:48 ` Felipe Contreras
1 sibling, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 23:48 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ramkumar Ramachandra, Thomas Rast, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 1:43 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 06/11/2013 08:16 PM, Ramkumar Ramachandra wrote:
>> This is an exercise. I can easily be more tactful (as evidenced by
>> other threads), but I'm choosing not to be. I want you to focus on
>> the argument, and not the tone.
>
> I stopped reading your email here.
Yeah, you are ignoring the arguments, what a surprise.
> In German there is an expression "Der Ton macht die Musik": "the tone
> makes the music", by which they mean that the *way* something is said is
> at least as important as what is said.
I know you don't care about reality, but you are committing the
is-ought fallacy. You are describing the way things are, not the way
things should be.
Yes, most people can't handle rational arguments, or truth, and need
hypocrites to hide things from them. That's why politics is surrounded
by people who never say the truth.. not really.
That doesn't mean that's the way things _ought_ to be, specially not
the way *you* should act.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 14:40 ` Michael Haggerty
2013-06-11 15:34 ` Felipe Contreras
2013-06-11 18:16 ` Ramkumar Ramachandra
@ 2013-06-11 19:55 ` Brandon Casey
2 siblings, 0 replies; 63+ messages in thread
From: Brandon Casey @ 2013-06-11 19:55 UTC (permalink / raw)
To: Michael Haggerty, Ramkumar Ramachandra
Cc: Thomas Rast, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
On Tue, Jun 11, 2013 at 7:40 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> At the risk of being
> presumptuous myself, I suggest that you show a copy of your email to
> somebody whom you know and respect in the real world, somebody who is
> not immersed in the Git community meltdown. For example, somebody like
> your mother or father, or a teacher whom you respect, or a member of
> clergy if you are so inclined. Ask that person's opinion about your email.
>
> It is so easy to lose perspective in the Internet.
Such excellent advice. Even if the advice is not taken literally, it
is probably enough to just imagine how that person whom you respect
would respond to the words in your emails. I am sure I do not do this
enough in my own communications.
I just wanted to draw attention to this wonderful suggestion again.
Sometimes it is necessary to take a step back when discussions get
heated, to regain perspective.
-Brandon
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 13:40 ` Ramkumar Ramachandra
2013-06-11 14:40 ` Michael Haggerty
@ 2013-06-12 11:56 ` Theodore Ts'o
2013-06-12 12:29 ` Ramkumar Ramachandra
2013-06-12 13:58 ` Felipe Contreras
1 sibling, 2 replies; 63+ messages in thread
From: Theodore Ts'o @ 2013-06-12 11:56 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thomas Rast, Michael Haggerty, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 07:10:11PM +0530, Ramkumar Ramachandra wrote:
>
> Presumably, Felipe is the "fire hazard" that we are talking about, and
> nobody else is to blame. He must be "removed" to prevent future
> fires. This is the "perception of the regulars", correct?
>
> Then why haven't you removed him yet? What are you waiting for? You
> don't need my "approval".
He (and you) get "removed" when individuals who have decided the vast
majority of their e-mails shed more heat than light, and so people
decide that it's not worth reading their e-mails. I have persionally
made this determination for both you and for Felipe; for you, your
participation in this thread was what set the "bozo bit".
Now, I'm not a major developer for git, so my personal decision
doesn't make a huge amount of difference.
But if people who *are* senior developers in the git community decide,
on their own, that someone isn't worth listening to, there's the
punishment has been inflicted, and this happens without banning
someone from posting or removing them from the mailing list.
Please stop.
Regards,
- Ted
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-12 11:56 ` Theodore Ts'o
@ 2013-06-12 12:29 ` Ramkumar Ramachandra
2013-06-12 13:58 ` Felipe Contreras
1 sibling, 0 replies; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-12 12:29 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Thomas Rast, Michael Haggerty, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
Theodore Ts'o wrote:
> But if people who *are* senior developers in the git community decide,
> on their own, that someone isn't worth listening to, there's the
> punishment has been inflicted, and this happens without banning
> someone from posting or removing them from the mailing list.
Yes, I have already been punished by several people. As a result of
my arguments on this thread, everyone will treat me like a troll in
the future.
As a rational person, why have I inflicted this upon myself? To make
a point about how increased tolerance is the way to reduce fires? No,
it is not worth it. Either way, I have failed miserably: by being
deliberately untactful, I have only aggravated the community.
> Please stop.
I have no desire to constantly exhibit deviant behavior that offends a
large majority.
Sorry.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-12 11:56 ` Theodore Ts'o
2013-06-12 12:29 ` Ramkumar Ramachandra
@ 2013-06-12 13:58 ` Felipe Contreras
1 sibling, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-12 13:58 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Ramkumar Ramachandra, Thomas Rast, Michael Haggerty, Git List,
Junio C Hamano, Jonathan Nieder, A Large Angry SCM
On Wed, Jun 12, 2013 at 6:56 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Jun 11, 2013 at 07:10:11PM +0530, Ramkumar Ramachandra wrote:
>>
>> Presumably, Felipe is the "fire hazard" that we are talking about, and
>> nobody else is to blame. He must be "removed" to prevent future
>> fires. This is the "perception of the regulars", correct?
>>
>> Then why haven't you removed him yet? What are you waiting for? You
>> don't need my "approval".
>
> He (and you) get "removed" when individuals who have decided the vast
> majority of their e-mails shed more heat than light, and so people
> decide that it's not worth reading their e-mails. I have persionally
> made this determination for both you and for Felipe;
On what basis have you made that determination? Have you made that
determination based on my contributions?
% git shortlog -n -s --no-merges --since '3 months ago'
221 Felipe Contreras
83 Junio C Hamano
69 Jeff King
62 Michael Haggerty
48 Ramkumar Ramachandra
35 Thomas Rast
33 Nguyễn Thái Ngọc Duy
32 John Keeping
30 René Scharfe
21 Kevin Bracey
Have you read each and every one of my 800 patches in the last three
months? Plus all my replies?
Or have you made that determination based on the tiny subset of those
that are controversial?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 12:33 ` Thomas Rast
2013-06-11 13:40 ` Ramkumar Ramachandra
@ 2013-06-11 15:06 ` Felipe Contreras
2013-06-11 15:41 ` Thomas Rast
1 sibling, 1 reply; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 15:06 UTC (permalink / raw)
To: Thomas Rast
Cc: Ramkumar Ramachandra, Michael Haggerty, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> My approach -- and in my perception also that preferred by most of the
> regulars who have spoken in this whole mess -- is that since there is a
> fire hazard, it would be more effective firefighting to just remove the
> hazard, thus preventing future fires.
You would make an excellent evil dictator.
A benevolent dictator like Linus Torvalds knows better, in the LKML
"fire hazards" are not removed, they are ignored before any flames go
up. This achieves the best of both worlds; if the person is truly
vicious, nothing happens, but if there's something to it, a person
that doesn't offend so easily might have a fruitful discussion, while
the rest ignore the thread.
In a flamewar everyone is guilty. Apparently you never learned that
"but he started it!" is not a defense worthy of an adult, hell, even
most children know that.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 15:06 ` Felipe Contreras
@ 2013-06-11 15:41 ` Thomas Rast
2013-06-11 15:52 ` Felipe Contreras
0 siblings, 1 reply; 63+ messages in thread
From: Thomas Rast @ 2013-06-11 15:41 UTC (permalink / raw)
To: Felipe Contreras
Cc: Ramkumar Ramachandra, Michael Haggerty, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
>
>> My approach -- and in my perception also that preferred by most of the
>> regulars who have spoken in this whole mess -- is that since there is a
>> fire hazard, it would be more effective firefighting to just remove the
>> hazard, thus preventing future fires.
>
> You would make an excellent evil dictator.
>
> A benevolent dictator like Linus Torvalds knows better, in the LKML
> "fire hazards" are not removed, they are ignored before any flames go
> up. This achieves the best of both worlds; if the person is truly
> vicious, nothing happens, but if there's something to it, a person
> that doesn't offend so easily might have a fruitful discussion, while
> the rest ignore the thread.
>
> In a flamewar everyone is guilty. Apparently you never learned that
> "but he started it!" is not a defense worthy of an adult, hell, even
> most children know that.
[Yes, I should let this thread die, but you are offering me too good a
chance to pass up.]
It's funny that you would mention Linus, considering there's at least
one instance on record where he broke almost every rule that Ram
attempted to set out in the thread starter, calling you among other
things a "fucking moron" and telling you to "go away".
https://lkml.org/lkml/2012/4/12/434
In case our readers wonder why the flame war suddenly died out at a
depth of about 19 replies, fear not, for the story continued:
https://plus.google.com/108736516888538655285/posts/7QSVy8taWgC
And before you try to shoot that down, please make sure your argument
also applies to the recurring situation of your repeatedly ignoring
SubmittingPatches as far as commit messages go against explicit requests
to stop that.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 15:41 ` Thomas Rast
@ 2013-06-11 15:52 ` Felipe Contreras
0 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 15:52 UTC (permalink / raw)
To: Thomas Rast
Cc: Ramkumar Ramachandra, Michael Haggerty, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 10:41 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
>>
>>> My approach -- and in my perception also that preferred by most of the
>>> regulars who have spoken in this whole mess -- is that since there is a
>>> fire hazard, it would be more effective firefighting to just remove the
>>> hazard, thus preventing future fires.
>>
>> You would make an excellent evil dictator.
>>
>> A benevolent dictator like Linus Torvalds knows better, in the LKML
>> "fire hazards" are not removed, they are ignored before any flames go
>> up. This achieves the best of both worlds; if the person is truly
>> vicious, nothing happens, but if there's something to it, a person
>> that doesn't offend so easily might have a fruitful discussion, while
>> the rest ignore the thread.
>>
>> In a flamewar everyone is guilty. Apparently you never learned that
>> "but he started it!" is not a defense worthy of an adult, hell, even
>> most children know that.
>
> [Yes, I should let this thread die, but you are offering me too good a
> chance to pass up.]
>
> It's funny that you would mention Linus, considering there's at least
> one instance on record where he broke almost every rule that Ram
> attempted to set out in the thread starter, calling you among other
> things a "fucking moron" and telling you to "go away".
>
> https://lkml.org/lkml/2012/4/12/434
Yet, this "fire hazzard" was not removed, nor was there any threat of
doing so at any point in the discussion.
> In case our readers wonder why the flame war suddenly died out at a
> depth of about 19 replies, fear not, for the story continued:
>
> https://plus.google.com/108736516888538655285/posts/7QSVy8taWgC
You sure like your ad hominem arguments. Perhaps it would be wise to
get the timeline right. The Google+ discussion you are pointing to
happened *before* the thread ended, even Linus replied after that:
http://article.gmane.org/gmane.linux.drivers.ath9k.devel/8675
> And before you try to shoot that down, please make sure your argument
> also applies to the recurring situation of your repeatedly ignoring
> SubmittingPatches as far as commit messages go against explicit requests
> to stop that.
There's nothing to shoot down, you are not making any argument. You
are doing nothing but throwing personal attacks.
If what you are suggesting is that we should do what they did in the
LKML; they did *exactly* what I'm suggesting you should do; *ignore*
the people that you think are vicious.
Is that what you are suggesting?
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 4:41 ` Michael Haggerty
2013-06-11 6:28 ` Felipe Contreras
2013-06-11 10:45 ` Ramkumar Ramachandra
@ 2013-06-11 16:10 ` Thomas Rast
2013-06-11 16:17 ` Felipe Contreras
2013-06-11 17:00 ` Junio C Hamano
2013-06-12 20:02 ` Junio C Hamano
4 siblings, 1 reply; 63+ messages in thread
From: Thomas Rast @ 2013-06-11 16:10 UTC (permalink / raw)
To: Michael Haggerty, Felipe Contreras
Cc: Ramkumar Ramachandra, Git List, Junio C Hamano, Jonathan Nieder,
A Large Angry SCM
Michael Haggerty <mhagger@alum.mit.edu> writes:
> * Accept reviewers' comments gratefully and take them very seriously.
> Show that you appreciate the help by giving the reviewer the benefit of
> the doubt. If, after careful consideration, you find that you cannot
> agree with a reviewer's suggestion, explain your reasoning carefully
> without taking or giving offense, and seek compromise.
I'm not sure yet how to phrase it, but I have come to the conclusion
that the dual nature of reviews is part of the problem.
On the one hand, reviews are code criticism: they are extra work spent
by the reviewer to try and help you improve your work.
On the other hand, they are also quality checks. Reviews serve to spot
bugs, misdesigns, noncompliance with project standards, etc. before they
ever go into the code base.
The problems start when these start having a contradictory impact on the
correct course of action in a discussion, or in the longer term in
dealing with a person. For example, I have attempted to deal with
Felipe at one point by refusing to review, i.e., ignore the email.
However, this must be weighed against the requirements of the second
kind of review. So while it is exceedingly easy for everyone to say
"just ignore the flamebait", the flamewars keep recurring because this
"gatekeeper" type of review continues to be necessary, and continues to
elicit nonconstructive responses.
The "easy" solution is to simply stop taking patches from Felipe, but
opens pandora's box w.r.t. the just application of such a measure, as
Ram has noted repeatedly.
Yet that is the only measure that I currently know that both keeps up
code review standards and has any hope of improving the current climate.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 16:10 ` Thomas Rast
@ 2013-06-11 16:17 ` Felipe Contreras
0 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 16:17 UTC (permalink / raw)
To: Thomas Rast
Cc: Michael Haggerty, Ramkumar Ramachandra, Git List, Junio C Hamano,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 11:10 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> * Accept reviewers' comments gratefully and take them very seriously.
>> Show that you appreciate the help by giving the reviewer the benefit of
>> the doubt. If, after careful consideration, you find that you cannot
>> agree with a reviewer's suggestion, explain your reasoning carefully
>> without taking or giving offense, and seek compromise.
>
> I'm not sure yet how to phrase it, but I have come to the conclusion
> that the dual nature of reviews is part of the problem.
>
> On the one hand, reviews are code criticism: they are extra work spent
> by the reviewer to try and help you improve your work.
>
> On the other hand, they are also quality checks. Reviews serve to spot
> bugs, misdesigns, noncompliance with project standards, etc. before they
> ever go into the code base.
>
> The problems start when these start having a contradictory impact on the
> correct course of action in a discussion, or in the longer term in
> dealing with a person. For example, I have attempted to deal with
> Felipe at one point by refusing to review, i.e., ignore the email.
>
> However, this must be weighed against the requirements of the second
> kind of review. So while it is exceedingly easy for everyone to say
> "just ignore the flamebait", the flamewars keep recurring because this
> "gatekeeper" type of review continues to be necessary, and continues to
> elicit nonconstructive responses.
Why do you assume the review is for the patch submitter? You can reply
so your review is stored on the record, and the maintainer, Junio, can
see it. Then you can ignore the fallout.
I think this type of review is hurtful, because the fact that you said
some words doesn't mean you are right, and you might be blocking a
perfectly good patch by not following up the counter arguments.
Presumably you are not worried about that, and you would be content
with simply blocking all my patches. Whatever floats your boat.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 4:41 ` Michael Haggerty
` (2 preceding siblings ...)
2013-06-11 16:10 ` Thomas Rast
@ 2013-06-11 17:00 ` Junio C Hamano
2013-06-11 18:24 ` Michael Haggerty
` (2 more replies)
2013-06-12 20:02 ` Junio C Hamano
4 siblings, 3 replies; 63+ messages in thread
From: Junio C Hamano @ 2013-06-11 17:00 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I would prefer a community standards document that looks more like this:
OK.
> * Accept reviewers' comments gratefully and take them very seriously.
> Show that you appreciate the help by giving the reviewer the benefit of
> the doubt. If, after careful consideration, you find that you cannot
> agree with a reviewer's suggestion, explain your reasoning carefully
> without taking or giving offense, and seek compromise.
In short, the only acceptable response to review comments are "You
are right. Here is a reroll", or "I think your suggestion will miss
these cases which I wanted to cover and that is why I did it this
way". There may be other small variants of the above two, but I
think I can agree with the general principle.
In cases, there are two or more equally valid approaches to solving
a problem. I do not think I had to accept (or reject) many "it can
be done better in different ways and this perhaps is not the best
one" (or "it could be argued that it is correct") borderline topics
in the recent past, but I suspect that "a disagreement is healthy"
has to be accompanied by how disagreements that do not resolve
themselves are resolved (I think I've heard somewhere that some
communities break ties in favor of reviewers, for example).
> * When reviewing other peoples' code, be tactful and constructive. Set
> high expectations, but do what you can to help the submitter achieve
> them. Don't demand changes based only on your personal preferences.
> Don't let the perfect be the enemy of the good.
I think this is 30% aimed at me (as I think I do about that much of
the reviews around here). I fully agree with most of them, but the
last sentence is a bit too fuzzy to be a practically useful
guideline. Somebody's bare minimum is somebody else's perfection.
An unqualified "perfect is the enemy of good" is often incorrectly
used to justify "It works for me." and "There already are other
codepaths that do it in the same wrong way.", both of which make
things _worse_ for the long term project health.
> * It is not OK to use these guidelines as a stick with which to beat
> supposed violators. However, if you genuinely feel that another
> community member is routinely behaving in ways that are detrimental to
> the community, it might help to calmly express your concerns to that
> person, preferably in a private email, and naming concrete and specific
> incidents rather than broad generalizations.
I would think it is perfectly OK to say "The way you are refusing to
listen to constructive comments is not how things work around here"
by pointing at a set of guidelines.
Why do you think is it not OK? The "beating" part?
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 17:00 ` Junio C Hamano
@ 2013-06-11 18:24 ` Michael Haggerty
2013-06-11 18:29 ` John Keeping
2013-06-11 20:33 ` Jeff King
2 siblings, 0 replies; 63+ messages in thread
From: Michael Haggerty @ 2013-06-11 18:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On 06/11/2013 07:00 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> [...]
>> * When reviewing other peoples' code, be tactful and constructive. Set
>> high expectations, but do what you can to help the submitter achieve
>> them. Don't demand changes based only on your personal preferences.
>> Don't let the perfect be the enemy of the good.
>
> I think this is 30% aimed at me (as I think I do about that much of
> the reviews around here). I fully agree with most of them, but the
> last sentence is a bit too fuzzy to be a practically useful
> guideline. Somebody's bare minimum is somebody else's perfection.
> An unqualified "perfect is the enemy of good" is often incorrectly
> used to justify "It works for me." and "There already are other
> codepaths that do it in the same wrong way.", both of which make
> things _worse_ for the long term project health.
I agree that the last line is fuzzy. And I don't think that I've
observed any cases where I thought that reviewers were being too strict,
so in a way it's just trying to head off hypothetical future problems
and to make sure that the balance between submitter and reviewer is not
*entirely* one-sided. Given our (proper, I think) strong deference to
reviewers, one could imagine a reviewer abusing his/her authority to
obstruct reasonable changes by (for example) making demands that the
submitter also fix tangentially-related things that are beyond the scope
of the patch.
In my own projects I have a rough policy of "not worse than before",
meaning that as long as a patch makes progress in at least one
dimension, and doesn't make things worse in any other dimension, then it
is acceptable. (Of course "worse" can include internal quality issues
like copy-pasting code or even an increase in the amount of code
disproportionate to its benefit.) A failure to make improvements in one
area should not be a reason to block an improvement in another area, as
long as nothing is made worse.
But I can't right now think of a succinct way to express what I have in
mind.
>> * It is not OK to use these guidelines as a stick with which to beat
>> supposed violators. However, if you genuinely feel that another
>> community member is routinely behaving in ways that are detrimental to
>> the community, it might help to calmly express your concerns to that
>> person, preferably in a private email, and naming concrete and specific
>> incidents rather than broad generalizations.
>
> I would think it is perfectly OK to say "The way you are refusing to
> listen to constructive comments is not how things work around here"
> by pointing at a set of guidelines.
I agree.
> Why do you think is it not OK? The "beating" part?
I think it would be counterproductive for people to start saying things
like "that is a violation of rule 3, section 2" *in everyday
discussions*. This shouldn't be taken as a list of black-and-white
laws, with allegations of small "infractions" used to shut down
discussions. And on the other hand, if somebody shows a long history of
acting contrary to the guidelines, and persists despite repeated
requests to stop, I don't want the discussion to turn into a lawyerly
analysis of the guidelines with point-by-point rebuttals and
counter-rebuttals of whether this or that guideline was violated.
The guidelines should just describe the expected tone of the community
in a way that the vast majority of participants can agree on, and any
kind of actions to enforce the guidelines should only be taken when an
overwhelming majority of the community
I think the CommunityGuidelines should have three main uses:
1. An artifact documenting the community consensus about what kinds of
behaviors are encouraged and what kinds are considered unacceptable. It
should only be accepted, and it only has value, if there is a strong
consensus in favor of it.
2. A resource to help new community members get up to speed on our
practices and expectations.
3. As a point of reference in the direst meltdowns, such as IMO we are
having right now.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 17:00 ` Junio C Hamano
2013-06-11 18:24 ` Michael Haggerty
@ 2013-06-11 18:29 ` John Keeping
2013-06-11 18:46 ` Ramkumar Ramachandra
` (2 more replies)
2013-06-11 20:33 ` Jeff King
2 siblings, 3 replies; 63+ messages in thread
From: John Keeping @ 2013-06-11 18:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> > * When reviewing other peoples' code, be tactful and constructive. Set
> > high expectations, but do what you can to help the submitter achieve
> > them. Don't demand changes based only on your personal preferences.
> > Don't let the perfect be the enemy of the good.
>
> I think this is 30% aimed at me (as I think I do about that much of
> the reviews around here). I fully agree with most of them, but the
> last sentence is a bit too fuzzy to be a practically useful
> guideline. Somebody's bare minimum is somebody else's perfection.
> An unqualified "perfect is the enemy of good" is often incorrectly
> used to justify "It works for me." and "There already are other
> codepaths that do it in the same wrong way.", both of which make
> things _worse_ for the long term project health.
One thing that I think is missing from these proposals so far is some
clear indication that a review should not be confrontational. Consider
the following two review comments (taken from a recent example that
happened to stick in my mind, but I don't want to single out any one
individual here):
Ugh, why this roundabout-passive-past tone? Use imperative tone
like this:
...
vs.
We normally use the imperative in commit messages, perhaps like
this?
...
Both say the same thing but the first immediately puts the submitter on
the defensive. If I see something like that on one of my patches I have
to consciously resist the urge to reply immediately and instead review
what I'm about to send once I've calmed down.
I realise that we shouldn't take offence to review comments, but we are
all human and it is sometimes hard not to take things personally.
In the examples above, the first makes it feel like the submitter is
fighting to get a patch included, but the second feels like we're
collaborating to get to the best result for the project.
As my mother would say, "politeness costs nothing" ;-)
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:29 ` John Keeping
@ 2013-06-11 18:46 ` Ramkumar Ramachandra
2013-06-11 19:54 ` John Keeping
2013-06-11 18:52 ` Michael Haggerty
2013-06-11 19:35 ` Felipe Contreras
2 siblings, 1 reply; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-11 18:46 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Michael Haggerty, Git List, Jonathan Nieder,
A Large Angry SCM
John Keeping wrote:
> Ugh, why this roundabout-passive-past tone? Use imperative tone
> like this:
>
> ...
>
> vs.
>
> We normally use the imperative in commit messages, perhaps like
> this?
>
> ...
>
> As my mother would say, "politeness costs nothing" ;-)
The review is being honest about her feelings in the first one, and
being artificially diplomatic in the second one. Both of them are
constructive and friendly, in that they provide an example for the
submitter to follow.
Either way, I'm not interested in problems that have no solutions.
The only "solution" I see here is to suffocate every contributor until
they are "tactful enough" for the majority's liking, and "remove" the
ones that don't conform. If you do have an alternate solution, please
share it with us.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:46 ` Ramkumar Ramachandra
@ 2013-06-11 19:54 ` John Keeping
2013-06-12 11:26 ` Ramkumar Ramachandra
0 siblings, 1 reply; 63+ messages in thread
From: John Keeping @ 2013-06-11 19:54 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Junio C Hamano, Michael Haggerty, Git List, Jonathan Nieder,
A Large Angry SCM
On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > Ugh, why this roundabout-passive-past tone? Use imperative tone
> > like this:
> >
> > ...
> >
> > vs.
> >
> > We normally use the imperative in commit messages, perhaps like
> > this?
> >
> > ...
> >
> > As my mother would say, "politeness costs nothing" ;-)
>
> The review is being honest about her feelings in the first one, and
> being artificially diplomatic in the second one.
I don't think it is artificially diplomatic, it's an attempt to convey a
helpful tone in an email. As has been said elsewhere, it is easy to
read an email in the wrong tone (there is an oft-cited statistic about
the percentage of communication that is non-verbal, and which cannot be
inferred from written text). For this reason I think it is important
for reviewers to make an effort to minimise the risk that what they
write can be interpreted as being aggressive.
> Both of them are
> constructive and friendly, in that they provide an example for the
> submitter to follow.
Both provide the same advice, yes. But I disagree that they are both
friendly. The top example reads (to me at least) as an attack on the
submitter for not knowing better. It may sometimes be necessary to
resort to strong wording if someone appears to be wilfully ignoring
sensible advice but we should not expect every submitter to know the
expectations of the project; the first message to someone should gently
guide them in the right direction.
> Either way, I'm not interested in problems that have no solutions.
> The only "solution" I see here is to suffocate every contributor until
> they are "tactful enough" for the majority's liking, and "remove" the
> ones that don't conform. If you do have an alternate solution, please
> share it with us.
I don't have a solution, only a hope that regular contributors will
learn from others how they can phrase review comments less aggressively.
I expect different people will read the same statement differently;
people are from different cultures and what is considered acceptable in
one culture can be considered rude in another. We should aim to
cultivate our own culture where we try to minimise the risk that what we
write will be misinterpreted by someone with a different cultural
background.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 19:54 ` John Keeping
@ 2013-06-12 11:26 ` Ramkumar Ramachandra
2013-06-12 13:14 ` John Keeping
0 siblings, 1 reply; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-12 11:26 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Michael Haggerty, Git List, Jonathan Nieder,
A Large Angry SCM
John Keeping wrote:
> On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:
>> John Keeping wrote:
>> > Ugh, why this roundabout-passive-past tone? Use imperative tone
>> > like this:
>> >
>> > ...
>> >
>> > vs.
>> >
>> > We normally use the imperative in commit messages, perhaps like
>> > this?
>> >
>> > ...
>> >
>> > As my mother would say, "politeness costs nothing" ;-)
>>
>> The review is being honest about her feelings in the first one, and
>> being artificially diplomatic in the second one.
>
> I don't think it is artificially diplomatic, it's an attempt to convey a
> helpful tone in an email.
Okay, so answer this: Why did the reviewer deliberately use the
"unhelpful" tone? Was she trying to attack the new contributor, and
intend to harm the community? Or did she just say what came to her
mind?
> As has been said elsewhere, it is easy to
> read an email in the wrong tone (there is an oft-cited statistic about
> the percentage of communication that is non-verbal, and which cannot be
> inferred from written text).
Yes, it is.
> For this reason I think it is important
> for reviewers to make an effort to minimise the risk that what they
> write can be interpreted as being aggressive.
Correct.
>> Either way, I'm not interested in problems that have no solutions.
>> The only "solution" I see here is to suffocate every contributor until
>> they are "tactful enough" for the majority's liking, and "remove" the
>> ones that don't conform. If you do have an alternate solution, please
>> share it with us.
>
> I don't have a solution, only a hope that regular contributors will
> learn from others how they can phrase review comments less aggressively.
The reviewer is not a thick-skinned bull that wants to harm the project.
4. Lead by example. If you do not like how someone presents
themselves on the list, you counter it by presenting yourself nicely
on the list. Others will follow your example, making that person's
behavior the minority. It is far more powerful than explicitly
stating what is "acceptable" behavior and what is not.
> I expect different people will read the same statement differently;
> people are from different cultures and what is considered acceptable in
> one culture can be considered rude in another. We should aim to
> cultivate our own culture where we try to minimise the risk that what we
> write will be misinterpreted by someone with a different cultural
> background.
So you have agreed that "tone" is subjective, and that attempting to
objectively state the "right tone" is a lost cause.
The solution to the problem, as I have already explained several times is to:
- Define an objective basis for people to react.
- Lead by example, and influence other contributors to follow your style.
What everyone is doing differently:
- Taking offense at every possible juncture.
- Taking sides and voting. Ganging up and playing politics.
- Making bad irrational arguments in the "right tone".
- Invalidating entire arguments, on the basis of tone.
- Making tone the entire subject of discussion, ignoring content.
- Bringing "majority opinion" to a rational argument.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-12 11:26 ` Ramkumar Ramachandra
@ 2013-06-12 13:14 ` John Keeping
0 siblings, 0 replies; 63+ messages in thread
From: John Keeping @ 2013-06-12 13:14 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Junio C Hamano, Michael Haggerty, Git List, Jonathan Nieder,
A Large Angry SCM
On Wed, Jun 12, 2013 at 04:56:27PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> >> Either way, I'm not interested in problems that have no solutions.
> >> The only "solution" I see here is to suffocate every contributor until
> >> they are "tactful enough" for the majority's liking, and "remove" the
> >> ones that don't conform. If you do have an alternate solution, please
> >> share it with us.
> >
> > I don't have a solution, only a hope that regular contributors will
> > learn from others how they can phrase review comments less aggressively.
>
> The reviewer is not a thick-skinned bull that wants to harm the project.
>
> 4. Lead by example. If you do not like how someone presents
> themselves on the list, you counter it by presenting yourself nicely
> on the list. Others will follow your example, making that person's
> behavior the minority.
I think that's what everyone is trying to do, the problem is when the
axiom "others will follow your example" fails. In that case it is
important to address the issue.
It is equally important to do this in a way that does not assume malice
on the part of the reviewer. It is quite possible that when English is
not someone's first language then they may not realise how their words
are being interpreted by some people. In this case a friendly message
sent off the mailing list may be appropriate.
> It is far more powerful than explicitly
> stating what is "acceptable" behavior and what is not.
>
> > I expect different people will read the same statement differently;
> > people are from different cultures and what is considered acceptable in
> > one culture can be considered rude in another. We should aim to
> > cultivate our own culture where we try to minimise the risk that what we
> > write will be misinterpreted by someone with a different cultural
> > background.
>
> So you have agreed that "tone" is subjective, and that attempting to
> objectively state the "right tone" is a lost cause.
It is subjective *to some degree*. If a reviewer takes care, then it is
possible to write a message that minimises the risk that the words can
be interpreted in a way that is not what was intended.
If we do end up having community guidelines, then I think that point is
very important. It is equally important that readers do not assume that
the tone in which they read an email is that in which it was intended
but I think that human nature makes that half harder.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:29 ` John Keeping
2013-06-11 18:46 ` Ramkumar Ramachandra
@ 2013-06-11 18:52 ` Michael Haggerty
2013-06-11 19:19 ` John Keeping
2013-06-11 19:46 ` Philip Oakley
2013-06-11 19:35 ` Felipe Contreras
2 siblings, 2 replies; 63+ messages in thread
From: Michael Haggerty @ 2013-06-11 18:52 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On 06/11/2013 08:29 PM, John Keeping wrote:
> On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> * When reviewing other peoples' code, be tactful and constructive. Set
>>> high expectations, but do what you can to help the submitter achieve
>>> them. Don't demand changes based only on your personal preferences.
>>> Don't let the perfect be the enemy of the good.
>>
>> I think this is 30% aimed at me (as I think I do about that much of
>> the reviews around here). I fully agree with most of them, but the
>> last sentence is a bit too fuzzy to be a practically useful
>> guideline. Somebody's bare minimum is somebody else's perfection.
>> An unqualified "perfect is the enemy of good" is often incorrectly
>> used to justify "It works for me." and "There already are other
>> codepaths that do it in the same wrong way.", both of which make
>> things _worse_ for the long term project health.
>
> One thing that I think is missing from these proposals so far is some
> clear indication that a review should not be confrontational. Consider
> the following two review comments (taken from a recent example that
> happened to stick in my mind, but I don't want to single out any one
> individual here):
>
> Ugh, why this roundabout-passive-past tone? Use imperative tone
> like this:
>
> ...
>
> vs.
>
> We normally use the imperative in commit messages, perhaps like
> this?
>
> ...
>
> Both say the same thing but the first immediately puts the submitter on
> the defensive. If I see something like that on one of my patches I have
> to consciously resist the urge to reply immediately and instead review
> what I'm about to send once I've calmed down.
That's a very good point (and a good illustration, too). How do you
like the new second and third sentences below?
* When reviewing other peoples' code, be tactful and constructive.
Remember that submitting patches for public critique can be very
intimidating and when mistakes are found it can be embarrassing. Do
what you can to make it a positive and pleasant experience for the
submitter. Set high expectations, but do what you can to help the
submitter achieve them. Don't demand changes based only on your
personal preferences. Don't let the perfect be the enemy of the good.
(As Junio pointed out, the last sentence is not so great and a better
replacement would be welcome.)
> As my mother would say, "politeness costs nothing" ;-)
Does your mother program C? We could use her around here :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:52 ` Michael Haggerty
@ 2013-06-11 19:19 ` John Keeping
2013-06-11 19:46 ` Philip Oakley
1 sibling, 0 replies; 63+ messages in thread
From: John Keeping @ 2013-06-11 19:19 UTC (permalink / raw)
To: Michael Haggerty
Cc: Junio C Hamano, Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On Tue, Jun 11, 2013 at 08:52:05PM +0200, Michael Haggerty wrote:
> That's a very good point (and a good illustration, too). How do you
> like the new second and third sentences below?
>
> * When reviewing other peoples' code, be tactful and constructive.
> Remember that submitting patches for public critique can be very
> intimidating and when mistakes are found it can be embarrassing. Do
> what you can to make it a positive and pleasant experience for the
> submitter. Set high expectations, but do what you can to help the
> submitter achieve them. Don't demand changes based only on your
> personal preferences. Don't let the perfect be the enemy of the good.
I'm not sure. I like the intent, but I'm not sure that it's clear
enough that we're talking about the tone of comments rather than the
type of feedback to provide.
How about something like this?
* Having your code reviewed should feel like a collaboration aiming
for the best result for the project, not like a fight to get your
patch accepted. Try to bear this in mind when reviewing other
peoples' code and consider how you would feel reading the same
comments if the review was the other way round. We are only human
and the tone of a review can influence how the following
discussion progresses.
* If you do feel that a review is aggressive, don't reply
immediately. Contributors are spread around the world in
different timezones and it is often better to wait a few hours for
others to comment before rushing to defend your patch.
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:52 ` Michael Haggerty
2013-06-11 19:19 ` John Keeping
@ 2013-06-11 19:46 ` Philip Oakley
2013-06-12 0:08 ` John Szakmeister
2013-06-12 14:49 ` Jakub Narebski
1 sibling, 2 replies; 63+ messages in thread
From: Philip Oakley @ 2013-06-11 19:46 UTC (permalink / raw)
To: Michael Haggerty, John Keeping
Cc: Junio C Hamano, Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
From: "Michael Haggerty" <mhagger@alum.mit.edu>
Sent: Tuesday, June 11, 2013 7:52 PM
[...]
>
> That's a very good point (and a good illustration, too). How do you
> like the new second and third sentences below?
>
> * When reviewing other peoples' code, be tactful and constructive.
> Remember that submitting patches for public critique can be very
> intimidating
I found this to be true. The tone on the list could at times feel
un-helpful (to the new person). It is almost as if it is an initiation -
those on the list know the protocols, and new folk either arrive like a
bull in a china shop, or more likely, timidly push the patch under the
door and run away (and variations in between) - some never push out
their (drafted) patch.
> and when mistakes are found it can be embarrassing.
Sometimes it isn't 'mistakes', rather it is simply a lack of sufficient
explanation to communicate intent, which may not have been understood by
the reviewer/responder. In such cases it can be a frustration to know
what was meant in the response, especially if the response is terse.
[i.e. I think it would be reasonable to squeeze part of this in here
somewhere to guide new contributors about this step]
There is separately a need to note the role of the maintainer, who has a
more difficult role as gatekeeper who's higher standards in applying the
precautionary principle
http://en.wikipedia.org/wiki/Precautionary_principle can feel like
unhelpfulness, or worse if misunderstood.
> Do
> what you can to make it a positive and pleasant experience for the
> submitter. Set high expectations, but do what you can to help the
> submitter achieve them. Don't demand changes based only on your
> personal preferences. Don't let the perfect be the enemy of the good.
>
> (As Junio pointed out, the last sentence is not so great and a better
> replacement would be welcome.)
>
>> As my mother would say, "politeness costs nothing" ;-)
>
> Does your mother program C? We could use her around here :-)
I think she programmed in Smalltalk and CleanYourRoom. (sorry not my
question ;-)
>
> Michael
>
> --
> Michael Haggerty
> mhagger@alum.mit.edu
> http://softwareswirl.blogspot.com/
regards
Philip
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 19:46 ` Philip Oakley
@ 2013-06-12 0:08 ` John Szakmeister
2013-06-12 14:49 ` Jakub Narebski
1 sibling, 0 replies; 63+ messages in thread
From: John Szakmeister @ 2013-06-12 0:08 UTC (permalink / raw)
To: Philip Oakley
Cc: Michael Haggerty, John Keeping, Junio C Hamano,
Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On Tue, Jun 11, 2013 at 3:46 PM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Michael Haggerty" <mhagger@alum.mit.edu>
> Sent: Tuesday, June 11, 2013 7:52 PM
> [...]
>
>>
>> That's a very good point (and a good illustration, too). How do you
>> like the new second and third sentences below?
>>
>> * When reviewing other peoples' code, be tactful and constructive.
>> Remember that submitting patches for public critique can be very
>> intimidating
>
>
> I found this to be true. The tone on the list could at times feel un-helpful
> (to the new person). It is almost as if it is an initiation - those on the
> list know the protocols, and new folk either arrive like a bull in a china
> shop, or more likely, timidly push the patch under the door and run away
> (and variations in between) - some never push out their (drafted) patch.
Interesting! I've had the opposite opinion. I've often been
surprised at how much constructive feedback has been given, and the
thoughtfulness of the reviewers to offer up alternative solutions,
show examples, etc. Junio, Jeff, and especially Jonathan have been
particularly good on that front--at least those are some of the
regulars that stick out in my mind. Overall, I've been pretty happy
with the community, and while I haven't contributed much, I generally
enjoy reading the emails. I feel like I learn something new all the
time. :-)
-John
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 19:46 ` Philip Oakley
2013-06-12 0:08 ` John Szakmeister
@ 2013-06-12 14:49 ` Jakub Narebski
2013-06-12 20:54 ` Philip Oakley
1 sibling, 1 reply; 63+ messages in thread
From: Jakub Narebski @ 2013-06-12 14:49 UTC (permalink / raw)
To: git
Philip Oakley <philipoakley <at> iee.org> writes:
> From: "Michael Haggerty" <mhagger <at> alum.mit.edu>
> Sent: Tuesday, June 11, 2013 7:52 PM
> >> As my mother would say, "politeness costs nothing"
> >
> > Does your mother program C? We could use her around here
>
> I think she programmed in Smalltalk and CleanYourRoom. (sorry not my
> question
Nb. there is purely-objective programming language named Smalltalk
https://en.wikipedia.org/wiki/Smalltalk
--
Jakub Narębski
(via GMane)
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-12 14:49 ` Jakub Narebski
@ 2013-06-12 20:54 ` Philip Oakley
0 siblings, 0 replies; 63+ messages in thread
From: Philip Oakley @ 2013-06-12 20:54 UTC (permalink / raw)
To: git, Jakub Narebski
From: "Jakub Narebski" <jnareb@gmail.com>
Sent: Wednesday, June 12, 2013 3:49 PM
> Philip Oakley <philipoakley <at> iee.org> writes:
>> From: "Michael Haggerty" <mhagger <at> alum.mit.edu>
>> Sent: Tuesday, June 11, 2013 7:52 PM
>
>> >> As my mother would say, "politeness costs nothing"
>> >
>> > Does your mother program C? We could use her around here
>>
>> I think she programmed in Smalltalk and CleanYourRoom. (sorry not my
>> question
>
> Nb. there is purely-objective programming language named Smalltalk
> https://en.wikipedia.org/wiki/Smalltalk
Yes, I knew that <smiles>. It was deliberate. Good to see someone
spotted it.
>
> --
> Jakub Narębski
> (via GMane)
>
Philip
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 18:29 ` John Keeping
2013-06-11 18:46 ` Ramkumar Ramachandra
2013-06-11 18:52 ` Michael Haggerty
@ 2013-06-11 19:35 ` Felipe Contreras
2 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 19:35 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Michael Haggerty, Ramkumar Ramachandra, Git List,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 1:29 PM, John Keeping <john@keeping.me.uk> wrote:
> I realise that we shouldn't take offence to review comments, but we are
> all human and it is sometimes hard not to take things personally.
>
> In the examples above, the first makes it feel like the submitter is
> fighting to get a patch included, but the second feels like we're
> collaborating to get to the best result for the project.
>
> As my mother would say, "politeness costs nothing" ;-)
That's right, I agree with everything you said, but what would your
mother say about the people are not polite towards you? I doubt it
would be "fuck them then".
You should be polite, you should not demand politeness. Being polite
towards the people that are polite to you barely has any merit,
swallowing your pride, taking a deep breath, trying to understand that
the other side might be just having a bad day, or any number of
reasons for the impoliteness... that's what takes effort.
Escalating violence is easy, blaming the other side for starting is
also easy (as any toddler would tell you), being the side that puts
the other cheek is what's hard.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 17:00 ` Junio C Hamano
2013-06-11 18:24 ` Michael Haggerty
2013-06-11 18:29 ` John Keeping
@ 2013-06-11 20:33 ` Jeff King
2013-06-11 20:55 ` Junio C Hamano
2013-06-12 12:03 ` Ramkumar Ramachandra
2 siblings, 2 replies; 63+ messages in thread
From: Jeff King @ 2013-06-11 20:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
> > * Accept reviewers' comments gratefully and take them very seriously.
> > Show that you appreciate the help by giving the reviewer the benefit of
> > the doubt. If, after careful consideration, you find that you cannot
> > agree with a reviewer's suggestion, explain your reasoning carefully
> > without taking or giving offense, and seek compromise.
>
> In short, the only acceptable response to review comments are "You
> are right. Here is a reroll", or "I think your suggestion will miss
> these cases which I wanted to cover and that is why I did it this
> way". There may be other small variants of the above two, but I
> think I can agree with the general principle.
>
> In cases, there are two or more equally valid approaches to solving
> a problem. I do not think I had to accept (or reject) many "it can
> be done better in different ways and this perhaps is not the best
> one" (or "it could be argued that it is correct") borderline topics
> in the recent past, but I suspect that "a disagreement is healthy"
> has to be accompanied by how disagreements that do not resolve
> themselves are resolved (I think I've heard somewhere that some
> communities break ties in favor of reviewers, for example).
I more or less agree with what both of you have said above. The "ties
goes to reviewers" thing I would be very wary of, at least as a hard
rule. We do not (and do not want to) put any restrictions on who is
allowed to do review. That sometimes results in unhelpful or even wrong
reviews by new people, but those reviews are a stepping stone to being a
more experienced and capable reviewer.
Most of the time such reviews are resolved by other community members
joining the discussion and coming to some agreement, but not always.
And that is not even getting into the cases where long-time experienced
reviewers are simply wrong or misguided, or the issue is legitimately a
difficult tradeoff to consider, and the discussion ends in a stalemate.
And I think that is where the benevolent dictator role comes in. They
weigh not just the points made in the discussion (or a summary of it),
but also use their judgement on who is making comments (how many people,
the utility of their past comments) and other factors (other things
happening in the project, being conservative because of recent mistakes
made, etc). They may break such a tie by applying or rejecting, even by
putting off a decision to revisit later (which is a de facto reject, of
course).
So there are no hard rules, and this is not a democracy[1]. For the most
part the community runs itself in an open and collective fashion, and
the dictator's job is easy; but ultimately, he or she is in charge of
what gets applied and what doesn't. Rules like "break ties in favor of
reviewers" are just a guideline for the dictator to use in making
decisions.
I do not think any of that is news to you, but I think the point needs
to be made, as it applies to any concrete rules.
-Peff
[1] Note that I think a benevolent dictator is a _terrible_ way to run a
real government, but it works in an open source project. I think the
difference is that dictatorship is open to abuse of power. In the
real world, there is a lot of power to abuse, and it is hard for
people to opt out of it. In the open source world, there is not that
much power, and if there is a bad dictator everyone can go somewhere
else (another project, or even a fork). So while a dictator _can_
play favorites, or start deciding which patches to take based on
what they had for breakfast, there is a real incentive to remain
fair and reasonable.
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 20:33 ` Jeff King
@ 2013-06-11 20:55 ` Junio C Hamano
2013-06-11 23:19 ` Felipe Contreras
2013-06-12 12:03 ` Ramkumar Ramachandra
1 sibling, 1 reply; 63+ messages in thread
From: Junio C Hamano @ 2013-06-11 20:55 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
Jeff King <peff@peff.net> writes:
> So there are no hard rules, and this is not a democracy[1]. For the most
> part the community runs itself in an open and collective fashion, and
> the dictator's job is easy; but ultimately, he or she is in charge of
> what gets applied and what doesn't. Rules like "break ties in favor of
> reviewers" are just a guideline for the dictator to use in making
> decisions.
>
> I do not think any of that is news to you, but I think the point needs
> to be made, as it applies to any concrete rules.
My original draft had "I am hoping we do not have to come to that"
after "(I heard some communities break ties this way)", but I
removed it by mistake.
And I think you are right. I also am hoping that I am being fair to
dictate ;-)
> -Peff
>
> [1] Note that I think a benevolent dictator is a _terrible_ way to run a
> real government, but it works in an open source project. I think the
> difference is that dictatorship is open to abuse of power. In the
> real world, there is a lot of power to abuse, and it is hard for
> people to opt out of it. In the open source world, there is not that
> much power, and if there is a bad dictator everyone can go somewhere
> else (another project, or even a fork). So while a dictator _can_
> play favorites, or start deciding which patches to take based on
> what they had for breakfast, there is a real incentive to remain
> fair and reasonable.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 20:55 ` Junio C Hamano
@ 2013-06-11 23:19 ` Felipe Contreras
2013-06-12 12:27 ` Theodore Ts'o
0 siblings, 1 reply; 63+ messages in thread
From: Felipe Contreras @ 2013-06-11 23:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Michael Haggerty, Ramkumar Ramachandra, Git List,
Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 3:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> So there are no hard rules, and this is not a democracy[1]. For the most
>> part the community runs itself in an open and collective fashion, and
>> the dictator's job is easy; but ultimately, he or she is in charge of
>> what gets applied and what doesn't. Rules like "break ties in favor of
>> reviewers" are just a guideline for the dictator to use in making
>> decisions.
>>
>> I do not think any of that is news to you, but I think the point needs
>> to be made, as it applies to any concrete rules.
>
> My original draft had "I am hoping we do not have to come to that"
> after "(I heard some communities break ties this way)", but I
> removed it by mistake.
>
> And I think you are right. I also am hoping that I am being fair to
> dictate ;-)
Fair? Fairness requires to judge each action without biases, nor
double standards. In the case of an open source community it requires
you to listen to the arguments before dismissing them, and consider
the patches before dropping them on the floor. Fairness requires no
favoritism.
You think you are being fair? You have acted the equivalent of a judge
that says "oh, you again? I don't need to look at the case, you are a
drunk and you go to jail". I'm not saying that's wrong, I'm saying you
can't call that fair.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 23:19 ` Felipe Contreras
@ 2013-06-12 12:27 ` Theodore Ts'o
2013-06-12 14:06 ` Felipe Contreras
0 siblings, 1 reply; 63+ messages in thread
From: Theodore Ts'o @ 2013-06-12 12:27 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Jeff King, Michael Haggerty, Ramkumar Ramachandra,
Git List, Jonathan Nieder, A Large Angry SCM
On Tue, Jun 11, 2013 at 06:19:23PM -0500, Felipe Contreras wrote:
> Fair? Fairness requires to judge each action without biases, nor
> double standards. In the case of an open source community it requires
> you to listen to the arguments before dismissing them, and consider
> the patches before dropping them on the floor. Fairness requires no
> favoritism.
At least in development communities that *I* run, if someone were as
rude to me as you have been in some previous exchanges to Junio, I
would have set the bozo bit a long time ago and reviewed your
submissions with a very jaudiced eye, and treated your non-technical
arguments with same amount of attention as I give madmen and drunkards
in the street. Junio has given you *far* more latitude than I would
have.
Keep in mind, the demands for respect go in both directions, and in
non-technical matters about style and "good taste", at the end of the
day the maintainer does get to have the final say, because he or she
is the one who applies the patches or accepts the pull request. So if
the maintainer says something like, "maintaining ABI backwards
compatibility for libext2fs (or for kernel syscalls) is critically
important", that's not up to you. Sending me abusive e-mails about
how I'm not listening to your arguments isn't going to help. You can
try to change my mind with reasoned arguments, but for questions like
that, or what functions do or don't belong in a library, the
maintainer is the benevolent dictator.
Things a very different for things like "this change causes a 30%
performance regression in a particular workload". For those sorts of
technical questions, a much more collaborative discussion style is
important. But for questions of what is and isn't "good taste", it's
not a good idea to reply to a maintainer's e-mail with "that's your
opinion" over and over again. For things like that it *IS* his (or
her) opinion, and if you can't live with it, you'll save a lot of
bandwidth on the mailing list by moving on to some other project.
Regards,
- Ted
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-12 12:27 ` Theodore Ts'o
@ 2013-06-12 14:06 ` Felipe Contreras
0 siblings, 0 replies; 63+ messages in thread
From: Felipe Contreras @ 2013-06-12 14:06 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Junio C Hamano, Jeff King, Michael Haggerty, Ramkumar Ramachandra,
Git List, Jonathan Nieder, A Large Angry SCM
On Wed, Jun 12, 2013 at 7:27 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Jun 11, 2013 at 06:19:23PM -0500, Felipe Contreras wrote:
>> Fair? Fairness requires to judge each action without biases, nor
>> double standards. In the case of an open source community it requires
>> you to listen to the arguments before dismissing them, and consider
>> the patches before dropping them on the floor. Fairness requires no
>> favoritism.
>
> At least in development communities that *I* run, if someone were as
> rude to me as you have been in some previous exchanges to Junio, I
> would have set the bozo bit a long time ago and reviewed your
> submissions with a very jaudiced eye, and treated your non-technical
> arguments with same amount of attention as I give madmen and drunkards
> in the street. Junio has given you *far* more latitude than I would
> have.
Yeah, you certainly can do that, but a judge cannot do that, can he?
> Keep in mind, the demands for respect go in both directions, and in
> non-technical matters about style and "good taste", at the end of the
> day the maintainer does get to have the final say, because he or she
> is the one who applies the patches or accepts the pull request. So if
> the maintainer says something like, "maintaining ABI backwards
> compatibility for libext2fs (or for kernel syscalls) is critically
> important", that's not up to you. Sending me abusive e-mails about
> how I'm not listening to your arguments isn't going to help.
I'm not abusing anyone. Junio is making the mistake of thinking he is
being fair, I made the judge analogy so that he can see that he is not
acting like a judge. A judge has an obligation of being fair, so he
acts fairly, Junio don't have that obligation, yet he thinks he is
being fair when he is not.
That is not abuse, that is pointing the truth.
> You can
> try to change my mind with reasoned arguments, but for questions like
> that, or what functions do or don't belong in a library, the
> maintainer is the benevolent dictator.
Yes, he makes the decision, that doesn't mean the rationale for the
decision is correct.
He is making the decision based on the idea that
init_copy_notes_for_rewrite() (and similar) will be used by binaries
other than 'git'. He is wrong.
> For things like that it *IS* his (or her) opinion,
The problem is he doesn't accept it's his opinion. He thinks it's a fact.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 20:33 ` Jeff King
2013-06-11 20:55 ` Junio C Hamano
@ 2013-06-12 12:03 ` Ramkumar Ramachandra
1 sibling, 0 replies; 63+ messages in thread
From: Ramkumar Ramachandra @ 2013-06-12 12:03 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael Haggerty, Git List, Jonathan Nieder,
A Large Angry SCM
Jeff King wrote:
> And I think that is where the benevolent dictator role comes in. They
> weigh not just the points made in the discussion (or a summary of it),
> but also use their judgement on who is making comments (how many people,
> the utility of their past comments) and other factors (other things
> happening in the project, being conservative because of recent mistakes
> made, etc). They may break such a tie by applying or rejecting, even by
> putting off a decision to revisit later (which is a de facto reject, of
> course).
Junio has one of the hardest jobs of all: his sense of fairness plays
a major role in determining the health of the project.
That said, I'm quite happy with Junio's sensibilities. He's not
devoid of shortcomings, but that is an unrealistic expectation.
> So there are no hard rules, and this is not a democracy[1]. For the most
> part the community runs itself in an open and collective fashion, and
> the dictator's job is easy; but ultimately, he or she is in charge of
> what gets applied and what doesn't. Rules like "break ties in favor of
> reviewers" are just a guideline for the dictator to use in making
> decisions.
Do not confuse "democracy" with "rule of the majority" (not implying
that you are; just saying). Governments have been voted out of power
because they failed to protect minority interests. When it comes to a
decision like "whether or not to execute this rapist", the government
does not make a decision based on the votes of the common public. It
has a constitution, and courts where it is interpreted and decisions
are made. Cases are often not won or lost on the basis of "hard
rules", but on the force of the arguments that the two lawyers
present. There are societies that use the jury system to lessen the
burden on the judge; but again, a decision cannot be made on the basis
of majority: the jury panel must reach a consensus.
It's not all that different from what happens in this community, I think.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-11 4:41 ` Michael Haggerty
` (3 preceding siblings ...)
2013-06-11 17:00 ` Junio C Hamano
@ 2013-06-12 20:02 ` Junio C Hamano
2013-06-13 3:45 ` Michael Haggerty
4 siblings, 1 reply; 63+ messages in thread
From: Junio C Hamano @ 2013-06-12 20:02 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I would prefer a community standards document that looks more like this:
> ...
>
> * Be welcoming to new community participants. Help them get oriented,
> and be patient with their questions. Gently introduce them to our
> community standards, above all by setting a good example yourself.
I agree that on-boarding is an important process.
In addition to the reviews I'd give to regulars, I personally try
to do some of these things:
- Even in a negative review, end the message with "Thanks". More
important is to express that the particular patch is rejected but
contributor's future contribution (either a reroll or a separate
topic) is welcome.
This is free, and there is no reason not to be nice.
- Point out problems in a milder way than usual. Instead of saying
"Why is this done like so?", risking to be misinterpreted that I
am saying the patch did something wrong and the contributor was a
horrible programmer, rephrase it to "Hmph, this may work in such
and such cases, but I wonder how well it would in this case?",
followed by "How about going this route instead, which would
cover all these cases?"
Doing so is more time consuming at reviewers' end; once you know
the current design well enough, you can immediately smell a wrong
approach a lot faster by just looking at code and design in a
patch, without having to come up with a concrete example.
- Instead of just pointing out minor nits and have the new
contributor reroll, point them out, and then show how the patch
should have looked like, often after "-- >8 --" and the "From:"
line that keeps attribution.
Again this is more work at reviewers' end.
Coaching new contributors, like mentoring GSoC students, is often
more time consuming than scratching the same itch yourself for any
reviewer, but it is an investment, which hopefully yields dividend
in the longer term.
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-12 20:02 ` Junio C Hamano
@ 2013-06-13 3:45 ` Michael Haggerty
2013-06-13 4:22 ` Junio C Hamano
0 siblings, 1 reply; 63+ messages in thread
From: Michael Haggerty @ 2013-06-13 3:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
On 06/12/2013 10:02 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> I would prefer a community standards document that looks more like this:
>> ...
>>
>> * Be welcoming to new community participants. Help them get oriented,
>> and be patient with their questions. Gently introduce them to our
>> community standards, above all by setting a good example yourself.
>
> I agree that on-boarding is an important process.
>
> In addition to the reviews I'd give to regulars, I personally try
> to do some of these things:
>
> - Even in a negative review, end the message with "Thanks". More
> important is to express that the particular patch is rejected but
> contributor's future contribution (either a reroll or a separate
> topic) is welcome.
>
> This is free, and there is no reason not to be nice.
>
> - Point out problems in a milder way than usual. Instead of saying
> "Why is this done like so?", risking to be misinterpreted that I
> am saying the patch did something wrong and the contributor was a
> horrible programmer, rephrase it to "Hmph, this may work in such
> and such cases, but I wonder how well it would in this case?",
> followed by "How about going this route instead, which would
> cover all these cases?"
>
> Doing so is more time consuming at reviewers' end; once you know
> the current design well enough, you can immediately smell a wrong
> approach a lot faster by just looking at code and design in a
> patch, without having to come up with a concrete example.
>
> - Instead of just pointing out minor nits and have the new
> contributor reroll, point them out, and then show how the patch
> should have looked like, often after "-- >8 --" and the "From:"
> line that keeps attribution.
>
> Again this is more work at reviewers' end.
>
> Coaching new contributors, like mentoring GSoC students, is often
> more time consuming than scratching the same itch yourself for any
> reviewer, but it is an investment, which hopefully yields dividend
> in the longer term.
Thanks for these concrete examples / suggestions for reviewers. I
remember especially that during my first contacts with the Git community
I was very impressed by these very things in your code reviews and in
those of other reviewers.
Are you proposing that your text should find its way into the
CommunityGuidelines in some form? I hesitate to make the document *so*
long, especially considering that the section for contributors would
then probably also be expanded by a similar amount. But I think
distilling the advice into one or two sentences, also taking into
account the suggestions of others in this thread, would be a definite
improvement.
When I have time I want to submit some form of CommunityGuidelines as an
explicit patch, and I will try to synthesize all of the suggestions that
have been made.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Documentation/CommunityGuidelines
2013-06-13 3:45 ` Michael Haggerty
@ 2013-06-13 4:22 ` Junio C Hamano
0 siblings, 0 replies; 63+ messages in thread
From: Junio C Hamano @ 2013-06-13 4:22 UTC (permalink / raw)
To: Michael Haggerty
Cc: Ramkumar Ramachandra, Git List, Jonathan Nieder,
A Large Angry SCM
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 06/12/2013 10:02 PM, Junio C Hamano wrote:
>> Coaching new contributors, like mentoring GSoC students, is often
>> more time consuming than scratching the same itch yourself for any
>> reviewer, but it is an investment, which hopefully yields dividend
>> in the longer term.
>
> Thanks for these concrete examples / suggestions for reviewers. I
> remember especially that during my first contacts with the Git community
> I was very impressed by these very things in your code reviews and in
> those of other reviewers.
>
> Are you proposing that your text should find its way into the
> CommunityGuidelines in some form?
It actually was the other way around ;-).
After reading your message, I tried to think aloud by listing what I
try to do, and I was impressed that your three-line advice was a
very concise and very well written summary of that. I agree that a
guideline should be kept as concise and clear as possible.
The main point of my message was that reviewing and coaching may be
costly, but we have to do them as an investment.
^ permalink raw reply [flat|nested] 63+ messages in thread