Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

David Lang
2013-07-16T07:32:53Z

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