 In Tim and Matt's talk on contributor sustainability and open source, they discuss the need to balance incentives between open source contributors and open source consumers. Much of this discussion was through the lens of who is contributing and why. Next we'll hear about another important facet to open source sustainability, diversity. While most folks first think of code when thinking of open source contributions, communities require contributions of different types from people with a range of backgrounds in order to be successful. Solona is here to show how to build a community that supports all of the different user and contributor personas through process creation and automation. Enjoy. Hi and welcome to It Takes a Village, Role Diversity at IEEE SA Open. My name is Solona Bonewald and I'm the Executive Director of IEEE SA Open. I can be contacted at GitLab. I'm at Solona One and also on Twitter where I'm just at Solona. If you friend me, I'll friend you back so that we can do DMs if you don't want to have a public conversation, but I'm always up for those. So by now, the majority of you have heard a fair amount about the benefits of diversity and have probably seen some different aspects of it, but I'd like to go into it a little bit further and review some of those with you. If you go and look at, for example, Harvard Business Review, you'll see that they've been publishing studies for at least the last 26 years. So many of these ideas come from there. So one of the things that it shows is one, the majority of the companies that have, say, a diverse board, they have greater profits. They have larger customers, things of that nature. But one of the things that I picked up and noticed, and I think that that's really going to be true for open source or some of these, which is one, diversity helps with creating better products. And we'll talk about that a little bit more. It also helps you grow the size of your community. And when you do things like growing the size of your community, you get to have things like hopefully less abandonware, because you'll have a larger community and you'll be more in touch with their needs and desires. And so you'll have more longevity. Also one of the major causes of abandonware is burnout. When you create a larger community, there's more to go around. And so hopefully less burnout occurs as well. And then a really big one is less biases. A lot of times when we're creating things on our own, we kind of get stuck. And when you have a diverse group of people working on things, you'll find where a lot of those biases are. So that's really helpful. And then I think a really big one is less tribal knowledge. In open source, you know, we've been around for a while. I've been doing open source for almost 20 years now. And there's a lot of tribal knowledge that starts to build up that we don't even realize that we have. When we expand and go to a bigger pond, then we find out a lot of times what those, that hidden knowledge often is and what those assumptions are. And then also when you have more diversity, it often lends yourself to having less toxicity. And we'll talk about that some more too. So I like this group, this image in that if you want to grow your community, you're going to have to go for a bigger pond. And that bigger pond is diversity. Some of the other benefits that you get are innovation. That one's pretty well documented. There's a bunch of different studies. If you'd like any links to it, you know, ping me on Twitter and I'll send you some increased productivity. Again, a lot of different studies in regards to that too. You get to have a larger community, better long term documentation. Like I said, they're really good at sessing out that hidden tribal knowledge, clear communication as well. Because you make less assumptions and it kind of chips away at those biases, that helps a lot in regards to communication. And that also helps lead to better quality. One of the things that I like to talk about a lot is if you're fishing in a small pond, you're not going to find those diverse fishes. And I'd also like everyone to really think about this one question. If it's not diverse or inclusive, is it really open? I think that's something that all open source communities need to ask themselves is if you're not doing that and you're not open to all of that, are you truly open? So why did I choose to focus in on role diversity? Well, there's a bunch of different types of diversity and there's a bunch of different types of studies going into all those different ones. I chose role diversity because of the fact that we're focusing on software. And I wanted to bring that into play. Some of the benefits of going towards role diversity is it's a functional diversity. And that kind of counters a lot of common problems that you see when communities are trying to work on bringing in diversity. A lot of times you end up having tokenism and that's a huge no-no. And so if we can go in and do role diversity, it helps with that a lot because one, it manages expectations. Everybody knows, oh, this is the thing that the person knows. The expertise is more of a given. You can focus more on by doing role diversity instead of any of the others. You can focus a lot on production readiness and so we're really trying to develop better software products. And then it also highlights the benefits of playing a role. So when that person comes in, they've got more confidence in regards to it. Have some really basic rules for that. And I think the biggest one is you want diversity, right? So be careful and make sure that when you bring those people in, you're not accidentally taking away their diversity at the same time. You really have to come in with an open mind and respect all of their differences. They may have different vocabulary. They may have different tools that they like to use. There's different locations. All of those different things need to be respected. For example, with vocabulary, we have the marketing advisory group. And there were some groups that were unhappy with the term marketing because they saw it as being too commercial and it indicating sales and things of that nature. And had to remind them that these people are marketing professionals. It's what they got their degree in. It doesn't have to do necessarily with sales and it doesn't have those connotations to them. And in fact, to sit there and say that it has those connotations can be a bit insulting. And that's the kind of thing that you have to work on when you're bringing in diversity so that you can be more inclusive. Also, remember they might not be familiar with the tools that are currently being used because they've been using their own tools. And those tools normally have actually been customized for them and their needs. So you have to work in regards to that as well and being careful for that. And then you also just need to go where they are in regards to location and things of that nature. And that also brings some interesting things into play in regards to how can you be inclusive when there are globalization and localization issues and making sure that you can take care of those properly so those groups aren't excluded. I'd also like to highlight the value of newbies. A lot of times when people are new and coming to open source software, people call them newbies. It's really inaccurate to do that because most of them aren't newbies. They're newbies often to open source. But that has its benefits because it means less tribal knowledge. They ask certain questions without fear because they're not familiar with some of those normal tribal knowledge or biases. And because of the fact that they're coming in with such fresh eyes and they don't know the history and they don't know things of that nature, they can really focus in on things like quality and usability. Also, remember that they're going to come in with some diverse processes. Their processes are going to maybe be different than the one that you've done previously. For example, at IEEE SA Open, we're merging standards with open source. And standards is very longstanding. It's been around for over 100 years. And it's about creating safety and trust and getting to consensus. And so they have balloting and all these other tools in their pockets that they use often, which open source can benefit from. But there's also some things where things are a little slower there. There's some problems with innovation. There's some other different things. And open source has that. So I kind of view bringing those two together as the Reese's Peanut Butter Cup collision where you've got some good peanut butter, you've got some good chocolate, they're even better together if you accept them in regards to their diversity and let them have their different diverse processes and figure out where the common ground is going to be. So how are we going about doing this at IEEE SA Open? Well, we're evolving the open source platform. And that involves GitLab CE. It also involves some of the other tools that we're using that are also open source. So when we're looking at our tools for going into our platform, we have some very specific requirements. The first one is it must be 100% open source. We're also using GitLab CE as our core. So it's kind of the centralization point for our platform. We're also doing a lot of work in regards to metrics. And we'll talk about that a little bit more. But one of the things that we need to be very careful of with the tools that we choose is what we call convenient data. Oftentimes with convenient data, we measure the wrong things. I know all of y'all are familiar with lines of code. How many people love measuring how many lines of code we created, how many lines of code, that's a poor metric. It doesn't really tell you what's going on. It just tells you that code is being written. And it's a dangerous one to measure because people can game it. If you told me that I made a dollar for every line of code, I could write lines of code all day long. It doesn't mean it's going to be good code. It doesn't mean it's going to be the code that we need. It doesn't mean it has any functionality. It doesn't mean it doesn't break the entire thing. So we have to be really careful about convenient data. We're also very transparent about our tools process as well. So in regards to the choosing of the tools, the suggestion of the tools, the vetting of those tools, all of those different pieces are transparent. So what we're doing in regards to the evolution of the platform is we're taking steps to go through it. And we're not just automatically coming in and coding and making a bunch of changes and doing things of that nature. Instead, we're walking through a process. And the first process is documentation. Where we go through, we will look at all the different pieces. We figure out what it is that we need. We talk about, we address it all from the meta level. And then we go back and we start templatizing things where we're going, okay, here's the basics that we need. Here's our checklists. Here's all of this type of thing. And we iterate on that for a while. We don't automatically start coding. We do several different examples. We onboard several different teams. We sit there and we see how it works. And then we do automation. With automation on the platform, we make sure that we can measure. And we can get those metrics that we just talked about earlier because that's really important to knowing how things are working because that's how we get to validation. On the validation, once again, we want to be careful about not doing convenient data. But we go through and make sure that we are measuring what we think we're measuring and that we're measuring it all properly. And then we standardize. This step of standardization is not necessarily the IEEE standardization, though many of the groups are already talking about going through that consensus-building process as well. But first, it's standardizing in regards to the term that we normally hear in software development, which is creating defaults that people use and use frequently. Another really important element for your community is rewards. And we're incorporating that into the platform as well. We're looking at badges and a bunch of other different things for doing that. Several of the things that we're looking at, these seem a little short and strange, but let me explain them a little further. The first one is healthy. And that's basically making sure that whatever it is that we're choosing to reward, we're rewarding the good behavior. For example, earlier I was talking about lines of code. Don't want to reward things like lines of code because it could lead to unhealthy behaviors. So we want to make sure that we're taking it to a positive place. The next one is making sure that things are accurate, that we are actually doing what we're doing and that we're rewarding things accurately and fairly. And then lastly, kind. Kind is kind of a strange one, but I worked in the gaming industry for many years and I watched games evolve on their rewards. And they often go to this place where you have a game, it's cool, it's fun to play, it's accessible, you can get new people on. It's a lot of fun. And then the game starts to evolve and the rewards get harder and harder and it just gets to the point where there's no point for newbies to ever come in and play or be a part of your game anymore. None of your friends who haven't been doing it previously want to join you. You lose a lot of people to it. It becomes very niche and clicky. And that's one of the things that we would like to make sure that we avoid in our reward systems. We are working with a bunch of other initiatives in regards to these metrics and looking at the role diversity aspect. Chaos at the Linux Foundation is doing a lot of stuff in regards to diversity metrics, both for open source and open source events. They've even got a diversity badge that they're working on. And we've been partnering up with them. There's also one that I just found out about a few days ago called a cross, which Google is doing. And that's focused on a schema and determining what those rules are and how they would like to measure those. And then lastly, it's a little different, but there's one in academia as well called Cassier's Credit. And they're also going through and looking at diversity in regards to open source and academia, which is a little different, but I think there's a lot to be learned there. And so we are talking to a bunch of those other initiatives too. I think the most important thing to note about the open source platform that we're doing is that it is community driven. IEEE as an organization is run by its volunteers. It takes a long time to be one of those upper level echelon volunteers, like most of those people have been doing this for like 30 years and they treat it like it's their second job. And so that's the kind of people that we've been attracting right now at the beginning for helping create a lot of those structures are subject matter experts, people who really know these aspects and bringing them all in so that they can create and set those policies and procedures from the get go. So within the community architecture in IEEE SA, we have a board of governors and they have committees that answer to them. One of those committees is OSCOM, the open source committee. This is the group that helps set things like which licenses are being accepted on the platform, making sure that everything is completely copacetic and they meet on every other week. There's also three other groups that we've created and here's really where you'll notice the role diversity coming into play. We have a community advisory group, a marketing advisory group and a technical advisory group. They also all have subgroups and I'll go deeper into detail about each of these groups in just a little bit. But the thing to note about these advisory groups is they really operate on a meta level. Oftentimes in open source projects you'll have groups that are similar to this, but they're called the technical steering committee or the marketing steering committee or even the community steering committee or things of that nature and they're all about the governance and how to do things within that open source community. This is going a little bit more meta than that and they're doing a lot of things in regards to best practices. If you have these kind of groups, how can you create those groups and what are a bunch of resources and things that they need to operate and operate well and so that's a big focus of these advisory groups. The first one to talk about is a community advisory group. This one is, I really consider it to be the heart of our community and that this is where you have a lot of the non-profits coming into play, a lot of the special interest groups, things of that nature. They really hold the culture of the SA Open platform and think of the processes for the community as a whole. Is this in the spirit of mentorship? Does this facilitate things? Are we coaching people through? How are we engaging in regards to participation? The types of people who normally gravitate towards this are, as I said, those non-profit leaders, the special interest groups who have, like we've got an education subgroup, the designers and the facilitators and those types of people. They provide a lot in regards to leadership, the inclusive nature, things of that nature, creating a very positive culture. This is on the platform. This is a little bit old but you can sit there and see the structure that they've even started creating. For example, all the groups have a project which is meetings, which is where all the meeting notes go and all the recordings of the meetings. They also have an issues board, which is where all the action items go as well and they check in on those and do a follow-through on that. The about section, we're hoping to soon be where we're kind of starting to grow the microsites for each of these advisory groups so that they can more easily reach out to the community at large and publish their documentation to use on social media. Then they have a lot of other different groups in here, notably the education group, which has just done a proposal to the technical steering, to the technical advisory group on features and changes that they would like in the platform to better support what they're doing in their work. That's kind of interesting. Then we also have the document and curation group which is working right now on a community handbook together with some of the people over at GitLab, most specifically Naritzy and Jaskrat are doing a presentation on that project. We're working together with them on that. We also work together with Red Hat on their open source way 2.0 book too. Similarly, sharing that type of documentation. Of course, you can sit there and see that we have a diversity equity and inclusion group. If you notice there's a naming advisory group, this has actually been moved over under OSCOM now because we realized that it needed to be something where we would be imposing certain rules for things like no, you can't use things that are trademarked. If you don't know the trademark, no, you can't call a project Mr. Poopyhead, things of that nature. That's actually happening and that's going through the official IEEE essay process now. The next advisory group that we have is the marketing advisory group. It's a little bit of a misnomer because it's a lot more than just marketing. It's also evangelism, social media, events, designers, artists, all that kind of thing. This is new. When I worked at Hyperledger, they have a marketing steering committee. That was just so very useful. I feel like most open source groups need something like that, but very few have one. This is very new and novel and they're working on a lot of different things in regards to it. They didn't even know how exactly do you do a marketing steering committee because there haven't been very many structures out there to go look at previous knowledge on. They have been a bit focused on creating templates and toolkits and things to better facilitate work for all the incoming new projects. They're doing things like creating a social media toolkit, creating a glossary. There's an open source, an OSINT group, which is open source intelligence, which is basically how do you go and do the research to find out about your market and do all that stuff ethically? To find out, is there a market for your product? How do I go find the rest of my community? Where are those people? What are they doing? What do they need? Things of that nature. Also, how to do things like social media branding, so getting the word out for that too. This is their group on the platform. You can sit there and see their page should actually be twice as long as this because of all the materials that they're working on and creating. I just couldn't fit it on here. I did want to point out the events one, for example, where they've created an events calendar that's on our website under saitriplee.org slash events where they're actually making it so the community itself can put events onto the calendar. They're even creating their approval process for that right now as to when events get put on the calendar, which don't. Right now, it's pretty open. It's basically, if you're doing an open source event, then you can put things onto the calendar, but they are trying to think in regards to the future, so go suggest something. Then lastly, the one that you should be more familiar with, but not really. This is the technical advisory group. Remember how I sat there and said, our advisory groups are being a little bit more meta than what you're probably used to? Well, this one is definitely going there. It's expanding out the rules here. It's not just maintainers and coders. Instead, it's also product managers, designers, architects, things of that nature. In fact, they're helping design the actual platform itself. The education subgroup in the community group went and they created a proposal that they actually presented to the tag last week about all the different things that they want and how they want to go through changing our platform for the better to better support academia and K through 12, which I think is really exciting that they've gone through and created this entire proposal. We've also been going through, and that's how some of the new tools have been added to our platform such as Big Blue Button. There's also some additional ones that we're doing proof of concepts on like Mitomo and NextCloud. They're all going through and saying, oh, we like these things. We would like to have them and they're creating an entire vetting process. It's fairly involved. It's about 12 steps long where first of all, they propose it. They have a checklist. Is it open source? Is it this? Is it that? And then we do a proof of concept and we walk everything through. And then they go through another evaluation process. We do a security analysis. We do a lot of different things for it before we actually go through and say, hey, we want to incorporate this on the platform. And the reason that we're doing that is because we want to have volunteers creating the features too. And so that way they can come in and do that. And by the way, all of this is 100% open source. So what does that mean? That means we're also sending this code back up to our parental open source groups like GitLab and Mattermost and Big Blue Button. And we're also sharing all of the different playbooks that we've created and run books that we've done for creating this platform as well. And then we're also working on containerization and modularization so that we can do things with other entities that have gone through and instantiated a copy and incorporate in their changes too. So we're going 100% open source all the way around. So this is their group on the platform. And you can sit there and see that they've got also with IEEE, we do a lot of publishing and standards which normally incorporates peer review. And so we want to bring that level of quality and validation to this platform and to the projects that end up running on it. And so that's why we've got the architecture group and the code review group, because those are groups that are looking at how do we do production ready software to get the level of quality that we really want to have here. And so they're working on some different pieces. And that's also the production ready applications. And then you've got the tool and features group where you can go and suggest that. And you can see the ones that have already been suggested. And then you can sit there and see that they're working on governance, best practices for creating one of these, the different components, things of that nature. So what we're talking about here is pretty ambitious, obviously. But IEEE, we've got 420,000 members around the world. So I'm hoping that once we get all of these people going in a really good direction, I think we can get there. We have a lot of goals. And I don't think that we could reach those goals without role diversity. And so when we want things like quality and accessibility and sustainability and creating things that are fundable, that really address the nonprofit needs and are reusable and easy to use and all of those different aspects, we really do have to get out there and recruit and make sure that we have a place for everyone. Because it really does take a village to grow our little software baby and to have one that's going to be mature enough to make it in this world. And so that's where we're headed. Thank you so much. Come and visit our website, essayopen.itriple.org, and ping me on Twitter. Or once you sign up, you can come and find me on Mattermost at Salona and chat me up. So thank you.