 Hello and welcome to Words Matter, a panel discussion about inclusive language and software, open source and the enterprise. We have a fantastic group of panelists with us here today to talk about inclusive language and why it's important in technology, how to get buy-in and support at all levels in an organization or community, and best practices for implementation and change management. Thank you all so much for being here with me today. Would you each take a moment and introduce yourselves? We'll start with you, Susie. Hi, thank you. Hi, Susie Greenberg. I am a vice president at Intel. My day job is in the Intel product assurance and security group, and the work that I do in inclusive engineering language is something that I've been passionate about for the last three years and working on is a side project, a very big one. Great. Amy? Thank you so much. I'm Amy Marish. I'm a principal technical marketing manager at Red Hat, and I serve as an individual board member on the Open Infrastructure Foundation, where I'm also the chair of the Diversity and Inclusion Working Group that has been doing naming and inclusion work. Great. Thanks for being with us. Hi, I'm Mark Miller. I'm a software developer in the high performance computing program at Lawrence Livermore Labs, and I've been getting involved in leading inclusive activities and software projects for the last several years, and I'm part of the language work stream in the Inclusive Naming Initiative. Great. Thanks, Mark. Well, I'm Joanna Lee. I'm going to be the moderator for this panel. I am an attorney at the law firm of Gizmer Up to Grow. I represent technology companies and open source foundations and projects, as well as standard setting organizations, and I'm also the author of Inclusive Prism.org, a set of resources for inclusive language in the tech industry, and share the standards work stream of the Inclusive Naming Initiative. Here are the additional resources that were just mentioned. If you'd like to learn more about inclusive language. To help provide context for and frame the discussion that's going to follow, I'd like to share just a little bit of background information about inclusive language generally, as well as inclusive language in the tech industry. Over the last couple of years, waves of tech organizations and communities have been announcing that they are replacing and removing the terms master, slave, blacklist, and whitelist from their software, APIs, standards, documentation, and other work product and materials. The terms master and slave are often objected to, because many people find it upsetting to hear these terms used in a casual manner to refer to technology, because these are terms associated with slavery, which is a horrific and tragic part of human history. And the terms blacklist and whitelist are often criticized because they have the potential to promote stereotypes and perpetuate biased associations of black with bad and white with good. This wave of progress was inspired, at least in part, by the resurgence of the black lives matter movement, following the racially motivated murder of George Floyd, Jr. in 2020. Although efforts to replace bias or exclusionary terms in technology have gained unprecedented support and momentum in the last couple of years, they are often met with great controversy and resistance, which we'll talk about more during our panel discussion. Inclusive language is premised on the idea that words do matter, and that words can have an impact on whether people feel welcome and included or whether they feel disenfranchised. Language has evolved in such a manner that it embodies bias and exclusion and historical inequity, even when this is unintended. For example, the words manpower and man hours reflect the historical exclusion of nonmen from the workplace, and the words master and slave have been used in tech jargon for decades to refer to parts of the system and their relationship to each other. The inclusive language movement seeks to build awareness about how the terms that we use can impact people's sense of belonging and inclusion and to evolve language and direction that is more welcoming and inclusive of people of all groups and identities. We're going to be using the terms exclusionary language, non-inclusive language and inclusive language throughout our discussion, so I'm going to provide some definitions to make sure that we're all on the same page regarding their meaning. When we use the terms exclusionary language or non-inclusive language, we mean words or phrases that are likely to cause individuals or groups of people to feel excluded, unwelcomed or treated inequitably because of an aspect of their identity. Obviously, this includes overt insults, racial slurs, and derogatory terms. Exclusionary language also includes language that conveys more subtle forms of bias and exclusion that are often unintentional and sometimes entirely unconscious. For example, addressing an audience as ladies and gentlemen is almost always done with good intention and yet this is exclusionary because it overlooks and ignores people who don't identify strictly as male or female. An inclusive language means opposite. It means words and phrases that are intentionally designed to communicate that people of all identities are respected, welcomed, and included. So I'd love to hear from our panelists how did the topic of replacing exclusionary terms come up and the organizations and the communities that you work with. So I can start. In 2018, I was actually working on security in the open source technology center at Intel. And I will never forget the day one of our senior engineers and another business group came to me and my manager and asked if there was anyone in our organization that would be willing to help a few others look at how we might want to start to make some changes to two sets of terms, master's slave and blacklist whitelist for the two sets. This person was talking about and the few others that she was referring to were a total of two individuals. So I volunteered and became the third person to try to see how we might want to tackle this challenge. And we had a lot of conversations with individuals and quickly realized that the challenge that we were going to be facing was incredibly daunting and that these terms are very pervasive across the industry. And it wasn't just a matter of making some sort of request to make this change that we really needed to take some big steps forward. I would say two years later, our team had grown doubled. So we were about six people and we were starting to engage with standard bodies and having conversations with executives and different teams about the change, but it was really the murder of George Floyd that we started to feel that ground swell of support and people wanting to activate and find ways to help. So the last year and a half has been incredibly valuable in bringing that grassroots effort to bear and really having a large swath of the company now focused on making these changes. So it's been quite a journey for us. It's been several years now and it's great to be here and be able to talk about the progress that we're making as a larger community. And I can go next. I think it's important to note that a lot of companies were doing things internally. And then, as Susie mentioned, George Floyd was murdered and it became a more widespread, more aware type of situation. So even in a board meeting, while we had been doing individual things in different projects for quite some time, it was brought forward that we needed a stance. We needed to take a stand on things. And going back to the community itself, we took six months to find a stance that worked for everybody because that's part of community is making sure everyone's comfortable with what you're putting out. And then we started working on the individual things. Now one thing that's important when you're talking open source is you are somebody's upstream, but somebody could be your own upstream. And things do take time. But getting that stance out there first saying, this is our line in the sand and this is what we're working on is very important. And I think that's what our companies contribute as well as us as individuals contribute to open source. And for me, I've, in the last several years of my career, gotten very interested in diversity, equity, inclusion in general, not specifically inclusive language, but also more recently inclusive language and inclusive practices and software projects. So I've led a number of really, really small, tiny efforts and various projects that I work on. But then I heard about the Inclusive Naming Initiative last fall and got involved with it. They were very welcoming of newcomers and I'm happy to participate in it. And as I have been participating in it and then learned about, for example, the issue with Master Slave, which is sort of the canonical language issue that we all are now really aware of and are trying to address. I just got very interested in it and it's not just that specific issue, but inclusive language in general and it's a very, certainly a very nuanced topic, but I think very important to be welcoming of all people on software projects. As software developers, we name a lot of things and the power to name is a very big deal and so choosing appropriate language is very important. And how I came to this work is, as you mentioned before, I represent companies and standard setting organizations and open source foundations and it actually started with a standard setting organization and then some of my other clients followed. The HDMI forum decided internally, it was the chair of one of the working groups that brought it to the board's attention that, hey, in our standard, we still have references to Master and Slave, shouldn't we be replacing these terms? This is really upsetting to a lot of people, including the engineers that are working on the specification and a lot of our adopters. Could we draft a policy to replace this? And that's how I got involved. And I've also, like Mark, long been interested in issues related to diversity, equity and inclusion in tech and so that started me down a path of advising a number of organizations on how to replace exclusionary terms in their code and standards and products and other work product. So inclusive language and replacing terms and technology is often met with controversy and resistance. So I'd love to hear from all of you. Have you encountered resistance in the organizations and communities that you've worked with and how do you go about dealing with that? I can start with this. Okay, good. So we had some resistance at first within the Open Infra Foundation projects and it wasn't that they were against it. It was because we are so international, they didn't understand. We actually had a conversation over a tool that's called EtherPad. We just happened to see the person comment on the stance and we started answering them and asking them questions and just developing a conversation explaining where we were coming from, why we were coming and explaining that we do understand that in European countries, there may be different terminologies and different feelings on things. So it's very important, at least in an open source community, that it's not just the USA's view on things but being accepting of the worldwide global view on things. And once the conversation was finished and everybody knew where everyone else was coming from, we were able to go forward. And I think that's the important thing is being able to listen as well as speak. Yeah, I think change is hard for folks. And in these instances, these terms have been used for decades. And there's this feeling of, why do we need to change them now or are we just reacting to an incident or a situation and therefore we need to invest years of work to make these changes? Are we being too sensitive or do they really have the meaning that you think that they do? So the best thing that folks can do in those situations is really focus on the history where you can and have a dialogue and then also just help try to put those folks in the shoes of the person that might be sitting in an office coding and having to write those words. And they have a history of their family being slaves or have been met with racism in their lives and how that makes them feel and how that may affect their productivity or their ability to bring their whole self to their work. And so those are the kinds of conversations that need to stem from those types of responses, but it's a shift and there's absolutely a point where you need to acknowledge that this is going to be a significant lift and that it is going to take a lot of time and effort. That helps to just acknowledge that you appreciate this isn't something that you can just go and do a replace all, that things will break and that we want to be able to provide the support and infrastructure needed to help make this as easy as it can be in these situations. And just adding one thing to Suzy's comment about, you can't just do a replace all because you may select different words to replace terminology based on where in the code those words reside. Right, right, absolutely. Yeah, real quick regarding resistance, I think it depends on the particular terminology. To be honest, once the issues, for example, with the use of the master slate terminology or brought people's attention, I'm not aware of anybody that's strongly resisted to the notion of changing it. There is some resistance to what implications that has as far as software compatibility and so forth. But there are other cases, for example, the word master in isolation. I think it's harder for a lot of people to accept, oh, do I need to change the name of my branches on GitHub that all use master for similar reasons? And so yeah, the resistance varies, I think, depending on specifically the details of what people are talking about. And maybe speaking to something Susie said, it's also important that this isn't a job in being word policemen. That's not what we're trying to do. We're trying to adjust and improve language so that we don't have these kinds of issues that Susie mentions. You're sitting there working on code if you're a black person working on code that has words master and slave all over, that can't be a very positive experience for anybody. And so trying to address those issues, I think is really important. And the organizations and communities I work with, unfortunately there hasn't been a whole lot of resistance because often the changes, the buy-in has been happening at varying different levels of the organization, which has been helpful. But this is technology and not all technology organizations are as diverse as they strive to be. And so I have definitely facilitated some conversations among mostly US-based, middle-aged white men. And sometimes it's very uncomfortable for them to have those conversations. And so I think having conversations, real authentic conversations, it's important to create a safe space. And so starting meetings by disagreeing that, hey, we're allowed to disagree. And if somebody disagrees, that doesn't mean that they're racist or sexist or anything else. Language is inherently subjective. Words that one person finds extremely upsetting may be completely innocuous to another person. And it's really important to acknowledge that and allow for those different viewpoints to exist. And the goal is really to create understanding about where is our lowest common denominator and how do we move forward? And I have found that when I've framed those discussions in that way, they seem to be more productive than when there are those outright agreements right up front. What advice do you, each of you have or getting buy-in at various levels within the organization? And is it important just to get buy-in from leadership and management? Or is it really important to get buy-in at other levels as well? What's your experience with that? I have a quick anecdote about that, I'll just share. And that is, I was, for example, there's a simulation code at Livermore Labs called AL3D. It's a flagship simulation code. So it's quite well known. And their management on that project actually had wanted to change the master slave terminology in that code, frankly, for years. But there's a large set of developers working on it. And the way that major changes like, well, the way that changes in a code base like that happen don't necessarily happen well by mandates for management. So even though the manager saw this problem and wanted to fix it, getting it fixed actually required some of the developers down in the trenches to actually start making the arguments that it needed to be done. And that's actually what happened following the summer of 2020. And actually online articles about this particular language and software projects. So that's one way it happened. Management couldn't change it, but the worker bees sort of said, oh yeah, we need to address this. Yeah, just building off of what Mark just talked about and that great example. I think initially when we were starting in 2018, the best approach we thought was to get the leadership to buy in and to really kind of have that tops down approach to getting folks aligned. What we learned pretty quickly to just build on what Mark is saying is that you also need to take that bottom up approach because you need to really have the individuals that are gonna be doing the actual work to understand why they're doing it and be invested in the change. So we had to quickly pivot and make sure that we weren't just getting in the executive alignment and having them support the teams that were going to make these changes, but we also needed to build a group of allies that were focused from each of our business units and technical leaders, principal engineers, fellows who were educated on the initiative and could help support and drive the progress within their specific organizations, give guidance, get resources, however it was needed. And then knowing that they had their executive leadership supporting that effort and that they were going to have their backs is really important. So we found out very quickly that it was both was needed. Yeah, and some things with open source communities, don't just go to a community and say you need to change and you need to do stuff. It's a whole lot easier for people within the community to lead those changes, to suggest those changes. Some things that we're doing is changing documentation first because we can discuss master sleeve and databases without using those terms, whereas in the code because MySQL or MariaDB or Galera haven't changed yet, we still have to have those in the commands and in the code itself, but we can start making changes that people see more readily because most people aren't going to look at your code if they're using your infrastructure, they're going to look at your documentation. So we changed documentation first, then we changed commands if we can, then we changed things when the upstreams changed them so that we're not making three million changes when Git or the database providers make their changes so that everything is as smooth as possible because we're not even talking just our software but all the operators who have it deployed. Thanks. Oh, I'm sorry, go ahead, Jamal. Oh, go ahead, Mark. Well, so related to that, for the project I mentioned earlier, AL3D, it wasn't just a matter of changing the words master and slave everywhere. There are derived variables in the code that were derived from those names. So you might see abbreviations, SLV or NS for number of slaves and NM for number of masters and stuff like that. And there are actually much more egregious examples in the code of language that comes out of the use of master and slave and the need to end certain processes in the way that you might do that in the Linux environment. But anyhow, the idea was they wanted to get all that out of the code and not even have derived variables have their names derived from that. And that took a lot more work than a simple global replace. It took some eyeballs on the code and a little bit of time. So what other advice do you have on managing dependencies and then the change management aspects of the planning and the coordination that has to happen around implementation of word replacement? Definitely do your tests at the same time so that you that'll help minimize any breakage you might have because you changed one parameter and there could be one parameter that you missed when you were making your change. And that's why you just can't do the search and replace as we mentioned earlier. You have to actually have eyes on the code. You have to run through the tests. You have to make sure everything's working and then hopefully have beta people running through the tests and manually going through everything. So change is not easy, change is not quick but it's important to know that change is coming and change is being worked on. So yeah, it was actually turned out for the example I mentioned it was a dependency that actually started the ball rolling on this. All of this, the particular product that the NL3 uses probably 30 or 40 different dependent libraries depending on how you configure it. And one of those libraries had said, well, we need to change this terminology and they were changing their interface and they were picking replacement terminology that was logistically gonna be rather difficult to accept and use within the constraints that we had at Livermore Labs. And so this initiated a discussion between those two code teams, the dependent library and NL3 and then those discussions branched out to other dependencies and it took a while to get agreement that it needed to be changed and then after that agreement was made, just a lot of dominoes started to fall. So that's sort of how it happened. What role does education play in getting buy-in and helping your word replacement projects move forward? I think it's absolutely critical because like I was saying earlier, if there's not even just a baseline understanding or acceptance of the harmful undertones and the impact that those births have on our colleagues and industry friends, it's really hard to get behind making the changes or to investing the time and energy that's required to do that. So that's always where I try to come from is a place of understanding. And Johanna, like you were talking about just being open to having those dialogues and to creating those safe spaces for folks to share how they might be feeling in that moment because it's much better to have those conversations up front and to have a dialogue with someone about the issues as opposed to begrudgingly having them go and make the changes because they feel like they might lose their job or they're going to be ostracized or given another label of their own because they're not complying with the change. So even just making sure that everyone has some base level understanding and at least it comes from a place of respect for our colleagues is as really important as you go through these changes. And so what does, go ahead, Mark. Well, I'm curious, both Amy and Susie have mentioned the impact of the George Floyd murders on some of this dialogue. I'm curious, do you have a sense if there would have been enough critical mass if the sort of racial reckoning that was happening in the country last year wasn't happening? I think there was progress in the area but it brought focus to the area. Finding out that, oh, we've been removing those words for the last three releases but maybe they weren't communicating that that one project had been doing so. So it became more relevant to speak out and say what you were doing and why you were doing it and that you had been doing it versus feeling like you had to do it in the background. I think that was mainly the big thing we were seeing that people had been working on this and discussing it but they were doing it on their own instead of out in the open. I think our steering committee grew significantly after simply because people wanted to find a way to contribute and to give back. And so the work had started, it was absolutely in flight but I think that there was a bigger push and more of a interest in finding ways to support efforts that are relevant to our everyday jobs. Everyone was trying to find a way to give back and that might have been through monetary donations to certain organizations or just having conversations or it was like I work in technology and I have been able to find a way where I can actively make a meaningful change today. Yeah, that's my experience as well. The whole tenor of the country last year really helped I think create a groundswell of interest in trying to address, fix what you can around you, what you see around you and so yeah, that's been my experience as well, interesting. And as so often happens with these events is a spark, a great deal of interest and then people get complacent again and sometimes the interest level declines. In your views, where is the interest level now and the motivation for inclusive language and tech? Is it waning and if so, how are you still, how are you still driving progress despite that? I don't think it's waning per se, it's just not like headlines anymore that we're working on things. But if you like check in with a group and see what their progress is, they're making progress. Like I said, when you're waiting on somebody else to make their decision, you kind of like get a little stagnant while you're waiting, but you're doing things around that decision. So putting your code in place that it will allow you to say make your Git repository branch, a parameter versus it being hard coded anymore. You can do that while you're still waiting for what the decision from the Git community is gonna be. I think one of the biggest things we've seen the work we're doing is being measured and celebrated across the company and it's becoming part of our 2030 inclusive goals for the corporation and that's a big shift as well. And quite a momentous occasion considering where we started in 2018 from that perspective. So having that accountability and making that part of the corporate goals has been really important to keeping people energized and focused on the work. So I've seen that happen not just at Intel but at all companies. And I think that's really where you're gonna start to hopefully see some of that accountability continue and the engagement as well. Cause it's important to our executive leadership. So how are you measuring progress and success? And when is Don done? Well, real quickly, I was thinking as I was hearing Amy and Susie's talk to it, just like many software projects, you're always continuously improving in some ways, continuous integration, continuous testing, whatever. I think at the end of the day, projects need to have an additional thinking capacity which is continuous improvements and inclusive language, for example, continuous inclusion. And so yeah, things don't stop with master slave and blacklist and whitelist although I do worry that many people may get involved with a project with that impression. And so it is important to remind them, well, no, this continues. I mean, and I'll just give a kind of innocuous example but why does everybody call it Haley's Comet? We call it Haley's Comet cause Haley discovered it. Well, it turns out Chinese astronomers had been aware of this comet thousands of years before Haley ever had his name attached to it. So there are plenty of examples of stuff like that in our world where we might wanna scratch our heads and go back and look at it. Is there a more inclusive way to talk about this? So I don't think it ever ends. Yeah, I mean, you can have a definition of done. Does it have a release note? Does it have documentation? Does it have a unit test and so on? But at the end of the day, you're never really done. There's always gonna be some word or something else that you find out that there's a history to it and that it's wrong and you don't want that in your code. Rule of thumb was one that came out that I did not know the history behind the word. I'm like, why is everyone having an issue with rule of thumb? And then you find out it was basically the with of the stick you were allowed to beat your wife with. Well, no, that's totally wrong and we should not be using rule of thumb. But until you learn the definition and the history behind a word, you don't know about it. And I think as we do more work in this area we're gonna find out more history of things. Sure. And language is always evolving. Words that at one time were considered perfectly acceptable are now considered very insulting, derogatory. And then sometimes communities will reclaim a word that was once considered derogatory and now it's celebrated. So yeah, absolutely. And how are you? So Suzy, you mentioned that you are celebrating not just measuring progress, but also celebrating it. And so we'd love to hear from Mark and Amy do you have the organizations of communities you work with? Is there a way you're celebrating knowledge and reward progress in inclusive language? Well, so that's, I would say from where I sit within my own organization, I see a little bit of that. And I'm involved in trying to celebrate, for example this recent change on the L3D project by writing a blog article about the work that went into that. In fact, I'm woefully behind on having published that article but I talked with the code teams involved and have learned what their experience was. That is one way is to sort of just get out there and put the word out that, hey, we went through this. Here's why we did it. Here's what it involved and we're gonna continue working on it. Talking about it's really important too, so yeah. We're doing things like a follow-up survey making sure that the word is out there that everyone is aware of the stands, that everyone's working on the initiative. If they're not aware of the initiative, once they learn of it, are they willing to step up and take on a role to help with the initiative? So those aren't quite celebratory but they're making progress. And the more people that know and the more people that are willing to lead within their communities, that's how we're gonna celebrate at the end. You know, another metric comes to mind to me that's sort of personal. And that is, I did, years ago I would not have the regular sort of experience of crafting an email to someone and typing a sentence and reaching a word in the sentence and realizing, do I really know what that means? For example, the phrase rule with thumb. I used a phrase earlier in the week, I can't remember which it was now but it doesn't so much matter. The experience matters that I'm now routinely sort of asking myself, do I really fully know what this means? Where did it came from and is there a better word? I never used to do that. Oh, the ninja, I was gonna say somebody's a ninja programmer. Well, is that maybe a cultural appropriation of some kind and should I pick a different word? And that's a metric for me personally that says, yeah, I'm wearing a new thinking cap now. Right, yeah, you mentioned something that I've also observed my own growth which is, I mean, there's word replacement which is, you know, it's a list of things that you do and you complete them. And then there's also the consciousness shift that happens around language and communication and are really thinking about the words we choose in a different way through an inclusivity lens that I think is very positive and healthy. As your organizations have been doing the planning and decision making around word replacement, have you had to make some hard decisions and what are those hard decisions? For example, making decisions about how far back do I go? Is it just future releases or is it legacy materials we're also going to try and correct? Oh, yeah, we're absolutely making those decisions every day. It depends on the standards body and how much they're on board with the change. Each individual team may have to make a decision for what they want to replace those terms with. It's not, you know, block list, safe list for example is a great one that works for a lot of groups, but not everyone. And so those decisions need to be made by a smaller subset of folks. We cannot kind of dictate to teams what it is that we think that they need to replace these terms with. So you're constantly striking that balance and just how much is going to go into the actual investment to make those changes and is it better to just make a conscious decision to use those replacement terms moving forward or is it worthwhile to go back and make those changes retroactively? Going back to the how many things you're gonna break along the way, how many resources and time and energy is it gonna take and making those meaningful changes are gonna look different for different groups and for different teams and different technologies. So acknowledging that upfront and having that level of flexibility and it's always a balance because you don't wanna be so flexible that there's just no consistency whatsoever. So yeah, there's many decisions being made all the time and that's why it's been so important to have those allies and those different groups because they really do understand the technology best so they can work with the teams to try to find those replacement terms that are gonna be right for the community, where and how the changes are made. All of those things are important decisions that are gonna vary. Yeah, we were originally avoiding giving suggestive lists and we were actually asked for them. So we came up with a list of suggestions with the full knowledge that the projects themselves were going to decide whether that was the words they wanted to use or if there was another better word to use. As far as how far back do you go, we're definitely not gonna go back into the code that's end of life. But we definitely wanna go forward in improving our code and if a piece of code gets back ported that has a change in it, then we're gonna have to address whether we're gonna go back and fix everything related that might be affected by that change or just say as of this point, we can't back port into that. Yeah, in the context of the L3D Project Master Slave Replacement Terminology, I don't think it was, it was not obvious to anybody at the time they started that just what level of effort was gonna be required. And in fact, there was no sort of new funding that was created in order to address the issue. It was put among all the priorities that the project was facing and then a portion of the resources were carved out to address it. And without really knowing what the full cost of it would be in terms of the level of effort and various things. Now that the code groups have some experience doing that, I think they can start to engage in conversations about, okay, what is it gonna cost us? We have this experience now and as each new example comes up, they can kind of make those choices. So those discussions are probably starting to happen now but yeah, a year ago we had no idea what it would involve. So each of you has talked about driving change within your own organizations and Amy, you've touched a bit on driving change within communities as well. But I'd love to hear more from each of you about what can tech companies and organizations do to help drive change in the broader ecosystem, whether that's working with your suppliers and vendors and educating them or driving change in the open source communities and the standard setting organizations that you participate in. I think it comes down to leading by example, that you have your decision, your company's decision, and what you're working on internally and then you take that out to your communities. You should not feel bad about any decisions that you bring. If you feel strongly about a word and you think it needs to be changed, work on changing it but work on changing it from within the community. As I mentioned earlier, don't just join a new community and say, you need to change all your words. You're not going to get any help doing that. It's kind of like trying to get management to make a decision and getting the developers to do it. Everyone needs to be on the same page. Everybody needs to work as a team. And I think if you go out to your suppliers and you bring your viewpoint in, your explanations of why, that maybe they need to change something in order for you to be able to use it, you'll get more buy-in doing it that way than just saying it's this way or the highway. I'll go ahead. I was just going to say, I think Amy summed it up really well. That's exactly the type of approach that we've taken as well and it's so critical. It's just really feel like I keep saying this but just having that dialogue, having the two-way conversation and being open to hearing the challenges and the questions and in an open way, right? So that people feel like they can bring their true selves to their work as well. We need to just all be very respectful of each other as we go through these changes. It's so important. There's a dimension to that. I'd like to add in these conversations, it's real easy for a group of people to get in a room and sort of like, oh, I read this article online about XYZ and we need to address it. And if you look at the way a lot of the demographics and a lot of parts of our world are within the tech industry, again, it's a lot of people that look like me that are going to be in the room talking about that. There might be good intentions in those discussions to make a change in one way or the other. But the reason I mention or want to say this is it's really important that those changes ultimately get informed by the communities that are impacted. So whenever possible, you want to seek out members of the community. And if you have members of the community that identified themselves as an expert, that they're willing to spend time talking to you about how certain terminology affects their community all the better. But that's something that I always worry about when I see groups of people getting together talking about, oh, we need to change this to improve our inclusive posture or whatever. And there's nobody in the community that they're hoping to help have involved in that conversation. And are there, is there any other advice that you'd like to offer the attendees of this conference today? Well, it's a big problem. And it's very, the language having, for the reasons that you hear Susan mentioned just a minute ago being well-invited. It's a big problem. It's very nuanced. So it's a marathon. It's not a sprint. And yeah, they're holding two truths is another thing that always occurs to me. And I think maybe Joanna, you mentioned that earlier in your introductory remarks. It's important to be aware of and sort of hold all the perspectives that go on during these discussions. And yeah, I guess that's my advice. I think my advice would be if you see something speak up. Because no one else may see it because they're used to it because they've been there forever or they may just not realize it's wrong. And I think that there is a tremendous amount of work to do. So if any of what we talked about today resonates with the folks that are watching this, please reach out to your respective communities, find ways to contribute. I really encourage folks to do that. And if this raises more questions for you or concerns, find someone that you trust to have a conversation and ask those questions and hopefully get to a better place in terms of understanding the work and the why. And then really just at the end of the day, it's important for us all to remember, Joanna, just like you were saying that words matter. And the intention and the meaning behind them can be incredibly impactful in a positive way and a negative way. And so that acknowledgement I think is really important for folks as well. Right, well, thank you all. I'll also add that there are some really fantastic efforts as you've heard about today, in particular companies and communities to drive change in conscious language and word choices. There's also a lot of collaboration happening within the industry. So if you're looking for additional information or resources or you'd like to join the Collaborative Cross Industry Initiative, consider joining the Inclusive Naming Initiative. And I'm gonna share a slide where you can find the website of that resource and some other resources. So thank you so much to our panelists and thank you so much to the conference attendees for being with us today. Thank you everyone. Here are the additional resources that were just mentioned if you'd like to learn more about inclusive language.