Re: IESG Statement On Oppressive or Exclusionary Language

[Tim Wicinski <[e-mail]>]

I was hoping the various "nits" tools would be updated to help authors.

tim


On Thu, Jul 23, 2020 at 2:09 PM 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:
>
>  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
>>
>>
>>
>