Hacker News Reader

Comment by olavk | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com