Skip to main content

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

Yes

Erik Kline
Roman Danyliw
(Alvaro Retana)
(Lars Eggert)
(Martin Duke)

No Objection

Zaheduzzaman Sarker
(Robert Wilton)

Abstain


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

Ballot question: "Is this charter ready for external review?"

Erik Kline
(was No Objection) Yes
John Scudder
Yes
Comment (2021-04-22) Sent
After reading much (by no means all) of the list traffic, and after reading all the Abstain positions others have written, I’m going with “yes” on this one. To me it seems like some of the sentiments expressed by the more skeptical amount to perfect being the enemy of good. Furthermore — and this is the deciding point for me — in the broader industry, the train has clearly left the station. We can lead, follow, or get out of the way, but doing nothing would be tantamount to standing on the tracks. 

I do think the charter has improved significantly since earlier versions, although I also agree with Éric’s remark about “hollow marketing language” at the end of the first paragraph.
Roman Danyliw
Yes
Murray Kucherawy
No Objection
Comment (2021-04-22) Sent
I have my reservations about this method of addressing the issue.  However, since this is just approval for external review, I'm content to let this version go and see what comments the community has.
Zaheduzzaman Sarker
No Objection
Francesca Palombini
Abstain
Comment (2021-04-21) Not sent
[re-posting my ballot position, which fundamentally hasn't changed since the previous iteration, since it's not about the text itself]

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.

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)
Warren Kumari
Abstain
Comment (2021-04-20) Not sent
[ Simply reapplying my previous ballot position]

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.

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-20) Sent
[No really changing my position as it is based not on the charter itself but more about forming a WG around this topic]

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.

Moreover, even if this potential WG publishes documents, let's not declare victory and let's not wash our hand of the real problem.

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 (updated):

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

s/The output of this WG will provide guidance to IETF participants/The output of this WG, if published, will provide guidance to IETF participants/ ,i.e., a WGLC should not be enough.

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

Regards

-éric
Alvaro Retana Former IESG member
Yes
Yes () Not sent

                            
Lars Eggert Former IESG member
Yes
Yes (for -00-06) Not sent

                            
Martin Duke Former IESG member
Yes
Yes () Not sent

                            
Martin Vigoureux Former IESG member
Yes
Yes (2021-04-22) Sent
I acknowledge the risks associated with this initiative (as outlined by other ADs) but I think that on the long run this will engender more benefits than problems.
Yet, I think something important is missing.
The output of the WG, if it goes all the way through the IETF Stream, will have IETF-wide consensus.
While it is impossible to anticipate on the actual terminology recommandations the WG will make, I believe the charter should take a position (or lead the WG to make a recommandation) on how to handle initiatives aiming at revising/updating/obsoleting IETF past publications with the purpose of changing terms they contain.
Robert Wilton Former IESG member
No Objection
No Objection () Not sent