Improved Code of Conduct

[imbev]

What's the feature you'd like to ask for.
A more suitable Code of Conduct such as the Ruby Code of Conduct. The current COC is unnecessarily long, specific, and controversial, as seen in the PolyMC and Opal projects.

Additional context
Ruby Code of Conduct (from https://www.ruby-lang.org/en/conduct/):

This document provides community guidelines for a safe, respectful, productive, and collaborative place for any person who is willing to contribute to the Ruby community. It applies to all “collaborative space”, which is defined as community communications channels (such as mailing lists, submitted patches, commit comments, etc.).

• Participants will be tolerant of opposing views.
• Participants must ensure that their language and actions are free of personal attacks and disparaging personal remarks.
• When interpreting the words and actions of others, participants should always assume good intentions.
• Behaviour which can be reasonably considered harassment will not be tolerated.

The Ruby COC is simpler, less controversial, and relatively future-proof compared to the current COC.

[Goldziher]

The Ruby CoC looks good to me.

Note- the current CoC was simply the default proposed by GitHub.

[cofin]

This COC proposal looks good to me as well. This is more succinct that the default COC.

[provinzkraut]

I personally quite like the current COC. It’s simply very explicit about being anti-discriminatory and that the community is "open, welcoming, diverse, inclusive". Being explicit in these regards isn't necessarily a bad thing. It can help signal that a community is a safe space for the explicitly mentioned groups. People within those groups will have often made the experience that places that explicit state they're welcome and protected there are way more often safe spaces than those who only do so implicitly.

On the other hand it doesn't really hurt anyone having a more explicit COC like this.

@imbev What do you think is controversial about it?

I wouldn't have any issues with shortening the "Enforcement Responsibilities" part a bit though, I'm not sure if that's necessary.

[imbev]

I think singling out specific groups might be interpreted by some as exclusive of other groups. As the plight of more marginalized groups is brought to mind, the discussion of whether to include or not may could be reignited each time. There is also the possibility of a rogue maintainer using the COC as an excuse to sabotage the project, similar to what recently happened with PolyMC.

The Ruby COC makes it clear that the community is a safe space for everyone, although I agree that explicit acknowledgement could be reassuring for members of the mentioned groups.

[provinzkraut]

I think singling out specific groups might be interpreted by some as exclusive of other groups

I don't think the way the COC is voiced is "singling out specific groups". It tries to prevent this by not singling out specific groups imho. Sinling out specific groups would be if it said "the elderly, women and Swedes", but it doesn't do that.

the discussion of whether to include or not may could be reignited each time

A vague COC will do just that, but in a different situation. The Ruby COC could maliciously be intepreted in such a way that for example homophobia would be tolerated since "Participants will be tolerant of opposing views.", " participants should always assume good intentions." and "Behaviour which can be reasonably considered harassment". Those all need to be interpreted. Is saying homphobic things that don't direclty attack someone personally just voicing an opposing view? Is it reasonable to consider this harassment?

When you have a COC as vague as this, you'll have to interpret it every time it's being used. It effectively serves no purpose, as it's not something you can quote that unequivocally says that a specific behaviour isn't tolerated. The purpose of having things like this explicitiy in the COC is that you can point at the COC and say "That's not allowed as per our COC, it says to right here", and don't have to say "I'm going to interpret this line in our COC in a way in which you're in violation of it".

The gist is, that a very explicit COC prevents discussions and arguing by removing the need for interpretation.

There is also the possibility of a rogue maintainer using the COC as an excuse to sabotage the project

There's also the possibility of a rogue maintainer using the COC as an excuse to defend their misconduct by arguing that it's not explicitly prohibited by the COC.

the Ruby COC makes it clear that the community is a safe space for everyone

I disagree with this as well. This assumes that the groups mentioned in the current COC are by default included in "everyone", which is not the case. You personally may mean in this way, but not everyone does.
That's why explicitly stating this signals to those groups, that they as well are welcome and protected, and to those who'd rather these groups were not included in "everyone" that this isn't a place that's welcoming of those views.

Lastly, I want to cite the Contributor Covenant FAQ:

Contributor Covenant explicitly lists a set of protected classes; does this make it acceptable to discriminate or make others feel unwelcome based on other factors?
No. Contributor Covenant explicitly lists protected classes for many reasons, such as reminding people to give them appropriate consideration, and assuring people in those protected classes that they are welcome.
However, this is not an invitation for rules lawyers to seek loopholes, or to discriminate against others or make people feel unwelcome based on criteria not listed here. (With the notable caveat that those who discriminate or make others feel unwelcome are themselves not welcome.)

You can't create a COC that's so watertight that it will never cause any friction anywhere, and people with ill intend will always find their way to bring discord into a community. You can decide however on which side you want to err. On the side of potential perpetrators of misdemeanors or on the side of their victims?

In the end, I see no harm in having an explicit COC like this. It will most likely only shy away people who weren't welcome anyway.

[Goldziher]

Well, my 2 cents are that this is a document on GitHub- if its more elaborate or less elaborate it doesn't really matter. We should do our best not go give maintainer access to sociopaths, and in general try to remain on the benign side of life- we are doing open-source after all. Thus, let's not go into too much of an argument over this - I feel that both CoC are fine and reflect healthy approaches to communal OS contribution.

If people feel strongly one way or the other, I am fine with replacing the CoC - but lets keep this in perspective.

[peterschutt]

Thanks for starting this discussion @imbev!

There is also the possibility of a rogue maintainer using the COC as an excuse to sabotage the project, similar to what recently happened with PolyMC.

Its not clear to me that what happened with PolyMC wouldn't have happened with any other CoC - seems like the dude just flipped out. I've only skimmed reddit/ycombinator threads on the topic though, and I'm not a user of that tool, so it was news to me when you brought that up in discord. Is there anything specific that you'd like to point out that puts the Contributor Covenant more squarely in the cross-hairs?

I tend to agree with @Goldziher - one way or the other we are trying to ensure contributors to Starlite feel safe to do so, and I think that either CoC has strengths and weakness to that end. Personally, I haven't seen an argument here that makes me feel we need to change the status quo, but I'm always welcome to having my mind changed.

An argument I'd make in favor of the Contributor Covenant is that it appears to be adopted by a lot of organizations/projects and there are translations and a FAQ that we can use if we need to. Given that we are still a small group of regular contributors, thinking of Contributor Covenant a little like CoCaaS appeals to me.

[imbev]

Considering provinzkraut's greater stake in this project and the reasons above, I agree that staying with the status quo is a reasonable decision.

Thanks for taking my request under consideration :)

[comradekingu]

@provinzkraut
The current one singles out people for immutable characteristics. In terms of cognitive behavioural therapy,
that is dangerous, and the complete contrary to the most potent societal tool in the box.
If for example the Ruby community was any better than that of others, maybe their text-file would have merit.
I happen to think it does, but largely because it isn't codifying behaviour, or requiring anyone to pledge allegiance.
There is no implemented way of knowing if anyone actually agrees anywhere, but that was never its point to make.
@imbev It doesn't actually do the same things, and so it neither is nor is called a "code of conduct". Would you agree?

Insofar as the default GitHub click-to-make-button-green text-file goes, it was made by someone working at GitHub,
that later got fired for not being inclusive. It is a horrendous document that could never make it into a license.
Not that the person making it didn't also try that, but it is just the opposite of welcoming.
GitHub itself doesn't use it, but GitHub has other rules. Nobody ever knows, because nobody cares to find out.
No safe space is created, and from studies conducted they don't even work.
There are so many other venues of actually communicating that people are welcome to be human, and this is the opposite.

The interpretative part is always to identify behaviour and making sufficient actions that are hopefully mutually beneficial.
In the greater sense, especially the current text-file doesn't do that. What it does do is provide some impetus that was there already.
Similarly, misinterpretation by maintainers is always possible.
What the text-file actually does is undermine meritocracy, by way of authoritarianism.

[imbev]

After searching, I found that the author of the current Code of Conduct is an anti-meritocracy activist and part of the counter-FOSS ethical source movement. According to the author, the CoC is a political document (https://twitter.com/CoralineAda/status/1041465346656530432?ref_src=twsrc%5Etfw)

Here is an article with information on the controversy that it caused to the Linux kernel https://itsfoss.com/linux-code-of-conduct/

One reason why I prefer Starlite to FastAPI is that Starlite is focused on code quality, not ego. I am now concerned that the current CoC may be unfairly weaponized in the future.