 Let me introduce my co-presenter Catherine who is head of community at Linkerd, among other things. She also contributes a whole lot to the CNCF, including through tag contributor strategies, contributor growth working group, which is how I know her. Yeah. This is Josh who is architect at Red Hat, and he is the co-chair of the tag contributor strategy. Cool. So the goal of this presentation and one of the goals of tag contributor strategies to help you figure out how to grow and promote the contributors in your project into greater responsibilities and greater roles. We have done presentations before and how to attract new contributors to your project, which is also an important thing, but that's not something that we're going to be covering today. Instead, we'll be covering how to get them to do more as reviewers or doc writers or maintainers or even project leaders. The talk assumes that you are yourself, a maintainer or owner or other form of project leader, or that is a role that you aspire to. Yeah. So we're going to start off with introducing the tag contributor strategy. Then we're going to go over some docs and guides that are available to you as maintainers. Then we're going to talk about recognition and promotion, governance, and then the project maturity level. Yeah, it's good for you. Oh, sorry. What is the tag contributor strategy? So it's a group from the CNCF with the goal to help projects like yourself be successful. We do that by creating guides, docs, and tools that you can use and apply for your projects. Why would we do that? I mean, there are so many other projects who have been through what your experience is today, like facing your challenges or whatever you're trying to achieve. So there's really no need to reinvent the wheel. So you can basically learn from projects that have done that and avoid their mistakes and apply what worked really well for them. So that's basically the gist of the tag. Yeah. In terms of sort of tangible products that we have for you, which we're going to be discussing today, is the tag actually produces primarily two things. One is templates that you can copy for your project and use for project paperwork, and guidance documentation, advisories, guides to how do I get new contributors, guides to how do I set up governance and that sort of thing, advice basically for running your project. What happened there? Oh, you can see it there. Oh, okay. Again, terrific. Okay. Right. The project templates can actually be found in CNCF such project template. We created a separate repository in case you want to just clone it or merge it directly into your project community repository in order to use some of these templates for paperwork that the CNCF requires, and that even if the CNCF didn't require, it would be a good idea for you to have them. For the advice, the best way to find it is to actually go through contribute.cncf.io, the website and this immediately branches off. The great work of Carolyn is immediately branches off into two sections, and what you want is the section that says, I am or want to be a maintainer, and there you can actually find a whole bunch of guides and advice on doing various things and running your project including stuff like setting up governance or how to monitor health of your project, which Dawn is going to be talking about later today, and what we're talking about today, which is how to foster contributor growth. You'll find the contributor growth strategy framework there, and I'm going to be talking mostly about that. That's a very high-level overview of things that you have to keep in mind to grow your contributor base, and a lot of these things sound very common sense, but it's really important to spell them out because it's often easy to forget, so everything I'm going to cover there, you can find there. Of course, it all starts with contributors. Where do they come from and how do you keep them? Initial motivation varies as much as people themselves. Of course, some need a feature, someone to learn something, some just want to be part of an open source project. So it's difficult for you to control that trigger, but what you can control is really to keep them motivated once they started contributing, and you can do that by trying to create a really awesome and welcoming experience. So today we're going to cover three buckets, honest and clear communication, lowering contribution barriers, and the human factor, and we're going to dig a little deeper in the human factor. So it's really important to be really clear about the level of effort that is required. What are contributors getting into? How much time will it take? If you don't spell that out, they're going to have probably false expectations that it's going to lead to frustration, or they may hesitate to contribute in the first place. So it's really important to be very clear about that. Also, when you and your docs and your issues, it's very important to be very descriptive. The more descriptive, actually, the better. But that takes time. So it's very easy, especially if you're very busy, it's very easy to say, oh, we have so many other things that we have to focus on. So I cannot focus on this right now. But if you don't tell contributors exactly what they need, how can they know what you're looking for? So you're going to get PRs that are not reflecting what you were looking for. It's going to lead to a lot of back and forth. It's going to lead to frustration. And yeah, so definitely not a good contributor experience and not good for you. So although it may feel like it's a lot of time, it will save you time down the line. The other things are the different paths that you can take. And Josh will talk about the contributor ladder in a little bit. But just on a high level, it's basically the same thing as a career, right? Like when you are starting your career or even at your company now, you're asking contributors to dedicate their time. So they need to know where you're going. Are your goals aligning with their goals, right? And yeah, so they want to make sure that it's a good fit for them as well. The other thing is if contributing is a pain, motivation will go really, really fast. And doing it right should really be the easiest path. So contributing should be easy and intuitive or at least as easy and as intuitive as possible. It cannot be always super easy, right? But make a real effort to make it really smooth. And then the documentation that goes into the previous point as well, right? Like clear communication. Clearly communicate what they should do, what they should expect when they're submitting a PR. That will smoothen the whole process as well. And then it's important to minimize the steps, right? Like be really clear about the development requirements. Point them to the right tooling. They shouldn't be looking around, right? That should all be in one place. And leverage tools to minimize, to reduce the steps as much as possible. There are a lot of tools that allow you to automate things. If it can be automated, your contributors shouldn't be doing this. But we're often so focused on the technology that we forgot about the human element. And that overlooking that can actually really discourage people. And we're gonna talk about the contributor letter again because it's a really important thing. But there are a lot of small things that are really important and have a huge impact. First of all, and that's what I'm saying. It sounds really common sense, but when you're really busy, you may forget, right? Like thank every single person contributor publicly, especially the new ones, but everyone, deliberately create a welcoming community. Reach out, start a conversation. What are you, how are you using our project? What are you working on? Like whatever it is, try to make that one-on-one connection, especially that's especially important for smaller project. Once you scale, it will become a little bit more difficult. But there are tools that can help you. So there are like community CRMs. I don't know if any, I know that a lot of people are not very familiar with them, but they are really helpful because they help you keep track of your contributors. You can even automate things like some tools allow you to automate. Thank you tweets or thank you messages through GitHub. They aggregate a lot of data. I mean, even if you're a small project, like if you have several contributors, it's really difficult to kind of keep track of food at what? Or at least for me, I wouldn't be able to remember. So that actually, those tools actually help you be a more, like create a better community because you remember the discussions that you had and so on. And then of course, like developing recognition programs, awards, event opportunities can be super motivating. If you have an ambassador program, if you create what's it called like private events where they can go, that's very rewarding and very much appreciated. For younger contributors, mentoring of course is huge. So that's very motivating. And swag, it sounds silly, right? But like becoming part of the project, becoming part of the tribe, really people start feeling like identifying with the project. So kind of being able to kind of show that project that makes them proud does make a difference. And here I wanted just to showcase like the recognition, one of the recognition programs that we have at Lincredi. So each month, the community nominates a hero and maintainers are going to select based on merit and we have three different categories. Code, content. So if someone wrote a really good blog or spoke at a conference and help, right? Like helping on Slack, we value a lot because that takes a lot of time. So if someone can help. And actually those two are like the code and the content and help are the ones that we kind of really, really want to encourage and I'll come back to that in a bit. And yeah, as you can see, we're trying to make it fun, right? Like some in engaging, everyone who becomes a hero, you can find them on the website. We write a little blog post about them. And yeah, we have a little social media around it and people really enjoy that. But there is so much more to a thriving community than code, right? And of course you need awesome features, but who cares about the features if no one is able or no one uses your project because no one is talking about it, right? Or if it's impossible to implement because the docs are incomplete or because it's difficult to get help because the maintainers are so busy they cannot really be there and explain it to people. So there are so many things that are part of the community and that you need. And it's a lot to ask from the maintainers to them all themselves. But interestingly, maintainers themselves are kind of perpetuating a little bit that burden because of their own bias towards code. And so because open source projects are focused on technologists who are good at coding, that's what they value most, right? And then, but as I said before, there's so much more to it, right? Then a bunch of developers. You need so many different skills. You need people who have the skills you don't have or that can do things that you don't have time to do. So basically you need a bunch of people with a bunch of different skills. And so to motivate these people to help you to be part of the community you have to be really inclusive, right? You have to see how you can recognize them for their non-code contributions as well. So that's a little call to action, kind of like thinking about that, reflecting and then seeing like, okay, who are the people that make this community, like besides the code, like who make this community much better? And then thinking about how to recognize them as well. So now one of the other things that really motivates people to contribute more is status within the project. And sometimes status within the project translates to status outside of the project, particularly on the job. So we kind of term to the common practice of sort of moving contributors up as their contributions grow in quantity and expertise and quality, right? That they get more responsibility and more authority in the project to go with that additional contribution and call that a contributor ladder. Now all projects have a contributor ladder whether or not it's documented. But documented contributor ladders make it explicit what contributors need to do to reach the next level. And by making it explicit, it really helps motivate contributors to put in just a little bit more effort. Consider the difference between you need to review more PRs before we make you a reviewer and you need to review five more PRs before we make you a reviewer. The first is, I don't know if I have time for that. The second is just five. I can do that. And there'll be a whole set of sort of other responsibilities that go with it, but by letting people know and giving them measurable requirements to reach the next stage of responsibility and the next stage, the next sort of title in the organization, that also lets them know that they're going to be quote unquote rewarded with greater authority and responsibility. Although really the greater authority and responsibility is what you wanted them to take on in the first place, right? And the other way that this really helps you is if you are a project leader, one of the problems you run into all the time is just effectively losing track of people, right? Is it gonna be a real tendency to promote the people who show up at meetings the most often because those are the people who are top of mind, even though you might have somebody who works in a time zone on the other side of the world who's been doing really great work on documentation and really actually ought to get that promotion. And by making sure that you don't miss people, you have an opportunity to promote more people. And for that reason, you really wanna have a contributor letter that's explicitly documented. So to help you with this, we have a template for contributor ladder in that project templates directory. And you need to actually look at the source for this because it is full of markdown comments for stuff to do. Now, this is actually a quite sort of elaborate contributor ladder with, I think six different potential levels. You are not going to use all of those. Most projects have somewhere three to four different levels on their rungs on their ladder. And so the idea is for you to cut out the stuff that doesn't apply to you. And also obviously you can see there is lots of stuff to be replaced with the things that actually make sense in your project. And then sort of each stage in the contributor ladder in terms of documenting has a list of what somebody has to do to reach that level in the ladder, what responsibility they will have, what privileges they will get and what the process is for approving them. And that makes it so much easier and friendlier for someone to advance because they know what they need to do. So now we've talked about all the things to do in encouraging. I'm going to talk a little bit about sort of maintaining state, particularly so the role of governance and saying, okay, well, this is about promoting contributors. Why are we talking about governance? Well, I'll give you that one word which is membership. If we have that, yes. Which is people care about belonging to something. They want to be equal participants in your project. And formal written governance is one of the ways that we prove to them that they are equal participants. If they're an independent contributor, they care that they're going to be treated fairly, that their contributions will be equally recognized, even though they don't work for a big important company and that they'll be respected. And that they will have an ownership stake in the project. And if they are employees of a company who is supporting your project, they want to know that when there are roadmap changes and there are other things that might break people's projects, they will have a voice in those changes. And formal written governance is a way that you prove to contributors that this is going to happen so that they feel safe in making that big time commitment on your project. Now, this sounds like a lot of stuff. Keep in mind that this grows, the idea is for this to grow with your project, right? You don't need to have all of this when the project is very small and it's new and it's say at the sandbox level. And you don't even want to have a whole ton of paperwork at that level because then that paperwork can be daunting to people. So you start out with something like say a three level contributor ladder and a code of conduct in a fairly simple how to contribute. And then as you mature in your levels, you maybe add some extra roles, your contribution guide gets longer with stuff about testing and all kinds of other things. And then eventually by the time you're a graduated project, et cetera, you should have sort of all of the documentation and all of the practices, even things like individual role handbooks for different jobs in the community for people to step into. So to sort of wrap it up here, you need to keep your contributors motivated and encouraged to contribute additionally and level themselves up through communication, lowered barriers and recognition. Consider creating a recognition program or more than one and remember to encourage and recognize your non-code contributors. Formal governance and contributor rules lower the risk and the difficulty of contributing and leveling up and they should evolve with the project. Yeah, and please visit the website and check out all the resources. And if there is something that you need and you don't find it, join us and we can help you create it. Like, so really like we can help you connect you to people who can help you, who can answer all the questions you can put it all in a doc and it's not gonna be only for you. We're gonna contribute it to it so anyone can benefit. So that's why I think this is really great. Like that's actually how I worked on the framework with some other people. It's like just talking to all these people. I would not have been able to do that. Just like saying, I want to do this for LinkedIn but if I'm doing it for the tag. So if you have an idea, we're always looking for new projects to work on. And with that, we're ready for questions. So questions. Eddie? Through the microphone. Yeah. So one of the, we actually had a conversation this morning about as a maintainer, obviously the most valuable thing to me is growing new contributors. And I personally would dedicate tons of time as much as the contributor needed for that. So one-on-one mentoring, pair programming. The scary thing to me is investing that time in someone and they make their contribution and then disappear and don't come back. So how do we identify contributors that are worth investing in that won't just achievement unlocked, got a contribution and disappear? Okay. So the question is, the question is if you're a maintainer and you're going to invest a lot of time in mentoring a contributor, how do you identify somebody who's likely to stick around versus somebody who might leave? You want to take that? Should I take it? Well, I, you can, my feeling would be it's just the same thing. I mean, like sometimes you feel you feel that someone is more committed but it's basically the same thing as in the job market, you know, you hire someone, you invest in them and they may leave too. So I think like it's really just like you can, sometimes you can tell and you have a feeling if someone is really committed and then you have to make a bet, but it can go wrong. So it's like, I don't think there's a secret but I think our gut feeling I would say is very often right, but it's can be really disappointing if it's not, but you may have. But the other thing I would say is this is why we actually spent, you know, 15 minutes talking about, about keeping your contributors motivated to contribute more, right? Because people don't just leave randomly, they leave for a reason. And honestly, if your project is a fun place to be and they feel rewarded and encouraged and respected for contributing, they're more likely to stick around. So you can't determine for the individual but you can try to create an environment where they are less likely to leave and more likely to stick around and do more. But you have to take a bet, right? Yeah, we have to take a bet and some people will leave, right? Because particularly just around when you're mentoring then they will change employers and the new employer will not be somebody who's contributing to the project. And, you know, you can't control that. People have careers. So more questions from here? I was actually wondering you keep saying the word project doesn't singular. And I'm actually part of a company where we have an organization where we have multiple projects. We have actually over a hundred of them. And that's a hundred different maintainers we're working with and many, many contributors. How would you work with a community that large to ensure that their contributor journey at an individual level is still on the right path when you've got hundreds of projects to look after? You're the community CRM person here. So wait, so the first question is, let me repeat the question, right? Because we gotta do that. Which is the question is, if you are in charge of an organization and you have dozens or hundreds of projects, how do you keep track and work with the contributors of all of these projects to keep them moving along in their contributor growth path? Well, I would think it's just like a lot of time. Like you have maintainers for each project. So like it's like each project is individually and they have to go through the same thing. And like we just had like the sand, but like the little different stages where you're at. So I think it's just like those maintainers have to see themselves. Like of course you want it as an overall, but I think like it's per project, you have to do the same things, create the community that people really wanna be part of. And yeah, maybe those CRM tools can, community CRM tools can help you automate some of the stuff, you know, that, yeah, so you don't have that much of a burden, but I would say it's the same thing. For the maintainers themselves, it's the same job. Like it doesn't matter if they're part of the same organization where they have 100, right? And yeah, and part of that is, I mean, at least in my, so I'm kind of, I think I'm kind of in the same situation. I guess one of my questions for you there would be, are we talking about a hundred different projects that are still kind of part of the same community or like separate projects? So a little of both, a little of both, yeah. Because I deal with about six dozen separate projects, some of which are kind of part of the same meta community, but a lot of which are not. And in my case, a lot of it has come down to tooling. And so that is one of my big responsibilities is to try to actually add and deploy tooling and then give the maintainers of the individual projects access to that tooling so that they can use that information. The, I would say in a lot of cases when you think about recognition programs and mentoring and motivation and stuff, you wanna think at the level at which people identify as part of a community. So even if things are separate projects, you actually look at them as a contributor. If they think of themselves as part of the same community, you wanna look at them as a single contributor base. So sometimes you create groups. Like in my case, I would say an example, the ones I go in there is for the ML data pipeline stuff, you know, across Strimsy and Kafka and TensorFlow, etc. Is that group tends to regard itself as kind of a continuous community. And so you look at how do I promote people regardless of which actual project they're contributing to. And then talk to those maintainers as a group also. Okay. Oh yeah, the, okay. So the question was how does one join the tag and find the meeting? So for finding the meetings, the CNCF has a CNCF community calendar that has Google and I think Apple calendar as well that you can sign up for and then you can see all of the meetings, which is really the best way to do it because sometimes we change our meeting times. We have separate meetings of the tag in general, maintainer circle, which is another thing that we do. And in fact, we're doing later today. And the governance and contributor growth working groups because like the contributor growth working group right now is 1pm Pacific on Thursdays, but that has changed and will probably change again. So subscribe to the calendar. For other stuff, we have tag contributor strategy channel on the CNCF Slack. So if you wanna get a hold of us somewhat asynchronously, that is the place to do it. Or you could jump on the project templates repository or the tag contributor strategy repository and file an issue. And those are the ways to actually interact with us and join and get involved. And if you're actually looking to get involved and to contribute and maybe be part of one of these efforts, I would say, jump on one of those and say, hey, I'm really interested in contributor growth. How do I get involved in actually doing that? And any of those three mechanisms will work for that. So the question is, which projects have adopted and adapted those templates? And the answer is, it's mostly new projects because the templates have only been published for about, I don't know, five, six months. Yeah, very recent, yeah. So are you using any of them in LinkedIn? No, because we did the ones before as well, yeah. Because you did the ones beforehand, right, yeah. So it's mostly new projects. So several new projects in Sandbox and some projects looking to go to incubating. So for example, Coopvert is using the maintainer council governance template with modifications. And that's actually an interesting way to see modifications on things. And we have a few who are applying to Sandbox who are actually using them because they wanted to have some kind of governance in place before they applied. The, who's at a higher level who's adopted stuff? I have to look, I know that there's another incubating project that has copied the templates, but I don't remember which ones. Follow up with me later. We're asked later on Slack and I'll get you an actual set of links. Okay, do we have any other questions? Any questions online? Okay, well, thanks very much folks. Thanks. Thank you.