Re: IESG Statement On Oppressive or Exclusionary Language

[Toerless Eckert <[e-mail]>]

I think this document should become an indificual submission draft/RFC. It is a
good socio-linguistic research/position paper, but if we wold run it through a work
group process we would excude a lot of community members that are not interested
or fear getting into this type of socially critical discussions and we could get
 arbitrary ratholing about details from other community members. 

IMHO The actual work to be done to suggest a process for us would best be in a new
document that really only needs to be scoped on two simple questions: 

Abstract:

This document discussses:

  I)  How can we make new work product (RFC) use words that are not gratuitous
      metaphores without so significanty improving readability as to outweigh
      possible negative connotations of the metaphores ?

  II) How can we agree to as few a possible, consistent replacements for words falling into I)

For examples and justification see <individual-submission-doc>

/Abstract

Example for I): We should have a process that would also be able to cope with
words accepted to be problematic enough even if from different contexts:
   "kill" command in unix comes to mind
   "red" and "black" in accounting comes to mind

For I): I am mostly worried about as few as possible == consistent replacement words.

For something like blacklist/whitelist i think its eay to randomnly select a single
replacement. My random choice would be denylist/permitlist

For master/slave it seems more difficult:

In 2018, Python replaced uses of the term "master" variously with "main", "parent", and "server"; and "slave" with "worker", "child", and "helper", depending on the context.

Aka: these type of replacements are where the real problem will lie.

I would propose our process includes to capture/summarize all replacments/choices
we make on some page (like RFC editor abbreviations page). Maybe a wiki: 
outlining reasons for specific replacement word choices and also pointing which
older RFCs (which we can't change anymore) these should be equivalent...

Cheers
    Toerless

On Thu, Jul 23, 2020 at 10:54:46AM -0700, Ted Hardie wrote:
> Howdy,
> 
> On Thu, Jul 23, 2020 at 10:36 AM Michael StJohns <[e-mail]>
> wrote:
> 
> > Hi -
> >
> > I support the general goals you've stated below, but I have a few problems
> > with how you're (IESG) suggesting we approach them.  Two in particular:
> >
> > 1) The onus for implementing whatever we end up deciding will be on the
> > RFC Editor and the RPC - that argues that the primary driver of the
> > language effort should be rooted over on the rfc-interest mailing list, and
> > driven by the RSE (or the temporary equivalent) and not as part of the
> > general area.  I'm not sure why this even needs to run past Dispatch?
> >
> >
> For what it's worth, I disagree with this.  The primary mode of
> implementation here for new work will be a change in community practice,
> not a set of changes implemented at the end of the process by the RSE or
> RPC.  It also seems to clear to me that it would be valuable for the other
> streams to consider the same issues, but I don't believe that changing the
> IETF's practice requires the consensus of the other streams to change.
> 
> To put this in a slightly different way, we're better off if alternatives
> to terms like master/slave are considered and adopted by the working groups
> who are building the technologies than if the alternatives are brought
> forward only after the work is done.
> 
> As a result, I believe BCP and IETF processing is appropriate here, even if
> the other streams adopt similar conventions.  It may still happen that
> there are issues flagged late, but I'm guessing it would be at IESG review
> rather than at the RPC exceptional circumstances.
> 
> regards,
> 
> Ted Hardie
> 
> 
> > 2) I'm not enamored of the document [1] for a number of reasons:
> >
> >    - At least three of the sources  (BrodieGravesGraves, Burgest, Eglash)
> >    are  behind paywalls making it difficult for anyone besides the authors to
> >    do a meaningful review
> >    - other sources appear to be paper only - at least there are no
> >    on-line references
> >    - there are few peer-reviewed scholarly papers referenced - it would
> >    be helpful to have more to strengthen any arguments rather than depending
> >    on popular press opinion pieces (Grewal, Jansens, McClelland)
> >    - because X, Y and Z did it isn't a great set of arguments for why we
> >    should do it (e.g, Drupal, Github, etc)
> >    - If we're going to get into this, we need to also address "master" as
> >    a stand-alone term, not simply in the context of "master/slave" - e.g.
> >    "master copy", "mastering a recording", "zone master file", "mastering a
> >    skill", "master controller".  I'd *really* like to not have to do this
> >    multiple times because we lacked imagination or completeness.
> >    - the list of master/slave alternatives within the document doesn't
> >    really deal with the "controlling entity/controlled entity" pattern.
> >
> > Later, Mike
> >
> > On 7/23/2020 12:35 PM, The IESG 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
> >
> > _______________________________________________
> > IETF-Announce mailing [e-mail]://www.ietf.org/mailman/listinfo/ietf-announce
> >
> >
> >

-- 
---
[e-mail]