idnits 2.17.1 draft-gondwana-effective-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 August 2020) is 1337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GENDISPATCH B. Gondwana, Ed. 3 Internet-Draft Fastmail 4 Intended status: Standards Track 25 August 2020 5 Expires: 26 February 2021 7 Effective Terminology in IETF drafts 8 draft-gondwana-effective-terminology-01 10 Abstract 12 The IETF and the RFC series are trusted names, for producing high 13 quality technical documents that make the Internet work better. 15 While the success of our documents is variable, many of them are 16 widely used over a long time period. 18 As norms in the outside world change, our documents need to remain 19 relevant and accessible to future generations of those working on the 20 internet, everywhere in the world. 22 This longevity of our documents, and the impossibility of predicting 23 the future, implies that we should be conservative in the language 24 that we send. Effective language expresses our intent with clarity, 25 and without distraction. 27 This document describes a glossary for increasing awareness of terms 28 which are going to be clear and effective without turning readers 29 away, to enable our mission of making the Internet work better. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 26 February 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Adapting to a changing world . . . . . . . . . . . . . . . . 3 66 2.1. Words have multiple meanings and change meanings over 67 time . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Words can encourage or discourage participation . . . . . 3 69 2.3. Analogies change meaning over time . . . . . . . . . . . 4 70 2.4. The best time to plant a tree is 20 years ago . . . . . . 4 71 3. Change is not always necessary . . . . . . . . . . . . . . . 4 72 3.1. What we're doing is generally working . . . . . . . . . . 5 73 3.2. We will naturally follow emerging consensus in the wider 74 world . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. How to choose terminology for our documents . . . . . . . . . 5 76 4.1. Engineering considerations take priority . . . . . . . . 5 77 4.2. Avoidance of "pixie dust" . . . . . . . . . . . . . . . . 5 78 4.3. Decentralised control . . . . . . . . . . . . . . . . . . 6 79 4.4. Centralised knowledge . . . . . . . . . . . . . . . . . . 6 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 86 1. Introduction 88 The IETF, and even more so the three magic letters "RFC", is a 89 valuable brand. This brand is valuable because we have produced many 90 documents over the past 50 years which have helped others 91 interoperate, and have kept the decentralized internet reliable. 92 This is an amazing success, and a clear sign that we are doing a lot 93 of things right. 95 The IETF has no coercive power in the world, our documents are 96 adopted because of their quality and our reputation. The documents 97 stand on their merits, and we create change in the world through 98 persuasion and trust. 100 This is a large responsibility. We are keen to bring the benefits of 101 our work to as many people as possible, and to be ethical in 102 assessing our impact on the world (see [I-D.draft-iab-for-the- 103 users]). 105 In the same way that "Security Considerations" in every document 106 detail how we imagine our work can be misused, we also need to 107 consider ways in which our work can harm or exclude. 109 2. Adapting to a changing world 111 2.1. Words have multiple meanings and change meanings over time 113 While a word can have one meaning a technical context, it can have 114 other meanings which are highly distracting to the reader. A topical 115 example from 2020 is the word "Trump". In many card games, any trump 116 card always defeats every non-trump card which is played in the same 117 round. This idea is a very useful metaphor for any overriding 118 consideration that must take priority, but it is also the surname of 119 the 45th President of the United States of America, and many readers 120 will be distracted from the technical purpose of the document upon 121 seeing this word. 123 Likewise, words have different meanings in different cultures, 124 different languages, or to different groups of humans. 126 While we can't enumerate all possible words which are distracting, we 127 can avoid the ones we know. This naturally happens anyway as 128 individuals in working groups become aware of them, and it happens 129 more quickly if we crowd-source change. 131 2.2. Words can encourage or discourage participation 133 It is human nature to look for encouraging or discouraging signals 134 when interacting with any group, particularly at the start. We look 135 for signals to see whether we are welcome, and whether we will be 136 treated fairly. While we can't predict how everybody will react, 137 there are broad strokes where sending a signal can encourage 138 participation. 140 Our documents are effective when the rest of the world trusts us to 141 produce quality work, and wants to use that output. If we use words 142 that turn people away who are writing standards, they will do their 143 work elsewhere. If we use words that turn people away who are 144 reading standards, they will bypass us and look for standards 145 elsewhere. 147 We remain relevant by being persuasive and welcoming to the largest 148 possible audience. "Virtue Signalling" has a dirty name, but 149 "welcome signalling" is valuable to the extent that we follow up by 150 actually welcoming new people and being a place where they want to 151 participate. Thoughtful choice of words to use is part of being 152 welcoming. 154 A diversity of new people with different backgrounds contributing to 155 the IETF brings new ideas and new knowledge, and is valuable when 156 their contributions are technically sound and in line with our 157 mission. 159 2.3. Analogies change meaning over time 161 In the year 2020, the icon for "save" is still an image of a floppy 162 disk, though there are more software users every year who have never 163 actually used a floppy disk. 165 Generally, changes in meaning will come from outside the IETF, and be 166 organically taken up by authors who are building documents that they 167 hope will last. 169 2.4. The best time to plant a tree is 20 years ago 171 The full proverb is "the best time to plant a tree is 20 years ago, 172 the second best time is now". While it is costly to change 173 terminology, or to replace an existing protocol, it will only be more 174 costly in the future! 176 This analogy does not always hold. We can't do all possible work at 177 the same time, so just because something has some value does not mean 178 that it's the most valuable use of our time. 180 However, just because something will take a long time or be costly 181 does not mean that delaying it or not doing it is a better choice. 183 3. Change is not always necessary 184 3.1. What we're doing is generally working 186 It is easy to criticize various parts of how the IETF functions - 187 nobody thinks we're perfect in every way - however we are achieving 188 our mission quite well. It's important to stay grounded in that 189 reality and acknowledge that while we may be able to do better in 190 certain ways, what we have right now is pretty great. 192 3.2. We will naturally follow emerging consensus in the wider world 194 When a technical word happens to match a word which is harmful in 195 other contexts, it does not always turn away a significant population 196 who would otherwise both engage with, and add value to, our 197 community. 199 Where a consensus is developing in the wider world about a term, it 200 will follow that reviewers, both inside working groups and during 201 last call, will notice those terms and flag them as possible concerns 202 to the authors. 204 4. How to choose terminology for our documents 206 4.1. Engineering considerations take priority 208 Sound engineering judgement and compatibility with deployed systems 209 are primary values that serve us well. They are why our documents 210 are well regarded and continue to have value. 212 Solving difficult problems can be uncomfortable. While we don't want 213 to deliberately make people uncomfortable, correctness must be a more 214 important value than keeping everybody comfortable, to retain the 215 quality of our work. We must embrace conflict to be able to solve 216 difficult problems, while ensuring that we debate the technical 217 issues, not the person raising them. 219 Our documents are the bedrock of the internet. While fashions change 220 in tech quite quickly, we should strive to be as timeless as possible 221 with our designs, so that we don't need to revise our work 222 frequently. 224 4.2. Avoidance of "pixie dust" 226 Technical terms are often chosen based on analogies from civilian 227 life. 229 No analogy is 100% perfect. There are always tradeoffs with novelty, 230 searchability, accessibility and confusion potential. 232 Where an existing term adequately describes a concept, it is 233 preferable to use that term. If there are multiple terms for the 234 same thing, the best choice is one least likely to cause confusion. 236 4.3. Decentralised control 238 Those closest to the document are best placed to know which terms are 239 in wide use within their own fields, and will be best understood. 241 The work is done by those who show up. 243 It is incumbent on the authors to treat feedback on terminology from 244 the working group, and from other reviewers, in the same way they 245 treat technical feedback - soliciting advice and making choices in 246 the best interests of the IETF, the Internet, and the long-term 247 success of their document. 249 It is incumbent for those reviewing and wishing to provide feedback 250 to understand the scope and history of any technical term, and not 251 just match on keywords and provide no other contribution. 253 Final term choice always rests with document authors. The mechanisms 254 for objecting to that are the same as for technical choices - a 255 competing draft with different authors, or failure to form consensus 256 and progress the document. 258 4.4. Centralised knowledge 260 The entire IETF is best placed to have an overview of which terms 261 have different meanings in other contexts and may generate unwanted 262 side effects. 264 It would be valuable for a group within the IETF to maintain a 265 glossary of terms, with both their technical meanings and other 266 meanings in different cultures, professions, or languages. 268 This document should reference other similar documents produced by 269 non-IETF groups, in order to align our language with the rest of the 270 world. 272 This resource would be useful for authors and working groups - both 273 for words to avoid when coining new technical terms, as well as to 274 avoid creating multiple terms with the same meaning. 276 5. IANA Considerations 278 This document does not ask the IANA to do anything (unless we decide 279 that IANA is a good place for a central glossary to be kept) 281 6. Security Considerations 283 Bad faith actors can already interrupt the consensus process by 284 raising spurious and unsubstantiated complaints that look reasonable 285 at first glance. 287 To the extent that claims of harmful terminology are harder to prove 288 or evaluate than other claims, this makes it easier to derail the 289 IETF from its mission, and to use the IETF's brand as clout in 290 political battles. 292 Working Group Chairs and the IESG should be wary of changes to 293 terminology requested by those with no relationship to the work being 294 done or interest in evaluating the tradeoffs being made. 296 7. Changes 298 EDITOR: please remove this section before publication. 300 The source of this document exists on github at: 301 https://github.com/brong/draft-gondwana-effective-terminology 302 (https://github.com/brong/draft-gondwana-effective-terminology) 304 *draft-gondwana-effective-terminology-00* - my initial suggestions, 305 probably needs lots of review and I imagine I've missed a lot. 306 Please give kind feedback! 308 *draft-gondwana-effective-terminology-01* - based on initial private 309 feedback, trimmed the "Background" section entirely and simplified 310 some wording. 312 8. Acknowledgements 314 * I'll fill this section out once this is public and based on public 315 feedback. 317 Author's Address 319 Bron Gondwana (editor) 320 Fastmail 321 Level 2, 114 William St 322 Melbourne VIC 3000 323 Australia 325 Email: brong@fastmailteam.com 326 URI: https://www.fastmail.com