Hacker News new | ask | show | jobs
by Symbiote 264 days ago
Eric's suggestion for a CoC:

> "If you are more annoying to work with than your contributions justify, you'll be ejected."

is not unreasonable (whether written down or not) for an individual's hobby project, but for something run by a company or other organization I think more detail is required.

The OSI code of conduct seems too general, perhaps open for different interpretations or potentially selective enforcement: https://opensource.org/codeofconduct

The Linux one I prefer, since it's concise and clear, e.g. "sexualized language" and "harassment" are unacceptable: https://docs.kernel.org/process/code-of-conduct.html

My own employer's code of conduct (we have open source projects, discussion forums etc) looks similar to the Linux one. I think it is enforced about once a year, and I think the reason has been either sexual harassment or repeated personal criticism of individuals' work.

2 comments

Everything can be selectively enforced and open to interpretation.

Good questions are: What purpose does a CoC serve? How does it help?

In most, if not all cases, they are not very helpful beyond, indeed, politics and drama because they turn into a weapon (on the assumption that this wasn't the aim all along).

When a CoC is pushed by a company I think it's probably because companies need company policies for employees for HR and legal reasons. I am not convinced they could explain why that must extend beyond that, and really this is an ass-covering exercise in case things get too "raucous" in the project and produces bad PR.

> What purpose does a CoC serve? How does it help?

At work I think it has helped since we now have a clear procedure to follow if there's a problem.

Having the Code of Conduct be a public document rather than only an internal one means there are fewer excuses available for not following it — for example someone can't claim they thought it would be OK to ask a developer for sex since we wrote down that that's not OK.

It's also easier to explain in case the problem individual is employed by a paying customer.

>someone can't claim they thought it would be OK to ask a developer for sex since we wrote down that that's not OK.

The person who thought this would be okay will not be stopped by a Code of Conduct.

The people who know it's not okay don't need a Code of Conduct.

The whole thing is useless. This is the same retarded shit as people stating their pronouns, trying to engineer every social human relation.

Don't be a jerk with people. If someone looks a certain way, it would be kind to assume they want to be treated in a certain way, etc, etc. You don't need terms of conduct and similar bullshit for that.

> > "If you are more annoying to work with than your contributions justify, you'll be ejected."

I'd argue that this is unreasonable for any project large enough to need a CoC at all. What it amounts to is excusing misconduct by project insiders, while allowing them to drive off new users by declaring their behavior 'annoying'. This isn't a code of conduct at all; it's a formalized "old boys club" dynamic.

You are correct, thanks for the explanation.
An OSS project has de facto owners and an established group of contributors. If they want to "drive off" new users that's their prerogative.

In fact, a CoC is no more than them laying down the law explicitly on how they want people to behave in the project.

"If you are more annoying to work with than your contributions justify, you'll be ejected" is spot-on on how things work in general.

That might lead the project to fail or fork (beauty of OSS) but that's life.

It also establishes that the project is a meritocracy, which is not necessarily something that every project wants. (And from a personal point of view, many meritocracies seem pretty toxic to me.)
> it's a formalized "old boys club" dynamic

There's a risk that this happens, sure, but it can be more charitably read as allowing/retaining people like Steve Jobs or Linus Torvalds, who, despite being assholes, are effective assholes and usually spew vitriol only in the interests of the product itself.

Weighing annoyance against contributions is a valid methodology. Your concern is valid, as well, so governance should always be introspective enough to ensure that the metrics of "annoying" and "useful" are objective ones and don't grandfather in the insiders.