Language choices / Getting people on board with the CEPC

[mnot]

I asked Pete Resnick (one of the IETF Ombudsteam) to take a look at the CEPC, and one of his comments was:

As with all policies of this form and style, I suspect a bunch of it is going to become anachronistic pretty quickly and will need to be rewritten, but it gets the points across now. I think certain folks will react to it badly (because of the terminology and broadness), but that doesn't make it wrong.

Specifically:

"Age badly" is likely to happen in lots of places. Particular ones I noticed: I suspect the terms "concern trolling", "deadnaming", "neurotype", and "cissexist" are short-lived. (They're all at least new enough terms to not be able to tell what their longevity will be.) The discussion in 3.1 #2 is in the traditional language of trauma-informed treatment, but I've been reading some stuff lately that thoughts on that may be shifting to new theories.

"Engender a bad reaction" is more global, as expected, but 3.3 is of note: "We will not accept" is an interesting phrasing, and the (perfectly reasonable) rejection of "reverse -isms" will send up the hackles of those who aren't clued in to the issues.

When I discussed this with him, a concern emerged that the language of the CEPC could have the effect of being exclusionary. Some people are "not onboard" with the goals of CEPC, and the language here could be seen as inflammatory by them, so that they reject it (and the W3C).

Obviously, some already are and some will never be "on board", but a large number of people may just need education and persuasion. Pete pointed out that one could do that by making the document more accessible to these folks (e.g., using less jargon), or one could create separate materials for them.

[wareid]

We're open to looking at better defining some of the more jargon-y terms in the document, we've already received feedback in regards to the language in "sustained disruption".

I understand that terms like "deadnaming", "cissexist", and "neurotype" are less familiar to some, and because of that they are defined in the glossary. However, they are also the most descriptive terms for the behaviours or characteristics we're describing.

I'm not sure I understand what you mean by exclusionary in this sense, if someone is not "on board" with the terms of the CoC then they can choose to either educate themselves on the terms that make them uncomfortable, or reach out to us, we're happy to help. As we've reiterated many times, this document is for the benefit and safety of marginalized communities, over the comfort of dominant groups, some discomfort is inevitable in work like this.

[mnot]

I'm not sure I understand what you mean by exclusionary in this sense, if someone is not "on board" with the terms of the CoC then they can choose to either educate themselves on the terms that make them uncomfortable, or reach out to us, we're happy to help.

'Exclusionary' is probably a poorly chosen word. Understand that Pete's operating in a very different context: the IETF, where these word choices would likely be extremely devisive and cause more of a distraction than they would help to advance the community. While we're not seeing that in the W3C, those people are out there, and if word choice makes a difference in terms of whether they come to us, participate and comply with the policy, that's worth considering.

As we've reiterated many times, this document is for the benefit and safety of marginalized communities, over the comfort of dominant groups, some discomfort is inevitable in work like this.

Absolutely. This isn't about comfort so much as it is about getting the broadest possible policy compliance -- and as Pete said, the best way to do that might be with introductory materials tailored to those uncomfortable with the more advanced / jargony / etc. language.

Overall, Pete's feedback was very positive, and I don't think this is so much an issue as it is food for thought (so closing would be fine by me).

[wareid]

Ok! The different in context is important, we wanted to be precise for the benefit of people who might look at the CoC for their specific needs, but I can see why IETF has gone the direction it has. There is no one right way to do it.

If there are any specific examples of words or terms needing clarification/refinement, please let us know. Outside of the known ones in sustained disruption, we have those in order. Otherwise, I'll let you close this if you're satisfied!

[dbooth-boston]

This isn't about comfort so much as it is about getting the broadest possible policy compliance . . . . if word choice makes a difference in terms of whether they come to us, participate and comply with the policy, that's worth considering

Agreed. Making the document accessible to the broadest possible audience -- including to those who might initially look at it unfavorably -- is something I've personally tried hard to do in the suggestions I've made over the past few months. Unfortunately I think those efforts have sometimes been misunderstood, and other times the group just didn't have adequate time or sufficient interest in considering them.

Case in point: The "We will not accept" phrasing that Pete Resnick brought up was something that I specifically tried to address, but aquiesced to leaving it as is due to time pressures for completing the current version.

I think one of the main issues is that folks who have worked hard on these issues and this document for a long time are not as able to see the document with the fresh eyes of someone who is reading it for the first time and may be coming from quite a different community.

All in all though, I think we've made some good progress toward making the document more broadly accessible, and hopefully we can continue to make more improvements in the next version.