 Hello, and thank you for coming. We're so glad you've come to our talk today. Keep your project healthy and grow your contributors. I am Kendall Nelson. I have been working in the open-stack community for about five years now in a variety of roles. Everything from the technical committee vice chair to the release management team. I've spent a lot of time working on developing our onboarding programs and tooling. So I've spent a lot of time developing the upstream institute program that we have and our contributor guide. I'm also involved in the women of open-stack, which has evolved into the diversity and inclusion working group. And other than open-stack, I have been involved in the Kubernetes community for a little over a year now in SIG Cloud provider, specifically provider open-stack, and also SIG contributor experience. Aside from working upstream in the world of open source, I love to travel, which obviously is not happening a whole lot right now. I love photography, Harry Potter, and Dr. Hoop. Hey, everyone. My name is Gwenevere. I have been a Kubernetes contributor since 2017. My main credentials are that I have led a Kubernetes release. And more to the topic of this talk, I'm one of the project owners for the Kubernetes new contributor workshop. As a second career techie, I'm super passionate about making open source contribution possible for people from all walks of life. So as a result, I will yell at you to document all the things as if you've never heard of Git before. Because you know what? Some really senior people in tech have never used it. I love sharing knowledge in the form of pair programming and other things. A lot of my favorite command line tricks are things I've picked up from pair programming or shoulder surfing with someone. I love food. I love the outdoors. Owls are my favorite animals. You can find me on GitHub by my profile picture, which does, in fact, have an owl in it. So without further ado, welcome to open source high tee. We are here to talk about community building. This talk won't be about getting all of your questions answered. It's really more about figuring out how to ask yourselves the right kinds of questions that are appropriate for your community. To go with the tea party theme, when you invite friends over for a hot beverage and tasty baked goods, you have lots of decisions to make, right? And especially right now, we are all just so eagerly planning that next physical get together. I'm sure you have lots of ideas. What will you serve? Who is invited? How many people are you inviting? So take all these thoughts and planning and ideas, because in the same way, you have key questions to answer about your open source community. So when you host high tee, you want everyone to have a good time and leave looking forward to the next party. You need to think about sending out invites and planning your features, I mean baked goods. You need to know how many people to plan for. So you'll maybe want to host a bigger party next time or get together more often. Who will help you with organizing and decorating? I mean documenting. Who pays for the event supplies? What kind of space is your party held at? Do you need to rent a building or get a permit for the park cookout shelter? In open source, all of these are good questions to ask yourself about your community. Let's start by thinking about project health. This is related to what you want your community to look like. So how do you set the table? How are you organized? What kind of governance structures does your community have or need or aspire to? What kind of guests do you want? Do you need writers? Do you need community organizers? Of course, we'll want technological contributors who write code. Do we need people who are specialists at DevOps or testing and so on and so forth? Furthermore, what are you serving? What are your community's offerings? What features, what technologies, what processes are you developing and making available to the public at large? What do you want to talk about in your community? Do you use email? Do you use a chat instance of some kind? Do you have regular meetings? Do they include video? Do you have agendas? Do you take notes? Is there a dress code? Do you expect everyone to have agreed to a certain code of conduct or have a license agreement signed? And also, this kind of brings us into the next thought, which is a little bit less comfortable. How do you discover and address conflict in your community? So that's a lot of things just to plan a party, right? How do you get some real numbers here? So first, one thing you need to realize is that, unfortunately, it's easier to measure things that don't work than things that do work. And there are, of course, two types of things to measure. The quantitative assessment of your community and the qualitative assessment of your community. How many lines of code do you see? And how effective are those lines of code for a basic example? If you do want to try to measure things that work well, there are some kinds of surveys that you can devise that might get you closer to good answers on the positive aspects of your community. So some things we can measure. I mentioned already. Contributor numbers. People who want to hear about your technologies and use them. People who want to build extensions to your project. People who want to use your project in a number of ways that you didn't anticipate. You can hear about these projects at conferences and workshops. You'll find out what they do and how many people are doing it. Then you can always measure lines of code, frequency of releases, new features and bugs, security issues and security fixes. How quick is the turnaround on all of these things? How quick is the turnaround on a filed bug or a code change request? These stats may tell you whether you have code review or capacity for incoming changes. You can also measure adoption numbers, depending on which code sharing tool you use, how many people have starred or forked or cloned your project on your code hosting platform. Are these users contributing back upstream or are they off using their own fork forever and ever? How many questions do you see on Stack Overflow? Are they getting answered in a way that helps people? Quickly, slowly, thoroughly, this gets back into the turnaround on code changes. So another thing that you can think about is how long do contributors stay active? Do people really only show up for just one thing and then leave again? Do they stay around and give back? Those are things you can look into as well. However, that kind of gets us into the next issue where the fact is that numbers are not the only way to measure health. A lot of these statistics are valuable, but large numbers of contributors don't necessarily reflect the quality of their output or the frequency of their contribution and so forth. So some of the things I mentioned in the previous slide kind of leak into the qualitative statistics around your project's health. So my first point on the slide is psychological safety and really that's almost the only point here. The other ones are just variations on that point. The basic question here is, how accessible is your project to contributors regardless of level of technical expertise? And again, technical expertise, that might mean a number of different things. Tech is a huge field. People might be experts in things that have nothing to do with your project. So they might learn quickly if you help them out. Some examples of project accessibility include, how quickly can a new contributor get started on fixing a bug? How quick is the turnaround on that issue or that bug? How do people resolve disagreements, both technical and personal? How many resources do you dedicate to documentation? Do you have paid writers? Do you need them? Hint, you do. Yes, you do. General and large accessibility. For example, do your events have sign language interpreters? How do screen readers respond to your documentation? Do your docs exist in other languages? Do you have events only in your country or elsewhere? That kind of gets to the next point. Can you support your maintainers? Your maintainers really need that psychological safety. That includes time off, time to work on a thing, rest, resources, understanding that your contributors have jobs that may or may not align with your project, understand that contributors might need to take time off for reasons that are completely unrelated to your project. So you can measure some of these things by watching and responding to contributor statistics. But for others, you might have to just resolve to talking to people directly, to having surveys on contributor satisfaction, and similar measures. So we've kind of gone over all of these questions that you have to ask yourself. And then we have this other difficult question on top of it, as we've just established by going through how impossible it is to measure things, because you can't compare apples to oranges and not everything is quantitative. Every community is very different. And not being able to compare them means it's hard to set a clear definition of what a healthy community looks like, because everybody has a different definition of health. So you can kind of start thinking about the answer to this question by establishing what is different. So you can't compare one community to another, because there are so many different things. You have different internal structures, the code layout, and the people that review and merge it are going to be different. There are different tools from community to community. In the OpenStack community, we use a tool called Girit for merging and reviewing code where the Kubernetes community uses GitHub. We have Zool in the OpenStack community for our CI, CD, and gating system, versus Prow in the Kubernetes community. Each community has different goals. You might be working more focused on container technologies versus virtual machines or something completely different. It might be databases or a number of things. There are open source projects on just about everything these days. There are different schedules for the project, different release cadences, event schedules, election schedules. All of that changes how a community functions and how healthy it is as well. You have different stages in their life cycles. Also, a newer project might be more focused on getting all of the new features and growing as rapidly as they can, where ones that have been around for a little bit longer might be more feature-complete and are focused on stability and maintenance. But just because it's not the new shiny thing doesn't mean that it's not healthy. Each difference makes a community unique, just as each tea party is different because of those who are hosting the people that are attending, the different kinds of tea you're drinking. And I, for one, have enjoyed just about every tea party I've ever been to. While there are a lot of different things about every community, there are definitely a lot of basics that each community should or hopefully has thought about. So you have a code of conduct. It might be implied or it might actually be something written out and backed by a foundation, the governing process. So some open source projects have committees and working groups. Others have special interest groups. And then along with your elections, there might be individual project leads or lists of maintainers. There's some sort of oversight somehow. And it's very different from project to project. Foundations also, more options. There are a lot of more options for foundations than just the CNCF. There's like the Eclipse Foundation, the OpenStack Foundation, the Mozilla Foundation. And it's totally okay if your project isn't actually hosted at a foundation either. Like it doesn't matter one way or the other. There might be a better fit for you to be on your own or at one of these foundations. But you should have a reason why you are in that situation and why that is the best for your community. There is probably also a mission statement. Some purpose for everybody working together and existing. You should think about like, what is the goal that you're trying to achieve and not just be going in a thousand directions at once. That's going to cause a lot of trouble down the road. So thinking about what is the goal? What are we trying to accomplish together? There's also a community culture probably. Hopefully you're going to be more welcoming, but sometimes smaller communities are a little bit more closed off because they're all focused on something that they're trying to accomplish together and they don't have time to ramp up new people. But if you're trying to grow your community, hopefully you're welcoming. And how does one join? That's another part of community culture. It is very different from community to community. Sometimes there are really good documentation on everything you need to know to get started and sometimes you just need to go in and introduce yourself and find a buddy to help you get up to speed. Every high tea or tea party is going to have something different to drink, probably some delectable baked good. Each one will probably have people, obviously, you don't wanna be drinking tea alone and there's going to be some sort of theme. So there are always basics across every tea party that you need to consider similar to how there are basics of every community. So now that we've spent all this time defining how impossible it is to actually quantitatively define if a community is healthy and what healthy looks like, let's talk about growth. Growth happens on all the levels from a single contributor to the foundation that it hopefully exists at but maybe not and sponsor companies also that are involved. A tea party or high tea is affected by everyone involved. You want people to RSVP, you need to know what time your caterers are going to show up if you have them. You need to know that you have a contract signed with the location that you're going to be having your tea party at. So on an individual level, you might first ask, what can I do? Well, consider that there are things both external that actively and directly address issues in your community and create solutions. And then there are other things that you may need to set like mindset that happen internally that affect others indirectly. So the world outside your head, you can directly affect other people in concrete ways. Things like mentoring is pretty self-explanatory. Hopefully your project has mentoring but sometimes you don't have the resources and that's okay too. There are other things that you can do directly to help others and that's recognizing signs of burnout and reach out to them. Make sure that they're doing okay, see if there's anything you can take off their plate without overloading your own because that's always a concern. Documentation is very important as Gwen has mentioned a couple of times now. So document everything you do and if it's not already documented or if there is documentation, make it better. It can always get better. Everything from the processes to actually contribute code to how to interact with the software in terms of usability, everything helps. Docs always need more love. Think others for their work. I know I love being thanked and I know I love thanking other people. I feel good when I give other people's compliments and they may end up giving you a compliment in return. You can always fill someone's tea cup and you can serve them at the table from a menu or have them select goodies from a buffet. There are lots of things you can do to directly make sure all of your attendees are having a good time. Mindset, as I mentioned a little bit, the things inside your head, things that you think about often do affect others whether it's direct or not as we talked about on the previous slide. So recognizing signs of burnout in yourself. Obviously it's not completely a responsibility. It does really help to have other people looking out for you. But knowing that you can say no to things when you're feeling overwhelmed. I often have a to-do list miles long and sometimes I need to just say no, I don't have time to add more things to that list or making sure people know that it's going to be a while before I can get to whatever work item. Open source requires an open mind, one that is flexible and kind. Being flexible and kind enables you to understand how you interact with other people better, be more empathetic. This, along with being proactive, saves you from more pain later. At a tea party, you can be polite and welcoming or you can be a bad host that maybe woke up on the wrong side of the bed. You can talk to your attendees and smile or you can go sip your tea in the corner and only talk to one person. That would not be a really gracious host. So what can a community do? Yeah, so we have talked about the individual's responsibilities, but some of this is really falls more into the realm of it takes a village. So as a community, there are some things that are possible to help each other out. So consider having a dedicated process for tracking and monitoring measurable project health statistics. Some communities do have entire governance structures formed around contributor experiences. So what I mean by that is establish really strong onboarding and peer mentoring processes. So make it easy for longstanding community members to mentor newer ones. What you don't wanna get into a situation of that all your top maintainers are so busy maintaining the code that they cannot share their knowledge, right? Because when you give them the time and the opportunity to share their knowledge, ultimately that creates more people with more knowledge and frees up everyone's time. In a company structure, right? A healthy team has a variety of experience levels and senior staff are encouraged and expected and rewarded for mentoring junior staff. So in an open source environment, the community has to make this possible. So one of the things to lowering the barriers for this happening, it's a two-pronged approach. Make it possible for your maintainers to mentor others and make it possible for newcomers to easily find mentors. Just as a side note here, make sure that disagreements are heard and resolved. So listen to complaints and definitely protect your contributors from bad behavior because it does happen and it can seriously harm your project. I can think of several examples right off the top of my head. But back to community organizing, ensure that you have great starting documentation as part of your community. Give a centralized place to get started contributing. Onboarding classes and workshops are another tool that you can use. Make them free to attend, make them accessible to as many folks as possible, that is maybe encourage scholarships for attendance or make this event available virtually or make this event available in multiple locations around the world. Develop peer mentoring and establish a culture of collaboration. In order to bring about a culture of collaboration, you must be approachable. That can mean any number of things. So really the most important thing is that you communicate really well what's expected. Firmly establish the way that your community communicates. Moderate the communication. Also look for blind spots, challenges that you might never experience but others might. This is again where I'm gonna ask you to sit a little bit with an uncomfortable thought. Do only outgoing, loud white people get to make the decisions? I'm not saying you must be warm, fuzzy and full of emoji to succeed as a community although I have my personal preferences. There are open source communities where you only ever get to know someone's community specific online handle. And that's fine. What's important is that you must let people know the proper etiquette. I'm reiterating some really specific points. Consider language barriers. Consider time zones. When you are creating meetings, it is really not fun to live in New Zealand and have to get up at 2 a.m. for all the meetings. Consider cultural barriers which might prevent people from speaking up or objecting in certain ways when there are disagreements. For yourself, consider that you might have internalized racism and or misogyny going on. This is a thing we can all work on. I do not exclude myself from this. Realize that people have different personalities. Some people are more shy. Some people are more outgoing. But the community can't do this alone. There are some community driven incentives that will attract contributors. You may hand out party favors to your tea party guests. So for example, I still cherish my Kubernetes contributor patch. If your tea party is important enough in town, people will be excited just to be on the guest list. Your open source tea party could also be a path for early career folks to make connections and write their first lines of code or learn a new skill. But again, that's not enough. For any of this to work, you need people and their time and their expertise. So this is where sponsor companies come in. They bring experts to the project. If you are a sponsor company, you need to make sure that your employees' open source work is prioritized appropriately. Do not ask your employees to do open source work on top of their internal real job duties. They're both real work. If you don't consider this, they'll get burned out. And your internal project suffers. Your open source tools that you rely on suffer and your employee may not be able to work for you for months or even leave altogether. Another thing you can consider is giving money to foundations which may have a better overview of where the project needs help. So with this, we kind of go into what can foundations do because growth happens at all the levels. So some of the things that they can do are like payment. If the foundation actually has enough sponsors, this might be something that they can do or they can employ people directly to work on the software project. They recognize the bigger picture and help be a non-bias third party when mediating between different companies, different things that they're trying to drive within the community. They can help provide marketing, promoting new releases that come out. They can focus on removing barriers being the home of that code of conduct that we mentioned earlier. And this is all very, very important because you need some non-bias third party to help balance everything and keep the community healthy. Hopefully we've given you a lot to think about today. I know it's not exactly a concrete list of actions like some of you may have wanted, but every community is different and health is a very, very hard thing to measure. You can make progress and throw an awesome high-T tea party experience if you keep those things in mind. No one person should be responsible for everything. Growth happens on all the levels. But in the end, we're all in this together. We succeed together and communities are beautiful but sometimes fragile. So we need to protect them and grow them as a community. Thank you.