Skip to content

Comment on Code first. Be professional. Leave politics at the door

Comments

I don't think the author is some mustache-twirling villain, but I do think the tweet is a case study in creating vague, subjective rules that will -- assuming a project lasts long enough and attracts enough contributors -- end up being enforced more or less by whim.

- No politics in open-source (left or right)

I sympathize with the desire here, but if you're being honest about this it is intrinsically self-defeating, as the definition of what constitutes "politics" is, itself, political. (I do not know anything about the author and am not accusing him of anything here, but I'll note broadly that -- in my experience -- many people who claim to want to keep politics out of discussions are interested only in keeping politics they disagree with out of bounds.)

- No COC, language policing, political banners, or any other divisive and inherently political symbols and tools of power

"No politics" is, itself, a COC. Beyond that, we have a mish-mash of vague and subjective restrictions; who, for example, decides what is or is not "language policing"?

- No consideration for conduct in other communities; whatever they said on X or BlueSky is irrelevant

Really? If Alex and Bob are contributors on the project who get into an argument, and Alex goes on Twitter to call Bob a pedophile and dox him, you're saying you won't take that into consideration? What if Bob comes to the project leadership and says he's done contributing unless you ban Alex? Are you actually going to keep the scumbag who doxes other contributors over the person he doxed? I agree that we shouldn't be mining people's social media feeds looking for one off-color comment to justify banning them, but saying that any behavior in other communities is outside of consideration is shortsighted in the extreme.

- Speech and conduct within the project should be professional and focused on the goals of the project

I thought we weren't language policing? I thought we weren't writing a COC? This just feels like a vague, subjective combination of both. (Despite that - this is at least the one point I find most agreeable of the pack. I wonder why the author felt they needed anything else.)

- The only valid reason to ban someone is because they are making MORE work for core contributors than their contributions justify (if Stalin wants to submit a good PR, merge it without fuss)

Sounds great on paper; what will you do if 10 prolific contributors who are responsible for, let's say, 50% of all contributions come to you and say "we're done with this project if you merge the Stalin PR"? Are you going to endanger the future of the project in the interests of staying apolitical?

- The only valid reason to moderate is because someone can't respect the above, and in such a case, the moderator, moderation decision, and moderated content should be transparent to guard against abuse

This at least is broadly agreeable, but I have to note here that transparency does not intrinsically guard against abuse -- it makes it more visible, perhaps, but unless there is a process for responding to abuse and removing abusive moderators, visibility itself does precious little. Further, even if such processes do exist, the lack of a formal COC in favor of vaguely worded guidance creates enough ambiguity for abuse (eg selective enforcement) to run rampant.

My advice: if you're starting an open source project, start with the rule "don't be a dick," and enforce it yourself. In the extraordinarily unlikely event the project becomes large enough that you need a staff of moderators, bite the bullet and write a real COC, because otherwise you will spend huge amounts of time wrestling with uneven, biased enforcement and difficult, subjective appeals.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.