 So good morning. Great to see you. It's awesome to be back together in person and this is definitely a talk about building communities and so it's really great to see the community coming together again and I want to talk with you about how we can make our open-source communities as Welcoming and inclusive as possible so that we can be together and have a lot of different voices in the room and How how we can go about doing that and give you some some strategy some tool to achieve that I want to start by reflecting on the four opens that the open infra foundation is Living up to this is the the core values that we have in this community the first one is about Open-source and this is about the license of our source code and having it available to everyone giving everyone fair access to the features the the source code and And if you read more into it on the open infra vision, it's not just about the open-source license We go a little bit further to also Clearly say we're not doing open core, but all features are available to everyone So this is at a really technical Artifact level not yet about community. This is where open design starts bringing in the community aspect of saying we are Building something together. We don't want to have a few individuals making decisions We want to make decisions about how we develop Open stack and Zool and Cata containers and starting X as a community that's not to have assume one person knows everything but that together we get a better idea of the features that we all need and Work on a process together on doing that So this is where open design starts to embed community as a core value and it's taken a step further in the open development where now This idea of open development is how do we actually Have processes in place How do we make it possible that everyone can? contribute come on in join us and So we want to transparent inclusive development process Open development is about how we go about doing this the next value open community Really focuses on the people now on saying okay We want everyone voice to be heard. We want everyone represented in the community. We want to have leadership positions Filled with a diverse set of people So if we are looking at the open infra foundation and our projects what we are striving towards is to have this very inclusive environment So this is what we're striving towards now if you take a step back and look at the open source ecosystem as a whole For many years now, this is the github's open source survey from five years ago And unfortunately there are not really much newer information So we have to rely on these Somewhat older data, but I don't think a lot has changed. So let's look at those numbers that we do have Github found that 95% of respondents were men only 3% were women and So there's a huge imbalance if we look at the users of technology and The population on this earth as a whole where it's about even there's a huge imbalance Other surveys like Mozilla. They found a somewhat more even Distribution, but still there is an imbalance in the gender distribution in our community and Open stack had a community report Four years ago and even here the authors Said that typically in open source we have 10% women and open in open stack We have seven to eight in when we look at the code contributions, but then when we look at the leadership and governance We already see a larger portion. So we are making the right strides starting at the top for opening up the door and inviting Women specifically in this report to participate and make a difference and be heard and be seen and Have a role to play So so this is the situation that we know exists and we want to change that we want to work actively towards being more inclusive bringing more people in having a larger community and There are a lot of different suggestions of what to do a One that has become de facto standard today is to have a code of conduct and to enforce it The enforcing part is still where a lot of communities are struggling, but I've seen and heard many times now that if Community does not have a code of conduct developers are not even going there. They're like No, this is a minimal requirement for an open-source project today Just a very simple thing to say, okay these are the rules that we expect everyone to abide by just you know, not just be nice to each other but actively suppress toxic behavior speak out against it and Make sure everyone gets included we can go a step further and creates basis for our Contributors that are in a minority for whatever reason there is a lot of different Demographics that we could go by gender sexual orientation where you are on the on the globe which country you're in it might also be religion or Ethnic group or whatever so there are many different ways that someone can feel in the minority and have a harder time to Feel they fit in and contribute So how do we go about doing this? There are many different things. I Want to focus on one? one specific strategy That focus more on the technology side. What can we do on a technology level and to Counter the bias that we are sometimes introducing without even knowing it and I want to Follow a process that might seem familiar where we want to discover what is Maybe preventing someone from contributing Understanding why that is a problem to them Maybe it might not be to us but to them and then resolve it. How do we go about resolving it? And if you are Familiar with squashing bugs then this should sound very familiar where someone identifies something is not working, right? Okay, let's Look a little deeper. What's going on? Where's this bug coming from and then? discussing how to solve it and I want to thank Anita sama who is a professor at the Oregon State University who I learned this Strategy from so I want to give her credit for that and I'm also working with her on a book about this and other strategies and how to promote diversity equity and inclusion in open source So let's start with an example So you understand what? I'm what we are talking about. Let's say we have someone who comes to our community and discovers a Typo or something in the documentation where they say I I know how to fix this That like what what it should be correct, but how do I go about actually fixing it? So they might come to our Read me and the only blurb that they find for contributing to our project is to help us with code you know describes in One sentence that there's a 30-minute process for contributing anything Is that really an investment that I would be wanting to do if I just want to update? The documentation and make a fix there probably not so also in this description if If I am someone who Just once the here go here go here go here. I need to process to do it. This doesn't give me anything and so If you think about it, okay, who is this person? How do they like to solve a problem? We might come up with a much better Description say okay, we also want documentation Contributions here the steps needed to make this happen and then we break it down and make it pretty easy Now how do we arrive here? Let's first think of this is now the process that we can go through When we walk in someone's shoes, that's the goal figure out, okay What do they want to maybe help with? What are their goals with interacting with our project? What are they even interacting with? Are we talking about our issue tracker our read me? Installation guide the tutorial and then what do they want to do with it? So so we need to have a focus Once we understand what someone wants to do in our project We can describe the steps required to actually do it and we want to be explicit for Here are the things that you need to do so for making a documentation change on a GitHub repository it might require clicking the edit file and then describing the commit change in a commit box hitting commit and then We're not done yet. We also need to create the pull request and That there's a few extra steps So so we need to be clear about what are the steps to make that contribution? to achieve that goal and then we have to Think about our newcomer or someone who comes to our project. Who are they? How are they? Thinking how they what are their motivations? So is this someone who just needs to get the work done and or is this someone who likes to tinker with technology? What what is their background? Because that shapes the way that they're approaching our project and we want to think about this person a little bit So we can walk in their shoes Do they feel comfortable enough? Just clicking on a button and seeing what happens or did they want to know what actually is supposed to happen before? So they click on it. So there are different ways people approach technology and approach problem-solving on on our technology So we want to have that picture in mind and Then we can go into understanding. Okay, let's come to our read me if we go back to our example and Think about those first goal that we described back here Edit read me file. Does this imaginary newcomer? actually Figure out that they that's what they want to do edit the read me if Yes, maybe no, and then what in their personality might have Steered them towards yes or no and this is this important to note because if someone is an Information processing style that is comprehensive. So they like to understand everything the full contribution process first before doing something and we only provide them, okay You want to edit the read me file without giving the steps then they might be missing What are the steps that I need to do and so we can say no, they actually don't and market why The same we do for for the steps with Creating the commit creating the pull request. What are the steps? And why is that maybe a challenge for someone who thinks in a certain way? And I I know from experience that I made a change I saved it it's done and then GitHub that workflows longer and so for a lot of people the way that they think It's not intuitive so we described that first are they even Figuring out what the action is and then once they take that action Do they get the confirmation that they know what they did had the effect? They wanted to happen So is the feedback loop working in our process in our documentation in our Whatever they're using and then we can Prioritize fixing any any bugs that we find along the way We can count how many issues did we have with figuring out what needs to be done and taking the right actions and if we take into consideration that Where we had these checkboxes for the different Aspects of a personality Then we can also identify. Is this a diversity issue where someone just thinks differently from us So with the best intentions, we can write the best documentation But if we write in a way that is good for how we are thinking and someone else thinks differently then This process would would show us that this is an issue So then we can go ahead and say okay here is where we decide to Resolve this and then we do this again and again and again with different personalities in mind We do this walk through several times and the more often we do it and we do it as a team maybe two three people do it together and they bring in different perspectives to figure out okay where in our processes where in our contribution are the breakdowns and They do it from someone who is more of a tinkerer to someone who is more of I want to Have all of the steps laid out before I even start the process and That's how we find out where to make our improvements So this is this is this idea of discovering understanding and resolving the what what is maybe preventing other contributors from working in our communities and I will I I made it very fast. We still have plenty of time to talk about it and share experiences and If you have anything you want to bring up and share with the group I always like to provide a forum for that as well. So thanks for coming and having interest in this topic Just out of curiosity. It does this Approach make intuitive sense or are you like what is even talking about? Where are you on on this nods or shaking heads nodding? Yes Yeah, so for anyone who is on the live stream. I was gonna repeat it. Oh, we also have a microphone So for anyone who is listening from the internet the comment was about not just describing the prospect also motivating and getting people to Actually take that step to contribute and when they find a buck to also help fix it Yeah Okay, thank you. Yeah, so how do we how do we motivate? Maybe that's a good question for For discussion. How do we get people to? Not just say, okay, here's the buck and I reported which already can be a hurdle in itself How do we then engage them? So what are some strategies that we can use to do that? One of the things that I know turns people away is if they never hear from Someone else in the community some validation that yes, this is a bug. Let's work on this together so having some some SLA bad word here But some some response time that we want to maintain as a community could be a first step to engage the people right when they Feel the problem of the bug there. They already invested Contributing the bug report and now we can capture that interest by responding and inviting them. Okay How would you solve it? Yes? Thank you for reporting it Any ideas on what we can do next? Maybe that is a first step Any other ideas for how to motivate Contributions bug fixes Are there other things you have already thought about going in so that was just the first thing that that came to my mind So I think it's even hard to get to get the people in Motivated to first create the the bug report and open the issue on github and this is not because it's too hard for them because it's just Yeah, they check out the project and we'll never do it because why should I care for others code so I Think it's more to get the people into the Into the mood to contribute to open source projects here. We need more effort. I think So this is not about a single project more of a mind shift in the industry that When we are using open source and we're relying on it that we also want to Help maintain it and contribute back as much as possible. Yeah, so Yeah, it's a valid point Sustainability is a big issue in open source projects and that is one of the solutions we can have that Yeah Yes, thanks. No, I was just gonna respond to that point. I think that's probably also something to do with like Just imposter syndrome of new contributors who are just coming into the project thinking that oh What if my bugs not good enough or what if like it's not a valid point or What if like the maintainers know better so I think it's Having more inclusive documentation just in general Encouraging people to like file it here It's simple or like you said like documenting how you can actually File it or like the step-by-step process that it's actually these five steps that you need to take so I think That's probably one of the reasons Yeah, thank you and We can take that a step further not just describe Here is how you open that bug report, but here's also the response that you will get Here's what you can expect as a response because that can lower the anxiety Going somewhere new and not knowing Okay, am I gonna be called out on this or are people gonna be happy or What what's gonna happen next am I expected to now write 10,000 lines of code to fix it myself or you know just Also describing okay after you respond or after you create this issue Here is how we as a community have agreed to respond and maybe even have templates for that Where we can say okay as a as a buck triaging If I'm doing buck triaging here are the things that I will be looking for You know does it have the right labels? Is it in the right place? Does it have all the information? And so as someone who is opening that issue I Can already anticipate what questions I might be getting back how I'm expected to be involved in the following process So one of the projects that like I've been working on recently is to Actually help build a community around an open-source project that my team has built in the past So there has been this project like around for like more than two years. It's called It's a the project is called thought so it's about like Python packages and it's it's like a guidance service But we have recently been working around like actually building a stronger community around it making it more You know like you said me giving creating that whole feedback process where the new contributors actually get to see Time to response as a lios SLI's and all of that Information on like a dashboard or some sort of metrics Even including like AI or AI ops to it. So we have been working on a bot that can sort of That integrates with pull requests on a GitHub Repository and based on the past PRs of that repo it basically gives a time to merge estimate or a time to React estimate on the issue. So the new contributor already gets to see that. Oh, it's gonna be reacted within one week Two days three hours. It's not accurate always, but then with more Issues with more PRs it gets like rebuilt retrained Iterated upon and that's also something we are gonna talk about today that whole process, but I think There's so many ways you can do this, right? Like like you said like giving that sort of Feedback that this is when it'll be reacted on this is what happens after you open the bug or the issue and whatnot Yeah, thank you for sharing that Do you have You said you have like dashboards and tracking of the responsiveness and how long things are open or first response Are you are you seeing an impact from implementing certain strategies to? Retaining contributors newcomers or what does the data show you if I if you don't mind me asking So that's the sort of next step which you are going to be looking at right now we are at a very Amy come in so right now we are at a stage of like just Creating those outward-facing dashboards and integrating them directly into either the GitHub repo or the website where the Users would generally go to either like find documentation or open bugs and whatnot. So I think Right now we are trying to put it out there capture some metrics and see How many people actually landed and how many people who landed on the dashboard actually went to open a github issue? Or went back to like clicked on to the repo or like did something and find that whole user journey and That's our next step. We haven't gone there so far, but Like I'm very curious to see like does that create does creating that kind of visibility into React time into support Make an impact on the user actually so TBD still being investigated, but we'll find out soon. I guess Yeah, awesome. Thank you. Thank you for sharing. I Would love to talk more with you about this Afterwards and we're also going to be Emilio and I were going to be in the metrics corner downstairs Where we have dashboards for all of the Open-infra projects well open stack we're still working on that but the others we have dashboards and metrics Those kinds of insights at least for the open-infra projects any other comments Anything you have tried or experienced something that failed maybe even where you're like, don't do this again All right. Well, I think we have two minutes. So We'll all get two minutes back Thank you so much for joining the session and I hope to see you around the chaos community, thank you Amy is The community health analytics open-source software community where we talk about metrics analytics community health diversity equity inclusion So a lot of the things that I learned I learned through conversations with members in the chaos community