 All right, it is start time. So let's go ahead and do the thing. Greetings, everyone, again. And thank you all so much for joining my presentation entitled, Keeping Your Open Source Projects Successful to All. So this is a topic that is very near and dear to my heart. As I know I wouldn't be standing here today if I weren't for the support, encouragement, and allyship of my free and open source software comrades, a couple of who are sitting in the audience right now. It is an honor and a privilege to have opportunity to lend my voice to making our community even better. So thank you all so much for coming. All right, so now that all the SAP is out of the way, is my breathing in this mask disturbing anyone? OK, cool. So now we got that all out of the way. Let's go ahead and get the show on the road. So you're probably wondering who the hell I am and why I'm holding this poor dog hostage. My name's Trevo, and I am a technical community manager for a project called Cata Containers at Open Infra Foundation, formerly known as OpenStack Foundation. So I have an extremely short attention span, which has resulted in the development of a skill for describing complex things like eight words, which has gotten me pretty far in my career as I started out in the call center. So I was fortunate enough to get recruited out of that call center by a company called Rackspace where I was introduced to something called OpenStack, which led to a full immersion into the world of open source and the rest of history. So it's been a hobby, and now it's my job for a while to manage open source engagement for several open source projects, with the job lens having communities that were in an infancy stage that I was responsible for growing. Being who I am, DEI was the top priority. So I was thrilled to have what I saw as an opportunity to build these communities from the ground up with focus on recruiting and maintaining engagement with a truly diverse audience. DEI is also super important to my co-presenter, who's, yeah, I figured, napping right now. So this is Sir Harold B. Goggington III, a.k.a. Goggy. He is Pink Penguin's chief cuddle officer, and he is my prescribed psychiatric support animal. So we're fortunate enough to have been at companies that are very, very accommodating. And also have a lot of dog lovers on the board, so I get to take him everywhere with me. But the reason why I do that is to put a face to invisible disabilities, and just to let you know that you never know what somebody else is going through, so always approach them with empathy and compassion. Getting into why we're here. So the reason why DEI is one of my main focuses, one of my main focuses, is because I don't see very many black women in the circles that I travel. So I figured, why not use my position to do something about that? Seriously, over, I guess, five years now? I don't know if 2020 counts, but dozens of conferences, I've met maybe 10 other black engineers who identify as female. Now I know there's more out there, but the important question that needs to be answered is why don't they want to be seen? So as maintainers for open source projects, we all want more diversity, which is why we're here. I think I've said that before, but where do you start with trying to find these individuals and how do you get their attention? Well, before we get to the solution, I have to throw some numbers at you to make this look more professional. Just stick with me here, I'll get to the good part in a second. So according to the Bureau of Labor Statistics, about 23% of professional computer programmers identify as female, about 16% of respondents said that they belong to an ethnic or national minority group, and about 34% self-identified as black, Asian, or Latin American. When compared to overall US demographics, those numbers aren't great, but they're not all that awful either, especially when compared to statistics from 10, 20, or 30 years ago. Since virtually every programmer will touch some type of open source software over the course of their career, you'd expect contributor demographics to look about the same. Well, unfortunately, they don't. So back in 2017, GitHub surveyed about 5,500 open source users and developers from around the world on a range of topics, including demographic information. Out of the 5,500 randomly selected individuals who completed the survey, a full 95% of respondents identified as male, 3% identified as female, and only 1% identified as non-binary. What makes these numbers interesting is that most respondents also stated that most of their open source contributions are done on the job. So if we believe the Bureau of Labor Statistics that 23% of devs and programmers are female and almost 35% are people of color, why don't the demographics for open source contributions match? Seriously, what the heck's going on? Now, I don't believe that this is happening as a result of there being a deliberate effort by the otherwise all welcoming open source community to exclude people of color, LGBTQIA plus, or they're differently abled. But clearly something is making members of marginalized groups hesitate to get involved. Excuse me, okay, catch my breath. Could it be that uncomfortable work environments are souring people on open source before they even get involved? Because would be contributors expect the same level of hostility, judgment, unfriendliness, et cetera in open source peers as they get during their work hours? I mean, think about it. If you were on a job where your contributions and talents were minimized at best, or at worst you were outright ignored and exploited by your cishet male peers. Would you be all that excited about joining in on what may assume is a similar environment during your personal time for free? Further, how do we as open source software maintainers show that no, not only do we not tolerate that type of behavior in our communities, but there are also massive career benefits to being an open source contributor slash maintainer. So I don't know if you can tell, but I just kind of wedged this in based off a conversation that I had very recently with a colleague. So I don't have any more content around that topic or around that point just yet, but hopefully we can save some time for the end to discuss it a little bit further. Now heading back over to our survey data, that lovely survey included a section where respondents could specify some of the reasons they decide not to contribute to open source projects. Some of those reasons include incomplete or missing documentation, dismissive responses, or no response at all for maintainers, conflict with other community members, unexplained rejection of contributions or ideas, and unwelcoming language or content. Now while we don't have full control when a personality conflict may occur, like if someone takes it personally, that a maintainer prefers DC over Marvel. I don't know why I thought that was so funny what I wrote it, but it's still in there. What we do have control over is whether or not responding to pull requests is prioritized or if time doesn't permit, whether we do things like setting up auto responses and creating clear outlines that set proper expectations from the beginning. We can control whether we just close a quote unquote bad PR or whether we seize that opportunity to mentor a budding developer. What else do we have control over? Updating the dag gum docs. Bad documentation was the highest reported deterrent across the board for getting involved in open source. From personal experience, I can tell you that especially when I was a baby society man, nothing was more frustrating or discouraging. Then attempting to read through documentation for software that read like somebody had cut out each word, put the words in a jar, shaken it around, dumped it out on the floor, and then transcribed whatever happened. Keep in mind that there's an increasing population as this admins, developers and engineers who are basically self-taught. They're clearly extremely intelligent and driven, but they may not understand or even care about topics like curing completeness or the mathematical equation used to calculate exactly how many fragments an OSD is broken into before it's being spread across hosts unless and until it's explained to them. Clear, concise documentation is arguably the best and most important component for attracting new contributors. So please, update your documentation. And more specifically, don't make assumptions about what your audience knows. If you think you're over-explaining, you're probably not. It's always better to over-explain than under, trust me. Oh, these masks are so hard to breathe through, but they look great, don't they? Better yet, have someone look over the docks with fresh eyes to ask the questions that someone new to the project would ask. You'd be surprised how many complexities you don't give a second thought to because you do them all the time and therefore you leave them out of your instructions. While you're ramping those docks, simplify it when you can. One of my favorite quotes from Albert Einstein is, if you can't explain something to a six-year-old, you don't understand it yourself. Now, that might come across kind of insulting and harsh, but as I mentioned, some of us are self-taught. Some aren't native English speakers and folks are getting into open source younger and younger. We don't want to discourage or frighten them off with quick starts that we'd like quantum calculus, which leads to the next bullet point, creative lossering. So for example, open-stat glance is a project that has excellent examples of this in action. Open-stat in general has a massive, active, passionate and very diverse contributor list, with skill levels varying from thinking Yamal is a type of yogurt to, I wrote 90% of the code for ironic bare metal because I was bored. And the person who did that is actually here. I think she gave a keynote yesterday because their documentation is top tier. As a member of the no CS degree gang, it was immensely helpful to have a glossary of terms directly related to the projects I was working on available because sometimes Google will lead you down a rabbit hole completely unrelated to whatever it is that you're actually looking for, which can be a time sink and super boring. Having those resources readily available is a great way to foster more community engagement. And while you're implementing those changes, don't forget that they're friendly able. Something as simple as adding a WordPress plugin and make all the difference in the world for someone who's vision impaired or has a learning disability. The example gift is a demo of an accessibility plugin that I'm particularly fond of, created by a company called user way, which has several accessibility options to adjust contrast, font size, animation and even includes an option to switch page fonts for easier readability for those with dyslexia. As a person inflicted with dyslexia, I didn't realize how much of a strain it was to follow the words on the screen until I didn't have to do it anymore, which was incredible, especially as an adult. Even small things like adding a WordPress plugin can make a huge difference in that first impression you make on potential contributors. So please always keep that in mind. Am I going too fast? But relatively small adjustments to how you choose to document and present your code is the most critical factor in increasing engagement with your project, not just from members of marginalized groups, but in general, which is what we all want, right? Yeah, so while you're at it, be mindful of exclusionary or otherwise icky language, like using the mostly deprecated master slash slave to describe controller and nodes, for example. Now I'm not here to kink shame anyone, but the terms are uncomfortable for a number of reasons, for a number of different groups. Another example would be using gendered language, like you guys when addressing a group of people. Try to err on the side of caution and use neutral alternatives whenever possible. When you start getting all of this wonderful, diverse talent contributing to your projects, it's important to acknowledge them, not just to celebrate that specific person, but also to encourage and inspire others who for whatever reason may mistakenly believe that they're unable to do the thing because of who they are or where they're from. Just don't be weird about it. For example, if you only acknowledge women in your community on International Women's Day and ignore them for the rest of the year, that's weird. If you only acknowledge black contributors in February and ignore them the rest of the year, that's weird. Seriously, it's very uncomfortable for the person or persons involved, whether they say it out loud or not, and it just looks really bad to people that are looking from the inside or from the outside, I'm sorry. Instead, making effort to celebrate people of color, BEMS, LGBTQIA+, and other marginalized groups just because they did something great, not during a specific time. The greatest thing about open source is that we're all open to helping one another. If you're not sure how to keep from crossing that line, lean on the community for advice. Those of us working towards true equity will be glad to help. Next point, be responsive. Now this might seem like an obvious statement, but when those PRs and issues start pouring in, respond to them. Completely ignored PRs honestly isn't something that I've personally seen very often, but unfortunately it does occasionally still occur. Slower, no response to questions, pull requests and feature requests is the best way to make an individual write your project off forever. Now I know this is easier said than done, especially if you're managing one or several open source projects in addition to work, family, social life, what is that and other obligations. But responding with a quick few words or even adding tags or some other interaction as acknowledgement can make all the difference in a baby dev's perception of our community. So even if you don't merge immediately, try to respond within like 24 or 48 hours or at least set proper expectations. If it's not possible to replicate yourself enough times to be able to respond to every message in 30 minutes or the piece is free, add a section to the read me or to your community guidelines page that gives a general timeline of when you'll be able to reach out to that new contributor. Also, complete the read me. It takes me to no end to see nothing but project name and some warm ipsum or something equally as unrelated to the GitHub page or even worse for the read me to have five year old info that conflicts with the original documentation just enough to ruin your demo setup. So please update your Amy. So you know the saying, there's no such thing as a stupid question, right? Well, I like to expand that too. There's no such thing as a bad PR, which to me means that every proposed feature or fix deserves at least some consideration. You don't know for sure whether or not the individual reaching out is off track or if they just have issues expressing their ideas until and unless you follow up. So do that to give an in real life example. One of my former colleagues named John Murphy had say the whole thing and his incredible response to a massive ambitious pull requests to one of replicated my former company's open source projects that he spent a month carefully reviewing TLDR. Not only did the project get several cool new features after he was done, but we will replicated got a new employee who started I think in February and he's been doing great so far. And that is all because of John Murphy's willingness to dive into a single PR and take time to mentor who ended up being a massive resource for replicated. So thank you so much to John Murphy for being a shining example of what open source community is like and congratulations Alexander for getting a new job. So in addition to boosting engagement numbers it's been proven that there's diverse workplaces in tech with all those different skill sets, perceptives, perspectives and experiences generate more money and innovation faster than racially homogenous and all are mostly male companies. Open staff got to go back to them again with their massive and diverse contributor list grew from five projects to dozens of community contributed projects frequently used as basis for a whole bunch of your favorite cloud platforms and it's a perfect example of what can be achieved when we work together. So that's all I got for now and I'm going to add a breath from this mask. Thank you all so much for joining the session and I guess this is where we're gonna have our Q&A time. If you have any questions feel free to throw them out if you wanna pet the dog he is free for petting and we'll absolutely love you just don't let him fall you home and as I mentioned there are stickers but thank you all so much for joining and I'm gonna put up my appendix which I think has my contact control in there. No it doesn't but you can find me. So all right, questions? That is interesting about how long is it taking you to respond to those future requests and PRs? Is it maybe a time thing? Right after, do you have time? Sweet, okay. So yeah, let's dig into that one. In our organization we have a very muscle approval so I just wanna give you back who goes. Thank you. This is one of the few fields where being crazy works for you so. Okay. Yes, I'm sorry. Large, basic community, who they are and where they are and they'll sell out naturally by default is basically. So do you have any like some practice that is in front of the front? Basically in a not appropriate way to say it's like beating them out because they're being basically out there who are quite even late who have been attending some events and seeing people using all their stuff over two years will never actually help them. So that was actually, I feel like that's the kind of challenge they're all fighting in the community is but in the active community is that they stick up on themselves. Right. Which is one important thing. Right. Like if they're not pulling up to this other day then it's more like how do you actually go? That is a great question. I don't have a clear answer for that. That's something that I've been, I've been kind of like thinking on and working towards for years. The only kind of work around that I have so far is to for those who want to be visible make them hyper visible. There are issues with, okay. So there are some people who just don't want to be seen. They want to be active in the project but they don't want the attention. So meet them halfway. One of the ways that I worked around that my old job was working with the engineering team. If they wanted to put together presentations and things like that but they weren't comfortable getting on stage themselves I would do it. So with the project that I'm managing now I'm trying to do that same thing. Codd containers, huge widely used project. Not a lot of engineers are willing to go and like speak in front of hundreds of people about it. So I just volunteered to do it myself and I also try to keep other people in my pocket who are willing to do the same. I'm not sure if that is a good answer to your question but that's kind of what I got so far. Quiet you. Yes, sorry. So one of the ways that we worked around that was to at the time of the feature is being created. Also engage documentation teams so that or I guess that's only a good answer if you have a documentation team. If you're a single person or you're working with a very small team and you're trying to put out any feature and you dub at your docs. The quick and dirty is just to add something about that feature in your release notes and how to use it and then update the docs as quickly as possible afterwards. Quiet you. Any other questions? Anybody want a dog? Thank you. Any other questions? We are all on social distancing. We, from the old school, we are facing a need into a barrier with the project we want to introduce to them. They basically, when the people that has succeeded in our training programs may already make their first contribution, no matter if they are following the the conclusion guidelines and following the community standard of the project, they are facing a problem and they try to do it by the first act. How and also how to take the situation and how people should... I can't hear the last part of your question because it's stupid. Okay, the situation and how people will get into their first contribution if they are able to do what they want to do. So I've seen a couple of ways that people or that different projects have addressed that. There is RDO. They have their mentorship maintainer list where it's just direct GitHub userdames where you can reach out to someone who's been involved with RDO for a while to walk you through the PR process or the feature request process. That one I am very much a fan of. Some other ways is sandbox. That might be a bit of a heavier lift to set up a full on Git sandbox to walk someone through the PR process but that works very well for OpenStack, the main project. And quick start guides. Just write it out as granularly and as detailed as possible. How to submit a PR. That's helpful. Good reference point. Those are the ones I can think about to top of my head for now, but I don't know, maybe we can talk about it a little bit afterwards. Yeah. Yeah, absolutely. I've been trying to think of different ways to incentivize adding oneself to the maintainer's list but it is very difficult to get people to volunteer. I don't know, let's chat about it. Any, yes? I feel like this is what you want to make your community a bit more accessible in the local community. One thing that I have seen what challenging is that since where I come from was not an inclusive community and when we started a community, trying to make it inclusive, trying to make it diverse, very welcoming. Even though all of that is there, it's quite challenging to implement that and make the members of the community use it, use those exclusivity. It's taking a bit of effort to let them open up to get started, although we totally encourage beginners, we want, we are welcoming. That's the first step I've seen our students is still quite challenging. They're still hesitant to get started. So what tips would you say that we as a student community could do? We don't even know that we're implementing all inclusive best practices in diverse. How do we still kind of create this regular environment that people just join and get started for us? I know it's quite an effort to make a first step as a person, you're not an exclusive community and then you're coming in such a place. So how do we get that cycle started in a student community? So first off, I'm gonna say thank you for coming. I'm been a student in a very long time. So take this advice from an old person with a grain of salt. What, that is a question that I've also been trying to solve for a while. I believe that one of the best ways to get people involved and keep them involved in open source is to show the long term career benefits to working with open source because when you say that word, either a person is going to think Microsoft or they're gonna think, why am I doing work for free? Well, that free work pays off like leaps and bounds in the future. I am standing here as proof of that. I would say that highlighting others who started out in open source and where their careers have taken off to would be a great way to encourage and keep community involvement from a student perspective because remembering 180 years ago when I was a student, one of my main interests was being able to pay for that student thing once I got out. So, sure. I am actually, am I over? I think I'm over. So any further questions? Yes. I have a question. I hope I'm not out of line by asking this but I recently was invited to a group who meets every third Friday called Lunch with Friends and it was with many African American community leaders, entrepreneurs and so forth. And we even had a special guest that you're gonna leave by the name of Celia who I believe is from the mayor. Does this program that you're representing reach out to smaller groups like this to help each other in a sense? Because what we were discussing at this last, the first meeting I went to which was last Friday was the housing situation in Austin and elsewhere around the United States, homelessness and things of that nature. And I would love to try to get some feedback on that and see if we can maybe have those entities work together. I love that idea. So I am not a native Austin, I actually live in New York but my company OpenStack slash Open Interfoundation is I think based here. That is something that we are absolutely passionate about and I think that yes, we can get involved and we can support you. Mostly we deal with nerd stuff. If you're okay with like dealing with some geeky stuff every once in a while, then yes, absolutely we would love to support you. I'm from Brooklyn myself, so we can make it work. All right, thank you. Sure. They're not, they're just, I mean we, I'm not even that excited that it was an opportunity to join the team and the person that was with me. Who do you think that, and what I'm wondering about, what's the, what's the main number of different groups where some of you, if that shows in contact with, how much is someone supposed to be there for that opportunity? Yeah, it's going to be all of those communities that are going to be included in person. They're not going to be exposed to it. Well, okay. I don't have a quick answer to that. So I guess going back to personal experience, I have been at 5,000 member companies where there was just no way to for the company to really monitor what was happening and to really assure that everyone had equal opportunity that like you just, you just can't. And I've also been at smaller companies where there was a direct effort to make sure that opportunities were not afforded to certain people. I don't know. I'm just going to say I don't know instead of saying something stupid. But it's, I don't know. Maybe any suggestions from the audience? That's a tough question. I guess just do the best you can. I mean, at least don't actively work against it. As a company scales, that is very difficult to address but I don't have a clear cut answer for it. I'm sorry. Well, that was disappointing. Any other questions, questions, comments? Anybody want to put the dog? Yeah. No, it's not a bad note. It's just. Of course, sure. Yeah, the following up on the question of like do corporations have responsibilities then maybe it isn't that you're supposed to have the answer or I'm supposed to have the answer but that we're supposed to have the answer. So I mean, I've worked with my fellow colleagues on these issues inside our company for sure and other people I know do too but maybe we're not, maybe some more of this job but this is a great world here talking about this together and there's just more chances to do that. So thank you for bringing that. You know, the, yeah, that opens the conversation. So maybe there's a light at the end of the tunnel. I guess maybe that's the answer. Start the conversations because that's where things actually happen. You get different perspectives, you get different suggestions, things that you're not thinking about because you're not impacted by them. Talk to people. So I guess that's a start. And that, you actually answered your own question. Uh-oh. Well, that's why I'm here. Any other questions? All right, well, this has been awesome. Thank you all so much for joining. I really appreciate your time. Thank you so much. And I hope the panel is going to play open source summit and if you see Dago and I out and you need a puppy break that is why we're here. Feel free to cuddle. Thank you all.