Skip to main content

Effective Terminology in IETF Documents
charter-ietf-term-00-07

Note: This ballot was opened for revision 00-03 and is now closed.

Ballot question: "Do we approve of this charter?"

Erik Kline
Yes
Roman Danyliw
Yes
Comment (2021-04-08 for -00-03) Not sent
As Ben's position noted, there is still community feedback to process.
John Scudder
No Objection
Comment (2021-04-07 for -00-03) Sent
Nit: I don’t think “Internet Drafts” needs a hyphen.
Zaheduzzaman Sarker
No Objection
Comment (2021-04-08 for -00-03) Sent
Languages evolve. This  evolution depends  on lots of factors - the use, the time, the context, the events, the diversity -- this list is long here, also the evolution does not really happen through same mechanisms everywhere. Hence, the use and meaning of particular terminology or words will differ in different time context. Best possible strategy should be to try to use terminologies/words best suited for the job at hand. For IETF, that job at hand is to produces technical specifications. For such specifications the desire must be to avoid  ambiguity, offensiveness, exclusion (in whatever from) as much as possible. 

There has been long discussions on the term charter and there has been concerns. I believe, this work on recommendation for effective and inclusive terminologies requires scrutiny to some extend to produce fruitful outcomes. Hence, I foresee term working group as a platform where discussions can happen, constructive feedback can be exchanged to produce consensuses to on terminologies to be used in the technical specifications paving way for more diverse and inclusive IETF. Thus, I have no object on approving this working group.
Francesca Palombini
Abstain
Comment (2021-04-08 for -00-03) Sent
While I also agree with my co-ADs that any effort to make the IETF more inclusive is important (and I won't repeat everything Warren, Rob or Éric already said about supporting inclusivity efforts in IETF and aligning with other SDO's similar efforts) I don't think I can ballot anything else than Abstain. If there was a Recuse button, I would ballot that instead, but as there is not I am abstaining instead. There are mainly two reasons for this:

1. And most important - I have co-chaired gendispatch and shepherded the first proposal on this topic through the recommendation to create a WG (based on draft-gondwana-effective-terminology) [1], and although I have been as unbiased as possible, it would feel strange for me to approve on the chartering of this working group, while I also (together with my co-chair and AD at the time) evaluated the community consensus that lead to effort on chartering the working group. 

2. Because I have followed the discussion on the topic very actively, if not since the beginning at least since its arrival in gendispatch at IETF108, I am concerned about the potential of this work to create divisiveness and hurt in the community, and I am worried about the potential of the working group of being destructive rather than constructive.

The conclusion is that I have a serious concern about this working group being chartered, but as my concern is not actionable, and as I stand behind my evaluation of consensus at the time of chairing gendispatch (after hearing the community speak in 1 meeting, 2 interims [2], and countless emails [3]), I will not block this effort. I however wanted to mark my opinion and make sure the resp AD and the whole IESG pays particular attention to its evolution.

Thank you Ben for summarizing the last set of comments we got on the charter. Additionally, as an actionable comment, I still think mentioning in the charter that draft-gondwana-effective-terminology is the starting point of this work might help.

Francesca

[1] https://mailarchive.ietf.org/arch/msg/gendispatch/iHDh7KBVRvGB2EWKYYh11LjP95E/
[2] https://datatracker.ietf.org/doc/minutes-108-gendispatch/ 
      https://datatracker.ietf.org/doc/minutes-interim-2020-gendispatch-01-202009012000/
      https://datatracker.ietf.org/doc/minutes-interim-2020-gendispatch-03-202009071100/
[3] https://mailarchive.ietf.org/arch/browse/gendispatch/?q=terminology (excerpt, I know there is more)
Murray Kucherawy
(was No Record, No Objection) Abstain
Comment (2021-04-08 for -00-03) Not sent
Several of my fellow ADs who are abstaining or DISCUSSing have captured my position nicely.  The larger problem(s) here probably need to be addressed in a scope different from what's being proposed here.  Thus, on reflection, I too am concerned that the output of this WG as proposed might make things worse rather than better, but I do not wish to stand in the way of progress of the consensus opinion.

I respectfully ABSTAIN.
Warren Kumari
(was No Objection) Abstain
Comment (2021-04-08 for -00-03) Not sent
I agree that we should not be using terms that are, or could be, offensive, hurtful or send discouraging signals. I also believe that the vast majority of people in the IETF who do use terms like this are doing it unthinkingly, and without malice. These two precepts lead to the “it would be good if we had a resource where we would learn about terms which may be offensive, and easy replacements for those terms”. So far, so good….

In addition, I’m very supportive of building an IETF where anyone, and everyone, feels comfortable and welcome participating. The question for me is not whether this should be done, but rather what is the most effective, inclusive, ground-up method that will have the most buy-in and be the easiest to build upon further.

I don’t think that a working group is the right way to accomplish this - I oscillated between Abstain and NoObj, and finally settled on NoObj because I want to be clear that I do take the problem itself seriously. People should *want* to treat each other well, and anything “official” created by the IETF (like a WG) seems, to me, like it doesn’t solve the root problems, and probably makes them worse.  I understand that this WG is “chartered to produce an Informational RFC containing recommendations on the use of inclusive terminology in the technical work produced by IETF participants.”, and that this is supposed to “complement other efforts at fostering inclusivity in the IETF”.  My concern is that this approach will simply further polarize the community, and will lead to more division and antagonism.  Telling someone they are bad and must change doesn’t generally work; it generally makes them feel like they are being judged, become defensive, and attempt to justify, if not perpetuate, those behaviors. Helping them understand why their actions may be considered harmful  seems much more useful and likely to result in a positive change.

Even if we were to magically remove all terms which might cause offense to someone, I don’t think that that fixes our inclusivity issues, and, based upon the fact that we clearly have some set of people who are trolling for a fight, I think it makes things worse.

I would much rather that we instead work on actually addressing the inclusivity problems and treat the malady and not just the symptoms. More focus/resources on newcomers, meetings in more countries, discounts for first time attendees (and better student support), plenaries on inclusivity (and understanding other cultures!), more focus on things like GAIA, etc all seem (to me!) useful. 

There are already resources for people who want to improve - anything “official” like an IETF WG / RFC is (in my opinion) likely to just trigger the trolls and give them more of a platform. For potential newcomers to the IETF, I’d prefer the larger “most of us are actually nice people” context to be in the forefront, instead of a loud, unpleasant, minority. In summary, I’m all for helping people understand why some terms are hurtful/harmful - but I don’t think that the current way we are trying to accomplish this works… 

I understand that I’m in the rough here. I understand that (and why) many want this chartered. I’m not trying to block progress, I just don’t think that this is is going to make things better…  but I will not stand in the way of those who do.

[ Update: I had balloted NoObj, but I'm changing to Abstain after yet more thought. I *do* believe that the inclusivity problem is important, but I also think that the chartering of a WG/publication of an RFC  is likely to make the issue worse, not better. You cannot mandate that people be nice; attempting to do so *may* send the signal externally that we are trying to improve, but ultimately, I think, it makes the division in the community worse, and makes the IETF a less welcoming place. People need to be encouraged to be better, this effort, I fear, will be viewed as telling them what to do - and this leads to defensiveness and outrage... ]
Éric Vyncke
Abstain
Comment (2021-04-08 for -00-03) Sent
[Updating my ballot position from NO RECORD to ABSTAIN after more thinking]

The diversity and inclusion issues are critical within the IETF community (and in IETF documents).  But I am very skeptical whether any informational RFC will change anything or have any useful impact, I am also concerned that this WG could become divisive among the IETF community... polarization has, alas, become common in the recent years in all fora.

Beside D&I, it is also important on the editorial side to keep a common terminology with other SDO... so, there are editorial guidelines to be written, but, again unsure whether a WG is the best place.

Hence my 'ABSTAIN' position in the sense of 'I oppose the creation of a TERM WG but understand that others differ and am not going to stand in the way of the others'.

On the charter text itself (unchanged from my previous NO RECORD COMMENTS):

Thanks for addressing my previous comments ;-)

Nevertheless, I am puzzled by the replacement of "work produced by IETF" by "work produced by IETF participants" because "IETF" includes the processes, BCP, RFC Editor, etc. while "IETF participants" does not (at least for a non English speaker).  Is there a reason for this change ? The other use of "IETF participants" later in the text sounds better.

"This maximizes the benefits the IETF derives from its core principles, such as its open process and volunteer core." Sounds really like a marketing statement to me...

Suggestion s/when language is inclusive or exclusive/whether language is inclusive/ to be consistent with previous sentence.

Having said this, let's continue to look for a more diverse and inclusive IETF community, which is more important.

Regards

-éric
Benjamin Kaduk Former IESG member
Block
Block [Treat as non-blocking comment] (2021-04-08 for -00-03) Sent
Given the number of times the question was raised by the community, I would
like the IESG to actively come to a conclusion on whether an IETF WG is the
right venue for this work at this time, before approving the formation of a
WG.
(I do not expect to hold this as a blocking position after the IESG telechat.)
Lars Eggert Former IESG member
Yes
Yes (for -00-03) Not sent

                            
Martin Duke Former IESG member
Yes
Yes (for -00-03) Not sent

                            
Robert Wilton Former IESG member
Yes
Yes (2021-04-08 for -00-03) Sent
I don't know if a WG is the perfect way to achieve the required outcome, but that was the consensus decision of the gendispatch process and the idea of punting this issue to the RFC editor was discussed and dismissed.  We have been discussing this for at least 9 months, and I think that changing tack and starting down a different path now will not go anywhere useful.  I.e., perfect is the enemy of good.

I also believe that most IETF participants wish to focus on producing technical standards, and are happy to use language that doesn't accidentally cause offense, and are either supportive or agnostic to the IETF providing guidance on what language should be used.

I hope that the members of the community who have concerns work constructively to try and find a consensus position within the TERM WG.

I support the chartering of this WG.
Alvaro Retana Former IESG member
No Objection
No Objection (2021-04-08 for -00-03) Sent
I agree with many of Ben's and Warren's points.


Inclusion is not a yes/no proposition; it is a never-ending and always-changing road.  With that in mind, the focus should not be on "inclusive terminology" but on it being non-exclusionary.

"The principles should match the expectations from a diverse set of IETF participants."  Even though we've seen support for this effort, I am concerned that it won't necessarily translate into participation and contribution, especially from a "diverse set of participants."  This task won't be easy; the diverse composition of the WG should be an absolute requirement.