 So welcome everybody to the tag contributor strategy maintainer session or tag contributor strategy, which means we're a group within the CNCF that helps projects be successful as cloud native open source projects and to do a number of things including recruit contributors, which is something that projects are really working on. And all of us are contributors to tag contributor strategy. And so you're going to meet everybody who's going to come up and speak including Catherine and Dawn and Sandy and Ali and Rian who are all going to talk about some of their areas of knowledge. And the idea is to lead you down sort of a little journey of all of the things that you do to attract and maintain contributors including accessibility and responsiveness and advancement and activities and roadmaps and and recognition. So with that, I want to get started with talking about accessibility with Sandeep. Hello friends. I'm very excited for my first ever speaking opportunity at CubeCon. A few seconds back, I intentionally spoke without voice and I wonder how many of you followed what I spoke. So in the same way, unless there is accessibility in class, deaf and hard of hearing people like me cannot try to follow the conversations. What accessibility helps work is creating a level playing field so that use of us can contribute actively. It helps to get your project a diverse set of contributors rather than having just a specific set of contributors. I remember showing up at my first deaf contributor strategy group meeting over Zoom. I did not know anyone. I just showed up and a few minutes into the meeting, Josh, he asked me if the captions are working fine. So that's one line, that's one line whether the captions are working fine or not. It really made me feel belong because I'm a person with hearing impairment and I rely entirely on captions and lip reading. So the sense of belonging that I felt, the sense of inclusion that I felt made me feel so much welcome. Accessibility doesn't need a rocket science. All it needs is a spark of empathy, a bit of awareness and willingness to include a diverse set of people. One of the most beautiful things that you could do about accessibility is to me and any other body. Throughout my career, it is the hearing people who have acted as an employer. Like my first job, like the time when I got my first job, the time when I first time went to a client's place, all my very first speaking opportunity at CubeCon. So in the last CubeCon at Chicago, in the keynote session, I happened to sit next to Catherine and I got talking and she introduced me to the deaf and hard of hearing working group that she just helped to find. And a few months later, she introduced me to the wonderful panelists. So you can imagine I did not know any of them a couple of months ago and today I'm collaborating with them and speaking here. So being an analyst is an incredibly powerful tool that you can use. And one point is that people with disabilities will take some more time for the initial ramp up. But once they ramp up, their hands go like an human eye. The second point I'd like to make is to make sure that your contributor guidelines talk is simple, clear language without any technical jargon so that newcomers don't feel overwhelmed. Your ability to put complex phrases into simple terms demonstrates your maturity as a software engineer. And lastly, being consistent is the key. Accessibility is not like you do it one time and forget about it. It has to be internalized, it has to be consistent. Now when you start contributing to open source, you wonder where to begin. And the same goes for accessibility as well. When you begin work. And so the staff and the heart of your working group has come up with a set of guidelines, best practices and recommendations that you can easily incorporate to make your meetings more inclusive. You can attend one of our meetings and you can ask us how we can help contribute to our projects. We have set up a kiosk in the pavilion booth. You are free to drop by and say hi to my members sitting here in the front row. And today evening we have, today evening we have a sign language crash course that is guaranteed to be fun. So please make sure you attend it. Summing up, I would say that when you embrace accessibility, you unlock opportunities to get truly diverse sort of contributors in your project, taking it to the next level. Thank you. Over to Ali. Thank you, Sandeep. So I talk about, I will talk about being responsive to your community. So what being responsive to your community means. So if you're running a business, for example, and if you're not replying to your customers, you'll lose those customers. So same happens for contributors and open source projects too. Nobody wants to be part of a community, which is not very interactive, interactive, or people cannot get answers or helps. So this seems like a simple thing, but it's really important to state the obvious. You're not very responsive if your PR time to merge is too long, or if you're not triaging your issues, PRs in time. If you're not responding your Slack messages, questions in time, or if you have these giant endless discussions for a feature request or for a bug report or whatever for making a discussion about it, making a decision about it. So CNCF DevStats can help with measuring some of these. It's a bit detailed topic, so I will not go into details here, but you'll find me around if you want to talk about CNCF DevStats and how to compare your projects with other ones. So what you need to fix in this situation, if you feel like your community is not really responsive, is you need to fix this. Someone else will handle it attitude and you also need to fix your decision making. And the good thing is this is rather a low investment fix. You don't need a complicated setup. You don't need complex tooling or stuff like that, but you need community awareness for this. So to raise this awareness, mention this problem in your community meetings, in your emails, or better yet be a good example yourself. So for being a good example, I have a few suggestions. Always acknowledge queries when someone asks your community something, even if you don't know the answer. So if you don't know the answer, you can always ping the right person. Do issue triaging or PR triaging session in your community regularly. I'm pretty sure some of you do this, but there are also some projects, some communities not doing it. Employ a lazy consensus for decision making. In case you don't know, this is basically saying we're going to go with this decision in two weeks, three weeks, whatever, unless there's a big objection. So we don't need to wait for approval from every single person. And also recognition, you need to recognize contributors. But there will be other panelists talking about contributor kudos and I leave it to them. Thank you. Next is. Okay, so Ali just talked about responsiveness. And one way to improve responsiveness is by recruiting more people into your project and moving them into leadership roles. A contributor ladder is a really good way to help people take on increased responsibilities within their project. And as they do that, they move up the contributor ladder to reduce the load on the already overworked maintainers and other contributors. Defining the roles and responsibilities for contributors, reviewers and maintainers can really help with recruiting new people into these roles. It can help to think about this as a ladder where contributors climb up to become reviewers. Those reviewers become maintainers. And what's important is to document this ladder and make sure that people understand how they can climb the ladder and gain more responsibilities within the project. And all of this helps set expectations for the roles and encourages people to think about how they might take on increasing roles of responsibility within the project. And as you get more people moving into maintainer roles, you can reduce the load of the existing maintainers. Now, the good news is that we have a template at the bottom of the slide that you can use to avoid building this from scratch. Now, the template probably has more roles than most projects need, so it can usually be simplified and customized for what you need for your project. At a minimum, you should probably have a community participant, a contributor, and a maintainer roles. But I would also strongly encourage you to add a reviewer role, since it can be a good step on the ladder to help people prepare to become a maintainer. And I would also like to see more projects have an option for people to move into emeritus roles, which recognizes the hard work that someone put into a project while, and then giving others a point of contact if they have questions about what came before, while also allowing that person to step away from the day to day roles within the project. And if you're a maintainer, I really encourage you to think of stepping into an emeritus role as a way of successfully handing off your duties to the next generation of maintainers for your project. One thing I think people sometimes forget is that you can have maintainers or other leadership positions for people who are responsible for things like community management, documentation, program management, product management, and lots of other roles. These people become responsible for making decisions and approving PRs in areas where those types of activities happen in the repository. And people working on these tasks make decisions about decisions also that might not necessarily happen in a repository. And I think too many maintainers underestimate the amount of time they spend on these activities, and recruiting people into these roles can really help reduce the workload of other maintainers and project leaders. Within TAG Contributor Strategy, we also have a non-code initiative, so the link at the bottom of this slide, within our Contributor Growth Working Group, where we talk about ways to get more people involved in the CNCF and other open source projects. And with that, I will turn it over to Josh to talk more about how to actually recruit those contributors. So if your project is responsive and you have a bunch of contributor roles that you want to recruit people into and you're ready for those additional contributors, one of the things that you will want to do is to have some contributor recruitment activities. But that can be a little scary because once you start investing in contributor recruitment activities, you're like, oh, there's mentoring and we can do some stuff at KubeCon, and we have this other stuff, we do a hack fest and we do a participant hacktober fest and that sort of thing. And it becomes a real state of option paralysis. We end up doing nothing because there's too many things to do. And the answer there is to restrict your scope of activities to the things that you can sustain. And one of the ways to do this is that we talk about high investment versus low investment contributor recruitment activities. So low investment contributor recruitment activities are ones where you can put in a little bit of effort to help attract more contributors. And often the effort is one time, right? Like something like a basic contributor guide, right? Is you do that and then you only update it like once a year. You don't have to continuously be active on it. Whereas, you know, and the idea of these low investment activities is you should do several of them because they are low investment. And eventually as your project matures, you're going to do most of the possible low investment activities. High investment activities require a lot of maintainer time. They require a bunch of maintainer time. They require maintainer time every time you do them. And as a result, you're only going to do like maybe one or two of these. You know, maybe two of them a year or something like that, three of them a year. And that's okay. That's actually what you should plan on. Now you start with the low investment activities because a lot of the high investment activities depend on the low investment activities to be successful. So let's talk about a few of these. So the first low investment one that you should be doing because the CNCF requires it is to have a basic contributor guide, right? Now you'll improve this contributor guide throughout the lifetime of your project, but you can get some basics in there right away. And then after that, a lot of your other low investment activities consist of other documentation, right? Which is also like a reviewing guide and a guide to communication channels in your project and the contributor ladder and a bunch of other things that give convenient access to potential contributors to things that they can do. Now the, and the other big part of low investment is obviously maintaining your comms, is to have a few comms channels and make sure that those are staffed as Ali talked about. Now, once you've done some of the low investment activities, you want to look at maybe doing one or two high investment activities. Now you're here at KubeCon, obviously one of those is there's a whole bunch of opportunities for contributor recruitment right here at KubeCon. Now those are obviously high investment because your project members need to make it to KubeCon in order for those to happen. But that includes things like maintainer sessions, kiosk, contribfest, other activities. Now you can also do those sorts of live event recruitment at other events, right? Like at a KCD, at a meetup, you can participate in online hackathons. Again, probably not more than one a year. These are a lot of work if you want them to be successful. The other high investment things you want to look at is ongoing stuff, right? Kubernetes, because it's a really big project, we actually have a fully interactive contributor tutorial, right? And if you have the kind of resource to produce that, it's a very valuable thing to have. But it is a lot of effort both to build and to maintain. You have video programs and you can do other things that are high investment and help you contribute recruitment, but again, don't get carried away. So to sum up, you know, basically pick three, four things that you can do that are low investment. One or two things you can do that are high investment and do this based on these activities are largely equivalent. Do this based on what works for your project, right? What somebody already wants to do, what's convenient for their location or their schedule or their preexisting skills, right? You know, minimize your effort, maximize your impact. And with that, we're going to talk about one sort of medium investment activity that you can do to attract contributors. Thank you, Josh. So Josh, talk to us about how to get contributors to your project. And mostly the first point of contact would be your GitHub repo. So Albert Einstein said, what's obvious to you might not be obvious to others. And it's also not even obvious that he said that. So when people go to your GitHub repo, the first thing that they see is your readme. And then they might actually look at your charter. Go to your own GitHub repo, look at it as if you've never seen it before. Does the readme actually tell the person what's the product about, when are we meeting, who's the leadership, basic things? Are you actually communicating that? Make sure that your readme does what it's supposed to do. Your charter, your project is five, six years old, and then you had a charter when you started off. Are you actually still following that charter? Is it still up to date? So make sure those things are, new people look at that and say, oh, yes, I can get involved. And then they get there in the charter and the project's not matching up. So make sure about things like that. GitHub repository, that is your filing system of your project. If your filing is a mess, nobody can find the code, nobody know how to contribute all the documentation that Josh referred to. Make sure it's filed in a way that is intuitive to new people. Look at it again, like you've never been there before. Say, oh, this does not make sense and just reorganizes low investment. Then very important thing, when you go to your repo, you manage things through GitHub issues and PRs. If you just have a list of issues, what's important? Nobody knows. If they're not part of the in-group, they can't tell what's important. Get a GitHub project board, they are very useful. Lots of automation available, automate as much as possible. It should not be hard work. It should actually reduce the work. Put it in columns that's suitable for your project. If it's in Backlock and it can't be fixed, block it, put it somewhere. Bonus step on the project board labels. There's a lot of CNCF projects that does not have any labels on their project. Use labels like Help Wanted, Good First Issue. You can put code, you can put information about the feature. Use the labels extensively and then there's features inside the project board where you can filter by views for specific types of labels, specific types of work that also makes it easier for people to find things where they can contribute. Make it easy for people to be in your project and see where they're going. We talked a lot about many aspects on how to build your contributor base. The last area we're going to touch upon sounds fairly simple, but it's incredibly powerful and that is contributor kudos. Everyone appreciates a thank you. We know that. A thank you goes a really long way and that's no different in open source. Your contributors are donating their time to improve your technology, to help others like on Slack maybe, to educate others on your project. Some may contribute to the docs, some may write a blog post, others may share their journey at coupon or other conferences and all this is really critical for your project. And the least they deserve is a thank you. I think we can all agree on that. But the interesting thing is that a thank you may actually be one of the most powerful tools you have. And the good news is that anyone can do this. So be sure to include shout outs wherever possible. When you write an announcement blog, make sure you mention the contributors who helped build those features on social media as well, on Slack everywhere you can. That's an easy one. If you want to go a step further, you can build a recognition program. And I wanted to kind of show the LinkerD recognition program as an example. So for LinkerD, maintainers and community members can nominate their LinkerD hero. And so we have three categories. We have code contributions. We have helping community members. And we have spreading the LinkerD message. And the latter two are really, really important because most people think of code when they think of open source contributions. But your project needs all of it, right? So it's very important to also, to publicly recognize people for those contributions as well. So they know that that is important as well. And so we tried to make it really fun. You saw the previous graphic, and we have here one with a hero. We also created a dedicated blog post, and that may sound like a lot of work, but we're all busy, right? So we cannot really write a custom blog post for every single person. So we keep it simple. We have a template with one customized section, right? And I ask whoever worked with that contributor to help me write like one or two sentences to make it very, very personalized, right? And the rest is like very standard. So it's really easy to create these. Then every person gets, every hero gets a LinkerD badge, sorry, LinkedIn badge, typical project problem. So a LinkedIn badge is actually a CNCF benefit, which is really cool. So all projects can use that. So initially when we were building the program, we asked the CNCF if we could have one of those badges, like everyone who has spoken at KubeCon has gotten one of those, so you can get like something similar. So yeah, if your project wants to create something like that, please reach out, and you can request that for free. And then everyone gets on our hero wall. And then, yeah, our community members really, really appreciate that. So I encourage everyone to take contributors kudos really seriously, because it may seem like a small thing to you, but it does show contributors that their work is appreciated. So it is, it really goes a long way. And so that's all for today. Here are a few ways to get in touch or learn more. You can join our Slack channel. You can just pop in one of our meetings. You can participate in the maintainer circle. We have lots of resources. So check those out. And one last thing Sandeep already mentioned it. So the deaf and hard of hearing working group has a kiosk in the mornings. So we would love for you to swing by and say hi and talk to these wonderful people. And I think we're ready for Q&A. Yeah. So you have questions. We have ideas and we have a second mic. Hi, thank you very much for all the recommendations. They would work perfectly for large organizations and large projects, obviously. My question is, how do you compare them for small scale projects, small organizations, individuals, and they usually need much more contribution? How would you compare your recommendations? Thank you. I think the part about what does your repo look like is super important, especially young projects. That's often the get up repo is not a proper recruiting tool. So make your read me exciting, make your way you're going with the project clear, what you're trying to achieve with the project, what is the problem we're busy solving. Make that clear. And somebody will come and say, oh, I have this problem. And then they'll start using the thing and say, oh, I need this feature and they'll start contributing. But if it's unclear if it's just a logo and a few things you threw in there just because you opened the repo and I want to read me, make sure you invest time in your read me and your charter to say, this is where we're going because that's the vision, that's the light, the laser for the cats to follow you. And that was actually why I also talked about picking how much you can do in terms of activities, right? So you have a small project and you have one very part-time community lead that maybe you only do one activity a year, right? But you can only handle so many new contributors anyway, so that one activity is enough in that early stage. I'm a somewhat newly minted maintainer for the Istia project, which is pretty large. And it's my first experience as a maintainer there. And one of the things that I struggled with a little bit is understanding how to say no to what might be a first time contributor in a way that makes them not want to not come back again and contribute again, right? Like sometimes they, you know, the answer is let's work on this, we can make it better. Sometimes the answer is just the community has decided this approach, we're not going to do it, so thank you, but no. What are some tips for saying no in a way that doesn't make people not want to come back if you have to say no? I think one of the things that can really help is by having some of that documented as much as you can. So having really clear scope document, so what's in scope and what's out of scope for Istio. And that helps because then you can point people to something. You can say, hey, you know, thank you for your contribution, but we've decided to go in this direction. Here's where you can find more details. We'd love to have you contribute more. And so I think just being really careful to be kind and empathetic in those responses I think can go a long way. And maybe if you can, you know, as you're saying no to them, if you can think of something related that they might be interested to work on, maybe pointing them in another direction that might be, you know, kind of along the lines of their skills and their interests. One of the other things I would say is say no quickly, right? Don't ask them for just one more thing like seven times and then say no. That's what really drives people baddie, right? And do give them the opportunity to participate in the discussion also, right? Is to say, hey, we're going to discuss your proposal at our next community meeting, you know, if you can be there. And if you can't be there, then, you know, I'm going to have some questions for you. So they feel like even if they didn't get the answer they wanted, they had a chance to participate in determining that. They have a great presentation and a lot of useful things you can take away today, so thanks for that again. I am curious about what do you all feel are the most impactful or, you know, the activities that we can do that will have the biggest impact on the, like, a large set of contributors we have in a project that are, you know, doing smaller fixes and, you know, more scope things to getting more of those people to take that leap to, you know, big epics and big designs and stuff. Like, what's the most impactful things that will get people up the ladder from smaller stuff to bigger stuff? I would say, I mean, one thing is obviously actually, or you could take this, Ollie. One thing is obviously mentoring, right, is that to get to that big epic and that sort of thing, they're really actually going to need, and this was listed, but I didn't really talk about it in my high investment activities, obviously, is to have a reviewer, an existing reviewer, maintain or mentor them in working on that big change. And I think, too, asking people for specific things. So, you know, noticing that someone is interested in working in a space or that they have a particular skill set in an area that you need for the project, sometimes just asking them, and it makes them feel appreciated, it makes them feel like you value their input. And, you know, they may or may not have the bandwidth to do it, right? But I think that, you know, just people knowing that they're appreciated helps kind of encourage them to step up on the project. And then also looking at your road mapping in your charter. So, if you have specific needs, write them out an issue, clearly describe, I'm looking for somebody to do these things. This is the outcome we're looking for. Stick it in the backlog, and then you can add, use the labels and say, help me to get first issue. Or you can, as you say, you've got first issue people, but you want them to do the advance, and you can kind of, everybody wants the next badge. So, you say, this is next level iteration or think about what would be the bait that you can hold out for somebody to say, oh, I could do that, but maybe I should pick up these and make it attractive as the next, and be clear about what you want and list them in the issues. Because people get there, and they're unsure, and they're new, and they're not sure. And if they read the issue, say, I've got this skill. And also with your labeling, if you specifically go lang or need rust, or whatever, label it according to the language or the skill, and that would also help. I can say one last thing. So it's a generic answer, but again, invite this person to the community meeting. So people feel more encouraged in a community meeting to take new responsibilities instead of just seeing the hundreds of issues and trying to find out which one is the best for them. So thanks for the nice discussion. I have a small question, maybe from the language barrier, but I never heard the word charter in this context. So could you maybe explain what you exactly mean by charter? So charter, most of your CNCF projects have an explanation of what is the project. So if you go to the contributor strategy repo, you'll see we have the charter, and the charter says this is the work that we plan to do and the vision that we have for this specific working group. And then you can also have a section that says this is in scope. We're going to do these things, but we're not going to do those things. So you can say I'm doing a storage project, but we stop at the network level. So by drawing a circle around your specific work, is your charter making it clear to people what they're getting involved in? So also your charter is the question that you ask honestly with your charter is what's the problem we're solving? So you write out I'm solving this problem with this project, this is how we do it, and this is how we're not doing it. And that just helps people to understand what it's about. There's a bit of a marketing document as well. That also helps you with the whole saying no problem, because if you have a clear charter that says what's out of scope, then you're less likely to have somebody come along with a piece of functionality that you just really don't want as part of your project at all. Just to follow up, one thing that is nice for non-native speakers is to record your meeting so people can catch up after for things they don't understand, and for CentOS board meeting we did that, and we got a lot more engagement after the meeting because we could publish the whole board meeting in the video, and nowadays it's not too hard to do. It was not true a few years ago, but nowadays with Google or Zoom, whatever, it's not that hard, and it helps a lot the people that don't catch up everything during the meeting and the director. So if you can do that, in general it helps a lot. Just to point on charters while they pass the mic, we actually have a whole document in the governance section about how to describe your charter and what should go in it and what it should look like for projects, for maintainers. So my question is around recruiting... Can you speak up? My question is around recruiting contributors. As a... basically the CNTF as a foundation, right? How should we approach or how are we trying to actively recruit volunteer contributors? And how do we basically strategize that so that we have a more diverse set of contributors? Strategies for attracting a more diverse set of contributors. Okay, so I think to attract more diverse set of contributors depends on what kind of diverse people are you looking for. Okay, like for example in my case the needs of accommodation are pretty simple like I just want captioning and as long as captioning works I feel like I'm able to follow everything. So then it's like if you want to have like a heart of hearing people who are relying on captions you just need to make sure that your meeting includes the accommodation. But then there are people like my friends who are sitting here that don't allow captions and they prefer sign language interpreters. So then if you plan to include them you need to make sure your meeting has some interpreters that they can follow. And then if you want to have like blind people or more blind people contributors you need to know like if one of your meetings or whatever strategies you are using is inclusive for them. So accommodation needs very widely and as I said it does not need a huge investment it's not that complex. What you just need to know is just result to them like if you see me here you can just come and talk to me and say what am I accommodation needs. If you meet a blind person you just don't need and then you say if you have that if you have that accommodation then they can very easily be a part of it. And it all starts basically from your empathy to see a human being as a human being as long as you see a human being as a human being you will feel the natural desire to include them. That's what I'm saying. And I think of course you don't know who wants to participate before I mean you don't know it right like as a project just being very vocal about it or like publishing it somewhere on your get up report or something that accommodations may be made can be made or to come and talk just invite people to come over and say we'll figure it out if you want to join. Because you don't really know who wants to be you cannot guess who might be interested right. So just letting people know that if they're interested come and join us tell us what you need because one of the important things is like you have to ask them what they need don't assume right. Like a lot of people make that assumption like oh a blind person needs that or that person needs the other thing like ask them what they need and what's comfortable for them. So I think just being public about that I think that could attract at least in the accessibility part a lot of different people. Then another way for projects to if you want to diversify the community that's actually contributing it we have the mentoring working group underneath the tag and tribute strategy talk to us about that so basically it's not a job offer arrangement but it works quite similar so the project can make a statement about work that they want done and then they submit that to the to the mentoring working group they publish it and there is in the LFX platform a way that people from all over the world apply for that and if you're a project and you want to increase your diversity you go through the applications and find people that suits your need that you try to resolve and you can actually look at the skills you can look at the time zone you can look at various things like language whatever so if you were in France so if you need French contributors but you're in the US then publish it and say I need somebody that can speak French and can program in Golang and then people with those skills will apply and if you have an edge case of diversity that they want to fill just properly stated in your requirement One last thing I'll add there in addition to mentoring one last thing that I will add there is that we haven't mentioned before is code of conduct that is really important you need to make sure that the leadership in your project believes in the code of conduct and is willing to support it because people need to feel safe and if they don't feel safe they won't participate Just one more point that I'd like to add is sure like I'm in a project meeting then you can just meet about it and then add a tag like accessibility inclusion and mention that you are looking for diverse contributors and then put that in your social media and somehow through a context it will be retweeted and some of us see and then we get the feeling that I am to see that they are looking for diverse contributors and we are encouraged to be a part of it but as George said in my talk I said when I joined the meeting he just stopped for a moment and said are the captions working so in the sense of inclusion in that line I mean that's the way you get more diverse people it's about just saying a line or two just to make them feel welcome because there is as I said there is an initial ramp up time to have a diverse people because you may not suddenly feel that belonging that you are natural so if you can take one step you can take ten steps further and you can jointly work together okay yeah so we are at the end of our time slot but we are all here at the conference a lot of us will be in the project pavilion and you are welcome to come by with other questions or ideas or things that your project needs help with from the CNCF because one of the things we do for people is help connect them with CNCF staff and stuff for other resources and thank you very much for coming