Re: IESG Statement On Oppressive or Exclusionary Language

[Ted Hardie <[e-mail]>]

On Thu, Jul 23, 2020 at 11:08 AM Michael StJohns <[e-mail]>
wrote:

> On 7/23/2020 1:54 PM, 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.
>
> Hi -
>
> I'm actually surprised that you think its a good idea to do this on a
> stream basis rather than on a community basis.   Regardless, the draft
> cited is pretty clear that it wants to add constraints to the RFC process:
>
Just above the text you cite is this:

Authors SHOULD: * Replace the excluding term "master-slave" with more
   accurate alternatives, for instance from the list of Section 3.1.  *
   Replace the excluding term "blacklist-whitelist" with more accurate
   alternative, for instance from the list of suggested alternatives at
   Section 3.2.  * Reflect on their use of metaphors generally * Use the
   neutral "they" as the singular pronoun, and * Consider changing
   existing exclusive language in current (reference) implementations
   [socketwench] * Consult the style sheet maintained by the RFC editor.


Getting the cultural shift to this reflection on the consideration means
that it will be rare that the RFC editor will need to offer alternatives.
It also means the language in I-Ds and working group discussion will avoid
the terms early, rather than expecting a post-facto adjustment by an
expert.  A BCP covering the IETF practice here seems to me a useful thing
to do, even if all the other streams come to very similar practices.

Adjustment of the language of the draft to reflect that targeting would, of
course, be fine by me.

regards,

Ted Hardie




>  RFC Editor MUST: * Offer alternatives for excluding terminology as an
>    important act of correcting larger editorial issues and clarifying
>    technical concepts and * Maintain a style sheet that collects all
>    terms that have been considered and indicate wheter they are deemed
>    acceptable, and if not what terms Authors should consider instead *
>    Suggest to Authors that even when referencing other specifications
>    that have not replaced offensive terminology, the Authors could use
>    another term in their document and include a note to say that they
>    have used the new term as a replacement for the term used in the
>    referenced document.
>
> That puts the scope of the effort completely within the RFC model.   Or to
> put it another way, no one has any control about what goes into the IDs
> except the person that writes the ID.  The RFCs are from start to finish a
> product of the community and must meet the community standards.
>
>
>
> 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.
>
> I think I'm about to get into an argument about tail wagging and dogs, so
> I'm not going to do that. Suffice it to say, that you've got folks that
> submit to multiple streams and will have to follow different guidance on
> what's acceptable content for those streams.  Sounds confusing to me.   I
> think this is a community issue, not a IETF stream's issue and I think
> treating as an only an IETF stream's issue is just going to make more work
> for us and lead to less progress.
>
> Later, Mike
>
>
>
>
> 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
>>
>>
>>
>