The kernel's code of conflict

acks are sent *before* the commit, presumably Linus (and others) had ample opportunity to give theirs in time...

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

> 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.

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.

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.

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

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.

<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...

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.