Not so interesting- fallacious irrelevancy [LWN.net]

Not so interesting- fallacious irrelevancy

Posted Jul 17, 2013 20:29 UTC (Wed) by Tobu (subscriber, #24111)
In reply to: Not so interesting- fallacious irrelevancy by biehl
Parent article: On kernel mailing list behavior

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

to post comments

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."