 Hello. Welcome to the Inclusive Naming Initiative. There will be Q&A at the end of the session. Please raise your hand if you have a question or put it in meeting play. After the session, please don't forget to rate the session on sketch.com. Now, please welcome Celeste Horgan. Hello, everyone. My name is Celeste Horgan. I am one of the co-founders of the Inclusive Naming Initiative, along with Priyanka Sharma, who is not in the room today, and Stephen Augustus, who is in the room today. I am a staff technical writer at the Cloud and Native Computing Foundation by day, and I also run the initiative as a part of that purview. So a little agenda of what's going to happen. We're going to go over what the Inclusive Naming Initiative is, how we work on things. I'll give you a little demo on how we create a recommendation. We'll go through what we've done, what we're working on, and how your company can actually help and get involved in a concrete way. So what is the Inclusive Naming Initiative? The Inclusive Naming Initiative's mission is to promote and facilitate replacing harmful and exclusionary language in information technology. We are acting as a clearinghouse to collaborate and discuss DEI efforts. We were officially founded in June 2020, and as of earlier this year, are now a Linux Foundation-directed fund. All of our own. Applause, please. We have over 300 contributors from various different companies. Most are contributing just on their spare time, actually, as well as contributions from Cisco, Microsoft, IBM, Red Hat, Splunk, Canonical, Akamai, Gessmer, Optigrove, LLP, and many, many more. This is project leadership. I apologize for the slightly small font. The real takeaway from this slide is everybody is really cute. So a little bit about how the Inclusive Naming Initiative works, because this is a very high-level and kind of weird topic. What we're really set up to do is to produce language recommendations, push those language recommendations into open source projects, into individual companies, and hopefully into standards bodies. There are two main ways that we take in recommendations. One is from the work that individual companies are already doing. So one of our major contributors in that respect has already been IBM, who has a very active internal language group. So it's taking recommendations that that group has done and helping them open source it, essentially. And the other thing that we do is because this is an initiative that tends to attract a lot of writers, producing recommendations of our own that are based on consensus and subject matter expertise, that companies that are smaller, that don't necessarily have a writing department, can then use to essentially outsource that kind of work. Something that we've discovered in the year or so that we've been doing this work is that there's a lot of companies who are very, very desperate to help out to do better and to really improve kind of their language situation, but they don't have the expertise and how to do it. So a bit of a dual-pronged effort in that regard, it's one, helping larger companies take their work open source and bring it to the community, and it's helping community companies by providing a place where they can acquire those recommendations and have a conversation around DEI stuff. What we're working on right now, as I mentioned, language recommendations, that's kind of the bread and butter here. We have three sets of recommendations based on the severity of the term involved, as well as how embedded something actually is in a particular computing system or how complicated would it be to actually remove and replace something. Something we're also producing is guidance for companies and open source projects on how to implement language changes without breaking the world and how to advocate for them in different organizations. Open source and sort of enterprise companies are very, very different spaces for this kind of things, and the consensus-building process is very different. The third thing we're doing is outreach to standards bodies like the IEEE and IETF to try and push these consensus-based recommendations into the work that they do to produce standards. One of the risks involved in changing language and why people are often very resistant to it is because they have to adhere to standards bodies, and if they change the language that is defined in the standards, then they're off-standard, and then the entire product doesn't do very well. We're hoping to sort of start influencing standards bodies through the effort. I'm going to break for a little bit and demo a little bit of how we work on a language recommendation. I would say the largest component of people who contribute to IEEE are technical writers. We work with actually not one but two taxonomists, which is a job that exists only in very strange corporations like IBM, but also any corporation where they have a lot of terminology that they need to manage centrally. So IBM is one of them. Blizzard Entertainment, the games company, also hires a terminologist, interestingly enough. So the bread and butter of how we work is a sort of language change. Early in 2021, we went through the process of surveying our members and contributors to see what work they were doing internally in their companies around making more inclusive language recommendations. What we were looking for when we went through this, and we have many hundreds of lines of responses, was consensus. What were multiple companies looking to recommend and change? So you have an example here of the word bulletproof, which we turned up sort of three times in our survey. Chinese Wall turned up a couple of times from a couple of different companies. Cripple turned up many other times. We're going to follow bulletproof through its recommendation cycle. So first things first was gathering this information from our members. At this point, this spreadsheet is probably like a few months old at this point. So at some point, I imagine we'll do another survey, but that's not on the road map right now. From there, we kind of consolidated our recommendations and started picking them apart to see who's going to do what work. From there, this went directly to the language workstream where we started the work on the actual recommendation. We have a sort of template that we follow for these recommendations. And this document is actually not particularly marked up, but after writing the recommendation, there's usually a smaller group of us who work on any one recommendation. We send it out to the larger language workstream for review where there's usually a lot of discussion and a lot of long tail around this. Once the language workstream has had at it for a few weeks, we then open a pull request in our website repository. And the broader initiative of around 300 contributors then provides its comments. And once again, there is an incredibly long tail around how that works. Once things are merged, and I'll just sort of go through this real quick, they land on the word list that we produce. So like I said, the entire point of this is to drive sort of consensus based recommendations. The other thing that we're really looking for here is to categorize things into tiers, things that need to be replaced immediately because the harm they provide in terms of language is so strong, things which you should probably consider replacing, and things which are not great, but they aren't nearly as egregious as the other two. So we currently, I'm not actually sure about the total of what we have published is now. But you should definitely take a look at the word list, take a look at the overview, so you understand the process a little bit more. And while you're on the website, also take a look at the language evaluation framework to understand how we decide what is harmful and what isn't. So that's a little demo of how the entire process works. It's really just a document drafting process. It's not particularly mysterious, but it does involve a lot of discussion. If you're interested, we have some open recommendations for you to review and participate in. Blacklist, whitelist, we are revising our initial recommendations based on the donations of the IBM Words Matter Working Group. So thank you to IBM and to Carl the Quinn in particular for that. We also have, as you saw, a bullet proof recommendation open. And these last two are a little bit of a fib because we closed these just earlier today for sanity check and sanity test and segregate. However, the language work stream is something that kind of eternally needs contributors. So if you are interested, please join us. You can find meeting times and meeting locations on the website. As I mentioned previously, we published things into three different lists. They are categorized both on the severity of the term involved as well as how difficult something would be to replace. So a great example of this is the term abort. Abort is not a great word to be using. For people for whom it's harmful, it is actually very triggering. However, it's very deeply embedded in operating systems like Linux and that is very, very difficult to replace and should be approached with caution. Comparatively replacing your GitHub main branch, which might be titled master with something more like main, fairly high impact in terms of the terminology, but a lot less tangly, particularly at this point because of the work that GitHub has done around that to do so. So take a look at that work when you're ready. So one thing we've received in the various presentations that we've done in terms of feedback is that companies are looking for really concrete advice on how to launch an inclusive language program within your company. So the second half of this presentation is going to go through that. If you are working in a private company and you are thinking, wow, we're using some real bad words and I'd like to use less bad words, the thing that I would like to drive home to you is that this is a consensus driving process. I am a technical writer and usually when things like this happen, people look for the writer in the room. They said, oh no, we said something bad. We got to find the writer, just learn how to say something good. Yeah, simple, simple, right? But the thing that I would drive home to is that your writers are often not empowered to be decision makers. So to succeed in an initiative like this, you need to empower your writers. And the way that you do that is by having high-level management sponsorship. So at the Linux Foundation, we have Priyanka Sharma, who is our sponsor and who is sitting in the back. Hi! So if you wanted to quietly see a rock star in this conference, she's snuck into the room. Don't tell anybody, I'm sure she's trying to hide. But you have to get really high-level buy-in for management for this kind of thing to float because if you don't have buy-in for management, they will tend to think you're wasting your time. If you work in a tech company, which I assume most of you do if you're here at KubeCon, the other thing you really need to do is find a high-level technical sponsor, particularly when it comes to changing code bases. And particularly if you're not the person who owns the code base, again, as writers often aren't, you need extremely senior-level technical sponsorship for this kind of initiative or you will run into some very angry engineers. Luckily, again, as we've discovered, there are all sorts of people out there who actually do really want to help. You just need to find who they are and bring them into the room together. The next is to start diving into it. What terms do you want to replace? What are you going to replace them with? What do you need to update to replace those terms? Do you need to touch code? Do you need to touch documentation? Are there APIs that are exposed to your customers? Are there marketing materials? Internal company policy documents? Do you follow standards organizations or all of the above? And what realistically can you actually tackle? The example that I'll give is Kubernetes, which imports Go modules into almost every single repository. And those Go modules don't always have the greatest words because we don't have control over what Go does. It's not necessarily feasible for Kubernetes project owners to go in and try and change Go. That's not the best use of their time. So you have to figure out where your limit is. Finally, how far back are you going to go? Are you only going to update materials going forward or are you going to just deal with or are you going to go all the way back, basically? So you decide your scope, get by and from your managers. The next prepare policy document for dissemination within the organization to essentially tell people this is what we're doing. This is what we are and aren't going to change. Communicate the policy and kind of get your people together. Start designing roles and start actually tackling the action plan aspect of that. Particularly from a technical aspect, be very, very mindful of dependencies and you need to make sure that testing is incorporated into every step of this process. When you're going around securing buy-in from your sponsors, be prepared to have some really difficult conversations with people who may not understand the importance of this or they may only partially understand the importance of it. I think it's safe to say I don't know that I fully understood the importance of this when I started this work. You can grow through it and that's fine. Some people understand immediately. Some people may not understand but are willing to learn and some people may be resistant. A few other things to consider as you move forward, sponsoring underrepresented minority groups in your companies and connecting them to your writers is a great idea. Building inclusivity into your business processes is also a great idea and requiring your vendors to use inclusive language in the products and documentation they supply to you will all go a long way into not introducing that language into your companies to begin with. In conclusion, how can your company help the Inclusive Naming Initiative? As I mentioned to some people earlier, we are a Linux Foundation Directed Fund as of earlier this year which means that we are seeking sponsorship. So reach out to us at sponsorship at InclusiveNaming.org for more information. It's a pretty neat way to get involved in the Linux Foundation community in my opinion. Join our company work stream and take our new training course, LFC 103 Inclusive Strategies for Open Source. Here's a list of resources and ways that you can kind of get a hold of all of us and that's it. Thank you all for your time. Thank you.