Your "polite" has moved way too far into manipulative / passive-aggressive with weasel words like "I see" and "in its current form". If you are in a position of power like Linus, where your perception is the project's reality, couching such realities as if your perception is the only problem will lead to fights and a lot more resentment. Just saying, "Thanks, but I won't accept this until X, Y, and Z are corrected," is still polite, but also gives a clear course of action for the recipient. And yes, some people read directness as rudeness. You can't help them.

Why would you start fighting and/or feel resentment if you received a reply like the "polite" example? Genuine question, I don't see the issue but I'm ready to learn.

Not the parent - but I think it's because it can be seen as too subjective and too open for debate. Like: Oh, so one person opines that x, y, and z are not for them, let's debate it (or outright dismiss it).

And the resultant debate might well be polarising or destructive by itself.

Without knowing what the parent experienced to cause their take on this type of politeness I'm just guessing, though.

It is interesting because I think I see a cultural thing here too: in some cultures "I feel" and "I see" and "currently" are as firm as "unacceptable until it changes" - just worded in a way that conveys respect for the author. But in other cultures it is read as vacillating. Dunno. Guesswork, as I said.

Spot on :)

As I said, some people will interpret directness as rudeness. Those are the ones that expect for the language to be couched. But, in my opinion, it's better to be seen as occasionally rude than allow for those other negative behaviors to occur.

It's not a direct decision to fight. It's more that the weak language opens the possibility of action where none really exists.

What they see is a chance to convince you ("I see...") or refactor ("... in its current form"). What you see is someone who is being stubborn and just not making the changes. So, it leads to a lot of friction and talking past each other.

I guess this depends on the context, but I don't really see the problem. If I reject a patch due to some specific problems with the code, then surely I should reconsider if the submitter could refactor to avoid the reasons for rejection? And if I was actually wrong about X, Y or Z, then I would like to have that pointed out. Everybody can make mistakes.

Nothing about saying, "Thanks, but this won't be accepted until X, Y, and Z are fixed," precludes having a conversation. By all means, if you think X is not a problem, I would expect a response along the lines of, "I don't think X is a problem because insert mitigating factor here." Or, perhaps, "I don't understand the issue with X; could you explain?" In other words, allow directness to beget directness. Enumerating all the possible ways you might be wrong, just in case one of them is actually true, seems silly to me.

In any case, using phrases like "thanks, but..." is an example of politeness.

I don't understand this... I used that exact phrase in my original response, calling it an example of being polite, but without passive-aggressive or manipulative weasel words.

I wanted to get back to my main point which was not the particular turn of phase in my example, but just that politeness have nothing to do with incompetence. This was in response to the comment that stated that politeness would mean accepting bad code, which I strongly disagree with. You show that a patch can be rejected with a polite and still technically relevant on-the-point message, so we agree about the important point. I don't think politeness implies passive aggressiveness either, so my example sentence might have been badly chosen.

Anecdotal, but I'd enjoy feedback in that "polite" form.

Of course, it might also depend on that person's reputation and my previous interactions with them. If I have had 50 negative interactions in a row with them, getting such feedback might make me want to throw my laptop into the toilet.

But in most cases I think it would be a good way to phrase feedback.

my understanding is your politeness would be interpreted in essence as saying that the issues are subjective rather then objective. when later in the process this is revealed to not be the case, this will lead to friction: hence fighting and resentment

I think it depends a lot on the context. Some examples:

- Someone injects an obviously inferior idea for political reasons (e.g. the recent TLS 1.3 debate). Then, a rude response might be your best option to deter the opponent. I think, some of Linus's attacks from the past fall in this category.

- Someone is just inexperienced and proposes a bad idea with good intentions. Then go for factual "This is flawed, here is why".

- Someone proposes an idea with flaws, but you see potential beyond the current proposal. Then, one should politely point out the current weaknesses, and at the same time encourage the proposer to improve on it.

As successful leader, you need a repertoire of responses.

For someone acting in bad faith (e.g. trolling, deceptive agenda) insults are probably justified. On the other hand, this is probably the actors who are not really deterred by insults, so I wonder how constructive it is.

>So you are equating politeness with not halting bad ideas. That is not politeness, that is incompetence.

In some cultures, direct comment on an idea is the norm, but in others it might be very rude. Even engaging in what you might find to be polite critique can be a challenge; even the most well intentioned comments might not transit cultural boundaries unscathed.

Worse, there might be some context you're missing that causes you to trigger someone without any intent to cause offense.

Example:

A new, senior developer transfers to my team. He puts up a CR and asks me for review. As I comb through it, I find a couple small bugs and take the time to explain why they are bugs, thinking perhaps he did not understand a subtlety in a library we are using. This same library has tripped up a number of developers on occasion, as there is a state that is being manipulated, but under certain circumstances it can be put in a state that is not intended. It's part of a language standard library and not something we can wrap in a safer way, sadly.

He apparently knew about it but just didn't account for it, and he took my explanation to be very patronizing and condescending, given that he already knew the problem. He then read into the rest of the review a hidden malice.

This is partly my fault; perhaps I didn't need to fully explain how the function works, though with the misuse I thought it could be a chance to teach. I probably should have taken more care in some of my verbiage; I tend to be somewhat direct, which comes across stronger than I intend it to. Not "You're a moron, delete this bad code" but more "This function call will not do X, Y, and Z. It will do W instead. Why not use ABC instead?"

Well if there actually was a bug, as you state, you are clearly in the right to point it out. Both parties in a communication have a responsibility. The party criticizing the code has a responsibility be factual, concrete and constructive, and to only criticize the code, not the personality of the author. The recipient of criticism on the other hand have the responsibility to listen and not become defensive or take criticism of the code personally.

Personally though, it also really irks me when someone carefully explains me something I already know, so I understand the mindset.

> only criticize the code, not the personality of the author.

Hence denying the author the possibility to improve. Eventually the author will be let go, and they will have no idea why or what they did wrong.

This is called "being polite."

If you criticize the code by pointing out factual issues, then the the author can lean and improve by understanding these issues and improving the code. Calling the author an idiot does not help to improve anybody.