The kernel's code of conflict

Fedora too.

branden, my sentiments exactly.

So far everyone in the kernel community has been exceedingly helpful and friendly to me. I must be doing something wrong.

> This development process [is wonderful and doesn't need to change]. If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable.

> It puts the onus on those who are not treated fairly, whereas it should begin by stating the responsibility of reviewers and maintainers to treat others fairly. It also doesn't address the possibility of harassment of other kernel community members outside of a review process.

I agree completely; that's a bug. Put that together with the very heavyweight process for actually raising a complaint, and I doubt that any of the direct targets of abusive mails will end up gaining much value from this document.

On the other hand, nothing in this document prevents others involved in the community from raising such complaints in response to such behavior, even if they're not the target. In particular, the next time (and sadly there probably *will* be a next time) that some high-profile kernel maintainer decides to be a terrible person on LKML, anyone on LKML can and should actually exercise this process. Preferably making it clear afterwards what result they obtained from the process.

The first time someone does so, we'll find out if this code actually works.

That's the one reason I felt like this was a sufficiently non-zero improvement to ack it. It's by no means a sufficient code of conduct; it fails several of the standard tests for effective codes of conduct. But at best it might actually provide a channel for curtailing some of the abusive mails in the kernel community, and at worst it's no more ineffectual than not having a code at all.

BenHutchings, submit a patch? But maybe we should wait for some test results first.

Raven667, I agree with you completely. Incivility and rude behaviour are allowed and expected in war. But this isn't war; this is communal cooperation. And no community will long stand when one group of its members appear to strive to keep most members at each others' throats.

If submitted code stinks, say it stinks, explain why it stinks, and offer suggestions how to make it less smelly. In other words, take the opportunity to teach someone who probably wants to learn. People who have spent a lifetime learning and perfecting have a duty to pass along what they've learned to a new generation, and have a duty to recognize when they need to take a break from answering the same questions day after day, month after month, year after year, when the questions come from newbs who want to learn, who try to learn, who want to contribute to the community.

In a sentence, it takes a lot more energy to build than to raze. Build anyway.

Your hesitation is warranted, otherwise you would be misreading.
Every time you try to legislate that it is only a matter of time and you see
the poisonous effects of it. There are loosers only.
You do not want to be treated like crap, act accordingly. There is a good chance you will find support from others, unexpectedly.

The kernel's "code of conflict" is an act of deliberate laziness - passing
a problem to other people and expecting them to find a solution to YOUR
problem.
You could not work it out in your all wisdom, but you expect it from
others.
And if that leads to more rules, laws, and bylaws the better for everybody.
Really ?
Do you remember the convoluted Debian TC process regarding systemd adoption ? Pretty scary.
So, now you want to have a replay of that at Linux Foundation ?
In other words, the initiators of this idea placed a stinker in
Foundation's courtyard.
And the peanut gallery will enjoy it greatly from now on.

I think it's no coincidence that your proposals (which I agree wholeheartedly with) read a bit like "Postel's Law": "Be conservative in what you do, be liberal in what you accept from others".

After all, it's a protocol what we're trying to establish.

Being black and British I refer to myself as a Black Briton. You can carry on the discussion now...

There is no practical need to discuss race on the kernel list, so no need for any such distinctions. If only that were true everywhere...

It clearly won't be enforced because there is nothing to enforce.

It can't be really enforced on a legal basis.

That's exactly why I didn't add my Ack to this. I believe that adult people should be able to resolve conflicts on their own, I don't really see this document providing any help in that respect.

Of course, things like life threats need to be taken very seriously. But should that happen, official authorities need to be involved anyway, TAB doesn't really have any powers there.

Which is wonderful for those who are assertive in-person, [are invited,] and can afford it.

Yes, we were. My reasons for not ACKing that thing (and I'm actually surprised that it wasn't the most common reaction): no examples whatsoever of TAB actually doing that kind of mediation - unsurprisingly, since it hadn't done any yet.

<viro> FWIW, what makes me somewhat nervous about it is that it covers everything from "... and that address routes to /dev/null (and I endorse that)" to "... and a crew with baseball bats will descend on the offender to explain the error of his ways (and I endorse that)"
<viro> thus the question about the examples of previous mediations in such situations

which got basically, "understood, but we really have no examples yet" in response. I don't like signing off on something _that_ vague - not because I expect either of the variants I've mentioned to materialise, but because there's a whole lot in between and I won't blindly endorse the entire range.

My reading of that thing is "Not everything is a flame, but if you feel real bad - send complaints to $ADDRESS. Try to trigger fewer complaints". What's missing is any information about the handling of such complaints - not just how anything could or could not be enforced, but much more basic "how does TAB end up dealing with such cases". And consisting of well-meaning folks doesn't cover it, obviously.

No examples to judge by - no ACK...

> You have a point, but I cannot imagine a public discussion on this sort of
> patch being at all useful. It is not like code that can - to some extent -
> be objectively measured. You'd end up with endless bike-shedding and
> little progress.

Yes this is a topic with a high flamewars potential. But that alone is not a reason for doing things behind the scenes IMO. Once there would be a sufficient Acked-bys then the patch would be justified for merging. Besides that any NAK would have to be justified properly as well ("I do not think this would help" argument doesn't fall into that category).

It would be quite natural to ask whether all changes to this document are going to be handled in the same way because by the flmatory nature will not change most probably.

> The non-TAB individuals who gave their 'Acked-by', didn't get to discuss
> or revise the wording. All we got was the opportunity to publicly
> support the TAB in this initiative

TAB is a technical advisory AFAIK and my perception is that issues mentioned by the document are not technical by definition.