Re: IESG Statement On Oppressive or Exclusionary Language

[Toerless Eckert <[e-mail]>]

On Fri, Jul 24, 2020 at 10:41:36AM +1000, Mark Nottingham wrote:
> P.S. I'm seeing 'main' used as a replacement for 'master' in a few places; e.g., `git checkout main` is easier, because you can type `ma` and then tab complete.

I like main too.

One problem we have not discussed in the thread is that of the euphemism treadmill:

So now we use maybe "main" instead of "master" and "secondary" instead of slave,
and a new round of the treadmill starts, and not in our industry, but in the
culture of the USA people start to diss each other as "main" and "sec"'s,
and 20 years from now we're sitting on exactly the same mail thread and argue
about replacing min and sec.

So question: Would we nail down that we will stick to perpetuity in new work
to terms we once choose before they had negative connotations, or will we
commit ourselves to willingly follow the need to periodically follow 
euphemism treadmill cycles ?

One could of course try to always pick words so obscure that the chance of getting
abused into a euphemism cycle is low. E.g.: i feel pretty confident that
permitlist/denylist will be safe for perpetuity.

Cheers
    Toerless

> > On 24 Jul 2020, at 2:35 am, The IESG <[e-mail]> wrote:
> > 
> > The IESG believes the use of oppressive or exclusionary language is 
> > harmful.  Such terminology is present in some IETF documents, including 
> > standards-track RFCs, and has been for many years. It is at odds with 
> > our objective of creating an inclusive and respectful environment in the 
> > IETF, and among readers of our documents.
> > 
> > The IESG realizes that the views of the community about this topic are 
> > not uniform. Determining an actionable policy regarding problematic 
> > language is an ongoing process. We wanted to highlight that initial 
> > discussions about this topic are taking place in the general area (a 
> > draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108).  
> > Updating terminology in previously published RFCs is a complex endeavor, 
> > while making adjustments in the language used in our documents in the 
> > future should be more straightforward. 
> > 
> > The IESG looks forward to hearing more from the community, engaging in 
> > those discussions, and helping to develop a framework for handling this 
> > issue going forward.
> > 
> > [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/
> > [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/

-- 
---
[e-mail]