Upstreaming your code - a primer [LWN.net]

Do not write excuses for acting like an ass

Posted Jan 16, 2011 21:35 UTC (Sun) by neilbrown (subscriber, #359) [Link]

Maybe the article has been updated since you read it, but I could find no reference to rude answers. Only "very terse, or seemingly irritated".
In those cases it is very possible that the developer is not meaning to be rude, but someone who doesn't know them well, or does not understand the dynamics of email, could interpret the response as being rude. This is a very important issue that a document like this *should* discuss.

Do not write excuses for acting like an ass

Posted Jan 17, 2011 17:16 UTC (Mon) by jmm82 (guest, #59425) [Link]

In my experience some developers are "terse" and others are blatantly "rude", but to a new-comer it all appears as rude.

I think this is only a subtle distinction noticeable by the seasoned veteran. Maybe "terse" developers should consider they could be falsely viewed as "rude" by new-comers if they really care..or just be "rude" and stop trying to pretend they are not.

I personally see the wisdom behind being rude. It weeds out the weak programmers who are more likely to write code, dump it, and then walk away. Also, I see the wisdom in being polite to newbies. The more programmers the better in theory open-source code becomes.

Do not write excuses for acting like an ass

Posted Jan 17, 2011 9:14 UTC (Mon) by farnz (guest, #17727) [Link]

So why are you engaging in rudeness on LWN? Have you discussed this with the article authors, or are you merely insulting them behind their backs? The mere need for me to ask this should show just how rude and arrogant you are being. The preceding sentences in this paragraph are illustrative, not serious.

More seriously, as someone who watches the LKML and netdev (I assume other high-traffic Linux lists are similar), genuine rudeness for the sake of it is frowned upon. There are some classes of behaviour that are accepted by LKML that can be seen as rude, though; I've noticed three:

The "you can't just duplicate functionality" responses; e.g. the recent attempt to submit a second driver for USB 3.0 UAS devices. It might be better, it might be worse, but the kernel community is being shown two large chunks of code for devices for which most of them lack hardware, and having to make a judgement call about which one to support; one's already upstream, and maintained albeit slowly. The other is coming from a new person, who can't explain why their code is better on a technical level, and refuses to patch the existing driver in a long patch series, instead stating that it's take their code as a lump or lose it. They feel that the kernel devs are being rude about their engineering skills by saying "why can't you just fix what we've already got".
The "you can't regress userspace like that" responses; e.g. the ongoing pile over changing the OOM killer. Fundamentally, the "establishment" are worrying about whether there's an unknown out there that depends on the current interface; they're perceived as rude because they keep coming back to this argument, no matter how often the people changing the OOM killer and associated exposed interface try and claim it's no longer a problem.
The "we've had this discussion before, more than once. Please look it up on your favourite mailing list search, and don't come back to it unless you have something genuinely novel to bring to the argument." responses (e.g. the recent pile around krefs). It's obvious why these are seen as rude; if you've not been following LKML, the old history is new stuff to you, and being told to catch up on the rest of us before you post implies that you didn't do enough research.

It's an ongoing problem; the worst of the gratuituous rudeness has gone from LKML, but there will always be behaviour perceived as rude, because LKML et al expose engineers to external criticism over which they have no control - .if I'm a senior engineer in house, I can silence a lot of criticism with "I know what I'm doing, and you don't". That doesn't work on LKML, and some people just don't cope well with it.

Do not write excuses for acting like an ass

Posted Jan 18, 2011 17:29 UTC (Tue) by pboddie (subscriber, #50784) [Link]

So why are you engaging in rudeness on LWN?

I don't think what was written can be considered rude. It's completely possible for people to regard terse, irritated responses as rude even when rude words are absent, not because the person taking offence is some uptight corporate-hierarchy type who can't take criticism, but frequently because they may perceive an attitude from the people representing a given project along the lines of "your insubstantial contribution is not worth our consideration", which would probably bother anyone who has spent time working on such a contribution and then having to try to adhere to all the technical (and frequently political, social or organisational) requirements of submitting that contribution.

When open source projects try and attract contributors there's often some kind of realisation that willing contributors should be helped in getting their contributions into a form that is acceptable to the project, and not along the lines of "you have made a spelling mistake in your essay, so I have burnt it and you will need to write it again". There's also the realisation that willing contributors really want to make the project better and can have genuine, if modest, contributions, and are not merely "trying to bask in the glory of our already highly successful project" - how the attitude mentioned above can be considered in a more extreme form.

Of course, some projects aren't bothered about attracting contributors or even alienating the ones they already have, and are therefore not likely to arrive at such realisations by themselves.

Do not write excuses for acting like an ass

Posted Jan 19, 2011 15:41 UTC (Wed) by farnz (guest, #17727) [Link]

You'd be surprised; I've worked with people who would consider kju's statement as written the height of rudeness (definitely worth trying to get someone fired over), because it's expressed as "you have done something that you should have known was wrong".

In a document discussing the process involved in upstreaming something, reminding people that they should try hard to not take offence is no bad thing; there are always people who will take offence where none was actually meant, whether because something was badly phrased, or because they're sensitive to particular triggers that the other party is unaware of.

This doesn't excuse people of their social responsibility to not cause offence whenever they reasonably can, but does explain why you must make excuses for rudeness in a document talking about how to interact with a community - you want to remind people who are only used to interacting with deferential colleagues who know what their triggers are that upstream doesn't know you personally, and that you are not yet a proven engineer to them, merely one more person with code.

Upstreaming your code - a primer

Posted Jan 21, 2011 13:43 UTC (Fri) by dmag (subscriber, #17775) [Link]

> advice such as "Please don't take offense[..]" is only reinforcing and perpetuating unhealthy community norms

I think the truth is somewhere in between.

- It's a fact that most submissions will have something major wrong with them. (dup functionality, too narrow, hard to maintain, too intrusive, ignores performance/security/future plans)

- It's a fact that most people get upset when they hear "No, we will not incorporate your code [until it's fixed]".

- It's a fact that it takes longer to write a nice note explaining exactly why the developers don't like your code ("well, in 2005, so-and-so tried that approach, but found these problems..", compared to just summarizing the reason ("we tried that and it won't work").

It's hard to prove, but I believe it's better to let people tell the unvarnished truth ("your code is broken because it doesn't handle this case") than try to be politically correct ("Thank you for your excellent submission. We are sure this code is destined for mainline inclusion! However, there is one small issue: the code does not work in the following areas, and may need major restructuring to handle that case.")

So saying "don't take offense" is sound advice.

The question is: Do we cater to the needs of newbies submitting code to the kernel, or to experts maintaining the kernel? I'm OK optimizing slightly toward the experts, because if you go too far to the newbies, the experts will simply leave.

Upstreaming your code - a primer

Posted Jan 21, 2011 15:20 UTC (Fri) by bfields (subscriber, #19510) [Link]

I believe it's better to let people tell the unvarnished truth ("your code is broken because it doesn't handle this case") than try to be politically correct

Agreed, but are those our only choices?:

("Thank you for your excellent submission. We are sure this code is destined for mainline inclusion! However, there is one small issue: the code does not work in the following areas, and may need major restructuring to handle that case.")

I think you're gone well past politeness here, towards buttering-up; if you leave out the "excellent", the (presumably inaccurate) second sentence, and the immediately contradicted "small" and "one issue", you get: "Thank you for your submission. However, the code does not work in the following areas...."

The result strikes me as polite but unvarnished.

There's no conflict between the two: you can acknowledge the effort to contribute while still being frank about its flaws.