Prevent potential CoC abuse

[srid]

I believe I speak for everyone when I take "harassment-free experience," as delineated in this CoC, to include harassment based on political beliefs (conservative, liberal, libertarian, etc.) as well. This PR explicitly includes it, to prevent any potential abuse of the otherwise excellent CoC.

For reference, compare with Microsoft Open Source Code of Conduct which already handles this, viz.:

Our communities welcome and support people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.

(emphasis mine)

[sjakobi]

Thanks for bringing this up!

I'm admittedly not very experienced with regards to different codes of conduct. Do you happen to know why political belief isn't included in the Contributor Covenant CoC (which this CoC is derived from)? It seems like an interesting omission.

[srid]

@sjakobi Here's some background reading: https://phil.tech/2016/09/15/codes-of-conduct-maybe-theyre-not-so-bad/

Reading that blog post I realize that Contributor Covenant has made revisions to mitigate this abuse:

Contributor Covenant has had a bunch of changes to it since that incident. Now it has a whole chunk in there about "Scope", which explicitly states people have freedom to post on their own social media and things not representing the project.

This is good, and probably "good enough" for some people (including me, as I don't talk politics in a project environment, and perhaps also Charles Max who got kicked out of a Linux Foundation event after it was made known that he publicly wore a MAGA hat).

However, mitigation is not prevention. I have worked with coworkers with the habit of talking politics at work; if they don't know any better (and with no "don't talk politics at work" rule enforced by the organization) they could easily get into trouble.

---

When Gabriel added this CoC back in November he stated his intention to "test drive the code of conduct" in this project first, before he will propose a CoC for dhall-lang in its entirely.

So here you go: a piece of feedback for this test drive.

There are arguably better CoCs than Contributor Covenant. Those which explicitly avoid abuse potential like this and emphasise the importance of being friendly and respectful up front. The Microsoft Open Source Code of Conduct is good in this respect, but my personal favourite is the one written by Shriram Krishnamurthi (he explains why here).

[sjakobi]

Thanks for the background info! :)

So the potential abuse you're concerned about is that someone (person 1) would demand that someone else (person 2) should be excluded from the project because person 1 disagrees with the political beliefs of person 2!? Is that a somewhat accurate summary?

[srid]

Yes (within scope). The blog post mentions a real-world example of that.

[sjakobi]

OK. I'm inclined to accept this change, because I believe that it would be nice if this project could be a place where people collaborate regardless of their political beliefs, especially in these politically divisive times.

What do other contributors think about this change?

[Gabriella439]

@srid @sjakobi: I'm fine with this change. In my eyes, if that sentence already mentions "religion" then it is fine to also include "political belief" since I view both of them as being in a similar grey area. Specifically, both religion and political belief are risky in the sense that they can be used to justify intolerance towards others and risk running afoul of other provisions of the Code of Conduct.

My interpretation of the Code of Conduct is that religion and political belief are protected classes insofar as they don't conflict with the rest of the Code of Conduct.

To further clarify things: suppose that I wanted to exclude contributors who subscribed to a specific policy (such as supporting ICE, as an example). In such a case, I'd amend the CoC to explicitly enumerate the exclusions, both to avoid ambiguity and also to hold the exclusion accountable via the peer review process.

If you have a specific test case that you'd like me to weigh in on to clarify then I'd be happy to do so, otherwise I'll merge this change tomorrow.