I see. I agree that any such code of conduct should be limited to communications involving the project directly, and be the minimal set of rules necessary to ensure civility.
"Communications involving the project directly" is a good goal, but is ambiguous when e.g. one developer is belittling another in a semi-related forum like their personal Twitter account where they regularly have technical conversations, their HN account, etc. If (hypothetically) Linus were to be nice and polite on LKML, and reply to tweets about bugs saying "Yes, that's a bug, the developer should be retroactively aborted," I think we'd still not have solved the problem of people not wanting to contribute because they don't want to subject themselves to that.
I do agree on the other hand that digging up 30-year-old Usenet posts would tend to just get everyone in trouble and a code-of-conduct process should ignore them, or at most provide ample opportunity to distance oneself from those statements and then go with what's said today.
My preferred solution is to make sure the party handling the code of conduct process is someone who seems level-headed and likely to use their judgment well. It means you move away from codified rules, but it also means rules can't be gamed. For Linux the enforcement body is the Technical Advisory Board, which I think is a little weird precisely because it's a technical body and not necessarily a good-at-people one, but we can see how it goes. For small projects the enforcement body is typically the project founder, and if you don't think the founder will handle things reasonably, no code of conduct can make them trustworthy.
Your example isn’t that ambiguous, that’s a public communication directly about the project. That should be covered by the CoC.
However unrelated statements, even very politically incorrect ones, should be outside it’s remit. If for example someone was a virulent racist on twitter. That’s arguably a bad thing, but those statements are unrelated to the project and should have no bearing on contributions to it.
(Now that’s going to be an unpopular sentiment. Downvotes ahead.)
No downvotes from this guy here. I work with some terrible engineers who I wouldn't trust to design a tire pressure gauge but they're pleasant to be around. On the other hand, I've worked with world class engineers who are abrasive as hell but still write/design good gear. Code shouldn't have a thing to do with their political leanings. To quote an old OpenBSD saying: "shut up and hack".
Then you’re into territory where the CoC controls everything that a contributor says on every platform, as another contributor can always claim some indirect harm.
Always? All sorts of speech cause indirect harm to someone, analogous to "virulent racism"?
If that's really true, doesn't "shut up and hack" apply all the more? If you really cared about the code, you could keep your political opinions to yourself.
(Also, this is precisely why many codes of conduct define the exact harms they care about - so racism is an excluded harm, but, say, making Hans Reiser feel bad about being a murderer isn't. If you're a fan of racism, you might use this as an indicator to avoid the project and find another one, or fork it under the license.)
Which is all just censorship by the back door. With the possible implied accusation of racism aimed at me. I’ll spare both of us the usual freedom of speech rationales, I assume you’ve heard them before. It seems from your posts that you personally really do wish to use CoCs as a tool of wide-ranging ideological enforcement, exactly as their detractors fear. Or have I misinterpreted you?
However on forking I do tend to agree. There appears to be an audience for projects with less controlling, or less ideologically intended rules. These projects should be formed and developers should make their own choice between them.
reply