Executive/ TL;DR Summary: Rather than looking for new mechanisms or trying to see if we can build tools that are smarter than we are, we will do far better for both the IETF community and the Internet by expanding our existing document development and review processes to include being as sensitive to inappropriate vocabulary or presentation as we are to technical flaws. The issues are important and will often be difficult but, if we cannot educate ourselves and each other to be able to deal with them, any other attempted solutions are likely to cause worse problems. --On Tuesday, July 28, 2020 10:54 -0500 Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: >... > It would seem that evidence in this matter is important. > Evidence of our having a problem would help drive faster > adoption of better solutions. Conversely, lack of evidence, > or even evidence that we don't have a problem, would help us > quickly dispose of solutions to non- problems. And... --On Tuesday, July 28, 2020 11:00 -0500 Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > I'm surprised not to find there anything like a survey of > RFCs, current I-Ds, and maybe even expired I-Ds, of > problematic language. Or any analysis of the prevalence of > problematic language and trends in its use. Did we use to > have a problem that we now no longer have? Do we still have a > problem? Is it getting better or worse? >... > It would be quite useful to have such a survey. I'm actually not sure about either of those assertions. We know that language -- and, more specifically, terminology-- has been used in IETF documents and other Internet technical specifications in the past that reasonable people can interpret as having connotations that are problematic (including, but not limited to, "Oppressive or Exclusionary"). Like Rich, I would like to assume (and am convinced) that the vast majority of such language was chosen out of ignorance or lack of sensitivity to the possible issues and not out of some malicious intent or explicit sense of superiority by the author toward other populations. Should we do better at identifying such language in new documents, bringing it to the attention of authors and, if needed, the broader community? I think so and I think that would be true if we are talking about one incident a year or a hundred incidents every week. This is not one of those subjects on which saying "well it doesn't happen often enough to be a concern, so we should just move on" is reasonable, nor is it one for which a larger volume of problematic language would justify a radically different response. And so I don't see what more statistics would tell us that would be useful... other than, maybe, promoting a large sense of outrage, something that, IMO, is not useful if we are willing to engage with the problem and that should not be needed for us to be willing to engage. So, to repeat: We should get better at encouraging people to speak up when they spot problems of vocabulary or usage or even tone that makes them uncomfortable (or other terms along that scale). Some explicit encouragement from the IESG and IAB might be helpful in that regard; it almost certainly could not hurt. We should try to be sure that the community is as supportive as possible when someone does raise such concerns, possibly building on the ombudsteam mechanisms for dealing with other types of inappropriate reactions in the community. We should try, as we should try with technical issues, quiet, supportive, and educational private conversations with authors and speakers rather than anything that amounts to public shaming. If that fails or is inappropriate, we should expect WGs to detect and adjust the language of their drafts and, if something slips through, to catch things on IETF Last Call. If documents with problematic language get through to the IESG, I hope the IESG will catch those problems and push back but that they will also examine why problems got through to them --how things failed at earlier stages of the review process-- with an eye toward looking at ways to preventing recurrences [1]. And I think we should be very careful to not create official "bad vocabulary" lists or formal mechanisms to enforce them. We should also be careful that people don't set themselves up as arbiters of what some other group would find offensive -- that is ultimately either as demeaning of that other group and its inability to speak up for itself or an indication that the IETF has become toxic for that group in a way that discourages them from speaking up. The latter is not a problem about vocabulary and, should it occur, our dealing with it effectively is probably far more important than vocabulary issues. That won't solve the problem of vocabulary that might be offensive to people from populations who have no presence in the IETF but, as others have pointed out, the solutions to that lie in more outreach and diversity rather than trying to narrow our language to eliminate anything we think might be a problem for someone else. The other advantage of that approach -- simply expanding our existing mechanisms for developing and reviewing documents rather than inventing a new system or mechanism-- is that it is also well-adapted to reasoned discussions about what to do about language in older documents that we might object to today, decisions that will certainly have to be made on a case by case basis considering the disadvantages of trying to change established usage. Of course, if we can't have reasoned and reasonable discussions on these topics (again like technical ones) we either need to educate people and fix that problem or we should consider whether the IETF has outlived its usefulness. Finally, I think we should thank the authors of the I-D and the IESG for bringing the issue to our attention and stimulating this discussion (regardless of what I think of the timing). It is just the solution to which the I-D seems to point that seems entirely inappropriate for the IETF (and for any other body that wants to be broadly and internationally sensitive to the broader issues, not just a particular list of bad words. If I am misinterpreting the intent of either the authors (who have been surprisingly quiet in this discussion) or the IESG, I apologize and welcome corrections. And now, having said that twice in different ways recently, I'm going to retreat into trying to get other work, some of it technical, done. best regards and wishes to all, john [1] Something we often (probably not often enough) tried to do when I was on the IESG a quarter-century ago wrt technical issues and that I think the IETF would be a better place if the IESG were doing a lot more of now with technical issues as well as choices of vocabulary or the like. If we could view every single issue that gets through IETF Last Call but is then grounds for a DISCUSS in the IESG as a sign of a process failure that the involved ADs are required to investigate and suggest ways to prevent the next time, we'd see a more smoothly-functioning IETF, fewer documents tied up for extended periods after IETF Last Call, and probably even less generalized rancor. (Now we get to see who has read this far :-( )
