 Hello, thank you very much for joining us. If you are a Kubernetes maintainer, welcome. We're happy to see you on this maintainer track. And if you're joining us from the LF inclusive language community meeting that happened earlier on, we are also super excited to see you and to go into a bit more detail about what we're doing in Kubernetes to create a space that's more inclusive, particularly in use of our language. My name is Celeste Horgan. I'm a senior technical writer here at the Linux Foundation, and I'm going to take you on a deep dive of what we're doing here in a working group naming. So there are four leads for the naming working group myself with the Linux Foundation, Stephen Augustus, an engineer with VMware, Zach Corlison, a technical writer with the Linux Foundation, and Jay Singer-Dumars, an engineering manager with Apple. And the four of us have come together to achieve one specific goal for the Kubernetes project, and that is evaluating the language and naming choices within the Kubernetes project with a specific initial focus of replacing harmful language with neutral terms whenever possible. For the purposes of the naming working group, what we're defining as quote-unquote harmful is language that is racist, sexist, homophobic, transphobic, ableist, or discriminatory in general against any protected or historically underrepresented groups, particularly within a North American context. Big mission. So this is something that tends to scare a lot of engineers, particularly when we talk about language and renaming features in code, because it's viewed as not necessarily as high value as delivering new features, but potentially really difficult to actually execute on and really really controversial. So let's let's go into a few examples of what we're trying to do with the naming group, working group, and why that's important. So we're gonna dive way back into Kubernetes history now. So the year is 2016, and once upon a time, slightly before general availability of Kubernetes, 1.3, I believe. There's a feature called Petset. And if you're like me, somewhat new to the Kubernetes community, this might be really confusing to you, and you might know it as stateful set, because it was in fact renamed before it went generally available. And the impetus for that was this issue by Dewey Cordera, which I think outlines really well in its language why this is something that we're interested in doing. So let's dive a little bit into what Jimmy said in his issue description. The name Petset is derived from the common metaphor and infrastructure of pets versus cattle. The pet has a personal and emotional value to you, but the cattle is just a commodity. Try to think about how our language perpetuates our culture and our beliefs in the same way that homophobic or racist language was, and in some cases still is, commonplace and accepted in days past. In the modern world, we generally recognize that this language is unacceptable because it promotes a negative worldview that we have progressed past. Imagine how angry people would be if this feature were called Wifeset, and the analogy were wives versus bar hookups. So I think Jimmy did a incredible job of describing the value of names and why we need to care about them in our code here, and he breaks it out into two pieces really well. The first is this idea of using a metaphor. Metaphors are very powerful things, but they're also very culturally specific. How I treat my pet may not be how you treat your pet, and there are cultures where having pets is not necessarily as commonplace or where pets serve a very specific purpose, aside from enjoyment and emotional attachment. So the first thing that we need to address with this idea of petset versus stateful set is whether a metaphor is something we actually want to be using in our code, and from my perspective as a technical writer, the answer is no. The second is maybe the more important bit, which is the fact that our language perpetuates our cultures and our beliefs. The Kubernetes community is quite large. A typical kind of in-person coupon runs about 10,000 people, and there are two or three of those a year. Which means we have a reach of about 30,000 people, and that's the bare minimum. Those are the people who can show up to a convention. The contributor community is about 700 people large, and that's another huge, huge community in comparison to many open-source projects. We have an incredible ability, but also burden to develop specific kinds of culture, and we need to be very, very mindful about what kind of culture we are trying to create and perpetuate, and whether we really want to carry things from our past, either as technologists or as people, into our presence in our future, and language is one of the ways that we carry these things. So I think Jimmy did a great job of describing that there. But let's look at another example. So now the year is 2017, and we have an issue in Kubernetes's website about renaming master components to a more inclusive synonym. So this is something that's on a lot of people's minds right now in response to the Black Lives Matter protests that began in America in June 2020. But I think it's important to note that this has been on some people's minds for a really long time now, and we can bring up another example from last year about in Kubernetes, we've chosen to use the word control plane over master, but we're not super consistent about that yet. But I think the point that I'm trying to make here is this is something that's come up in our community again and again and again, and when something comes up again and again and again, it's usually a good idea to do something about it, which is why we decided to form this working group. The Kubernetes community is a super positive place, but it also would be good if we stopped pouring energy into this repeatedly over the years by taking a stance saying this is what we recommend instead of using these controversial terms and then moving forward. I think the other thing to note is this was definitely a working group that was formed from that need to do something that I think all of us felt in June and July of 2020, because violence is violence as the sign says, and I think we all felt a great need to do something positive in our communities to support people who are otherwise underrepresented. So, so what is the working group naming actually doing? The working group naming's formal deliverable is to create recommendations for replacing problematic language in the Kubernetes project. From there, there's a handoff process of recommendations to steering and steering kind of enables those to be implemented by the different SIGs involved by giving their their approval as well. The other thing that we looked at doing with the Kubernetes project was creating a framework by which we could evaluate language going forward and creating a process by which when a term was identified that we didn't like, the community could handle it without necessarily needing a working group. Our goal in a lot of ways is to disband. So, on that last point, let's talk a little bit about how we evaluate language, because this was something that we ran into in the Kubernetes community very early on and something that we spent a lot of time working on initially. So, something we found a gap in when we began this work in Kubernetes was the lack of a way of evaluating language. Lots of different projects and different companies were addressing words like master slave and blacklist, whitelist. Some were going a little bit more broadly and addressing terms like man in the middle attack or being grandfathered into a situation. But it didn't seem like there was a rigorous way of evaluating a piece of language. These terms were kind of coming up out of the ether out of conversations that had begun three or four years ago as we saw earlier. But we weren't able to look reflectively at our own work. We were just sort of accepting terms that were floating around and we wanted to do better. So, we defined a framework for ourselves for evaluating language. You can find the full framework in the Kubernetes community repository under the working group namings documents. We do intend it to be something that people can use and people can share. But we broke it down into three sections. The first were what we call first order concerns. The second and third order concerns as well. So, the first order concerns were language where harm was egregious, overt, and very clearly problematic. Second order concerns were language where, which was problematic, but had a less definite impact. And third order concerns were language that could use improvement, but born doing demonstrable harm. So, we have a set of questions for each of these orders of concerns. And our use case is that you have a term under evaluation and you run through the set of questions for the term. The more yeses you have, the more likely it is something that you need to consider changing. But the concerns are categorized for a reason. And that reason is that first order concerns are significantly more harmful than third order concerns. So, even if you only have one first order concern that you've checked a yes to and nothing else is a yes, we would still recommend putting more weight to those first order concerns and slightly more weight to those second order concerns and running the evaluation that way. We are intentionally non-prescriptive in how many yeses or noes you might need from first or second or third order concerns because we don't want this to become a system that can be gained. And we don't want it to become a rigid rubric that's never going to work for language. So, really it's a set of questions to ask yourself about a term. And as a general rule, the more yeses you have, the more harm the term may be doing, but there are some harm is more important than others. So, let's run through those concerns really quickly. And we'll give a few examples for each, okay? So, first order concerns are characterized by being overt. Regardless of the context, whether it is technological or non-technological, these are terms which clearly imbue harm. The second thing that first order concerns are kind of characterized by is they are very specific to an identity. So, you can attach those meaning in the term that is very specific to specific people. And the questions we ask ourselves to clarify whether something is harmful in a first order concern way is if the term is overtly racist, if it is overtly sexist, transphobic, or pejorative about a gender identity, if it is overtly ableist, pejorative, or too neurodiverse or disabled people, and if the term is overtly homophobic. So, a really good example of a first order concern is master's slave, where while master potentially has other connotations, slave is very clearly racist, particularly in an American context. And while Kubernetes is an international community, many of us are based in America. And in an American context, a slave means a black person. So, for us, this is a first order concern that we are answering it a huge affirmative to, and something that we feel very strongly that we need to address within the community. So, second order concerns are things that are harmful, but they're a little less specific. And these are characterized in two ways, typically by a bit more ambiguity in terms of language and a lack of specific identity. So, in terms of ambiguity, within code, and in within some contexts outside of code and technology, this term may not be harmful. It's sort of a Merriam's dictionary definition thing, where one of the definitions may be a harmful definition, but the others are not as bad. And it's hard to say what the connotation truly is. And the other is lack of a specific identity in this regard. So, whereas first order concerns were, is this racist? Is this sexist? Is this X? Is this Y? We can't really do the same for second order concerns. So, the two terms were, the two things we asked ourselves for second order concerns are whether the term is violent, and whether the term is militaristic. So, a good example of a violent term would be kill commands in the UNIX system, where it's clearly violent. It's not violent towards anyone in specific. And within UNIX, a kill command has a very specific sort of meaning of sort of terminating a process very suddenly. This has the potential to make people uncomfortable, but we can't say specifically whom. Another example of this might be master in a non-master slave context. So, master in terms of main or kind of a template or default state, like the master key. There are many uses of the term master, which are not directly about slave owning, but there's enough ambiguity in that language that sometimes it is. And so therefore, within our framework, this is still something we would flag as a yes. So, third order concerns are things which are not necessarily harmful in any way, but they could still use improvement. And these are typically around the actual language itself. So, is the language clear? Is this the clearest term we could use? Are we making things seem human that aren't human or anthropomorphizing them, is what we call them in writing? And is the term idiomatic? And an idiom is typically something that wouldn't translate very well to another language because it has very specific cultural connotations. So, the two terms or the two questions that we think of in this regards are, is the term evocative rather than descriptive? And is the term ambiguous? And petset versus statefulset is a great example of a term which is evocative, but not necessarily descriptive. Petset has meaning to us emotionally versus statefulset, which describes what the component actually does. And from a writing perspective, from a perspective of working in an international community where we translate our documentation, we want the descriptive name because that will translate better regardless of somebody's cultural background. So, once we've run through the evaluation framework for a term and decided that we'd like to replace it and propose some replacements, the next thing that we'd like to do is to record our replacements in effectively an architectural decision record or ADR document. And we chose this for a couple of reasons. For example, we didn't want to just hand a list of words that we felt needed replacing off to steering and off to different sigs because we wanted people to be able to see the context in which that decision was made. And there's a number of different pieces of context that we wanted to capture. The first was the date and time in which we made the decision because as societies progress, they typically get more empathetic and more accepting. And words that we didn't feel need replacing in the past, in the future, we may make a different decision. So, we wanted to record the date. We wanted to record what our thought process was and what our justification for making this change was within ourselves. We wanted to record changes that other communities or other open source projects might be making to see if we were in alignment or if we needed to go in a different direction for our own purposes. And we wanted to record what stakeholder sigs we were identifying as potentially receiving the downstream effects of this decision. So, this is our first recommendation that's been formalized for changing master to control plane across the project. And a big thanks to Erin Krickenberger for PR'ing this just a few days ago at the time of recording. So, we have an approval workflow for changes that go through. It's pretty simple. First off, we like it when people propose changes via the mailing list first. And we'll go over where that mailing list location is later on this video. In our experience, these conversations about wording tend to get very long-winded very quickly. And the mailing list is a great way of doing this asynchronously and allowing that discussion to fully spin out in a way that everybody's comfortable with. The second is once things have been discussed on the mailing list, we like to formalize whether or not we'd like to make a recommendation through our weekly meetings. This is effectively a pre-approval step. And once things have been discussed for a few days or a few weeks on the mailing list, bring it to the meetings we meet once a month currently, we're thinking of bumping it up to twice a month. So, the next thing we like people to do is just as Erin's done for master and control plane is to open up a PR in Kubernetes communities, working group naming, directory. There is a template available for making recommendations and for the reasons discussed earlier we like if you follow it. And the final thing that we do is commit that change. And once the change is committed, that effectively means a few things. First off, that you have the working group namings leads permission that we agree with this change. Second off, that if we feel that we needed to bring in other stakeholders to approve that decision, you have those stakeholders approval and tacit kind of agreement to do the work. And third, that this is something that we can hand off to steering. Other SIGs and working groups are a part of the approval process typically because some SIGs are more heavily affected by a certain change than others. For example, one changing black with whitelist to allow list deny list. If there are visible API methods available, API machinery needs to be involved because that does constitute a breaking change and we need to start moving through the deprecation policy for that. So by way of wrapping up, I mentioned this earlier in the talk, but I think that it's sometimes a hard sell to do this kind of work. Because as I mentioned, sometimes it introduces breaking changes. Sometimes it's very difficult. It's really hard to name things in computing as engineers love to remind us. So why do it? And I think the answer really comes back to intentionally creating inclusive communities. We're very lucky in the Kubernetes project in that we have a very diverse, very accepting, very open community. But I think as the project moves forward in maturity, it's important to remember that there were very key actors and very strong actors who did this intentionally. Kubernetes did not become what it is as a community overnight and without intentional action. And it's intentional action that continues to protect that community going forward. And addressing the kinds of words that we use in our computing is something that will continue to protect the community going forward. So it's very, very important to do. So hopefully this all sounds great. And away now let's talk about kind of ways that you can get involved. So first off, join us on Kubernetes Slack and in working group naming. Join our mailing list where you can find the actual discussions happening and the decisions being made. If you join the mailing list, you'll get a meeting invite to our monthly meeting that is currently set for the second of Monday every month attempt 30 Pacific time. And as a final note, and this is I think very particular to the people joining us from the LF naming group, please take the work that we've committed to Kubernetes community working group naming and use it in your own organizations. I think one of the coolest things about open source is that everything we do is publicly available, nothing is behind a firewall, it's free for anyone to use remix. And we are part of the reason that we made the decisions to do things like architectural decision records to create a framework. And was because we wanted people to be able to use this as a resource. Something that we've noticed is that there are a lot of different organizations and groups and open source projects trying to do this work all at once. And not necessarily consulting each other. So we're really hoping that what we create can also be a resource going forward for people so that they don't have to reinvent the wheel every single time this conversation comes up. And on that note, thank you so much for attending. It was lovely to virtually see you. And what made me even happier is if you join us for a Q&A session after this talk. I really look forward to chatting with all of you, and I hope you have a great afternoon.