|
|
Log in / Subscribe / Register

Sharp: Closing a door

Sharp: Closing a door

Posted Oct 7, 2015 14:14 UTC (Wed) by rahulsundaram (subscriber, #21946)
In reply to: Sharp: Closing a door by malor
Parent article: Sharp: Closing a door

There is no contradiction between being civil and insisting on code quality.


to post comments

Sharp: Closing a door

Posted Oct 9, 2015 17:26 UTC (Fri) by nevets (subscriber, #11875) [Link] (10 responses)

In a perfect would I would agree. But there are times that people just don't get it. Pretty much every time Linus blew up and it made headlines, was due to this. After lots of civil communication, the point is not getting across. People (especially Linus) will then exert a bit of nastiness. Amazingly, people usually will take a step back and look at the bigger picture when that happens. Linus's rant about ARM is a perfect example of things getting done afterward.

Motivation is driven by emotion. The more passionate you are about something, the more you work at it. Fear of being yelled at can also motivate. There was a time that I wasn't listening to a major maintainer about something and he totally ripped into me (it wasn't Linus). It took several times at being yelled at for me to get a clue. As a result, I now have probably the best personal self made test suite that I run on my code before posting any patch to linux-next. I didn't make this because of civil conversation. I made it because I was terrified of being yelled at again.

Private vs public

Posted Oct 10, 2015 8:39 UTC (Sat) by marcH (subscriber, #57642) [Link] (8 responses)

> There was a time that I wasn't listening to a major maintainer about something and he totally ripped into me (it wasn't Linus). It took several times at being yelled at for me to get a clue.

Thanks for sharing this, which - as has been said many times - isn't a usual type of events yet always gets reported.

I think it's possible to mitigate even these rare events: simply by switching to private communication. I know that private emails are "just bad" the vast majority of the time, but all good rules have exceptions and IMHO this is one. I mean: when everyone gets it but the person too passionate (or else) to listen, why keep in public the (lack of) dialogue? Yelling "Now will you at last listen to me?" at someone in public is orders of magnitude more embarrassing and problematic than the same thing in private, and not just because the former is archived forever.

I've heard and seen more than one manager practice: "praise publicly, criticize privately". While it does not completely apply in this context there's still a lesson to take from it.

BTW there's often reference to the higher value given to respect in Asian vs Western cultures but it's always about public contexts; curious about private exchanges.

Now of course there's the risk the tone raises up a bit higher in a private communication. It typically still feels much better than being scolded in public. And wait: who said private communication has to be email, which *everyone* knows to be flame-prone? What happened to the good old telephone? The Internet star killed it? A lot of this entire debate actually comes down to just "email sucks" for all the well known reasons - mainly lack of oxytocin: https://youtu.be/ReRcHdeUG9Y?t=2149

Private vs public

Posted Oct 10, 2015 14:06 UTC (Sat) by nevets (subscriber, #11875) [Link] (7 responses)

Actually, there is a lot of criticism in the private. We just don't see it because, well, it's private.

But private criticism may not work as well either. When you are in a private forum, you can make claims that just wont hold up water. But doing that in a public setting has a bigger impact and both sides really need to have the facts straight before they post. Otherwise, if you yell at someone and are incorrect yourself, you can have others yell at you. This has happened, and kept the one that was yelling in check.

Escalating to public shaming really should be the last resort, but should still be on the table. Everyone that posts code to the Linux kernel should be a little nervous about it. That nervousness keeps one in check. Once you can post code without any anxiety then you can easily post low quality code. I've been submitting code to the Linux kernel for over 10 years, and I'm still nervous with every patch I send out. That drives me to make sure my patch can stand on its own, and keeps me from doing something stupid. If you can't handle that, and want to be able to send out "no worries" patches, where if you totally screw up, nobody will criticize you, I'm sorry, you are not fit to submit to a project as serious as the Linux kernel.

Private vs public

Posted Oct 10, 2015 14:09 UTC (Sat) by nevets (subscriber, #11875) [Link] (2 responses)

BTW, when I said "you" at the end, I don't mean you :-) That was just a generalization. I like German because it has a separate word for that "man", which doesn't mean the English "man".

Private vs public

Posted Oct 10, 2015 15:51 UTC (Sat) by cebewee (guest, #94775) [Link]

I should be able to use "one" in (most of) those case.

Private vs public

Posted Oct 15, 2015 8:02 UTC (Thu) by paulj (subscriber, #341) [Link]

You can use "one" as a general abstract pronoun for people, as a contraction of 'someone', in conjunction with "they", "them" to reference that abstract person, etc., e.g.:

"If someone can't handle that, and they want to be able to send out "no worries" patches, where if they totally screw up, nobody will criticize them, I'm sorry, they are not fit to submit to a project as serious as the Linux kernel."

"one" just happened not to fit easily in there, but often used in "One might think", "If one wants to avoid criticism". Note that "one" can come across as a bit stilted, just using "someone" usually sounds better IMO. "someone" is pretty much the same as the germanic "jemand" / "iemand".

Private vs public

Posted Oct 11, 2015 16:38 UTC (Sun) by nix (subscriber, #2304) [Link] (3 responses)

> If you can't handle that, and want to be able to send out "no worries" patches, where if you totally screw up, nobody will criticize you, I'm sorry, you are not fit to submit to a project as serious as the Linux kernel.

That is tantamount to saying that most people from huge chunks of the Earth (where the culture militates against public criticism of people and where people will go to great lengths to avoid such criticism) are not fit to submit to "a project as serious as the Linux kernel".

There's nothing wrong with criticizing the *patches*. There's something wrong with criticizing the *person* -- and you claim above that criticizing the person is just fine. That's pretty horrendous (if you meant it, rather than being a sloppy way of phrasing "nobody will criticize your patches". Obviously if the code is crap, you should say so, but that's not the same thing. Everyone totally screws up now and again. This does not reflect on them except to prove that they are human, and attacking them for that is wrong.)

Private vs public

Posted Oct 11, 2015 19:43 UTC (Sun) by lsl (subscriber, #86508) [Link] (2 responses)

> There's nothing wrong with criticizing the *patches*. There's something wrong with criticizing the *person* -- and you claim above that criticizing the person is just fine,

I don't think criticizing a person is generally inappropriate. Sometimes the actual problem is not as much the patches but the mindset that lead to their existence. This is, I think, what Steven's saying.

If you go to great lengths to avoid it, but slip up anyway, well, that happens. The *patch* gets torn apart, you clean it up and everything's fine. But when submitters don't do their due diligence and send crap to the list where it's obvious that they didn't even bother to read the relevant docs, then that's a totally different situation. If you don't even get the most basic stuff right and send one broken patch after another, there's no point in criticizing the individual patches. Until that *person* understands that touching kernel code requires a more careful mindset, looking at the patches is just a waste of time.

So telling those submitters to stop until they change their approach to programming is not only appropriate, but desperately needed. There's more than one way to do that, of course, and no one said you're supposed to scar them for life. With a bit of empathy, you can probably do it without causing all too much pain.

Private vs public

Posted Oct 11, 2015 20:55 UTC (Sun) by neilbrown (subscriber, #359) [Link] (1 responses)

> ...where it's obvious that they didn't even bother to read the relevant docs....

It is *never* obvious what someone else has or hasn't done in private. "They didn't read the relevant docs" may be the simplest explanation that you can think of given your perspective and values.
But people are different and complex. And they change from moment to moment.

Maybe they didn't ready, maybe they read but misunderstood. Maybe they forgot. Maybe they were hasty and careless. Maybe they are having a bad day and they pushed the wrong branch.

That is why attacking the person is such a bad idea. What you are really attacking is your mental model of the person, which is probably quite different in many details to the actual person. You may know what they did publicly,. You never know for certain why. So only attach the actions (i.e the code) not the person.

> If you don't even get the most basic stuff right and send one broken patch after another, there's no point in criticizing the individual patches.

There certainly comes a point where criticizing the patches doesn't seem worth while. But that does not justify attacking the person.

"I'm sorry but I won't be reviewing your patches any more because doing so doesn't appear to help. If you stop posting patches here for at least one month I may then look at future patches you post. If they appear to address my previous review comments, then I may proceed with them"

This talks about what "I" will do, how I see the patches, and specific public actions that you may or may not perform. This is all safe territory. It does not say anything about "you" or the reasons for "your" behaviour. It just identifies the problem and outlines the rules for engagement.

> So telling those submitters to stop until they change their approach to programming

Make that "stop until their patches address the identified issues" and I'll agree with you.

Private vs public

Posted Oct 11, 2015 21:50 UTC (Sun) by neilbrown (subscriber, #359) [Link]

Just a quick addendum...
Modern technological cultures like ours claim to value science over superstition.

Science is about that which is observable and measurable.
Superstition is about whatever we suppose to be the case - untested by measurement.

I'm just suggestion that we should be scientific, not superstitious, in our responses to each other.

Sharp: Closing a door

Posted Oct 11, 2015 16:43 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

>But there are times that people just don't get it. Pretty much every time Linus blew up and it made headlines, was due to this.

He didn't get on news for being critical but because of the way it is being expressed. Yes, he usually doesn't respond that way but the price of being a celebrity (even if you wear that hat uncomfortably) is that you have to that much more careful.

>Motivation is driven by emotion. The more passionate you are about something, the more you work at it. Fear of being yelled at can also motivate

True but studies have shown that intrinsic motivation is often more powerful compared to external pressure. If you are involved in development in a public way, you should be open to public criticism. That by itself isn't the problem. You do have to watch out for how you do it though. You can very easily drive off other contributors by doing it poorly.

Sharp: Closing a door

Posted Oct 9, 2015 17:42 UTC (Fri) by nevets (subscriber, #11875) [Link] (9 responses)

I will admit that not everyone can work in that type of environment. Sarah obviously has the talent for kernel development, but unfortunately, she is not one that can work in this environment.

There's talk about weighing "code quality" with "human wellness". I had this conversation with someone in Seattle, and at first I couldn't find a reply. Then later I was in a room where the presenter was talking about all the things that were using Linux to solve medical diseases, and such. Then it hit me. Quality of code is directly related to "human wellness". When the quality is not there, people can die. Whether directly or indirectly, Linux is used to save lives.

Try going into the medical field (several of my friends are). You think LKML is nasty? Residents are very much belittled in order for them to understand the full seriousness of their job. The more serious the project is, the harsher the environment.

The problem with Linux is that it is not a company. If someone is constantly sending in abysmal code, there's no performance review to correct that. Same goes to someone not following the standards. The only real tactic we have is to yell at someone. Otherwise you may waste days, weeks or months trying to be civil about it. As Linus always states, "in the internet, nobody can hear you being subtle".

Note, most of the time, civil conversation is all that is needed. The yelling is the exception and not the norm. Read LKML or even just Linus's emails. You'll find them mostly boring. It's only those rare occurrences that things had to escalate to set things straight again. Unfortunately news sites don't talk about the 1000's of boring "civil" emails. They only hone in on the one rant where civility didn't work.

Sharp: Closing a door

Posted Oct 11, 2015 16:41 UTC (Sun) by nix (subscriber, #2304) [Link] (8 responses)

But Sarah was *not* sending in absymal code, so it seems unlikely she was getting too much criticism herself. What you're saying is that if you can't cope with the stress of watching others be publically belittled (and it *is* stressful), sod off, we don't want you no matter how good a developer you are?

I have to say, any company I've ever heard of that had that policy would have been sued into the ground by now by ex-employees, and rightly so.

Sharp: Closing a door

Posted Oct 12, 2015 15:53 UTC (Mon) by ksandstr (guest, #60862) [Link] (7 responses)

>But Sarah was *not* sending in absymal code, [...]

She was, though. A "simple, trivial" patch, rejected off-hand for being obviously broken, with a comment to the effect of "did you even compile this?".

Look it up. It concerns USB3, of course.

Sharp: Closing a door

Posted Oct 12, 2015 22:34 UTC (Mon) by PaXTeam (guest, #24616) [Link] (6 responses)

> Asked for evidence, a concrete reference to the public communication by which the condemners formed their opinion, what do they answer? "Go search for it yourself."

the irony is just too rich.

Sharp: Closing a door

Posted Oct 12, 2015 22:41 UTC (Mon) by bronson (subscriber, #4806) [Link] (3 responses)

Ha, that is funny. The reference: https://lwn.net/Articles/660365/

Sharp: Closing a door

Posted Oct 12, 2015 22:42 UTC (Mon) by corbet (editor, #1) [Link] (2 responses)

Funny or not, it's looking to me like it might be about time to close the door on this discussion. I think the important stuff has been said at this point...

Sharp: Closing a door

Posted Oct 12, 2015 22:52 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

while I agree that the important stuff has probably been said, has this been open to non-subscribers? (today it would have come out of the escrow so I'm not sure)

Sharp: Closing a door

Posted Oct 12, 2015 22:59 UTC (Mon) by corbet (editor, #1) [Link]

This wasn't a feature article, so it's been open to the world since it was first posted.

Sharp: Closing a door

Posted Oct 18, 2015 11:14 UTC (Sun) by ksandstr (guest, #60862) [Link] (1 responses)

Well, you could've asked.

Sheesh.

Sharp: Closing a door

Posted Oct 18, 2015 17:45 UTC (Sun) by bronson (subscriber, #4806) [Link]

Are you reading what you're writing? Obviously that applies to you too.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds