On Mon, 15 Jul 2013, Sarah Sharp wrote:
The people who want to work together in a civil manner should get together and create a "Kernel maintainer's code of conduct" that outlines what they expect from fellow kernel developers. The people who want to continue acting "unprofessionally" should document what behaviors set off their cursing streaks, so that others can avoid that behavior. Somewhere in the middle is the community behavior all developers can thrive in.
By defining your viewpoint as being "professional" and the other viewpoint as being "unprofessional" you have already started using very loaded terms and greatly reduces the probability of actually getting the other group to agree and participate.
As has been said elsewhere, almost all the attacks are against code, not people. There are occasional outbursts at the more experienced/trusted people along the lines of "you should know better than to do that", and while there is heat there, there is also a lot of truth. If those people can't be trusted not to do the wrong things, then we are back to the time when Linus had to review every patch himself and we hit that wall quite hard.
People do need to be called out on their mistakes. In companies, if you don't fire managers who do the wrong thing soon enough, it can ruin the company. In kernel development, you have a very large number of observers and if they don't see people being corrected for doing the wrong thing, they will emulate it.
I find that frequently the most educational discussions to read are the 'heated' ones, they are the ones where the 'right' and 'wrong' processes are most clearly explained, not just in terms of what the processes are, but also the WHY of the process being 'right' or 'wrong'.
If Linus just snaps at someone and they say 'oops, missed that', it's no big deal for anyone. But when a full argument/discussion takes place, a lot more people learn and apply the lessons to their own work.
David Lang -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html