 Hello everyone, I'm Triyanka Sharma and today I'm here to present a panel on inclusivity. We're going to talk about how inclusivity starts with language and because of that, why we are trying to remove bias from code. Very excited to bring this panel to you today at Open Source Summit. Thank you so much to the organizers for giving us the space, giving us this time to bring up this very important topic. I'd like to go over introductions really quickly. So, I'm Triyanka Sharma and I'm the general manager of the Cloud Native Computing Foundation. The CNCF, as it's commonly known, hosts 70 plus projects with Kubernetes, the container orchestration engine being our flagship. CNCF has seen tremendous growth over its existence of the last five years and today we have 550 plus members. And we have our event coming soon, CubeCon Cloud NativeCon North America, November 17 to 20, where we are going to continue this discussion. I personally feel passionate about bringing inclusivity to code because Open Source has given me so much. It's given me an identity. It's given me a profession and it's given me lifelong friends. I believe that a lot of change can happen if everyone is included. Everyone belongs. We in CNCF say Team Cloud Native is everybody. To that end, we have to make ever-approving efforts towards bringing more and more people into the fold. This panel is going to discuss exactly that. Today, I am honored to have very awesome guests on this panel with me and I'd love for them to introduce themselves. We'll start with Kate Stewart, Senior Director of Strategic Programs at Linux Foundation. Welcome Kate and please do tell us what makes you interested about this on this topic. Oops, we can't hear you. Thank you so much, Franca. I'm delighted to be here and I do feel very strongly about trying to make sure that we get everyone included into our software development as well as our projects because the more people we have, the better decisions we're going to be making and the more perspectives. I've been interested in these topics for quite a while and it's actually hit home directly after the events of this year. But one of the things is like one of my projects in the LFZF has been busy trying to figure out how to change and how to do this effectively. And there's other projects I'm working with that are trying to do this effectively. And so figuring out what the best practices are and how we can also get together and figure out a flavor is something I'd really like to see. And so that other open source projects can learn from what the best practices are and have an easier path of what's a reasonable set of transitions and what works for everyone. Absolutely. Thank you so much for being here, Kate. And a quick reminder to everyone, please keep your mics unmuted because I've heard it's better video audio for recordings which feels counterintuitive but just FYI. Moving on next, would you like to go, Steven? Hey, I'm Steven Augustus. I am a senior open source engineer at VMware. I'm also a chair for a few things in the Kubernetes project including the working group for naming. The reason I'm here is I think that, you know, to Kate's point, inclusivity is important and there is so much that can be done in a project to gather new contributors to make people feel welcomed in that process. And from the engineering standpoint, I think that I don't like repeating work and I see that a lot of the naming efforts that have happened across multiple companies have kind of opened up this opportunity for us to get together and talk about this as a team. Absolutely. Awesome. Well, Dale, do you want to go next? Hi, I'm Dale Davis Jones. I'm an IBM Distinguished Engineer and Vice President. I have been leading an initiative and IBM around our words and IT language. And the reason I'm really excited about this is that there's been so much energy and passion around making the workplace more inclusive and IT making the content and the code reflect an environment that's good for the workplace. So I'm happy to join forces with you and the team here to bring this forward in a standard way. Awesome. Dimitris, your turn. Thank you so much. Hello, everyone. I am Dimitris Cheetham and I am the Senior Director for Diversity, Inclusion and Belonging Strategy at GitHub. And why this work is so important to us is we are the home currently to 50 million developers around the world. And we plan to get to 100 million developers within the next five years, four and a half actually. And if you really want to think about that, how we can create a platform where people feel safe and feel like they can belong and that they can contribute, we have to look at our language. Words matter. And we know that we can't tackle this alone. So what we talk about at GitHub a lot is that we have to open source diversity and inclusion just as we open source everything else. And so we can't do that without all of our partners, many of who are here on this panel today. So delighted to be here. Thank you so much. Honored to have you all at this virtual table. And I think we will have a very good discussion, which hopefully folks who are considering making changes to their code can learn from. So my first question today is for you, Dimitris. We all saw the news about GitHub changing master to main across the whole org. And I'm curious to learn about what was the experience like coming to a decision to do it? Second, why did you choose main? And then what's it been like since? Sure. So like many of the enhancements that we make to our platform, it all started with very passionate discussions amongst our employees. So about a year ago, GitHub employees, they got on Slack and they started discussing this. They started talking about how words really make a difference and it caught the attention of our leadership team. So about five months ago, our senior vice president of product and our VP of communications and corporate marketing, they decided to co-sponsor an event or an initiative where they would explore all of the different suggestions that those passionate Githubers were talking about in those discussion forums. And so what they wanted to do with this initiative was really to create a plan for how we would approach this work as well as how we would really tackle and really just focus on what areas amongst our content, our products, our marketing materials across the board. Internally, as well as how we would influence this word externally with our customers, partners, and others in the industry. So once this got to going and that initiative started rolling, then the employees just started identifying other areas. And so what came from that is that, as the point you just made, we decided to replace master with main across all of our platforms and our default branch name for new GitHub repositories. We had already done this in other areas and other products like desktop and CLI last year. And we've already completed that across github.com as well this year. So going forward, we're going to continue to look at more and more of our products. We're going to continue looking at our content and actually our employees in true GitHub fashion, they've taken the initiative to also update our code base to include more inclusive language as well. So as we said, we're here as part of this work and as part of this group because we want to influence this even more externally because we just think that this is the right thing to do to make it a more inclusive platform and a more inclusive industry for everyone. Awesome. This is so exciting. I'm really impressed that you folks have been, you know, making changes like sounds like over a year back. That's really impressive. And it's, you know, it's just right now. I think the time is ready for the changes you've made. So luckily we've been, the world has been able to see all that you're doing. That's really awesome to hear. And I am very looking forward for all of us to collaborate here with all your knowledge. Kate, with all the work you're doing over. Oh, sorry, did you? No, let's keep going. Finish the question. Yeah, I wanted to ask you. So you're looking at it as, you know, as a senior director at Linux foundation, you see many projects, you see many initiatives, and you're closely involved with some of them such as Zephyr and STDI. What causes the most worry to you as people are going to change terms? Doing work twice or three times. I think we can do it once. I'd say I think if we can also have standardized on things and we do it once the developers are quite happy to apply it and discuss it. Generally, when the topics start being discussed in Zephyr, we've got some board members that are very passionate about this topic as well from Intel and we sort of recognize that needs to be led by the developers to a certain extent. And so we've had some issues that we've been discussing this on and working through it. And partially we've decided, okay, we're just going to line up behind what GitHub is doing. So thank you very much that remove one set of discussions. And then we have some other terms that we're going to be working on in Zephyr in the sense that it's challenging for us in some senses that we're very low level to the hardware and a lot of the standards and protocols have languages too. And so we have to sort of work that balance out. And so we've come up with the terms we're going to be just shifting to and we've got our plan put in place to start our transition in that code base. And because Zephyr was doing it and others were doing it, we started thinking more of us need to be doing all the open source projects and going through the same problem set right now. And so part of the decide, you know, some of the things that's been, I've been getting interested in working on recently is how do we start doing this at scale across all these open source projects. And so we're going to be doing a software. It's just launched a software developer and diversity and inclusion initiative. And with that, we're hoping to be working very closely with this, the initiatives from CNCF and try to build a whole thing of where we're all coming up with what the best practices are. And we have research to prove that it's working and we also make sure that we're feeling inclusive. But the thing that I'm worried about is we just make sure that we make it nice and clear for the developers and everyone roughly agrees with its good direction and we go forward. That's awesome. I feel like it's this panel's battle cry can be do it once. Do it once. Yeah. It's a good one. And speaking of developers being involved in the process and driving change themselves, Steven, you are in the weeds in all of it for Kubernetes. And so I'm curious to hear how, what's your experience been pushing for this change? And as I know, you're doing it in an open working group. So what's been that dynamic like? It's tough. I think it's the nicest way to put it. I think, you know, that as community members, as developers, as people who may be in featuring projects, you're often looking for the guidebook of how to, you know, how to get started, how to do this correctly, how to do this sympathetically, right? And it doesn't exist right now, right? So, like, by and large, it doesn't exist. Being, so in Kubernetes, I've, you know, I've led a few efforts. I'm a chair for a few things, a Meredith chair for a few things. No big deal. Kind of a big deal. And, you know, after a while, the management style turns from, I need to look for, you know, instead of I need to look for the playbook, I need to make the playbook, right? Yeah. And I rally people around me. And so it becomes, I guess I'm going to go do this, right? This, you know, this effort started as a, we discussed on a mailing list the way that we discussed control plane nodes, right? That started off on like the cluster lifecycle mailing list. And it evolved into something that was, I was like, okay, let me loop in architecture and docs. And now we're talking to release because this is going to end up in a release. And this happened a year ago. And the conversation kind of died down. And this year it came up again. And I was like, Hey, it's probably time that we do something about this. So really, you know, the first part is just being okay with the fact that there is no playbook, right? And a lot of us are taking learnings from each other. It's happening in real time. The second, the difficulty of this is that like the Kubernetes community is amazing, right? We have so many willing contributors. What this leads to is, is excitement about getting things done, right? So like for these efforts, the common search and replace is not the end of the story, right? It's how do these, how do these terms proliferate across our API is right? Considering our API documentation, considering the deprecation policies for these things that we have in place, considering the fact that Kubernetes is one of the largest projects that's housed in the, and everything that we do in a release has ripple effects, right? Across the entire foundation. So like trying to move deliberately and not too fast, right? So building a language evaluation framework and building recommendation templates and talking about the workflow of how this will, how various recommendations go from like ideation into execution is all of what we're doing right now. But, you know, in parallel, there are also people who want to make changes now, right? So making sure that we have at least an appropriate framework to iterate over and hopefully making something that is agnostic enough that, you know, when we form this, we thought, I want to build again. I don't want to do this again. And, you know, I want to build something that is usable in, on the, on the CMTF level, on the LF level, across multiple companies. Like I want to build something that is, is huge. And I think that that's, you know, I think that we're laying a lot of the groundwork for that improvement. Super proud of all the work you're doing. It's so inspiring to see these folks just like chipping away every day. And, you know, there's so much snark that happens, but, you know, it's like, we're going to be positive. That's what I see in these folks like Steven and co are just running with it. It's like, you know, no one can stop them and it's very awesome. So, you know, I think a lot of us in open source, we have a very like the projects we're like all kind of in alignment. We're going to do this. I have also had great conversations with folks over at IBM and Red Hat, both, well, both or one, however you want to call it, organizations. There are people super passionate about this writing, talking. And I'm curious, Dale, in your experience, how do these efforts that you are all doing, how do you see them impacting your business? What is the business value, so to speak, of these inclusion efforts? Great question. So first, the support of the leadership for taking on a topic and a challenge that is so close, near and dear to the hearts of every developer, every content creator, and giving us the support to run with making the changes. Sends a strong message that even in profit companies like ours, that we value our people, we value inclusion, and we are not going to just talk the talk, we're going to walk the walk. And that message really resonated around the company, the companies, and talking to my colleagues at Red Hat. The other thing is because we are embracing the need for change and coming up with ways to drive these changes, it makes people feel that we want to create an inclusive workplace. It attracts people to a workplace where inclusive language, inclusivity matters, and that's good for business. And more than that, it sends the message that it is important for us to value diversity, a thought, diversity of ideas. And one of the things that is, I would say, an unexpected bonus of this is the fact that it's unifying us across organizational boundaries. We're working with traditional standards groups on changing the language in a systemic way. So to quote Steve and Kate, we do it once at multiple times. We replace the language consistently. It also creates an opportunity for leveraging future technologies like AI to help prevent this and make this sustainable going forward. And then longer term, reaching back into industry and academia, I think IT sets the stage for other industry partners to follow. And I think it's good for business because we can actually help build stronger relationships with not just the IT industry who's working on this, but other industries who are also tackling this as well, including academia, the private sector, banking industries, we're seeing it across. So from a business perspective, stronger relationships from a people perspective, an inclusive workplace, and from a culture perspective, valued people. And then the opportunity is to really leap for our technology to drive this throughout society. It doesn't fix all of systemic racism, but it sends a strong message to people that this is something that's important and something we can turn IT to, towards to fix. So I think that's really important. I'm so inspired. You are a very powerful message bearer, I will say. It's so awesome to hear. I've definitely experienced this in my conversations with both IBMers and Red Haters. I don't know if you all call yourselves that. In fact, I was speaking with Chris Wright, who's the CTO of Red Hat, and he really encouraged me that go for it, push for this if you are passionate. And I actually don't think I would have done it without that push. In addition to Jim Zamla and Atia at LF also being like, yes, let's do this. Make it happen, Priyanka. And so I think you all have some great people over there. And you're absolutely right. Making people feel included, being inclusive of people is in every business's interest. And that just made sense to me right away. This is so great. So we all have a good sense of where we are at right now, I think. I think this panel has done a good job of explaining what's happening. Where do you folks think the industry should move from here? What do you want to see in, let's say, three years, five years, so four more spaces in technology? Start off because a lot of what I wanted to share, it dovetails nicely from what Dale just shared. Inclusion is such a personal journey. And it means something different to people depending on who or where they are in the world and what their life experiences are. It's journey work. And we in the industry, we have to treat it as such, right? You hear the old adage, it's a marathon, not a sprint. It truly is. And it's constantly, constantly evolving. So we have to evolve with it. And so that's going to require all of us to continue to listen, to seek to understand and just hold the different perspectives of people all around the world, especially as we start to expand globally. Diversity and inclusion is still very much a U.S. centric conversation, but we're going to have to start going into our neighborhoods and communities everywhere around the globe. And so we have to do that collectively, because all of us that are represented here are global organizations. So again, we have to open source diversity and inclusion, only when everyone feels that what they are experiencing is heard, is understood, and is responded to with empathy, will they feel like that they are included and that their work is valued and respected. That's when we get that true sense of belonging. And so as we strive towards that point, again, we have to do it collectively, and we have to do it in partnership because that's the same level of collaboration that we're asking for in open source. So we have to walk the walk as we talk the talk, like one of the panelists said earlier. Absolutely. This is rousing. It's awesome. Yes. Let's walk the walk. And not just talk the talk. Anyone else, do you want to chime in? So I was super excited, Dale, that you were saying that you guys are reaching out to the standards organizations because that was one of the big pieces that we are, the developers I'm working with are seeing is like, okay, how do we get the standards to refer to language so that we don't confuse people and they use one term and we use another in the code. And so we want to try to see how do we get this so that, you know, it's coherent. So can you elaborate a little bit more about what you're doing with the standards organizations? Sure. So as part of our work stream and we created a group that was focused on communication of why, right? Because it's not just important to say what, but why are we doing it? And that work included internal communications as well as external like the blogs you've seen. Included in that we also added the standards work stream because we realized that if we all started to replace the terms differently, we'll be trading one problem for another, right? And some companies resets me directly, right? And we had meetings to compare notes and we're like, oh, okay, we're not similar. And then we started to do an inventory of what everybody else was doing. And we're like, uh-oh, we're not on, you know, we had master, you know, what was not, was one word and it was non-inclusive. But now we see about, you know, half a dozen different replacements depending on which, you know, which technology company is making the change. So we really need to provide two things. Context, right? It says when is master replaced with the main, right? When is master maybe replaced with a controller or leader or whatever the right replacement term is or primary as in databases and can we get together influenced standards groups to make that change? So we've reached out to Insight. We have worked with them to create a policy statement, principles of inclusion, which says new content created should be inclusive and then existing content, wherever feasible should be inclusive as well. And that's the start. The next step is working with ISO because they're international. And then using them to influence the national standards bodies. And the good news is some of our, my colleagues who are working with this on me are plugged, well plugged into all of the, you know, the usual names you hear in the traditional standards boards. And we've actually added to that their ranks, some of the folks from our diverse part of our population. So they are representing the community that we are, that we're looking to serve with us. And so we know it's not going to happen overnight. But I really loved what Priyanka said. And I believe it was Steve that we are going to start putting together our points of views on the context in which the terms will be replaced. For example, you know, master main makes a lot of sense and open source, but master should not in our IT context be always replaced because master data management is not a bias term. So those are some of the things we, the new one says we wanted to include in the, in the dialogue and they'll be, you know, a number of other things like that. So I'm really excited because we have the standard stream going. We've got AI ethics team involved with us to make sure that there's fairness in the, in the, in the terms, because there's a couple of things we have to be careful about. One is that we are replacing the terms in a way that translates well into other languages. And we have a terminology team that's working with us with an IBM. We were lucky to have that in place before. And then the other thing is that in addition to ensuring that it translates in offensively, we're not being trivial in just replacing usages of terms because they are, you know, the color black is a fine color, right? But what black list is not. So, you know, giving the, that, that type of context, I think it's key. So the other thing we were looking at. So from a standards perspective is we start with IT industry, but we can see this pretty soon turning into an opportunity for other places. If we really want to sustain change, we've got to reach back into academia, universities, and then earlier education and open source is a perfect place for us to collaborate across those boundaries to make that happen. So you probably could have heard of quote for quote for racial justice that we just announced this week. It felt like it was a long time ago at all things open, but there we are one of the exciting things that, but that is we're hoping to use that and our relationship with Brianka and the Linux foundation to start working on not just the IT code replacement aspects of it, but the community around this, right? The trusted community who's going to look at the bigger topics around AI, ethics, language, the, and, and, you know, how do you get this back into academia? So it becomes something that's sustainable long after, you know, we stop doing this. Yeah. No, one of the things that I'm excited about with the software development first initiative, STDI is the fact that we're basically bringing researchers who've been studying these problems and studying these types of issues and trying to get them met up with industry as well as open source projects. So we can figure out what the best practices are and get them documented in a way that's accessible outside of the academic papers. So that the projects can go and employ them. And so super curious to learn more actually. And Definitely. We've got people I'm working with in the research community that are really keen to sort of figure out how to do this well. And you know, it's going to be so good because we are all sides, like all pieces of the spectrum here, right? Like we have a for profit company. We have an open source project lead. We have researchers. We have DNI leaders. Every perspective can come together into what is probably like the canonical advice so that it like reflects all the various realities of the initiatives that we're all doing. And I think us coming together is very powerful for that reason. We are pretty much actually over time. This panel that became super juicy, which I loved. Stephen, did you want to add any final words to what do you want to see in three to five years? Yeah, sure. So I, you know, I think I'm going to mention something that all of my mentors kind of expound on me and whatever I'm teaching, I try to do the same. It's it's people process tools, right? That's the order that we go in when we're learning doing things. And I think that we have started the right way. Right. We have understood that we needed to put the right people in the rooms or in the multiple rooms, virtual hangouts to have this discussion. Subsequent to that with those right people, you can develop appropriate processes to get this work done and get it done in a consistent matter everywhere. Right. And then, you know, moving forward, impressive to see the work that GitHub has done around around making those tooling changes. Right. So when you start to talk about tools, you can't do this, you know, you can't do this willy-nilly. Right. One of the things that we were worried about in Kubernetes is that, well, if everyone starts changing master domain, like RCI systems are going to fall over. Right. All of the bash scripts that we've written are going to fall over. So making sure that we're very deliberate about the way we make these changes. And that's governed by process, right? That's governed by process and that's governed by people who develop the process. So again, people process tools is the way to success. And I think that we are starting off the right way. So I'm happy to be here and I'm honored to be on a panel with all of these very impressive folks. Yes. Right back at you. Exactly right back at you. Thank you so much for that. I would like to wrap up this panel, this amazing learning experience by just saying to everyone that we are all here because you belong. In Team Cloud Native, in my little sphere of the world, we talk about how every contribution matters. Any person's contribution, any type of contribution matters. And inclusivity in language is one of the key ways that we will encourage all kinds of folks to just join in. To build this further, from here, we are going to be hosting a community meeting at our event, KubeCon, NativeCon North America, which is November 19th to 20th, 2020. It's virtual and I highly encourage folks to attend. It will be awesome folks like these as well as many more who are all interested in coming to that, you know, set of guidelines that we want to have together as an ecosystem so that we're not duplicating work and we can all do it once. So, with that said, I am going to just quickly share my screen so folks can know where to go to take a look at KubeCon, Cloud NativeCon North America. And of course, just when I try to do that, I cannot find the tab. But let me look really quick. Oh, did I actually hear a little bit? Well, okay. Sorry. Hold on one second. Apologies for that. Things that happen when it's not live. But yes, please join us. We would love to see you. All of us will be there time permitting and we'll be discussing the right term, like how to get to a place where the project wants to make a decision to decide what will be the change. And then the change management process, how to involve the standards bodies, all those questions we're going to discuss and it's going to be an open forum. So come to the event November 17 to 20. This particular session will be on Thursday the 19th at, I think, yeah, at 9 a.m. Pacific time. And in the agenda here, you'll see the details. But we really hope to see you. Thank you so much for listening and very happy to be at open source summit. And thank you so much to all of you, my panelists. Thank you. You're very welcome. Bye.