 Thank you for making the trek almost to Canada to get to this room. I really appreciate it. Good job, everybody. Give yourself a hand. But yeah, I'm here to talk about inclusive accessible tech. I almost combined those two words. But I wanted to talk about how do we do this work? How do you get to bias-free language? How do you get to that all the way into your code and configurations? So, but I want to start first with a, everyone is welcome. We do have to talk about words that are hurtful. I do have to use language that is hurtful, and I have to use it in almost a bland way because we're talking about these topics. So I'm sharing my efforts. I'm talking about this very openly, but I want to make sure you know there are other ways to get this information. I've already uploaded the PDF. So if at any point you get to a point where you're like, I can't listen to this anymore, or I want to get this in another way, please feel free to get it in another way. And I'm not trying to scare anybody off, but I do just want to make sure everyone knows, everyone's welcome here. This is an open space and it's a safe space. We want to talk about this openly. So, hi. I'm Ann Jennell. I work in developer relations at Cisco. And I live in Austin, Texas. We work with many teams across Cisco. We have a pretty large portfolio of APIs. And we like to make sure that Cisco APIs are getting better and better all the time. So we work collaboratively with teams and we treat docs like code across a lot of GitHub repos. So we manage a lot of code and we manage a lot of content. So hence my interest in a lot of inclusive language. So I've been pretty fortunate and I've been able to do this work almost as a side hustle at Cisco, but I'm here to tell you about how we've put it into part of our everyday work and how it fits into our social actions and how we can, you know, talk about how it works into diversity and inclusion at Cisco. But this is what I'm going to do as an overview. We're going to talk about our social justice journey at Cisco. Try to give people some ideas how it might fit into your own company, into your own organizations. I'm going to talk about how that works as policy to practice. That's not easy, but there are practical ways to go about it. And then I'm going to give some practical examples, code and configuration, what we've observed, what I've observed out in the wild, and how we're tackling it. And then I'm also going to give some resources that we have available that we're trying to share so that others can work with us on this problem with us. But first I just want to start with what we have as our sort of guiding principle. At Cisco, we really do have a tagline that is powered inclusive future for all. And so this is the opportunity in front of us. And I don't think it's just for Cisco. I think it is all for us in tech. We can lead this. We can guide this. We have this obligation because we have the privilege. It is our responsibility. We can do this because we work in technology and we can bridge these gaps. We can do this work. It is daunting. I won't doubt, I won't put any, you know, I won't gloss over how hard this work is. But I think that it's part of our responsibility, part of what we can do. And I think it is really important work. So at Cisco, we've actually put this into social justice actions. There are 12 at Cisco. We're down at the bottom, human rights in technology solutions. And that is split into three areas. So social justice and product development has three parts. There is human rights by design. That is a group that goes to product teams, does training, talks about have you considered these human rights parts? Have you considered how to work with the communities you're in? And just make sure that the whole product development life cycle has that in mind. Then there's also accessibility by design. So that is where you make your product accessible maybe by screen readers, maybe by making sure that it's accessible to someone with some sort of, you know, keyboards aren't as accessible to them, right? So it's putting that into the product development life cycle again. And then the one that I'm working on and talking about today is inclusive naming, inclusive language. So we're working on implementing a policy. I'm going to talk a little bit about what that is. We are trying to also build this into the employee culture, right? So build it into awareness, make sure people know about it. People know what to do if they see something. People know how to get involved. And then drive compliance across different functions. That could be in legal, that could be in product, that could be in our partner organization, it could be in training, it could be in documentation. There are a lot of areas to think about this. And when you start to think about the scope, yes, it does get pretty big. But we're here to work on that, right? Put it into bigger, to smaller buckets from the bigger, bigger picture, right? And then of course, we need to share best practices across Cisco and figure out who's working on this in different areas, right? And then we want to build that governance model. We want to make sure that people can feel like they can take a framework and build with us, so. And I'm only talking about language and naming mostly today, but I do want to point out that inclusivity and language can encompass multiple aspects, right? There's gender neutrality. Gender is not binary. So there's ways to write and ways to use your language in ways that don't make it a binary thing. And I think that a lot of the technology industry has gone to using they as the pronoun. Oracle, Cisco, a lot of technical style guides have gone that direction. And then also just trying to use respectful language, don't draw on stereotypes. I think this has become much more apparent to me as I've studied this. Powwow, Tribe, some of these other ones where I just hadn't thought before, oh, that is drawing on a stereotype. How can I, you know, actually realize where that came from? So I've become more thoughtful about the language and the root. And then people first, I have a son with type one diabetes, and it's not that he's a diabetic. It's that he has diabetes. And so that's the point with he's not his diagnosis that doesn't define him. He happens to be someone who has that. And then also this one really catches me a lot. Idiomatic language and another, this is another case where I'm, you know, I live in a pretty, you know, like privilege world, pretty English centric world in idiom, like up in the air makes no sense to an English second language person and pointing out plain English and just writing better more plainly. I'm an author and this still has to be pointed out to me. So thank heavens for, thank heavens. I don't know if that's an idiom either, but just being more aware of the things that you take for granted that just might be part of your everyday speech. But does someone else who hasn't, you know, heard that, or they have to think like, up in the air, what does that mean? So just being aware of that. And then I already mentioned the accessibility, right? So what would this look like to a screen reader? And I recently learned even with using alt text, which we probably all know that you can label your images with alt text. What I recently learned is that you should also put a period at the end of those because then the screen reader knows to pause and stop reading. So what about this? What about policy to practice? So in our case, we have four terms, master, slave, white list, black list, and we have recommended replacements. We've also put together like a WebEx room where people can come to us if they're like, this doesn't really match. I want a different recommended replacement. Can you work with us on this? So we have provided that sort of centralized, you know, rewriting as a service, I guess you could call it. But I also wanted to point out the inclusive naming initiative has language recommendation lists. So these are word lists that they've actually split into different tiers. So if you're just getting started, if you don't really know where to start, these are a good place to just get started or just start people thinking about what words might be the most crucial to get in there and think about replacing. So they have tier one, which is replace immediately. And then tier two, strongly consider tier three recommendations. And they are, you know, sort of continually adding to this list. I have opinions about this, but I do think it's a good place to start. And then another really helpful thing about these word lists is there's also a list that's no change recommended. And I think this is also where we get a lot of questions where, you know, is it important to talk about a master's degree as something that is about mastery? Well, then do you need to change it? It's not in a master's slave or, you know, connotation. So do you not change it? So there's good discussion in there about that too, where you can take that into your organization, take that to your teams and have that consideration done, right? But here's why I have opinions. I believe these word lists should be considered almost like an API contract. So how an API is managed as something that a developer wants to write against for years to come. So they make it almost like a contractual agreement. I know I can write code against this API and it will work for years. The same thing can be should be happening with word lists where we would agree with this word list for this many years to come. And then we can work with our engineering teams and say, let's change this set of four words and you will have that work done by, let's say, December of 23. Then we will start to tackle the next set of words and that will be almost like the API contract where that work will be done by December of 24. And I'm hearing a lot in the industry that Microsoft, Oracle, Dell, some of the larger organizations, IBM, they very much operationalized this work. And so I think this is kind of how we should go as an industry where we're documenting this is when we'll change it. This is when we expect the words to be changed. And then it also means that we could insert some kind of backwards compatibility so that we will not break people because of the word change. And then it also kind of says, we're still doing the work. 2020 happened. Yes, we're almost into 2023. We need to show that we're continually still dedicated to this work. So compliance. This is an interesting word. And being compliant, well, you also have to define what it means. And I think that's also where I'm getting into the whole idea of like a contract, right? So products have input and products have output. So what we're doing is we are saying to be compliant, you will look for these words and eliminate them and rewrite them in APIs, in your user interfaces, in your command line interfaces, as well as internal code. So no one should have to type, you know, get checkout master every day. That's just something that we shouldn't have to do as engineers, right? Then there's also the output. So log files, telemetry data that comes from products. Cisco puts out a lot of that, right? So we also want that to be compliant with the policy. So now we're able to tell teams and engineers want to know what this is defined as. Compliance means all of this is compliant. All of this can be clear of all these words. Well, I tell you what, a really low-hanging fruit is to just put automation checks into your CI CD so that people can just check is the word in there, eliminate it, and at the same time, you're also making sure these words don't sneak back in. So this is what we're trying to do with teams. And then of course, once the products are cleaned up, then the product documentation can follow. But I'm here to tell you product documentation, if it's just using like an architecture diagram that has master slave in it, it could be rewritten if the product itself doesn't need to have that, right? So I think that's an important point, too. Product docs can work ahead of product in some cases, not all cases. Oftentimes, it has to follow the product. So that's what compliance means for us. You might define it differently with your policies. So now let's get into some actual examples. So what we've done is we've done inventory lists where we're going into categories. This lets teams plan on what they might prioritize first, second, third, what they might put under some sort of CI CD testing. In this case, this is just code. It's probably not externally visible, but we'll put it into category one. Next, there's category two. And this is the CLI API stuff that a customer can use, can see. In this case, you need to be more careful. You probably want to do a text alias so that you're deprecating the old and inserting a new, but you'll want to support both for a period of time. And so this is complex. This is the hard work. This is the nitty-gritty. Then there's category three, and that's that output from a product, right? And I have an example I'll show a little bit later, but you don't want to break people, but you can probably support all the new, and you can probably do a cutover at a certain version. I have an example of, you know, a response body from an API that's JSON, and you can just kind of do a rip the band-aid off. And then the last one is documentation changes. And like I said, some of these simple cases you can probably just do, but more complicated where they have to follow the CLI, where the config file has to change first, the documentation has to follow. So let's do an example. I went to our GitHub org, Cisco DevNet, and just did a search for slave. Looking at this, it's like, huh, okay, and that looks like it's in code. Looks like it's in a comment. I'm going to call it a category one. What's interesting here is I took a closer look, and it turns out that it's actually referring to a Yang model. And a Yang model is a standard in the industry that is used to describe network devices. So it turns out, even though it's a category one, I have more work to do to go to that standard's body and say, what is your policy? What is your standard? How can we work with you to help get our code compliant? Because in fact, we're going to have to go to the standards and work with them to get the term slave removed from the Yang model standard. So that's an interesting case. It's turtles all the way down. It's very complex. But it's interesting work, I'll tell you. And then I mentioned, you can start to search for these in your CI CD pipelines. And so this is sort of one of the steps towards that is where you would put it into your authoring, your editing, your code editor, your VS code. There's a VS code extension called Alex. And so what it can do is look for words like master and just say, are you sure you want to use this? There are alternatives. So it could be insensitive. Here's others to consider. And I think you can see there's another case where it says mental and it's underlining that as well. So it's just a way to get more aware while you're authoring. It's a step before putting into a CI CD pipeline to help people become more aware. And I have that example a little later. But then I promised an output example. And this one is an API field name. So again, this is in the REST API and it returns a JSON body. And so what they ended up doing is just in the version 7.0 it was master device. In version 7.1 it was control device. And they just went through their entire API output and decided these are what we're going to do and this is the release we're going to do it in. And I think this is probably the right way to do it because customers can then do just an if 7.0, do this, if 7.1, do this, terrible at pseudocode, sorry. But the idea is what you would want, which is you don't really have to support both because you can just do that kind of bandaid cutover, let people write their scripts so that it would be the correct one in 7.1. There's another interesting example that it is a category one example. This is a training course that we have on our site. And so you would probably look at that and say, yeah, okay, and that's documentation, right? But it turns out that it's interactive documentation. And so underlying all of this is a Docker container that the authors work on with sample code inside of it. So this ended up being an interesting case where in order to start using master branch instead of main, we wanted to not have to write around the whole thing where you do get init, you know, you do this special get config so that when you type get init, it uses main instead of master. Perfectly good things to teach people to make them aware. But at the end of the day, we wanted to just fix the whole course so that we didn't have to use a term master, tell people how to do that whole other thing. So we had to upgrade get in the container, we had to upgrade Python because of the other upgrade. It ended up being a lot of dependencies, but it's totally worth it because at the end of the day, this is the modern way of working with get. And so I think the students are getting the better way to work. And they're learning, this is the new way. This is the way the world works today. And then I promised I'd talk about, you know, how do you look for this in code? How do you keep it out of your code once you've already done the replacements? And so up on our GitHub repo, we have put together a rule set. This is the rule set for master, slave, whitelist, blacklist. And it is the exact YAML file for this linter called woke. And so with this YAML file, which anybody can go get, there's a Jenkins job then that does a test and says, hey, you have non-inclusive language, we're going to give you two weeks to take a look, investigate what it will take to fix it, or the other messages, you're good with inclusive language, carry on. Now, the team in this case didn't make it a gating test at first. They just kind of wanted to make it informative. I think this team is very good. Their motto is, we want to be assistive, not punitive. And so I think this is a really good approach at first. But I also wanted to share a tool that we've put forward that's an inventory tool. So like I talked about the categories one through four, there are ways to start looking for those. So what we wrote is, I wrote it, I'm a terrible coder, but please go take a look and help us out. An inclusive language inventory tool. So with this tool, I'm just going to walk through it real quick. You basically, with a Python environment and a GitHub token, so a personal access token that has access to a repo that might have this language in it, you can go get the repo, make this config file, and again, a lot of you are probably more advanced coders and this is going to be rudimentary. But I'm trying to show that you can just walk through this, read me, and at the end of the day, get an entire inventory file for an entire org. So whatever you have access to, you'll be able to see, does it have master, does it have slave, and put it into a large Excel spreadsheet, which would then let you sort and figure out, who do I need to talk to? Is it actually category one? Is it category two? Where does this lie? Which team might be working on this? So this is the config file. I'm going to show you how to go get a personal access token. It's under settings, developer settings, then you go over to actually make a token. And another nice thing about this, if you're a little nervous about, you know, I don't want to do anything in my org. This is a read-only token. You can expire it whenever. And so you're not doing anything dangerous. You're only reading data. You're not writing to it or anything like that. And obviously, this one expired seven days later, so nobody can use it against me in the video recording or anything like that. So this one is just scoped to the sysco-openorg. I don't have a lot of access there, so when I run this, it's only going to come back with a couple of hits that are actually in my own repo. But it's just to show a demo of with this scoped token and the org, I can find some hits on some language and then put it into this comma separated values file. So back we go to the readme, find the next step. I believe the next step is to set up your Python virtual environment. The virtual environment lets you work in a little container, I guess, probably don't want to say container too many times at a KubeCon conference, but it lets you work in an environment that doesn't install anything that you don't want in the rest of your environment. So I'm going to set up this virtual environment, activate it, and then install only the libraries that I need for this little script. So pip install, all the requirements that are needed at the right point versions, and now I'm going to actually run the script. So Python, ghsearch.py, and it has a couple of prompts that you would enter. What keyword am I going to look for? And I think I did slave in this case. Yep. And then I wanted to look in markdown files so I just put md. So there it is. I have my, you know, just a comma separated list of values. And like I said, this is just a very small example. If you have access to a lot more repos and a lot more, then you're going to get something like this, which you can now sort on and try to track down who owns it, what type of files are there, and so on. I've since I did this, I've actually updated the script so that you can do inventory on Enterprise GitHub as well as public GitHub, because we needed it for our own inventory. So but like I said, a much bigger example would look like this at the command line. And then now I have my yang files, like I mentioned, any other, you know, there's go files, all these other types in here. So that's an example of taking inventory. Now let's talk a little bit more about what kind of resources we have to offer you, and I'd love to answer your questions in a little bit as well. But what are we looking for in the future, right? And I also mentioned, you know, the idea of code versus culture. So looking forward, there are questions that are keeping us up at night. And that is okay, what if we wanted to add the term abort that is on the tier one wordless in the inclusive naming initiative? We don't really know what would justify addition because we don't really have a way of scanning all of our code repos yet. Would we know how much that would cost? Would we know how many teams would be effective, you know, affected by that? What would justify that company wide change in that sort of wordless contract if I if I may. And so what would we do to make sure that we would have a governance structure in place that would let us say, okay, we're adding that word and we would like it done by, you know, December of 2024. So that's, that's a definite question that we still have in our minds that we're trying to figure out how to solve. And then there's a whole idea that, you know what, this is a very US centric, very North American history centric list of words. It would be really better to think of this with a more global global terms list in mind. And I do think we get that we're a global company, we work with everyone around the world. What would it take to put together a framework that would let someone from any country find the words that are the most damaging in their language and then put together a framework for them that could work for them. And then how do we meet these language needs across not only different languages, but as we get into legal documents, as we get into, you know, broadening and broadening the scope, that definitely keeps us up at night. And so we're sort of thinking it more in terms of, you know, there's an engineering change process, but then there's also the sort of cultural process and awareness process. So we're working on like an intake form where we would take in words from Cisco employees who want to better the language for everyone. And then we can also work together on, well, which words would you replace with? And so I think that's part of the work as well. And so one thing that we're doing that I think is really useful is we're going to our employee resource groups. So we have a group called Pride. And so we're taking our word lists to them where we're saying, do you think these replacements are correct? Are we using non-binary gender language in a correct way? Is this how you feel about it? We're taking it to the lack professionals group. And we're saying, are these the words we want to work on? Is this the correct replacements? And so I think we're not just working with the people who are interested in words and word editors and documentation, but we're taking it to the groups that are harmed by the words and getting their input. And I think that's a really valuable lesson learned. So I would definitely encourage people to not just stay in the groups of like, oh, I'm just with the engineers or oh, I'm just with the tech writers. Like try to get out into the groups of people who are harmed or affected by the language. So in the PDF that I uploaded, I have a pointer to the word lists. I have a pointer to the inclusive naming policy that we put on our public website. And then I also have a link to that inclusive language tool set. That's what the QR code is. It's not dangerous. It's not going to take your Bitcoin or anything like that. I do encourage you people to be very cautious about QR codes, but I will use them in presentations. So and I have it on this next slide as well. But I really wanted to leave everyone with this, you know, personal thinking. What can I do? What can we all do to advance inclusive language? So I already showed you an example of how to take inventory, maybe take inventory across code, maybe take inventory across log files, whatever it is that you have access to, maybe you work on a standards body, start to take inventory, see what you could do. And then I already gave a couple of my own personal examples of where I am reflecting on my own use of language. I made it through this entire talk without saying you guys. That's a first perhaps for me. So these are the kinds of things I'm doing to try to reflect on my own use of language as I work on this. I also found that when you do a practice with PowerPoint, it will point out you just use you guys. So I'm also trying to find tools that help me in my everyday work. I give presentations. That's something that I do. And I found a tool that will help me eliminate language I don't want to use in presentations. So what can you do in your role? What can you do in your own work? We found a way to do a linter integration in our API insights tool that basically does linting for open API files. In addition to doing linting for how good is this API, I talked about how we work on API quality, we added an inclusive language checker into that tool. So I just want to encourage everyone to just you can look for these little integrations. It seems like a small thing, but it really can make a difference. So while we're checking an open API file for quality, part of that quality work is does it use inclusive language? And then anybody who's a speaker here was encouraged to take an inclusive language, inclusive speaking training class. That was a really eye-opening one for me. And I encourage everybody else to look into that as well. I haven't taken the inclusive open source one, but it's the next one in the list. And I think that one's a really good one too. So with that, I want to just say thank you for coming. Thank you for walking nearly to Canada. And I'm absolutely open for questions. And we are hiring. We're very into API quality at Cisco. And obviously have the ability to make a difference in text. So I'd encourage you all to take a look. Thanks. Any questions? All right, we'll have a mic runner. Thanks. Hi. How do you, you mentioned an example where there was a code base maintained outside of your organization that you were, I think you use the phrase tortoises all the way down or turtle all the way down, whatever it is. How do you approach another organization whose code you're kind of pulling in or using to make similar changes that you're making within your organization? Yeah. So in my case, I tracked down the person that I knew was tied into Yang model standards. That wasn't too hard at Cisco, just because we're such a big org. But I could see where if you were a smaller org, you might just kind of wonder where to go. I would definitely just start looking on the website. I've worked in open source for a while. So you oftentimes just have to go to the website and then find out the working group or find out, you know, but I also think the inclusive, the inclusive naming initiative has a slack. And so we could help, you know, kind of make those connections as well. You know, I think one that comes to mind is like Jenkins still uses master and a lot of things. So I, you know, I think a lot of people are kind of trying to find the right in for those groups as well. But that, yeah, you just have to find the, I think you have to find the people and then the process. Yeah. So that's very related to that one. What if you find the community that's maintaining the thing you're using and they are all so set against using it that they literally block you and your organization and start a hate campaign? Yeah, yeah. So I have the privilege of having the only blog post that got a kind of a negative comment after talking about inclusive language on a blog post. And, you know, they're questioning why, why is Cisco investing here? Why do this work? So, you know, I don't think being argumentative is the right approach because they just don't care. Like arguing is what they wanted probably in the first place. And I heard this from other companies that we're working with in the working group that probably they're just looking for that energy. They want to stir things up so the less you do the better in some cases. Now I do think there are lines of argument that you can use. So one of them was, look, where else are you going to go? Our competitors are doing this work already. Juniper Arista has this work in play. We might even be behind. So you're not going to find another place that isn't doing this, right? So that was one line. Another line is, and this is fascinating. So one of the teams took this whole code scanning idea to their whole executive group. And an executive asked a question after they were done presenting, are we already looking for profanity in our code? And I honestly like, I thought, no, we're not. Everybody knows it's unprofessional profanity in your code. Or inefficient or something. But the more I thought about it, the more I thought, okay, I'm going to go search for BITCH and our entire thing. It's not there. So I think part of it is just that modernization of language where we will eventually get to the point where those are profane enough to be eliminated, perhaps, right? It's going to take time. Yeah, I just, anyway, that one cracked me up. Nobody's scanning for the F word. It's not a thing we do. It's inefficient and no one does it. So I don't know. Maybe somebody else has seen the F word a lot in your code bases, but in a professional environment, I don't think it's really done. And I don't remember seeing it much in open source either, but I'd love to hear otherwise. And then I think the other one is just that, you know, and this is kind of that modernization and historical argument. Like, I think, okay, so I found this and let me refer to it. So it was in Oklahoma. There's a Supreme Court case where men were not, the legal drinking age for men was different in Oklahoma. The legal drinking age for men was different than women because it was thought that younger men were less responsible than older women. So when you think about it, it's that by standing up for any marginalized community for whatever stereotype is being done, you're making it better for everyone. And so I think that's the one that a lot of people are not going to go for. But I think that that's the one that's the most like close to the reasons why we do this work. Make it better for everyone. Yeah. One more. I think we might have like one or two minutes left. And I can, I'll stand up afterwards. We'll get this last one for the video. Sure. Thanks. Hello. So I'm helping with a lot of the like, I wouldn't say linting, but kind of inventory in my current organization. We're not that large. But one thing I think we have difficulty with is helping leadership prioritize the work properly. So there's kind of, you know, thankfully, the organization is very excited to kind of work on this, but compared to a lot of other technical projects and getting resources available and stuff and actually, you know, getting a consistent message about like, you know, what do you want to do by end of year? Like, how does that rank against something maybe Kubernetes related, like, et cetera, et cetera, is a little bit difficult. I'm wondering if you have any advice on how to like, help guide your leadership create to create like technical goals around some of this work and like, if you've had past experiences in those conversations. Right. So we, we're able to hire a program manager at Cisco. And so some of the work was building executive dashboards because you want to show progress. And I think that's important. Thank you. So partially executives love to see numbers and dashboards in progress and so on. Right. But I think another important part is part of the executive brain is going to just say, well, why? Who cares? Right. And so I think beyond dashboards, you also have to set that vision and just say, this matters because and so start doing that storytelling. But yeah, I'd love your thoughts on that. So I am a technical program manager, which is interesting because I balance projects that are really deeply on the infrastructure side, but then also kind of have this side pathway that I've been responsible for. And so we're, it's, it's interesting because despite being in that role, it can be very difficult to, even if you're showcasing pace or indicating stuff, some of my work is guided based on like, what their priorities are given to me. Right. And there is a little fluctuate. So in the beginning of the year, they're a very gung-ho of like, you know, we're going to do like all of these things by end of year. By mid-year, people are like, oh my God, we're scrambling for like everything. Yeah. And so I'm wondering like, how do you, how do you set a like reasonable pace that might be achievable and digestible to people who are kind of in your higher leadership organizations? And like, I don't know if you've spun that or kind of described that. Yeah, I mean that, yeah, program management isn't my expertise area, but I think somewhat it's about like, also just sharing stories across the org maybe. We had one team that, you know, just tackled it, right. And so somewhat it's that, it's that snowball effect. So if you can get little wins maybe that might help. But yeah. And anybody else in the room who has ideas, let's, let's talk after, but yeah, we, we're out of time. So thanks everybody. Well, I'll, I'll meet up with you after if you have more questions. Thanks a bunch.