Subject: Some more thoughts about language and what to do next

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jul 2020 10:10:37 +0200

Hi Bron and everyone,

I’ve got a proposal for a way forward toward the bottom.  &tldr; be iterative and do research.

I very much enjoyed your explanation of virtue vs virtue signaling, and in particular the parenthetical got me chuckling.  On this point:

> On 29 Jul 2020, at 15:32, Bron Gondwana <[email-masked]> wrote:
> 
> It seems to be me that most of the debate in this thread boils down to: "is this effort is a clear signal that we're serious about trying to be inclusive rather than facile pandering to a particularly noisy political group?", and an associated "would publishing something like this be effective and attract people who want to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet?”

Yes.  But I think we can walk and chew gum at the same time, and that we can be iterative.  The IETF is by no means the only or first organization to have these sorts of ridiculously long and argumentative threads about terminology.  The arguments themselves are plaguing the OSS community, companies, and other standards organizations.  The arguments themselves are toxic and counterproductive, and not just at the IETF.*

As I have previously written, at the moment, there is no commonly accepted, well researched decision framework for inclusive terminology selection.   This leads to lots of opining (e.g., the toxicity).  A few of us are actively working to correct this by attempting to establish a funded agenda with an eye toward finding decision frameworks that people would be comfortable using.  The idea is to bring in experts such as linguists, ethicists, sociologists, psychologists, etc who understand these things far better than engineers are likely to.

Our challenge: gaining the attention of those sorts of researchers from our distant position from their normal professional lives.  My company is large and can make a splash.  A few companies can make a wave.  A lot of companies asking for help from experts will turn the tide.  If you work at such a company with a research department, and are interested in collaborating on such an agenda, please drop me an email.  A few of us are already in touch, and the more the merrier.

In the meantime, I propose an iterative approach, noting that we are all trying to learn a bit more on this:
March 2021 (or so**): a BCP that states what people should think about with regard to their terminology, and guidance to people doing reviews.  I would keep this short.  The idea is not to prohibit certain words but to make use of WG and IETF rough consensus rules to encourage avoidance of the more obvious terms that people are likely to find offensive.  This allows deference to the specifics of each case, and we don’t have to worry about formal role assignment at this stage.  Just by us being a bit more mindful, I imagine our documents will clean up nicely.
March 2023: a BCP that is a more normative process based on whatever we will have learned through experience and consultations with real experts, perhaps after the results of a bit of applied research and analysis.  This will also allow for a more formal approach to corner cases, like where we are interacting with works and processes outside the IETF.
By the way, I expect the research to be iterative as well, and that sometime after 2023 we would revise again.  Also, I am hoping that what we learn from experts will benefit more than just the IETF.

Eliot
* I apologize if I have contributed to that toxicity.
** Eight months for a WG result is pretty much lightning speed.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 30 Jul 2020 20:55:09 +1000

Hi Eliot,

Thanks for taking the time to write up such a thoughtful response.

I also have been thinking about this a lot, and hadn't managed to get it into words yet!

Our purpose contains ... relevant technical documents* that influence *the way people ...

So anything which detracts from influencing people is a mistake, including divisive terminology which causes people to get caught up on the words rather than the content - or on the flip side, made up pixie-dust terms to avoid using industry standard terms because we don't like them for whatever reason.

Our standards are designed to live for a long time, so being conservative in our use of language is wise - while not trying to predict the flows of fashion too much or encode a particular point of time that becomes rusty into our guidelines.

We like rough consensus and running code in the IETF, which means where there's rough consensus in society we don't need to tell people what to do (nobody uses 6 letter words starting with n in their drafts) - and we're not experts in the best language to use to influence those who design, use and manage the internet.  But in the end, that's our goal, so using any advice we can obttain is good.

Most of all, I think it's a mistake for either "side" to catastrophise the choices ahead of them - and it would be a mistake to allow the IETF to be made a "front" in anybody's attempt to use power to force "consensus" on society faster than it is naturally evolving.  It takes a long time to move public opinion on things.

Cheers,

Bron.

On Thu, Jul 30, 2020, at 18:10, Eliot Lear wrote:
> Yes.  But I think we can walk and chew gum at the same time, and that we can be iterative.  The IETF is by no means the only or first organization to have these sorts of ridiculously long and argumentative threads about terminology.  The arguments themselves are plaguing the OSS community, companies, and other standards organizations.  The arguments themselves *are* toxic and counterproductive, and not just at the IETF.*
> 
>  * March 2021 (or so**): a BCP that states what people should think about with regard to their terminology, and guidance to people doing reviews.  I would keep this short.  The idea is not to prohibit certain words but to make use of WG and IETF rough consensus rules to encourage avoidance of the more obvious terms that people are likely to find offensive.  This allows deference to the specifics of each case, and we don’t have to worry about formal role assignment at this stage.  Just by us being a bit more mindful, I imagine our documents will clean up nicely.
>  * March 2023: a BCP that is a more normative process based on whatever we will have learned through experience and consultations with real experts, perhaps after the results of a bit of applied research and analysis.  This will also allow for a more formal approach to corner cases, like where we are interacting with works and processes outside the IETF.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Thu, 30 Jul 2020 14:42:39 -0700

On Thu, Jul 30, 2020 at 3:56 AM Bron Gondwana <[email-masked]>
wrote:

>
> Most of all, I think it's a mistake for either "side" to catastrophise the
> choices ahead of them - and it would be a mistake to allow the IETF to be
> made a "front" in anybody's attempt to use power to force "consensus" on
> society faster than it is naturally evolving.  It takes a long time to move
> public opinion on things.
>

Yes, I think the way some people feel about "y'all" and "folks" is that
they're cloying--particularly if it seems like the speaker/writer doesn't
use those words most of the time. That doesn't make them incorrect or
offensive, but it's something to watch out for. That said, it is possible
to use contractions in a derogatory way, especially in quotations.

Perhaps a thesaurus is what's called for. No words are banned, but there is
a list of alternatives...

thanks,
Rob

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2020 17:17:39 -0500

On Thu, Jul 30, 2020 at 02:42:39PM -0700, Rob Sayre wrote:
> > [...]
> [...]

Or how about we give each other a bit more credit, assume good faith a
bit more often, and when we are offended, ask the SAA/ombudsperson.  The
SAA is more likely to be objective enough to be able to say "the speaker
clearly meant no offense", "can't tell, I'll talk to them" (possibly to
be followed with "the speaker meant no offense"), "I'll talk to them
[they were clearly being unprofessional or close to it]".

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Thu, 30 Jul 2020 16:07:09 -0800

I think there are two different things under discussion: 1) language
used in our documents, and 2) language used in our discussions, both
online and off.  draft-knodel is very clear that it's the former that's
in scope, stating in the abstract:

   This document argues for moving away from specific language
   conventions used by RFC authors and RFC Editors in order to encourage
   inclusive terminology in the ongoing RFC series.

I am not overly concerned about colloquialisms making it through working
group last call, let alone through the RFC Editor process.  So, while
whether or not "folks" and similar are going to be alienating is an
interesting and likely worthwhile discussion to have, it's outside the
scope of this particular document.

Melinda

[on reread, aside from other issues draft-knodel is a little squishy
about whether it's arguing for change or specifying those changes,
which is probably a minor point but wouldn't be much effort to
clarify]

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 Jul 2020 09:16:34 -0300

Hello, Eliot,

On 30/7/20 05:10, Eliot Lear wrote:
[...]
> As I have previously written, at the moment, there is no commonly 
> accepted, well researched decision framework for inclusive terminology 
> selection.   This leads to lots of opining (e.g., the toxicity).  A few 
> of us are actively working to correct this by attempting to establish a 
> funded agenda with an eye toward finding decision frameworks that people 
> would be comfortable using.  The idea is to bring in experts such as 
> linguists, ethicists, sociologists, psychologists, etc who understand 
> these things far better than engineers are likely to.

Maybe it's just me but, no matter how the good intentions, this feels a 
bit like resembling https://youtu.be/OZNwZiyGEuk?t=168

I'm fine with guidelines aiming at avoiding what's deemed to be 
oppressive terminology (*). But if the ultimate goal is really that of 
inclusiveness, this whole thing seems a bit like just scratching the 
surface and being able to say "we've done something about it", than 
actually trying to tackle the underlying problem itself.

(*) As noted before, if the effort is to be pursued, then the target 
should be all IETF contributions, as opposed to just I-Ds or RFCs.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jul 2020 09:05:38 -0500

> iterative and do research.

I've got a better proposal: let the SAA and/or obudsperson, and
ultimately the appeals process when participants choose to appeal their
decisions, be the arbiter of what is and isn't unprofessional /
unbecoming / offensive language.

A key required component of leveraging the SAA function -in order to not
overwhelm it- is that we should ask participants to try to see language
in the best possible light by ascribing good faith to other participants
_by default_.  The alternative to this is devolving towards being
confrontational by default -- surely not a good thing.

We have the SAA and ombudsperson functions for a reason.

For example, if I use the word "folks" in a post to this list[*], then
rather than immediately getting the vapors and passing out, maybe you or
whoever might take offense should start by assuming I didn't mean to
offend, then consider the possibility that due to regional linguistic-
cultural variations my use of "folks" might be perfectly innocent, and
*move on* -- or, if the rest of my note were to drip with condescencion
and betray intent to offend, or if you're otherwise still unsure, then
reach out to the SAA.

Nico

[*] I'm sure I have!

---

From: Eliot Lear <[email-masked]>
Date: Fri, 31 Jul 2020 16:21:25 +0200

Hi Nico,

> On 31 Jul 2020, at 16:05, Nico Williams <[email-masked]> wrote:
> 
> I've got a better proposal: let the SAA and/or obudsperson,

I think we’re talking about two different things- how we speak on list, and what goes into our drafts and RFCs.  I’m suggesting general guidance to working groups as a BCP (no MUSTs but guidance), and just use the existing process to avoid terminology that one might expect to be offensive.

At the same time, let’s seek more guidance about all of this from experts and develop a real decision framework that is based on firm ground, as it were.  Once we get that we iterate.

As to how we speak on list, I have no problems with what you suggested.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 31 Jul 2020 14:32:58 +0000

>    At the same time, let’s seek more guidance about all of this from experts and develop a real decision framework that is based on firm ground, as it were.  Once we get that we iterate.

Yes.

Except maybe we can stop using particularly egregious words, as indicated by consensus.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 1 Aug 2020 01:30:03 +0900

Eliot Lear wrote:

> At the same time, let’s seek more guidance about all of this from
> experts and develop a real decision framework that is based on firm
> ground, as it were.  Once we get that we iterate.

It should be noted that US experts are mostly ignorant on
realities outside of US.

Europeans has similar tendency, though, less badly.

						Masataka Ohta

---

From: Leif Johansson <[email-masked]>
Date: Fri, 31 Jul 2020 18:34:05 +0200

Skickat från min iPhone

> 31 juli 2020 kl. 16:33 skrev Salz, Rich <rsalz=[email-masked]>:
> 
> 
>> 

Isn’t such consensus something that develops in society, outside in the IETF? I certainly never had to read an I-D to figure out I shouldn’t write “lapp” in a technical document even though it is a great translation of “patch” to Swedish. That knowledge came to me from interacting with other humans.

I personally think that if we need the IESG to tell us how to speak and behave we have a dysfunctional culture in the IETF and that won’t get fixed by further arguing over documents or standing up IANA registries.

Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jul 2020 12:43:23 -0400

> ground, as it were.  Once we get that we iterate.

This presumes the existence of objectively qualified experts[1].  Will
we know one when we see one?  Who decides which experts are qualified?
I don't think ducking the responsibility to make the choices can work.
Ultimately, the IETF community are the experts in how we use our
terminology.

If in some cases we need to depart from past practice more rapidly than
would happen just naturally through contributors using what they
personally perceive to be accepted at the present moment, their peers
will offer (I hope polite) suggestions of more appropriate terms.

We don't have a crisis and no radical remedies are needed.  The ways in
which the IETF is not inclusive (let alone "oppressive") have
exceedingly little to do with our technical vocabulary.

Rather, it is the politics of convincing peers to accept (ideally sound)
proposals or to reject (ideally not sound) proposals in the context of
complex social alliances, that makes the IETF challenging for both
newcomers and old-timers.

Easily bruised egos don't necessarily fare well. :-(  Proscribing some
fashionably taboo words won't change that.  The most bruising encounters
will crush your most cherished ideas without resort to any bad words.

-- 
    Viktor.

[1] In sufficiently esoteric fields, the apparent experts are
*sometimes* mostly expert at marketing their expertise.  Was
Bernie Madoff an "expert" investor?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 31 Jul 2020 18:52:38 +0200

> On 31 Jul 2020, at 18:43, Viktor Dukhovni <[email-masked]> wrote:
> 

I may or may not know what an expert in this space looks like, but I can tell you what one doesn’t look like.  And so I guess I would fundamentally disagree with you that we are the experts.  However, we would be the customers of the expert advice, and we get to decide either individually or collectively to use it.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Aug 2020 08:34:31 +1200

On 01-Aug-20 02:21, Eliot Lear wrote:
...
> At the same time, let’s seek more guidance about all of this from experts and develop a real decision framework that is based on firm ground, as it were.  Once we get that we iterate.

Yes, but our source of expertise related to writing and publishing is surely already clear: the RFC Editor service. I am at a loss to understand why we're discussing this as an IETF issue alone. So I don't think a BCP is called for, but guidance from the RFC Editor, applying to all RFC streams. The vehicle for that exists: the RFC Editor style guide. It needs a new chapter.

I'm very happy with the IESG stating that IETF documents should avoid oppressive or exclusionary language. But I believe that we should go forward by requesting the RFC Editor to provide guidance and possibly tools to achieve this. Since all RFCs start as I-Ds, the guidance and tools would obviously apply to I-Ds as well as RFCs.

Regards
    Brian