Build your Contributor Pipeline - Carolyn Van Slyck, Microsoft & Josh Berkus, Red Hat: KNAI-5483 - events@cncf.io

Participant: wordly [W] English (US)

So before we get into attracting contributor. So let's think in general about where contributors come from new contributed 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 and 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 want to be a part of it.
They want to participate other times.
They have something specific that they want to add or to fix.
That's broken for them and their use case. Usually, those are what we call power users, who are using it in production who are using in some very Advanced way.
However, in the cncf, we actually get a lot of a second kind of user, which is what we call corporate users, which means that rather than the individual using your project, their company uses the project and depends on.
And for that reason, the company is 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
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 want to learn the programming language, maybe they want to learn the field of technology that your project is in.
in. Maybe they're about to graduate school and they want to 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 thinking about where they coming from, what are their motivations?
What's the cool people available to us? The most obvious? And 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
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 right your hand, everyone needs a tech writer.
You probably need someone to help make your website. Look, look right. Create concept art diagrams.
Yeah, 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 are coming to you and submitting, a polar Quest. You need to go to them and think about what you can, what they can
To your project and make sure that they know that that's welcome, so people can write documentation. They can give you user stories and feedback on your road map and Designs.
Write 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 and experience maintainer who has already been a maintainer another project and
You need somebody who's, you know, superhero essentially to help you out, but that's not even worth looking for these people. Those type of people already too busy and have their own projects.
So once we've identified, what kind of contributors who want to attracted 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
In practice people and I find it's useful.
Divide these up into enablers and blockers, enables are things that help you attract additional contributors. That is things that if there 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, the things that are high investment, low investment example, would be, hey, creating contributing that MD file or having a contributor Forum, right?
Is 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 paid
dividends in being really strong contribution enables 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
Bowl your code contributors to self start without needing to have one-on-one mentoring.
in order to contribute stuff and thus 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, you know, here actually, I've got can see right here. This is my kubernetes contributor Summit
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 did,
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
Stringent contributor. License Agreements are we do license agreement settle as opposed to a dco not having any visibility into the project in a variety of ways governance rights and repositories tests
Open searching. Your test framework is hard.
I understand, but on the other hand, somebody contributes, they get a bunch of presubmit test failures and they asked, hey, how do I troubleshoot this test failure?
Can 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 is open as possible about communication.
So, if you're having a strategy meeting or a developer meeting, or a stand-up or whatever, that should be in the open, external contributors, you know, 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 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 in 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 for you.
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 and that starts with anything that you can have, that's both written in
- so what if your documentation or a mailing list or a blog or a discussion forum of some sort?
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 going to reach more people, more easily, after that, start looking at and open developer meeting.
Because it's something you would hold any way. And then move on to more. Very contributor targeted. Things like office hours or end-user forms. Right? 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 want to make it clear that that's not everything you should be doing and you definitely should be trying to do all this at once. Consider your project size, how many people you have to support any recruiting efforts and then pick one try it,
See how it goes and 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 know, 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.
In your recordings, get old, you're always going to 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 and make another recruiting Drive
Anjali, but it is not a destination.
You're never going to be done with this.
So let's consider how you. Let people know that you want new contributors the obvious places.
The contributing guide, but there's actually a lot of other breadcrumbs, you should be putting out there, so the people know that you're actively looking for more contributors.
The first place, most people are going to see, your project is actually a readme. So that's where you're going to want to say, hey, we want to come join us.
Another place that I've seen people do is they have a dedicated page on their projects 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 hack-a-thon 'z things like that.
Hector Tobar Fest will link to all issues and GitHub and go look for ones that are good for sushi. Look for ones that are help wanted.
You can actually put up on your contributing guide linked 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, any time you're there, pitching your project, let people know that you want help.
So I mentioned your read me.
Apple from my project, Porter's read me here and like we're out of a Chablis, like we need help. Come contribute work with us and we link people to the new contributing guide.
So that's focused just on helping people get started with the project for the first time.
And then we also call out to our existing contributors, again, recognitions 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 going to welcome, especially if you're open to none, code contributions and let people oh 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 when you're contributing guide itself, it's kind of doing double duty here, right often times, you're talking about build task, how to do certain things, what are your bills groups?
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 Contraband contributing or every time you submit a pull request, it'll probably link to it at the top. So you want to 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 click. There are like common accepted default labels like, if you make a new video, 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
He 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 going to 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 and help with Doc's. You're looking for someone who has specialized networking knowledge,
That often times even though they're new to your project, they're not new to The Domain and so they can tackle more difficult problem issues than you would have expected.
Good.
First issues is a subset of help wanted, and the ideas were 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 get Hub.
This is what you should change.
Go here.
1 2 3 4. What should you be doing?
Where is the test?
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. They can copy, you know, 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 it a high level as 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 test, too.
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 going to close it because new contributors who are coming to my project, have a perspective that I will never be able to have again in 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 at and honestly your new user documentation.
So it's kind of cool to new contributor to be like I'm in the best possible position to do this task.
So make sure they always know that we want them to open PRS or just ping you. Anyway they're willing to give you this feedback about what it was like to be a new contributor or New Year's or user on your project.
Make sure you get that feedback.
Two one.
Now, let's take a look at you attracted. Someone to your project.
They're interested in contributing, you're going to 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 cloudnativecon.
So any videos or content blogs doesn't matter, something that's going to get them up and running with your own project before. They try to make a first contribution is going to save you a lot of Heartache.
Re teaching people things and it's going to help them feel more productive from day. One and in general you're going to want to focus on your little experience for that first poll request and and how you want to handle them and how you want to handle this.
Some people like to take this and encode it, like in my project we actually say all reviewers.
You're going to look out for new contributors are going to 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 new contributors?
Are now there's different ways. You can actually do this sort of intake process.
And like we said before, I want to say, first of all, the first way that you should work on is the sort of text guide version of this. It's going to be the most generally accessible.
it's accessible Around the Clock, it's much easier to maintain and keep current with your projects contribution processes and code and documentation.
Once you've taken care of the text version, then you might want to consider having some online videos because some people are video Learners. They learn better from videos, but if you want to going to do that, having a lot of short videos is better
This perspective.
Nothing else, right?
Because things will change about your project and it's a lot easier to re-record a single 3-minute video than to have to re-record that 90-minute full tutorial.
serve 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 it attracted is that is when you're having say
Check Summit.
It's actually the most resource-intensive to reach the fewest people.
This is a suggestion from Charles in from linkerd E 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,
Start to finish.
What is it look like to change my project to get set up, test the code Etc. 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, the 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 up front.
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 DC.
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 will manually and through the command line tool or an API, whatever makes sense for your project and then do an actual change like Porter's a command line tool.
So we always have someone make a sample command that like Prince 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 because again, closing the loop here, remember that they have the best perspective.
On improving these docks talk to them after they've done this and you're probably going to find something new that you need to change.
Probably every couple contributors.
Now one of the things we talk about in terms of computers is you don't want to 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
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, you know, add that in consider some things that you maybe don't have yet.
Has a way of recruiting people like for example, maybe you don't have a docks 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 on paper because 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 decided in advance.
Now, we have examples of this.
we just finished the contributor letter template, which is part of our project templates, but it advances 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
That's right.
Other roles might include reviewer, docks 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 using screenshots of what various documents are that would be really helpful to have in your project.
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.
you know, when it covers things like the readme in this contributor letter which 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, we'll go into details on how do you find
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 Health on advancing the project attracting to Jupiter's, this is what Sig contributor strategy is here for.
We have two different meetings for the synchronous option.
We have two different meetings, one every first and third Thursday, of the month at 10:30 in Pacific Time, alternating meetings are maintainer Circle meetings. The other meetings are General and
You are welcome and encouraged to bring your project in your particular problem and put it on the agenda for that meeting. At is completely invited for specifically attracting contributors.
We have the contributor growth working group meeting every second and fourth Tuesday at 2 p.m. specific.
And that I is for more contributor growth problems.
Anyway, 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.
Take any questions you have during the session.