[RFC 0114] Code of Conduct for NixOS Community

[jonringer]

A lot of the recent heated discussion around #98, #102, #111 highlights a lack of alignment in how the community should participate with others.

This also overlaps with the goals and value section of #98

Rendered

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/moderation-is-not-leadership/15750/19

[Profpatsch]

I would see a CoC as a precondition to #98

[7c6f434c]

I would see a CoC as a precondition to #98

I think #98 is expected to include some part that would serve the same purposes as a CoC. (I also think a significantly updated version is coming there, so I won't guess about details of the future revisions)

[samueldr]

My main thought about the topic of rules lawyering is not that we should prevent it from happening to prevent it from being abused, but to prevent it from happening to prevent straining the community and moderation people.

In other words, my fear is that bad actors™ may be incentivized by easily gameable terms into causing harm by needlessly exploiting it as a form of DoS (Denial of Service), and not as a backdoor for bad behaviour.

NOTE: these are my vague thoughts about rules lawyering. I am not judging whether any terms are exploitable or not in these.

[fricklerhandwerk]

Well, explicitly forbid DoS then and politely note that moderators are a finite resource to be treated with care and respect (who will rightfully silence you if you don't get it).

Is there any concrete objection to merge this? Any real show stopper? Anything that cannot be amended when practice raises the need?

[7c6f434c]

Any real show stopper?

This has a hard promise to exclude from communication people who harass anyone. With a definition of harassment that includes «delberate following» including «online», and without clarification.

I continue to follow a «words have meaning» value system. If the text if taken seriously and literally promises to excommunicate for subscribing to someone's RSS — either we have a problem, or, more likely, nobody has ever cared what is actually written in the text.

No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a ommunity member, please contact one of the channel ops or any of the NixOS moderation team mmediately.

If this is read seriously and literally, if ever anyone who has ever communicated in project spaces ever does any kind of (non-violent, mind you) community or political activism, the other side (or the same side if they are slightly clumsy?) is welcome to DoS the moderation team, who would be acting against the commitments if they just answer «get real»?

If we don't care at all what is written in the text, we should just continue using the Foundation Statement on communication norms. If you want pages of text, what's the value add if nobody looks at the actual meaning of words as written?

Also,

We are committed to providing a friendly, safe and welcoming environment for all, regardless of <…> level of experience

as written, in the present, if compared to reality, uses a pretty creative interpretation of «welcoming».

Also, the advice as written doesn't actually help with either of the two issues in one of the linked examples. If we want an actually useful document demonstrating what norms we have ended up with, I guess a summary of GitHub/Discourse ban reasons by the moderation team would be much more useful.

Scoping… well, scoping is also a complicated issue in practice, as we all have seen, and maybe it would be nice to have an actual explanation of reality, not borrowed vagueness. This is by the way why I don't like the word «community» and would prefer «project-affiliated communication channels» — I am not sure we have one single community, and also if we define whatever there is as a community I don't have the right to solicit (elsewhere) reviews on my planned patches in an insultingly worded style if I want, because it is kind of community communication?

[ashkitten]

I continue to follow a «words have meaning» value system. If the text if taken seriously and literally promises to excommunicate for subscribing to someone's RSS — either we have a problem, or, more likely, nobody has ever cared what is actually written in the text.
[...]
If this is read seriously and literally, if ever anyone who has ever communicated in project spaces ever does any kind of (non-violent, mind you) community or political activism, the other side (or the same side if they are slightly clumsy?) is welcome to DoS the moderation team, who would be acting against the commitments if they just answer «get real»?

i take issue with the implication that adopting a code of conduct is an invitation for anyone to test its edge cases to the extreme. words can communicate meaning, but it is the intent of those words that embodies the meaning. words are just a statement, and it is the duty of the listener to interpret the meaning in a way that most likely reflects the intent with which they were written. it is not an exact formula and never can be. if it were so easy to write words that exactly encapsulated everything the writer intended and no more, we would be living in a very different world.

If we don't care at all what is written in the text, we should just continue using the Foundation Statement on communication norms. If you want pages of text, what's the value add if nobody looks at the actual meaning of words as written?

though words are just a lossy form of communication, the intent of these words is to provide a concise yet expressive document with some idea of what to expect from NixOS spaces. the meaning of the words as written is to communicate exactly that. to read deeper and try to nitpick exact details and edge cases in a document that was not written intending to be read in that way is intentionally misconstruing the meaning and it is one's own fault if they try to exploit the imagined semantics and learn the consequences.

Also, the advice as written doesn't actually help with either of the two issues in one of the linked examples. If we want an actually useful document demonstrating what norms we have ended up with, I guess a summary of GitHub/Discourse ban reasons by the moderation team would be much more useful.

this is useful to give an idea of what the community has encountered before, but it certainly doesn't guarantee that issues that are important to someone will be represented in past examples. if we want to be welcoming to all, we should show that by talking about not just issues that have affected us but issues that affect other communities as well.

it's the show of solidarity that helps people feel safe and empowered to call out problematic actions when they see them, and they look to the actions of the moderators to back up the promises in this document. if the moderators fail to protect the people in question, it is not a failing of the document but a failing of the moderators. in the end, yes, one might contend that this means it does not actually matter what the words say, but the words are a statement that if backed up with appropriate action can be highly meaningful, and if undermined with inappropriate action can be equally meaningful but with a much different meaning.

rust is known as a community that is generally welcoming and safe for minorities. this is their code of conduct. it is not the only nor the primary reason for rust's success in community safety, but clearly adopting it is not antithetical to that cause.

[7c6f434c]

i take issue with the implication that adopting a code of conduct is an invitation for anyone to test its edge cases to the extreme.

It is not an edge case when a text bothers to separately say «deliberate following», stresses that «online» is included, and the widely used notion of «online following» is nowhere near the intent. It is not a text where too many words are needed to exclude the edge cases. It is a text where words were just put without any respect to literal meaning. It is not conveying a meaning.

It's not like this is under a point where «all such issues will be seriously addressed». It is under a point which unambiguously promises to exclude.

I do not think that signalling would be weakened by a clarification. Unless one wants to signal that the space is especially safe for those who are made uncomfortable by the very idea of words being able to have literal meaning and not just political pointing; but I don't believe that's the goal in a software project.

[fricklerhandwerk]

@7c6f434c please make concrete suggestions (as in: inline comments with diffs) that would remove your points of contention from the text. From what you wrote it seems they may not be invasive. Then we can discuss them inline.

A lengthy exchange in top-level comments straining readers' capacity to keep up with the discussion is one of the major causes for the RFC process to have a bad reputation.

[7c6f434c]

Can we start by including Jon's clarifications from allegedly «resolved» conversations?

[tomberek]

From RFC Steering Committee: Any updates?

[edolstra]

Moving this to draft status for now because we haven't had a lot of activity lately. Also, @zimbatm proposed:

IMO the moderation team should be empowered to propose a code of conduct without going trough the RFC process.

RFC is good for technical decisions that are hard to revert, like language changes.

[shlevy]

IMO the moderation team should be empowered to propose a code of conduct without going trough the RFC process.

Anyone can propose a code of conduct. Is the suggestion that the moderation team should be empowered to enact a code of conduct?

If so, I think that is significant disregard for the text and intent behind RFC 0102, which after all came into being precisely to be a surgical, scope-limited means of addressing the (purportedly) urgent issues inspiring previous all-encompassing RFCs like the one for a community team. If the moderation team is suddenly becoming the community team, on whose authority?

[zimbatm]

What do you mean by "community team"?

The moderation team already has the authority to enforce a code of conduct; it's just implicit. Writing things down will help us share what expectations we have in terms of acceptable behaviour. It also provides a clear entypoint for people that want to report something. Don't worry; it's not going to be some crazy document.

EDIT: this might not be the best place to re-open this discussion. If you have any uncertainty and doubt, the best is to talk to us directly; you can join the #moderation:nixos.org Matrix channel.

[7c6f434c]

I guess there is a difference between the two types of Codes of Conduct: is it really regulation or documentation. A code with its own independent legitimacy can justify some decision as an argument additional to the team judgement, a code coming from within a team relies on the team for any relevance and can at most justify consistency.

(But documentation is indeed useful as documentation.)

[zimbatm]

The moderation team has implemented this; see https://discourse.nixos.org/t/adopting-a-code-of-conduct/35136 for the announcement.

[jonringer]

Still find it interesting that a community CoC languished, while a moderation team CoC was ratified in relative short order.

The ratified CoC is mostly the same, and uses a lot of similar terminology to what I had; so I'm okay with it. The moderation CoC is just devoid of the "intent" behind what is encouraged or discouraged. So I'm glad we at least have something now.

However, I think it highlights how these RFCs are prone to wasting and often abandoned. I closely monitored this PR for ~6 months until it became clear that it would never reach a meaningful end state. Then after two years (and a motivating external reason), another CoC gets adopted in a very short time period with little to no community input.... I bring this up publicly to highlight that current RFC process isn't sufficient. The NixOS community did in fact need a CoC, and it wasn't until years later that it was adopted in a non-collaborative way because it was upgraded from "do we need this?" to "we need this now".

[7c6f434c]

The moderation CoC is just devoid of the "intent" behind what is encouraged or discouraged.

It is also devoid of binding the moderation team, or of «source of legitimacy» for decisions that end up controversial.

Non-binding documentation is safer than binding regulation.

I bring this up publicly to highlight that current RFC process isn't sufficient.

Well, whenever we can get away with punting the issue to subsystem maintainers maintaining it as they see fit because there won't be much controversy, we should prefer doing this to making a somewhat binding entire-community decision. We kind of already do this all the time. I think this is but a particular case of that general principle.

[jonringer]

Non-binding documentation is safer than binding regulation.

This is likely from own personal desire to have a reason or motive behind actions. Especially when the consequences of these decisions are usually to suspend or ban a person from the community.

[7c6f434c]

This is likely from own personal desire to have a reason or motive behind actions.

Of course, decision criteria documentation helps with both transparency and consistency — and that's a good thing.