4 ms·

I believe the biggest worry is that the CoC is loosely worded, but gives lots of power for removing people from the community that don't abide by the too-loose

I believe the biggest worry is that the CoC is loosely worded, but gives lots of power for removing people from the community that don't abide by the too-loose rules. This leads people to fear that contributors, some of them long-term, may be removed because of things like political views, even if they don't come up in a mailing list discussion, or if they were said by the person 30 years ago on Usenet. A lot of other people feel it wrongly shifts the focus from code-quality to political correctness and feelings, which are far harder to measure objectively. See paragraph 1.

jf- 8y ago
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.
- deleted 8y ago
  [deleted]
- geofft 8y ago
  "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.
  - jf- 8y ago
    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.)
    - deleted 8y ago
      [deleted]
    - TheJEB-AK 8y ago
      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".
      - geofft 8y ago
        So what do you do in the unlikely event that someone who's a target of the racism is interested in contributing to the project? Does "shut up and hack" apply to telling them to keep their racism to themselves? (I realize you didn't say anything about racism, but you replied supportively to a comment about it, so I'm not sure where you stand.)
        jf- 8y ago
        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.
        geofft 8y ago

jf- 8y ago

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.

deleted 8y ago
[deleted]
geofft 8y ago
"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.
- jf- 8y ago
  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.)
  - deleted 8y ago
    [deleted]
  - TheJEB-AK 8y ago
    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".
    - geofft 8y ago
      So what do you do in the unlikely event that someone who's a target of the racism is interested in contributing to the project? Does "shut up and hack" apply to telling them to keep their racism to themselves? (I realize you didn't say anything about racism, but you replied supportively to a comment about it, so I'm not sure where you stand.)
      - jf- 8y ago
        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.
        geofft 8y ago