Ingo posted a very interesting message on this thread [LWN.net]

Ingo posted a very interesting message on this thread

Posted Jul 17, 2013 18:58 UTC (Wed) by dlang (guest, #313)
Parent article: On kernel mailing list behavior

message ID 20130717181440.GA16955@gmail.com

Subject: open conflicts vs. hidden conflicts (was: [ 00/19] 3.10.1-stable review)

<snip>

In short: you are wrong on many levels.

Your notion that conflicts and insults somehow hurt group cooperation is wrong. It is a scientific fact that open conflict _helps_ cooperation while hidden conflict hurts it.

There's a famous psychological study that examined the cooperation patterns within string quartets playing music (Murnighan & Conlon, 1991): it evaluated different string quartets, examining their internal 'politics' and their conflict resolution techniques.

Effective, successful string quartets embraced open conflict: they honestly told each other when they messed up, not avoiding confrontation. Open conflict allowed them to eventually play music as a team, incorporating the concerns of all the musicians.

'Polite' string quartets on the other hand generally played poorer music, because each musician played individually, not as a team. The conflicts were never really resolved.

With a quick search I have not found the original study on the open web, but here's a citation of it:

> " Murnighan 84 Conlon (1991) found that effective string quartets accepted conflict as positive, and incorporated one another's concerns into the final product, whereas less successful quartets typically avoided conflict."

> http://www.delta.gatech.edu/papers/maximizing.pdf

[ I think this study might explain in part why the high tech industry is so strong in northern Europe: honesty pays off. ]

Your notion that insults are harmful because they 'hurt' is misleading to such a level that it's almost wrong.

Insults do hurt of course, but that argument misses the full context: in real life the typical substitute for an avoided open conflict is not singing kumbaya around the camp fire, but _hidden_ conflict.

Hidden, suppressed conflicts, office politics and passive-aggressive behavior are _far_ more harmful than the occasional four letter word:

There was a recent study that showed that 'giving the cold shoulder', 'the silent treatment' and other forms of passive-aggressive violence activate exactly the same brain regions as being physically injured. (!)

The difference between Linus's chiding of maintainers who messed up and 'hidden' conflicts is significant:

1) passive-aggressive violence can go on essentially forever, without outsiders noticing it. You won't notice it even on lkml, and yes, it occurs all the time ...

2) passive-aggressive violence _thrives_ in 'polite', 'professional' environments that supress open conflict. Hidden violence also occurs in a lot of 'polite' open source projects that I know.

3) so the net duration of the conflict is _far_ shorter in the Linus case.

I will pick an honest, colorful Linus flame over workplace mobbing or other forms of substitute passive-aggressive violence any time of the day.

I couldn't cite a single example where Linus flamed me unprovoked, unjustified, just for the sake of letting off steam or any other petty reason. I've not seen Linus flame newbies and I've not seen him micro-manage people over unimportant details.

In the large majority of colorful flames the flame was over something that _matters to the kernel_ - and heck do I prefer a top level maintainer who cares and who is honest, over someone who is indifferent or sloppy ...

to post comments

Ingo posted a very interesting message on this thread

Posted Jul 17, 2013 19:13 UTC (Wed) by corbet (editor, #1) [Link] (2 responses)

Ingo's message came in after the article was written; that's the hazard of writing about ongoing conversations. Here it is for those wanting to see it in original form.

Ingo posted a very interesting message on this thread

Posted Jul 18, 2013 8:18 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

Ingo's message is indeed a very good reading. It seems to me that it would be a good idea to update the article with a reference to it.

Ingo posted a very interesting message on this thread

Posted Jul 18, 2013 10:10 UTC (Thu) by daniel (guest, #3181) [Link]

Just looks like skillful justification of bad acting to me.

The same red herring as always.

Posted Jul 17, 2013 19:30 UTC (Wed) by HelloWorld (guest, #56129) [Link] (4 responses)

open conflict != insults and verbal abuse. It's perfectly possible to communicate unambiguously without resorting to swear words and verbal abuse, and if Linus and Ingo aren't capable of that, then it's due to their lack of communication skills.

Example:
http://lkml.indiana.edu/hypermail/linux/kernel/0612.1/172...
How does the phrase "Ok, what kind of ass-hat idiotic thing is this?" help? He should have written "The following is a bad idea:". How is "No way will I pull this kind of crap" useful? He should have said: "I am never going to pull code that handles IRQs in user-space". There is simply *no way* anybody could misunderstand my reformulations, and it has *nothing at all* to do with political correctness or subtlety, but simply with good breeding.

The same red herring as always.

Posted Jul 17, 2013 21:11 UTC (Wed) by rbuchmann (guest, #52862) [Link] (1 responses)

I fully disagree.

It's almost impossible to communicate unambigously, no matter wich words are used.

I don't know if the four-sides model of communication is well non outside Germany http://en.wikipedia.org/wiki/Four-sides_model.
But at least here it's probably part of every communication training (in companies etc.)

"Ok, what kind of ass-hat idiotic thing is this?" and "The following is a bad idea" don't tell the same story and they are both ambigous.
What is he trying to say?
- fact: code is bad/suboptimal/whatever?
- self reveal: I don't like it/I'm really upset/I take only perfect code?
- appeal: Change it/Go away?
- relationship: I usually trust you/I know you can do better/I think you are dumb?

I think that somethink like "Greg, you really disappointed me because I know you know better" would be more clear and polite (my interpretation comes from the Linus' explanations regarding his swearing referenced elsewhere).

The same red herring as always.

Posted Jul 17, 2013 21:37 UTC (Wed) by khim (subscriber, #9252) [Link]

I think that somethink like "Greg, you really disappointed me because I know you know better" would be more clear and polite

Are you really sure? To me Linus version translates to "Greg, you are really slow today and you are doing something really stupid, please stop and we'll be able to work from there" while your version translates to "Greg, you've disappointed me so much I can no longer even express it, I don't even have any swear words left and thus I don't know how I can continue to work with you".

I will expect to see something like "I remove you from list maintainers and will no longer pull patches from you. This is the end." in the next line.

P.S. And this not just my opinion as you can see.

The same red herring as always.

Posted Jul 17, 2013 23:16 UTC (Wed) by tao (subscriber, #17563) [Link] (1 responses)

I don't see either of "Ok, what kind of ass-hat idiotic thing is this?" and "No way will I pull this kind of crap" to be abusive.

If he'd written something along the lines of "Ok, what kind of ass-hat idiot wrote this thing?" it would have been abusive though.

I don't mind having my work criticized as long as it's justified. And for Linus to use such words the critique probably is... What I do mind is people calling me stupid if I'd do a bad job (though if I'd keep doing the same kind of bad job over and over it'd be nice to be told that maybe I should look for a different project to work on).

And at least in my case a harsh reaction against shitty code is far more effective to get my attention than something like "This code isn't what I'd expect", "I won't pull this", or similar.

In my opinion the lack of explanation of *why* something is crap is the big problem here, not the use of harsh language. Telling someone that they're doing it wrong, but not telling them what the right way is usually quite unhelpful, unless there's only one other way it could be done or if the proper way of doing things is already documented and part of things that you're expected to have read before submitting code.

So, for instance something like "The coding style here is fucked up beyond repair, go fix!" is enough (since there's a CodingStyle document that everyone who writes kernel code is expected to follow), but "This code is a total clusterfuck, I won't pull this" isn't, since it doesn't convey *why* the code sucks.

The same red herring as always.

Posted Jul 18, 2013 6:00 UTC (Thu) by khim (subscriber, #9252) [Link]

Telling someone that they're doing it wrong, but not telling them what the right way is usually quite unhelpful, unless there's only one other way it could be done or if the proper way of doing things is already documented and part of things that you're expected to have read before submitting code.

This is latter case. If you want to write driver for the hardware then you need to know how said hardware works. And in today's world of level-triggered IRQs devices must be explicitly silenced in IRQ handler before interrupts are enabled again. The code in question violates this fundamental principle. Worse: there are no way to write said code without violating this principle. I don't even know what to compare it to... well, I think "you are supposed to not just hang up wheel on the axis, it must be fastened up with screws, too, or lives will be in danger". Only here screws are not just not attached - bolts are used for fancy ribbons which means that can not ever fasten these screws and make car safe again!

I remember how my brother-in-law talked to guys who did that after minor fix in his car - Linus message looked nice in comparison. And I fully understand why: car which loses it's wheels on the highway because someone "honestly forgot" to use screws is not something which should ever happen. Dead machine is less of a problem then dead person I guess which explains why Linus used relatively mild curses here.

In my opinion the lack of explanation of *why* something is crap is the big problem here.

What lack of details? Linus explained quite well why such design can not be ever implemented correctly. Note: problem here is not even code of this concrete function, but with the fact that offered design requires such function - which in turn guarantees that there will be deadlocks on some systems.

Not so interesting- fallacious irrelevancy

Posted Jul 17, 2013 19:43 UTC (Wed) by jensend (guest, #1385) [Link] (8 responses)

Ingo is deliberately conflating conflict and insults, immediately from the get-go.

Yes, of course honest and open disagreement is vital. And even if you're honest and open, if you're insufficiently blunt the communication can be inefficient.

But that can be done better without abuse. Throwing in a bunch of f-bombs and calling the other person names doesn't make the conflict more open and honest or even more blunt. Sarah isn't advocating that core developers stop telling others that their patch is awful, that their approach won't work at all, or that they've completely misunderstood the kernel development process. She's saying that all of these things can be said without telling people "SHUT THE **** UP!" and calling them idiots.

It's quite trivial to change a couple lines of either of the emails Sarah linked in a way that makes them no less blunt but considerably less abusive.

It's conceivable that someone could still try to make a case for abuse- something along the lines of "Linus does this so as to be sufficiently awful and repulsive to scare off people who would waste his time; if he stated his disagreements more simply we'd have more development process scaling issues." But I don't really buy it.

Not so interesting- fallacious irrelevancy

Posted Jul 17, 2013 20:11 UTC (Wed) by biehl (subscriber, #14636) [Link] (7 responses)

"to scare off people who would waste his time"

That is my pet theory. I think swearing is Linuses "No brown M&Ms".

Not so interesting- fallacious irrelevancy

Posted Jul 17, 2013 20:29 UTC (Wed) by Tobu (subscriber, #24111) [Link] (4 responses)

It's part of the argument (emphasis mine):

Yes. And I do it partly (mostly) because it's who I am, and partly
because I honestly despise being subtle or "nice".

The fact is, people need to know what my position on things are. And I
can't just say "please don't do that", because people won't listen. I
say "On the internet, nobody can hear you being subtle", and I mean
it.

And I definitely am not willing to string people along, either. I've
had that happen too - not telling people clearly enough that I don't
like their approach, they go on to re-architect something, and get
really upset when I am then not willing to take their work.

Sarah, first off, I don't have that many tools at hand. Secondly, I
simply don't believe in being polite or politically correct. And you
can point at all those cultural factors where some cultures are not
happy with confrontation (and feel free to make it about gender too -
I think that's almost entirely cultural too). And please bring up
"cultural sensitivity" while at it. And I'll give you back that same
"cultural sensitivity". Please be sensitive to _my_ culture too.

[…]

From this message

Not so interesting- fallacious irrelevancy

Posted Jul 17, 2013 21:36 UTC (Wed) by kleptog (subscriber, #1183) [Link] (3 responses)

I agree with Linus' point about on the internet no-one can hear you being subtle. In fact, in real life people sometimes don't hear you either. For some reason a flat "no" is sometimes too subtle.

I'm surely not the only person who has had to maintain bad code that was committed because everyone was being too polite.

I can completely understand his point about not having that many tools at hand.

Not so interesting- fallacious irrelevancy

Posted Jul 18, 2013 9:43 UTC (Thu) by willnewton (guest, #68395) [Link] (1 responses)

I'm not sure I do. Ultimately he can choose not to pull your changes, what could be a stronger tool than that? I don't see why that would have to be accompanied by verbal abuse (not that it usually is of course).

To be perfectly honest I think a bigger issue for new contributors is apathy and indifference. Most new contributors if Linus were to flame them would go out and get a framed copy!

Not so interesting- fallacious irrelevancy

Posted Jul 18, 2013 10:24 UTC (Thu) by Tobu (subscriber, #24111) [Link]

Pulling or not pulling is binary. If most of the work in a pull request is useful or necessary, there's pressure to accept the pull request. For someone who has to take hundreds of pull requests, they need to shape the work that gets sent to them by documenting their expectations very clearly, being even more clear when those expectations fail to be met, and if warranted, flaming publicly so others may learn. Documentation/ManagementStyle also mentions ways to diminish the personal impact of flames which is their obvious downside (make them humorous and over the top, reserve them to people who should know better, don't be sanctimonious, spread the love and learn to apologise).

The initial topic of the linux-stable thread was expectations and policy for -stable and late -rcs. The policy was strict in both cases, but people were sending a rather higher volume of insufficiently tested non-regression work to Greg; at which point something to the effect of will I need to shout at people? came up.

Not so interesting- fallacious irrelevancy

Posted Jul 18, 2013 16:46 UTC (Thu) by josh (subscriber, #17465) [Link]

You can be unambiguously, unsubtly clear without going on the attack.

I certainly would not argue for passive-aggressive behavior; be clear, but don't be rude.

Perfectly reasonable, unambiguous responses to bad code or even bad patterns of behavior from a contributor:

"I don't want to see code like this ever again."
"Don't ever break userspace. Ever. It's never OK."
"I'm seeing the same set of mistakes in many pieces of code from you; please understand the problem better before sending any more patches."
"You should know better than this."

Not so interesting- fallacious irrelevancy

Posted Jul 22, 2013 20:45 UTC (Mon) by Baylink (guest, #755) [Link] (1 responses)

( for the people for whom kernel code is more interesting than pop culture:

In his autobiography _Crazy From The Heat_, David Lee Roth explains why the touring rider for Van Halen's first big 24-semitrailer stadium tour included, buried down around item 126 or so, something like "a bowl of M&M's in the dressing room reception area, with no brown M&Ms".

The *reason* for this item, which looked pretty goofy, and of which much light and fuss was made when it leaked to the public -- and which the band never admitted to at the time, *because it would then stop working* -- was that theirs was the first tour with lots of really heavy equipment rigged way up over top of tens of thousands of audience members, and they were thoughtful enough to realize that if they killed a substantial number of those because someone had not done their job properly, no one would ever do that kind of tour again -- quite aside from it ending their careers and possibly putting them up for manslaughter charges.

So they put the Brown M&M rule in the rider, and that gave them an easy way to check whether the promoter had properly read the rider, and implemented everything on it. They did, in fact, once come in and find brown M&Ms in the bowl, and they stopped everything and did a full inspection of the rig... and as I remember it, did find some dangerous practices, which they had corrected before showtime.

So things like that may in fact have non-obvious but desirable side effects, which drive why they exist. If you need more on this, go watch GI Jane, and find out how hard it is to become a SEAL. And why. And think about how many places the Linux kernel is now. And how many places it's going. )

Not so interesting- fallacious irrelevancy

Posted Jul 27, 2013 21:55 UTC (Sat) by nix (subscriber, #2304) [Link]

So, being vicious to people in a working environment[1] is acceptable because of, uh, Van Halen and brown M&Ms, and also Navy SEALs?

Sorry, not really seeing the connection here.

[1] which has never happened anywhere I have ever worked to the degree it happens on lkml, and I worked in the City of London, a famously vicious place

Ingo posted a very interesting message on this thread

Posted Jul 18, 2013 16:58 UTC (Thu) by josh (subscriber, #17465) [Link] (3 responses)

An intentionally adversarial environment requiring active support and defense of ideas does indeed produce far better results than one completely averse to negative feedback.

None of that requires flaming people to a crisp.

Code, sure; people, no. Even if you need to call someone out on a pattern of bad code to stop more from happening in the future, that still doesn't require flaming them.

Ingo posted a very interesting message on this thread

Posted Jul 18, 2013 22:07 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

An intentionally adversarial environment requiring active support and defense of ideas does indeed produce far better results than one completely averse to negative feedback.

It's also unnecessarily stressful. I for one could not possibly participate in any development process that was 'intentionally adversarial'. How many others are there like me?

Ingo posted a very interesting message on this thread

Posted Jul 19, 2013 12:05 UTC (Fri) by shmget (guest, #58347) [Link]

"It's also unnecessarily stressful."

So is the 100% PC-US-Coprporate-style, all-day, every day, crap.

"I for one could not possibly participate in any development process that was 'intentionally adversarial'. How many others are there like me? "

I for one could not possibly participate in a 'every opinion is valid' kumbaya development process, how many others are there like me? (yes me too can make an Appeal to the masses argument)

Ingo posted a very interesting message on this thread

Posted Jul 19, 2013 14:38 UTC (Fri) by josh (subscriber, #17465) [Link]

>> An intentionally adversarial environment requiring active support and defense of ideas does indeed produce far better results than one completely averse to negative feedback.

> It's also unnecessarily stressful. I for one could not possibly participate in any development process that was 'intentionally adversarial'. How many others are there like me?

"Intentionally adversarial" here just means the same as it does in "adversarial legal system": one in which different people argue different ideas or points of view, and those ideas or points of view may get argued against as appropriate, necessitating active advocacy, support, and defense.

Every time a patch submitter is required to say not just what they've changed but *why*, or a reviewer asks for benchmarks proving that the patch helps, or a reviewer says the code isn't clean enough and offers a list of proposed changes, that's what I mean by "adversarial". It doesn't mean the interactions need to be uncivil; it just means ideas are not automatically accepted and untouchable by others. It's OK to say "this is not acceptable".

By contrast, if you completely disallow negative feedback, how can you reject patches to preserve the quality of the project you're maintaining?

Ingo posted a very interesting message on this thread

Posted Jul 22, 2013 20:36 UTC (Mon) by Baylink (guest, #755) [Link]

Thank you thank you *thank you* dlang.