Summary: Has a BLOCK. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Do we approve of this charter?"
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.)
I present my own comments (as shaped by the community feedback) on the proposed charter text, followed by a summary of comments the IESG received. > The mission of the IETF as specified in BCP 95 is to produce high quality, > relevant technical documents that influence the way people design, use, and > manage the Internet. IETF documents, including RFCs and Internet-Drafts, are > most effective when they use terminology that is clear, precise, and widely > accessible to readers from varying backgrounds and cultures. This maximizes the > benefits the IETF derives from its core principles, such as its open process and > volunteer core. > > In the years leading up to the chartering of this working group, there has been > discussion in the IETF, in other standards organizations, and in the technology > industry about the use of certain terms (such as "master/slave" and > "blacklist/whitelist") in technical documentation and whether those and other > terms have effects on inclusivity. While opinions vary among IETF participants Given the difficulty in pinning down "inclusivity" (as compared to measuring "exclusivity"), perhaps "have an exclusionary effect" is a more precise way of expressing an equivalent question? > about this topic, there is general agreement that the IETF community would > benefit from informational recommendations about using effective and inclusive > terminology in IETF documents. Perhaps "benefit from advice and guidance on using effective terminology in IETF documents while minimizing exclusionary effects"? > The TERM working group is therefore chartered to produce an Informational RFC > containing recommendations on the use of inclusive terminology in the technical "advice and guidance" again? I also am not sure about the word "inclusive" here. It seems like it may have value in that it is becoming an established term of art in some communities, but what is lost if we just go with "on the use of terminology"? > work produced by IETF participants. The RFC will express general principles for > assessing when language is inclusive or exclusive. The principles should match This seems like it may be a false dichotomy (though I do note that the word "either" does not appear); some terms are neither inclusive nor exclusive. > the expectations from a diverse set of IETF participants. The WG will identify Is "should" an actionable requirement? > and recommend an external, independently-updated resource containing examples of > potentially problematic terms and potential alternatives to IETF participants, I a little bit wonder whether the emphasis should be on the potential for problems or on a recommendation for careful consideration prior to usage. It may not matter in the end, though, but any way we can reiterate that this is not a list of banned words is worth some consideration. > in order to align its efforts with broader activities by the technology > industry. > > The TERM working group is a focused group aiming to produce a single > deliverable. It is designed to complement other efforts at fostering inclusivity > in the IETF and will liaise with appropriate external groups, such as other SDOs > or industry initiatives, to coordinate. %%%%% The IESG got a significant amount of feedback on this proposed WG charter, and I think it is valuable to try to synthesize that feedback into a somewhat high-level (albeit extended) summary of the thoughts that were expressed by the community. I'm recording this here in my ballot position on the charter in order to provide a record of the feedback that was received and as a reference by which to evaluate the output of a WG (if approved). Some of the comments were sent directly to the IESG, and my initial notes did not track which messages were also posted to terminology@ and/or ietf@, so I will not provide attributions for the statements. (Most of them are not direct quotes anyway, and in a reassuringly large number of cases a similar sentiment was expressed by multiple people and I have synthesized it into a consolidated representation as part of the summarizing process.) We got some "support with no comment", and some "oppose with minimal comment", but as always, such opinions divorced from supporting reasoning does not add much weight to a determination of consensus. The main bulk of this writeup focuses, accordingly, on the actual comments received. Having constraints in the charter is useful. There is a sizeable chunk of work that looks attractive but we are not equipped to do properly and should not try to do. For work that is claiming to foster inclusivity, the effect so far just of talking about the proposal has been rather divisive (i.e., counterproductive). That might call into question whether the endeavor should be attempted at all, but it is possible that the act of reaching consensus on a charter and starting a WG can bring a fresh start to the discussions and move the focus away from the particularly contentious matters that are not even listed as deliverables in the charter itself. On the other hand, though, we must acknowledge that this work has the potential to destroy the IETF from within if mishandled, and that there is additionally risk of organizational harm from outside the IETF, if we attract the wrong kind of attention. That said, we got enough messages of support and indicating that the charter as written is good enough to proceed that I am willing to have us attempt the experiment, but expect the responsible AD to pay attention to how the work proceeds and the milestone deadlines; if it ends up unworkable we should close the WG rather than let it linger. Looking further in the past for inspiration, we heard that one outcome from POISSON was a desire to avoid broad/divisive topics if possible, and that POISED was an interesting case where there was such a clear need to make a change in how we work that seeing the change drive contributors, even prominent ones, away was seen as an acceptable cost. Such a consensus is not readily apparent for the current terminology topic, so drastic change is probably not a workable outcome. As far as the output of this WG goes, it's more useful to offer broad guidelines and patterns for use by document authors, so that we are equipping authors to make their own decisions, rather than to give specific (and potentially too narrowly scoped) advice on what to do or not do. Analysis of the landscape, explanation for why things are (dis)recommended, and guidance are good to provide, but specific direction and rules should be avoided. We don't need the result of this WG to be an immediate drastic change in what we produce, and it's best if the change is driven by individual participants and authors as we go about our work. In some cases, big change may not come about until the next iteration of a spec or even the next protocol comes around, but we will have a direction to work in. The output should be advisory only, and invidual WGs will remain in control of their output. This is, of course, only one of many issues that we face; probably not even the most important one. The IETF's "rough and tumble" culture of sometimes confrontational debates is probably a bigger barrier to inclusivity than the terminology we use in our written output. However, that doesn't mean we can't or shouldn't think about it or that we shouldn't a priori take action on it, even as we also take action on other fronts. Looking further in the past for inspiration, we heard that one outcome from POISSON was a desire to avoid broad/divisive topics if possible, and that POISED was an interesting case where there was such a clear need to make a change in how we work that seeing the change drive contributors, even prominent ones, away was seen as an acceptable cost. Such a consensus may not exist on the current terminology topic. We heard from many people that the charter text as-is is mostly reasonable, but there are many potential pitfalls not listed in the charter that still need to be avoided. For example, don't create language police, don't make recommendations about word usage that are too broad and exceed their scope of applicability, and don't exceed the WGs scope of expertise, especially if there are other parts of the IETF that would do better on one thing or another. The choice of chairs is especially important, both in their neutrality and their ability to maintain focus and avoid devolving into proxy debates on out-of-charter hot-button issues. In addition to the WG chairs, the IESG as well must neutrally arbitrate whether the process was followed, and not impose their own preferences. For a non-technical topic like this that has already seen controversy, even having the same IESG that approved a WG be tasked with assessing its consensus could be seen as problematic, especially if the WG approval process was swayed by the IESG or IESG members. It is most definitely not allowed for the IESG to push through something that lacks community consensus, even if (as may have happened for NEWTRK) the IESG might be within its rights to decline to publish something that does have consensus or for which the consensus status remains unknown. The question of such heavy involvement of the IESG in a matter that does not have many technical issues to adjudicate leads to a question of whether other mechanisms for assessing consensus could be used for this group or this topic, including whether an IAB program or RFC Editor-driven activity might be more appropriate. This topic was raised and endorsed by many people. While we have a pretty clear answer that the IETF stream *can* choose to apply more stringent rules than the RFC Series as a whole, the question of whether or not we *should* seems a little under-addressed. A couple of people replied on this topic specifically supporting doing the work (now) in the IETF, but many fewer people than were participating in the overall discussion. In a related note, the concern was raised that having the IETF present a fait accompli here might constrain the work of the ongoing RFCEFDP activity, which is supposed to be a broader scope than just the IETF. In a related vein, it's possible that RFCEFDP itself could lead to the emergence of a stronger RFC Editor function with a mandate to push back on the streams and actually apply editorial judgment. Such an RFC Editor function might be well placed to effect change on the terminology front and obviate the need for an IETF WG, but we don't have much way of knowing whether we will get such an RFC Editor function. TERM is not really a technical group in our usual sense, as is acknowledged by the previous paragraph. Yet there is also risk that for work in this space, an informational document will end up being a de facto BCP that is enforced just as strongly as any process BCP we produce, and we have ample reason to be concerned about falling into a scenario (regardless of exactly how) where there is active control being imposed over what terminology is used and policing to enforce it. No matter what kind of caveating language we might put alongside it, having any kind of list of "bad words", whether internal or externally maintained, poses risk of authoritarianism and a bad outcome despite good intentions. This leads to the question: do we want to maintain a list of terms, whether general or focused to our particular expertise and then augmented by a more generic list? Do we want to use a list of terms at all? If there is to be a list of terms, it should be picked based on community consensus, unswayed by the IESG. If maintaining a list of terms is to be out of scope for the WG, that should be clearly and explicitly stated in the charter (Lars thinks that the IETF maintaing a list of terms is intended to be out of charter for this WG). Interestingly, there is already a list at https://github.com/ietf/terminology (not maintained by this not-even-a-WG, of course), and it seems unlikely to go away and should probably get some further disclaimer or a path towards actual maintenace and official status. My understanding is that the github repository is not proposed to be a WG activity in the current charter, but this is still a good time to think about its long-term status. We are behind the curve compared to other SDOs and companies. This is not inherently bad, but we should probably default to the trodden path and only diverge when we have strong justification, even if some other option might be better in a narrow sense. There is value in alignment with other groups, for efficiency of communication among other reasons, though just as we do not rubber-stamp external technical specs, we should also be able to justify our choice if we adopt externally developed approaches on the terminology front. In a charter for a group about terminology, the specific terms in the charter seem like they may merit further consideration. What is "inclusive", after all? Most of what we discuss is about avoiding known sources of exclusivity, but merely avoiding exclusivity does not itself bring inclusivity. Likewise, what is "effective"? Effective at conveying technical intent, or effective at being inclusive, or both? "Recommended", for this audience, has connotations of BCP 14 language, but perhaps we really only intend to offer advice and guidance. Is it in scope to discuss what terms with "cultural baggage" might be unevenly accessible to IETF participants?
As Ben's position noted, there is still community feedback to process.
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.
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.
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.
Nit: I don’t think “Internet Drafts” needs a hyphen.
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.
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... ]
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) , 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 , and countless emails ), 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  https://mailarchive.ietf.org/arch/msg/gendispatch/iHDh7KBVRvGB2EWKYYh11LjP95E/  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/  https://mailarchive.ietf.org/arch/browse/gendispatch/?q=terminology (excerpt, I know there is more)
[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