 Hi, my name is Lindsay Nguyen and I am the chair of Hyperledger's Diversity, Civility and Inclusion Working. I'm also a technical program manager in Google's Privacy, Safety and Security Organization and I'm joined by my colleague Dan Middleton to present on the topic of diversity, civility and inclusion in open source governance. Hi, I'm Dan Middleton. I'm a principal engineer at Intel focusing on security technologies and I'm lucky enough to get to do a lot of that in open source, which is of course where Lindsay and I were able to meet a few years ago. We wanted to share with you what we've learned about promoting DCI in open source. I think it's something that's going to be something that's going to be relevant for for anybody in open source, but something that's particularly useful to those of you that are working in open source governance. So an institution's history is inevitably going to shape the context for its current state of diversity and inclusion. It's no different for us, which is why we've elected to start out here highlighting a few elements, diversity, civility and inclusion. These were the foundational principles that our organization was founded on in 2008 when Dan as the chair was joined by other passionate members of our organization to really found what we know now as our diversity, civility and inclusion working group. The industry is migrated to a term diversity, equity and inclusion. And inevitably as industries and programs do, it will evolve again. But the key takeaway here is that the mission and approach for each of these concepts is extremely important to crafting and architecting a successful diversity and equity inclusion program. Making sure that when people come in to your program, they see themselves represented there. Also that when they start to participate that they feel a sense of belonging and welcoming. And last but not least that it's done in a way that is both respectful and equitable and the systems and mechanisms that you create throughout your governing board are meant to actually reinforce each of these principles. And one of the reasons that we started with diversity, civility and inclusion is that civility was such an important factor in online communities. And of course open sources is a version of an online community. One of the other things that we get from open source though is the ability to take not just code from other projects, but we get to learn in a variety of ways, including best practices for open source. So in these slides that will be available for you, we've got links to a number of other open source organizations and their different diversity and inclusion practices. But what we're going to do in this talk is pull some themes that we found across these. To kind of kick things off though, we've got a few simple ones. The first is that the earlier you start, the more impactful your DCI effort is. We learn that from several people in CNCF that credit their success with having a healthy community from starting out with diversity and inclusion as important priorities from the early days of CNCF. Something else that you'll see across all of these that I was exposed to when I first joined Hyperledger was a code of conduct. That's sort of table stakes these days. Everybody should at least have a code of conduct as a starting point for your diversity and inclusion efforts. And then moving into the Confidential Compute Consortium where I spend a lot of my time now, I've found that having regular and recurring dialogue is one of the most important things for success. And we've heard that from some of the other projects that are listed here and elsewhere. But we want to draw some other aspects out of these experiences that we think are useful, particularly for governance. And when we think about governance, one of the things that comes up is the structure of how the open source body is organized. On the left side of the screen there, you'll see where some of the diversity and inclusion efforts are really focused around the foundation. So you really have kind of a more traditional company when you think about it backing the diversity and inclusion effort. But within the communities themselves, you'll still often have a different way of approaching it organizationally, whether it's from a working group or it's a portion of every aspect of the organizational structure of the open source effort. Now, no matter what end of the spectrum your organization falls on, what's really important to recognize here is that each structure carries with it its own challenges and stumbling blocks. In Hyperledger, as we've chosen to use the special interest group and working group model, some of the things that we watched out for very carefully is any evidence that we were creating these programs in a vacuum, that there were silos that didn't really allow our efforts to permeate the entire organization. On the other end of the spectrum, in the integrated approach, some of the things that I hear colleagues trip over very often is that they get lost in the minutia or it's not held at the same level of importance as all of the other business priorities or even worse, that they don't have a clear owner, our next action to really continue that momentum and fuel their efforts. So really, as you start to architect your governing body, make sure that you embed those feedback mechanisms throughout your program so that you get early and often signals on when you need to really adjust to ensure the success of your program. Yes, there's no one right approach here but we're going to share with you some of the approaches that you can consider and find what's right for your community. Now that I spend most of my time over in the CCC, our structure looks a lot like this, which is a fairly contemporary structure for Linux Foundation projects. You have some sort of technical governing body, some sort of more business oriented governing body, the projects themselves, you may have one or multiple of them, and then typically a variety of member companies that are actually contributing the developers and some of the other resources, technical writers into those projects. And then often you'll have some sort of marketing or outreach whose job it is to help promote the open source that's being created there. And when we look at any of these particular bodies, you can see from their perspective how they might actually be the most influential in promoting diversity and inclusion. And that's exactly what we want is to avoid that problem of nobody feeling ownership for the problem if you do try to distribute it across all of the governance bodies. So we look at what that might look like. So if you have in your technical bodies attack, a lot of times the role of that is to charter organizations, charter projects, charter working groups. So they sort of set the tone for what will be required, set the tone for what the composure is of that new project or working group. You go into the project itself, you can see right away, well, that's where the individual contributors are, that's where your community is. So each participant there, whether they're a first time contributor or a maintainer, they have an opportunity to encourage inclusive behaviors and bring new people into the project. If we go up to the governing board, now the governing board has this very important role of being able to set mandates for the entire organization. And one of the reasons that we know that a top down initiative for diversity and inclusion is so important is that we know that across the organization that everybody will listen to the priorities that the governing board sets. Absolutely. The importance of a top down approach really ensures that your organization's broader goals are inseparable from diversity, equity and inclusion goals. It makes sure that you don't just have a guest appearance in these dialogues, but you have casting characters who can really drive the success of this program on a continuous basis. Something that we sometimes lose sight of within governance is how we can work with the member companies. Because of course we're all part of, often part of these member companies. And the member companies are the ones that are supplying some of the talent into the projects. And so if we think about it from the member company perspective, what better way do we have to directly support the projects with the diversity that comes from your individual company and also share the values and diversity and inclusion that your companies have. I know within Intel we have a program called Rise 2030 where we're looking at completely reforming the constituency of our company with a target of the year 2030. And we're able to bring a lot of those new behaviors and best practices in what we do externally like an open source. And then last but not least is outreach. So while each of these other bodies has a direct point of connection with the community is some portion of the community themselves, outreach may be more than any of the others is really there to put the face on the open source project. When we were getting started with with Hyperledger, there's a lot of independent origin stories, if you will. So we had contributors from IBM research that we're working in one location, Intel research in another different startup organizations. I got to work with some colleagues at a company called Bitwise and we would meet in this cafe downtown and every day that we would go there we would walk past this sign inviting everybody to enter that business because everybody's welcome there. And we thought what better way to welcome new contributors into our growing organization than to adopt that slogan and adopt that image. So we worked with the creators of all our welcome here and we worked with our marketing organization to get something in the Hyperledger color scheme and that's really become, I think a fairly inseparable part of the Hyperledger brand. I encourage Dan to really tell that story because at the core of a successful outreach strategy is really inspiration, making sure that people feel inspired by what you're doing to continue this work. Sometimes, you know, as diversity, equity, inclusion, professionals or practitioners, or technical practitioners, you get very bogged down and, you know, discouraged by what seems like a very, very big lift. Don't forget that at the heart of each of these initiatives are things that are near and dear to people's heart and their livelihood. Also, when crafting the strategy, think about being inclusive. Don't just publish things and hope people adopt them on, you know, the latter end of your initiative, but make sure that they are included in the entire life cycle of this dialogue as you create the different artifacts and events and programs that are going to fuel your diversity, civility and inclusion governance program. And then lastly, but definitely not least, is authenticity. So making sure that everything you say is seeped in a genuine respect and care for the demographic that you are trying to rope into your initiative. I'm reminded of the saying, heal the novice and novice. It is a Latin term that translates to something about us without us. And it makes sure that you are really welcoming in diverse perspectives throughout the entire life cycle of your initiatives. It is absolutely imperative to people being able to receive what you are actually putting out as a genuine effort to rope them in to your technical or, you know, governance efforts. We also want to, you know, share a little bit about how we've done this in Hyperledger by talking about an event that I look forward to every year, Hyperledger Global Forum, right? We have a programming and events committee that really makes sure that even from the beginning when speakers are submitting each of their talks and content that it is done with a respectful tone, that is timely and relevant, but also that they can filter each of these talks through a lens that makes sense. One example comes to mind. A group of people submitted a talk to Hyperledger Global Forum. It was comprised of two men and a female contributor and the contributor that was female had to make sure that their session didn't come across as insensitive or intentionally presenting a man on, right? Which we know has been a persistent problem across the industry. So we had the conversation and we had the mechanisms to do that to make sure that the value proposition for that session was clear and that their approach was respectful and met all of the other criteria that the diversity, disability and inclusion group really gets behind. We need to make sure that you have those feedback loops embedded throughout your events, throughout different things, artifacts that you publish, and also just as a regular part of your meetings. We start off every meeting with a, you know, nod to our code of conduct and our principles in making sure that whether you're new or old, you are reminded of the things that drive our community and our outreach efforts. So on the tactical end, definitely make sure we're doing all the things, events, blogs, medium post-newsletters, but at the core, the thing we really, really want to drive home is make sure that it is done in an authentic, inclusive and inspired way. Yeah, and I'm glad that you mentioned welcoming people and referencing the code of conduct kicking off every meeting. It seems like a subtle thing, but having that constant presence is something that really helps develop the DNA of your organization. Now, we couched a lot of the last material there in terms of an outreach or a marketing perspective, but really if you think about a conference, that's going to go across each of your organizations. Your governing board is going to be involved in that, setting requirements like not having any manuals. You're going to have outreach, of course, promoting it. You're going to have your projects involved. So we want to come back again to that perspective of, regardless of which aspect of it is that you're contributing in your open source organization, there's going to be an approach for it that probably has about three different tools. We can think about it or three different methods to affect the kind of change or the new behavior that you want to see there. You can explicitly require something like a must or you can recommend something kind of like a should. And then you can also provide resources that facilitate that new behavior that you want to see throughout your organization. One of the things that I learned from some of my colleagues in the CCC from Microsoft is this idea of minimum viable governance. And that in my mind really goes to saying, well, we want to enable output in open source more than we want to control output. So wherever possible we look for ways to facilitate things to make it easier for our projects and our contributors to make diverse and inclusive choices. So here we'll share just a few examples of what that looks like in a concrete way for the diversity, civilian inclusion working group. Our code of conduct, which Dan mentioned earlier, again something that he pointed out was that it was inspired by another code of conduct that they found. What's equally as important is making sure you revisit that. Making sure that it is still fresh and appropriate. That is a living document and that it's something that each of the members who come to your community know exists and know is something that really drives the acceptable behavior for participation in your community. Also, each of our leaders, spokespeople throughout the organization are required to really educate themselves and take trainings to be educated contributors in this governance program. Making sure that as things change they are up to date whether it's on how women are included into the hyperledger efforts or how the black community is roped into the organization. The demographics and the DNA organization will change frequently, but making sure you keep up to date with that and constantly engage members of those communities is key to making sure that you're current. Also, recommendations are timely topics, timely events talking through those in the meetings or convenings that you all have. Making sure whether that's done in an asynchronous or in-person way that you have structures to actually facilitate each of the principles that we talked about earlier. Another example is in hyperledger global forum, having the parent support mechanisms for people to participate. Great feedback mechanisms to make sure that everybody who wants to actually participate is enabled and empowered to do so. Also, there are a number of things that you can find on the DCI website, but also things that are more real-time. One of the things that we created was a baseline survey to make sure that we were measuring the demographics that we had in the DCI group, but also creating a strategy that roped in members of the community that weren't represented there. Our localization efforts are another key example of how we chose to infuse those principles and activities into our program. We just hope that whatever again you choose for your organization that you can leverage this framework as a resource. We really want you to think of this as a framework. If you just take this slide and delete the bullets out of it and go into your next meeting with these three buckets and have an open dialogue about, hey, how as a community can we fill up these buckets? What are the important things to us? That can be an effective tool. Just to relate how this first conversation went in the confidential compute consortium, we recognized that we had already set a requirement that each project must have a code of conduct. That's an example of a requirement that was set. We didn't require a particular one, but if a project didn't have a preference we were ready to recommend for them the contributor covenant too. That's sort of a should statement. In order for codes of conduct to actually have some backing behind them, you want a reporting mechanism that is staffed. In the case of the CCC there's the email address that you see and that will actually get copied out to all of the board members. We're providing a resource that facilitates the projects having an effective code of conduct in a way that might be more difficult if the projects had to resource that themselves. But when you go and have this conversation and you start with a blank slate we don't want you to have to have that awkward silence of nobody knows where to start. We've got a number of recommendations within here to start conversations. The bullets that you saw in the last slide you can use those as a starting point. But if you're say outside of what is maybe more properly a governance meeting, let's say you're talking to the maintainers of one of the projects. This set of best practices is a great thing to talk through. It's very, of course developer or contributor focused and there's other parts of the organization that might not be as relevant for these particular ones. But we've got another slide here that has a broader set of resources for you to look through. We've mentioned training a few times. The Linux foundation has two classes which are great and they are publicly accessible so your communities can reach those I think without any cost. And it's a good way to inform them of some of the things that they can be doing. Often it's beneficial to have guest speakers come in whether it's to your tack or your board and do some education on maybe a technical topic that's relevant to your community. But it can also be a topic like diversity and inclusion. But just like when setting up conference you want to think about what kind of speakers you're having come in and make sure that you are getting a hold of people that are representative of the broader community. Of course a lot of our interactions and we don't think about this a lot are not face to face whether it's a video or just verbal on a call. The very first interaction that somebody has with your open source is likely to be your documentation. And if not your documentation then your code. And so making sure that that is up to date is one of the most inclusive practices that you can do. But then also further making sure that the way that you're developing the way that you're documenting is itself inclusive is beneficial. And so we've got some writing guides listed there that can help with that process. Another thing that they can kind of stall progress in open source organizations is sort of not knowing when to start or what the next thing could be. And so something that can stimulate some more discussion about that are using commemorative dates. So let's say Pride Month is coming up in the U.S. in June. That can be a calendar date to strive for. We want to accomplish a certain goal or start a new initiative and that's going to be relevant to that community in June. And since there's always something going on throughout the year we need to pick from to help stimulate new conversations. Mentoring is another area where you can get new contributors into your organization that you might not have without having gone through some extra effort. I know over in Hyperledger they will fund some mentors directly. Other organizations do as well. Over in the CCC we've just started talking about how we can work with Outreachy to get interns into more projects there. So one of the things that we hope that we have really imparted during this talk is that you have to keep the conversation going. It is a journey not a destination and the people all around you are really critical in making sure that everything you do is done in a way that is set up for success. Again we have talked through the structures to set up. We've talked through the different roles and responsibilities in the governing bodies but make sure no matter what there is a continuous tone of collaboration that is set across your organization and make sure that you're measuring and tracking success it will ensure that your program actually ups the bar and make sure that you are really keeping with those goals that you set for your program. Also making sure that there are the resources and artifacts at the ready for people to grab hold of in a way that's convenient for them but also as Dan mentioned from our localization efforts in a language that is going to hit home with them. Each of these key components communication artifacts at the ready for your community are really foundational. Dan, would you like to add anything? Because it's so important I will repeat the importance that it's having a conversation is the most important thing you can do and having that be a recurring thing is something that makes it in the DNA of your open source body. And in that same spirit we want to think as we come to a close in this meeting what's the next step? That's part of the conversation that you have in your open source is we're leaving this meeting having made some decisions or made some progress but what's the next step? So we're all thinking in mind what are we going to come back to and we have a starting point to pick up the next conversation with. So the next step is we want to hear from you. If you have something that's worked really well in your open source organization please let us know and we want to share it with other people we want to adopt it in the projects that we're on and even if you just have questions like I don't know where to start I don't know how to address this by giving us those questions that helps us figure out what content that we should develop and maybe we already have an answer for this journey together. Thanks so much for spending your time with us in our presentation. Thanks so much again for your time and your energy. I hope you all enjoy the rest of the conference but most importantly enjoy each other. Have a great rest of the conference.