 Hello, and welcome to Build Your Contributor Pipeline with CNCF SIG Contributor Strategy and Josh and Carolyn. We're here to explain something that a lot of projects have been asking about lately, which is how do we get contributors? How do we get new contributors for our projects? My name is Josh Berkus. I'm a community architect at Red Hat in the open source practice office where I work on the many cloud native projects that we support at Red Hat, plus a few that are technically supported by Red Hat, but I help in my role with CNCF anyway. I'm Carolyn Vanslike. I'm an engineer at Microsoft and I work on the CNCF Sandbox Project Porter. So before we really get into advice and things like that, I wanna just stop and make sure that we're being intentional and understand what we're hoping to get out of this. When you say you wanna build your contributor pipeline, what are you trying to achieve? Do you wanna create a community around your project? Are you trying to find that next special maintainer? Or are you looking for maybe adding more people who have diverse skills and perspectives that your project is lacking? Depending on what you wanna do, this could be a pretty big time investment. So you wanna make sure that it's not just you trying to figure this out and welcome new contributors to your project. You want all the other maintainers on the project bought in and understanding what your game plan is. So before we get into attracting contributors, so let's think in general about where contributors come from, new contributors for open source projects. Why do they join to begin with? Usually though, we've got three sort of different groups that come to projects with the goal of contribution or participation. The first group that people are the most familiar with is individual users. These are people who use your project or they use your project to build other things. And sometimes they're just really excited about the project. They wanna be a part of it, they wanna participate. Other times they have something specific that they want to add or to fix that's broken for them in their use case. Usually these are what we call power users who are using it in production, who are using it in some very advanced way. However, in the CNCF, we actually get a lot of a second kind of user so what we call corporate users, which means that rather than the individual using your project, their company uses the project and depends on it. And for that reason, the company has assigned them as an employee to work on the project. Either again, to add some functionality or to fix something that specifically matters to the company or if you're extremely lucky to maintain help maintain the project in order that the company can depend on it long term. Now a third group that people often forget to think about which is bad because this group is unique in a lot of ways is what we call learners. Maybe they wanna learn the programming language, maybe they wanna learn the field of technology that your project is in. Maybe they're about to graduate school and they wanna beef up the resume. The nice thing about this is these people will contribute to areas of your project that are fairly non-commercial because they don't care. And so you should cultivate them if you can. So let's think a bit about what type of user are you focusing? You know, we think you're not where are they coming from? What are their motivations? So what's the pool of people available to us? The most obvious, maybe the first place you should look for if you haven't already is look at your existing user base. These are people who are opening bug reports with you. They're already engaging maybe in Slack. They're pretty much maybe the best well to go to to find new people. But if you're trying to look even further, you can consider recruiting people who don't actually know your project at all. The learners especially fall into this group. Another thing you can look at is, are you lacking contributors with specific skills? Like raise your hand. Everyone needs a tech writer. You probably need someone to help make your website look right, create concept art diagrams. You know, someone to help with that roadmap for project management. And what a lot of these have in common is that they aren't code contributors and they're not coming to you and submitting a polar quest. You need to go to them and think about what you can, what they can bring to your project and make sure that they know that it's welcome. So people can write documentation. They can give you user stories and feedback on your roadmap and designs, right? A guest blog post explaining how they're using your project. A lot of these things are gold, but people won't give it to you unless you say it's welcome. Now some people may be looking for that unicorn, an experienced maintainer who has already been a maintainer on another project and you need somebody who's a superhero essentially to help you out. But that's not even worth looking for. Those type of people already too busy and have their own projects. So once we've identified what kind of contributors we want to attract and where we're going to be contributing them from, we actually need to construct a framework called the contributor framework in order to look at how we're going to attract these people. And I find it's useful to divide these up into enablers and blockers. Enablers are things that help you attract additional contributors. That is things that if they are present in your project if they're good will cause more people to show up and help people who have already shown up to stay. And you can further divide these down into things that are what we call low investment and things that are high investment. Low investment example would be hey, creating contributing that MD file or having a contributor forum, right? These don't take a lot of your time and energy to create and yet they really do help people become and stay a part of your project. And then there's a second group of things that are much more high investment but often also pay dividends in being really strong contribution enablers. Like for example, if you create a very detailed contribution tutorial going through every step of the way of, oh, hey, you want to add a feature to my project then that will enable your code contributors to self start without needing to have one on one mentoring in order to contribute stuff. And thus for you to get more of them and for them to be more productive once they do join. But creating that kind of a tutorial is hard and it will be a huge time commitment from one of your existing people. One of the other things that's often overlooked as a very simple enabler which is low commitment is recognition. So when somebody does contribute make sure they get noticed in some way. Digital badges, swag, here actually I've got, you can see right here this is my Kubernetes contributor summit Shanghai t-shirt. So special contributor swag, public thank yous and public contributor listings. People actually care a lot about being recognized even if they don't say that they do. Now, there is a bunch of things that can prevent even your best intention contributors from contributing to your project. And these are things that you want to try to eradicate from your project so they don't ruin your other efforts. And this is things like really stringent contributor license agreements or the license agreements at all as opposed to a DCO. Not having any visibility into the project in a variety of ways. Governance, rights on repositories, tests. Open sourcing your test framework is hard, I understand. But on the other hand, somebody contributes they get a bunch of pre-submit test failures and they ask, hey, how do I troubleshoot this test failure? And you tell them, well, you can't. Then that contributor is blocked until one of your existing people gets around to troubleshooting it for them. And that's a bad experience for them and it's a bad experience for your people. Now, one of the biggest things about enabling contributors is communication and being as open as possible about communication. So if you're having a strategy meeting or a developer meeting or a standup or whatever that should be in the open. External contributors, even if you have it's a company-sponsored project external contributors should be able to join that. Public contributors should be able to join that meeting if they want to. Now, a lot of the times they won't want to. But they need to know that it's there. And those meetings should discuss things like your strategy and your roadmap and your plans. Things are ideally also published in text because you want to make contributors, new contributors part of planning for the project which both makes them feel included and make sure that they don't spend a lot of time on things that are out of scope-free. Also, please, please, please don't make attending things like daily meetings mandatory for contribution because that limits your contributor pool to people who are being sponsored by companies to work on the project full-time. Now, when we've sort of been over this we've looked at the various ways you can communicate and there are some things that reach more people for less effort than others. And that starts with anything that you can have that's both written in asynchronous. So whether it's your documentation or a mailing list or a blog or a discussion forum of some sort if it doesn't require synchronizing time zones and if it's written, so people can refer to it in the future that's gonna reach more people more easily. After that, start looking at an open developer meeting because it's something you would hold anyway and then move on to more very contributor-targeted things like office hours or end-user forums that are just specifically contributors. One of the mistakes we see people making is they create this community meeting that is specifically just a community meeting and then it doesn't work because they really don't have any content for it and that should really be handled by things like your blog. So we're going to list everything that you can do to bring in and keep contributors in your pipeline but I wanna make it clear that that's not everything you should be doing and you definitely should be trying to do all this at once. Considering your project size how many people you have to support any recruiting efforts and then pick one, try it, see how it goes and focus on tasks that make you scale. Anything that involves one-on-one mentoring, live things, synchronous things, all that, save for later, start with all that written communication for example. And then over time, you can add more because what's important to understand here is that recruiting and growing your pipeline is not a one and done thing. If you add three contributors over time they're going to eventually leave, your project will change, you need updated documentation, your recordings get old, you're always gonna be doing more things. So commit to a small amount of work and find a way to be able to do it every couple months and refresh and make another recruiting drive essentially but it is not a destination you're never gonna be done with this. So let's consider how you let people know that you want new contributors. The obvious place is the contributing guide but there's actually a lot of other breadcrumbs you should be putting out there so that people know that you're actively looking for more contributors. The first place most people are gonna see your project is actually your read me. So that's where you're gonna wanna say, hey, we want you, come join us. Another place that I've seen people do it is they have a dedicated page on their project's website that talks about wanting contributors and kind of walking people through it. Another way to signal that you're looking for people and this one's kind of fun because you get a lot of people for free is labeling your issues as good first issue and help wanted because other projects, hackathons, things like that, Hacktoberfest will link to all the issues in GitHub and go look for ones that are good first issue, look for ones that are help wanted and you can actually put up on your contributing guide, link to these and give people ideas for where they can get started. Another thing is if you're given a talk, if you're doing a webinar, anytime they're pitching your project, let people know that you want help. So I mentioned you read me, this is an example from my project porters, read me here and we're unabashedly like we need help, come contribute, work with us and we link people to the new contributing guide. So let's focus just on helping people get started with the project for the first time. And then we also call out to our existing contributors. Again, recognition is important, let people know that you're going to recognize their contributions. I also have a page on my website that says, hey, we want you to work with us. For a lot of people coming to this, they may be unfamiliar with what your project is. So lay that out. Like point them to other places on your site, point them to tutorials, let them know where they should get started, let people know what are the types of contributions you're gonna welcome, especially if you're open to non-code contributions and let people know, is there a path to becoming a maintainer if you do this? Basically put up front all the recognition and rewards for working on your project into these documents. Now in your contributing guide itself, it's kind of doing double duty here, right? Oftentimes you're talking about build tasks, how to do certain things, what are your build scripts? But at the very top, what we like to do is let people know again that you're looking for contributors. People will find your contributing guide because someone will link to it and say this is the best way to get into contributing or every time you submit a poll request, it'll probably link to it at the top. So you wanna just always make sure that welcome mat is there and let them know the ways that they can contribute and then as always, it's welcome. So let's talk about labeling real quick. There are like common accepted default labels. Like if you make a new repo, you probably have a help wanted, you probably have a good first issue label, but there's so much more to making it workable. And your goal should be, if someone picked up this issue on the weekend, could they complete it without pinging people on Slack, getting lost, asking for help? Is there enough context in the issue that they can actually just accomplish it? Help wanted is kind of a special label. It does double duty essentially. One, it's great for people who are newer to the project and kind of calls out issues that are gonna have enough information for them to do things. But on the other side, they're also really good for saying, this requires a skill set or a particular knowledge that we're lacking in the project. Maybe you're looking for someone who's a tech writer to help with docs. You're looking for someone who has specialized networking knowledge, something like that. Oftentimes, even though they're new to your project, they're not new to the domain. And so they can tackle more difficult issues than you would have expected. Good first issues is a subset of help wanted. And the idea is we're really removing all the barriers to entry. We're making sure that you completely spell out, this is how to do the task. Give examples to the code, like link directly to GitHub. This is what you should change. Go here, one, two, three, four, what should you be doing? Where is the test? If it doesn't have a test and you need to kind of make it test out of thin air, you either need to link them to something that they can copy and kind of model off of, or maybe it's actually not such a good first issue yet. Here's an example of a good first issue and what's here doesn't matter. But what you can kind of see at a high level is I have links to the code that needs to be changed. And I've step-by-step instructions saying how the change should be made, maybe any background or motivation so they understand why they're making this change and then where they can add their tests to. Now, I've had a good first issue open on my repository probably since day one from three years ago and I'm never ever gonna close it because new contributors who are coming to my project have a perspective that I will never be able to have again on my project, which is being new to it, not knowing the right way to do everything, not even knowing the domain. And this is the type of perspective that you critically need in order to console me vetting your project and making sure that you haven't left gaps in both your new contributor documentation and honestly your new user documentation. So it's kind of cool as a new contributor to be like, I'm in the best possible position to do this task. So make sure that they always know that we want them to open PRs or just ping you any way they're willing to give you this feedback about what it was like to be a new contributor or a new user on your project. Make sure you get that feedback. Two, one. Now let's take a look at you've attracted someone to your project, they're interested in contributing, you're gonna need to teach them what it takes to contribute and what's involved for various things. There's the obvious, which is setting up your environment, right? And we'll get into that, but less obvious is telling them what your project is and how to use it. Thinking back again to those learners, they may have never used your project before, they may not be familiar with cloud native. So any videos or content, blogs, doesn't matter, something that's gonna get them up and running with your own project before they try to make a first contribution is gonna save you a lot of heartache reteaching people things and it's gonna help them feel more productive from day one. And in general, you're gonna wanna focus on the experience for that first pull request and how you wanna handle them and how you wanna handle this. Some people like to take this and encode it. Like in my project, we actually say all reviewers, you're gonna look out for new contributors, you're gonna do X, Y and Z, but it could just be something informal that you talk about with your other maintainers and go, what do we want this experience to look like for a new contributor? Now, there's different ways that you can actually do this sort of intake process. And like we said before, I wanna say, first of all, the first way that you should work on is the sort of text guide version of this. It's gonna be the most generally accessible, it's accessible around the clock, it's much easier to maintain and keep current with your project's contribution processes and code and documentation. Once you've taken care of the text version, then you might wanna consider having some online videos because some people are video learners. They learn better from videos, but if you wanna gonna do that, having a lot of short videos is better from a maintenance perspective, nothing else, right? Because things will change about your project and it's a lot easier to re-record a single three minute video than to have to re-record that 90 minute full tutorial. Sort of the last thing you should do, the thing you should do only when you feel like you are sort of fully staffed up and you've done all the other things is the sort of in-person workshop. Because as attractive as that is when you're having, say, a project summit, it's actually the most resource intensive to reach the fewest people. This was a suggestion from Charles from LakerD. And I took this and ran with it for Porter and I found that this was actually one of the most valuable things I could have done for my own pipeline, which is I wrote a contributing tutorial that says from start to finish, what does it look like to change my project get set up, test the code, et cetera. And the very first thing on here, again, is I want to see contributors try the project and understand what it is. Like they've definitely run it before they submit their first PR. I've got a number of first PRs before where it's like, you can tell they never actually ran it, they figured out the code to change. And I feel like you're not doing anyone a favor there. We're here to learn, we're here to become better at these things. So make it clear upfront, like try it, learn it, give us feedback on it, and then walk them through. How do you set up your environment to build the code? How do you check it out? If you have any specific build tool recommendations, most projects have signing, for example, like a DCO, do not assume that someone knows how to do this or this could turn into a blocker for you, even if it's something that could be easily done. Document how to do a DCO, how to sign your commit. And then also, oops, how to fix it when you forgot to sign something. Otherwise, things I like to look at is how to build the code, try it out with manually and through the command line tool or an API, whatever makes sense for your project. And then do an actual change, like Porter is a command line tool, so we always have someone make a sample command that like prints their name, for example, show them how to test their changes in general, and then celebrate, have them tell you when they finish the tutorial. Cause again, closing the loop here, remember that they have the best perspective on improving these docs. Talk to them after they've done this and you're probably gonna find something new that you need to change, probably every couple contributors. Now, one of the things we talk about in terms of contributors is you don't wanna just get new contributors, but you want to advance them, right? Because one of your goals eventually is to have more maintainers for the project, because that's the only way that the project is really going to grow. And moving from new contributor to maintainer goes through a series of steps that we like to call the contributor ladder. And for this contributor ladder to work, it's something you actually want to publish. The different sort of project roles and what the qualifications for each are and what the responsibilities of each are. So, add that in, consider some things that you maybe don't have yet as a way of recruiting people, like for example, maybe you don't have a docs maintainer, but you would like to have one. Well, putting that role in your contributor ladder is an opportunity for somebody to say, hey, I could do that. Also, it's important to write this down in paper because it's a good way for you to agree among all of your existing contributors how people earn trust and how they advance, because if you're having that argument in with the contributor at the time that they want to advance, it's a bad experience for everybody. Decide it in advance. Now, we have examples of this. We just finished the contributor ladder template, which is a part of our project templates, but in advance is exactly very simple, right? We have contributor and how you become a contributor, maintainer, how you become a maintainer, admin, how you become an admin, depending on the roles, right? Other roles might include reviewer, doc's maintainer, organization member for how people get credentials on GitHub. And we have some examples in the template of how you define those things. So we've given you a lot of examples and you've seen screenshots of what various documents are that would be really helpful to have in your project. Now, as part of our SIG, we've created templates where you can just clone this entire repository or cherry pick files that you think would be useful. And it covers things like the read me in this contributor ladder, which you may not be familiar with. We also have created guides. Now, basically all the information that we've given you here in this talk, you can find in text format in some of these long form guides on our website. For example, the contributor playbook will go into details on how do you find and recruit people into your project and attract them. Whereas the contributor growth framework is real stories from maintainers of successful projects and what has worked for them. And reflections on maybe what hasn't worked so well too. So if you have other questions or if you are excited about this or you want interactive help on advancing the project, attracting contributors, this is what SIG contributor strategy is here for. We have two different meetings for the asynchronous option. We have two different meetings, one every first and third Thursday of the month at 10 30 AM Pacific time. Alternating meetings are maintainer circle meetings. The other meetings are general and you are welcome and encouraged to bring your project and your particular problem and put it on the agenda for that meeting. That is completely invited. For specifically attracting contributors, we have the contributor growth working group meeting every second and fourth Tuesday at 2 PM Pacific. And that is for more contributor growth problems. Any way you're welcome. And around the clock, you can join us on CNCF Slack in the SIG contributor strategy channel. Now we will move on here to any questions you have during the session.