 Welcome to today's session on must know CNCF resources for project owners. And today I'm joined by Dawn. Dawn, would you like to introduce yourself? Yeah, sure. So I've been in the technology industry for over 20 years, working mostly on open source software from companies like Intel, Puppet, and now at VMware. I am director of open source community strategy within the open source program office. I'm on the steering committee for the Linux foundations to do group. I'm a governing board member and maintainer for the Linux foundations chaos project. I'm a board member of open UK and co-chair of tag contributor strategy. Yeah, and I'm Catherine. I joined the cloud native, not the cloud native of the open source community less than two years ago and I'm totally hooked, love it. And I worked for Boyan, the creator of Linkerdee, where I work very closely with our end user community. And I'm also the maintainer of the cloud native glossary. So as mentioned, we're gonna talk today about CNCF resources for project owners. But before we do that, let's talk about why we do a toolkit, why we need the toolkit at all, right? Because maybe you're thinking if we have great code that solves a real pain point and have docs, isn't that enough? But it turns out, of course, that is the basis, that's the foundation, but there is a lot more to it. And if you'll join tomorrow's keynote, you'll hear that project is very much like a lemon tree. It needs time and care to bear fruit. So let's have a look at all the different things that a project need that may not be that obvious, but are very, very important. So here you see a lot of things, right? You see governance, user recruitment, marketing, events. It's kind of overwhelming. And the CNCF does help with some of this, right? You get marketing support, PR, infrastructure tooling, but what about the rest? Yeah, you are a developer. You're not necessarily good at recruiting contributors or motivating them. So how can you possibly do all these things? And the good news is you don't really have to figure it out all by your own because we're open source, right? We are a community, it's all about community and it's not only within your project, it should be across projects. And the CNCF is our common home, right? And it really provides this great platform for us to connect and learn from each other, exchange ideas, and really create this thriving ecosystem of successful projects. And that is really what the tag Contributor Strategy is about. So we are a group of people from a variety of CNCF projects that are committed to helping projects succeed. By maintainers for maintainers, we define strategies to build, scale and retain contributor communities. So if you're a project maintainer, we definitely should connect. You can either join the effort or just use the resources. And so let's have here a quote from one of the people of your peers who has been using it. So Dipty from the Vitesse team said that the tag was very, very useful when they set out to restructure their governance system. And so yeah, let's have a quick look at what the tag contributor strategy offers overall. Like there are three main buckets. Once you have the maintainer circle, these are regular events where maintainers meet to discuss how they run their projects, to exchange ideas. These are super valuable ways to connect and learn from one another and you should definitely attend. Then there are like informational and training resources. These are like things like guides, tutorials, best practices, templates, and strategies for building contributor communities. And then just general guidance on how to engage with your contributors. So first thing you should know is there is a website. Here you'll see two options, right? One for maintainers and one for contributors. And on the maintainer side, you will see all the available resources that we'll discuss today. And again, these are developed by maintainers for maintainers. Under community, you will see three different resources. One is the community CRM Runbook, Project Health and Contributor Growth Framework. You may have heard about CRRMs. They are generally better known from the sales teams. And I don't know if you know or you may not know, but there are now like really great CRMs for open source projects. And they really help you structure, streamline your community work by just helping you out to do all these little things that you have to remember. And yeah, that can be tedious and so on. So in this Runbook, what you will learn is what these CRMs are and how they can help you. And you'll learn how to best organize your projects. For instance, how to break it down maybe in subprojects or tagging your members. You may have a community member who likes to code in a particular language or has a very particular use case or is interested in speaking about your project. And so by tagging them, maybe let's say a year from now, you need someone with that skill set, you can easily find them because obviously we cannot remember all these conversations, probably whatever conversation you had like two months ago is probably very difficult to kind of remember afterwards. So like keeping that information and organizing that is very helpful. And then of course, like keeping all the history of all interactions, right? Like you're probably interacting with a lot of your community members on Slack. That is all suddenly lost. You can keep a record of that search for that, which is also very useful when you wanna go back or kind of search for a certain conversation or a certain topic. And then you can automate a lot of tasks, for instance, tweeting, like sending a tweet, thanking a contributor each time a PR is merged or set reminders for things that you have to do regularly. Then there's a project health measurement doc, which where you will learn how a healthy project looks like, how to measure project health, and most importantly, how to make sense of all the dev stats that you get. We hear a lot of people have like find it very confusing. So there you'll learn all like, you kind of know how to navigate those stats. And then you'll learn about things, how responsiveness impacts project health, how to interpret contributor activity and even a contributor risk. So if that's something that you're interested really check that out, there are lots of great information in here. And the last one is the contributor growth framework. This is a document where you get a lot of tips from project maintainers on how to motivate and keep your contributors motivated, how to incentivize them to do more, and how to encourage non-code contributions. These are somehow very fluffy things, a lot of it, but they're really the things that make your community stick. So some of them may feel very obvious, but sometimes it's good to really hear it from maintainers and how they handle all that. Okay. So we also have a governance section on the contribute site. So governance is all about alignment and getting all of the various people within your community collaborating together. And it's one of those things that you may think you don't need until something has already gone wrong. Expectations aren't aligned, you're seeing unhealthy dynamics within the community. Governance helps outline the expectations around roles and responsibilities along with the decision-making processes. So it's important to have at least these basics around governance in place as early as possible. In the governance section of contribute.cncf.io, we have several guides published. And the tag is always working on more. So for starters, the overview section talks about the what and why of governance, along with roles, policies and procedures and how to document your governance. Having a charter will help people understand the mission, scope and values or principles to avoid issues and misunderstandings that might come up later. The overall cloud native ecosystem is super complex with many, many projects containing overlapping functionality. So this can help end users understand how your project fits into the overall ecosystem and what functionality it has compared to all of the many alternatives. Now the charter section of the website has details about how and where to include this information. And we have links to examples from other existing CNCF projects that we think have done a nice job in documenting some of these areas. Now the CNCF does not require projects to have any specific governance model, but by the time a project gets to the graduated stage and frankly, hopefully way before that, the governance process will need to include details about how leaders are selected. Our biggest piece of advice is that your process for selecting leaders should be appropriate for the size and type of your project. For example, small projects do not need elections to select leaders from three maintainers. Now the good news is that to take contributor strategy, we are here to help you put all of the pieces together to make leadership selection and other governance documentation easier with governance templates that any project CNCF or otherwise can use. You can clone the repo linked on the slide and just copy the templates that you need over to your project. Right now we still have the comments they're embedded in the markdown file with details about what pieces you need to update, but we're in the process of actually moving those out into separate more detailed how-to guides to make them easier to use. Now right now we have three governance templates. All of the templates contain a section about values, but the rest of the template varies depending on how your leaders are selected. Now maintainer is by far the most common, especially for small to medium sized projects. In this governance model, existing maintainers are responsible for selecting new maintainers. Elections are commonly used for larger projects like Kubernetes and Knative who have things like elected steering committees, technical oversight committees, those sorts of things. The sub-projects template is pretty niche and it's actually only used in cases where you have kind of a bigger umbrella project with smaller sub-projects that operate mostly independently. Now we also have several contributing templates, including a contributing.md template. We also have a reviewing.md template that contains a reviewing guide that your project can use to provide information about the reviewing process for your project. There's also a contributor ladder template that's designed to be used with any of the various governance templates to help your contributors understand the path to moving into roles with increasing levels of responsibility, including various leadership positions. We also have maintainer circles, which after a brief hiatus are resuming and should be happening about once a month or so. There was one earlier today here at KubeCon that was focused on skills required for doing code reviews and other types of reviews with a discussion about the care that you need to put into being a reviewer. And we're working on plans for the next several meetings too. And these are designed to be a mix of information with scheduled topics, along with plenty of time for networking and talking to your peers, because being a maintainer is hard. And this is a way for you to get support and learn from your peer maintainers. If you need a resource that doesn't yet exist, there's a good chance that someone else probably needs it too. So we encourage you to join us and help us build new resources. We're open source folks, right? We love to create things that other people can also get value from. So why not share what you come up with with the rest of the group? Now, we've only been around for a couple of years, about two years or so, and we have loads of ideas on our backlog, but only so many people to work on them. Anyone can drop into our meetings, the tag contributor strategy meetings, if you'd like to join us and build something together or just let us know what you need. You can also drop in at any time for advice about any aspect of contributor strategy for your CNCF projects, because we are here to help you. And here's where you can find us to get help for your project or to volunteer to help us build new resources. We're pretty active on Slack, so that's a good way to reach all of us. The mailing list is relatively low volume and is a really good way to get notified about things like meetings and other tag activities. And as I mentioned earlier, you can drop into our meetings to get advice or join us, and I encourage CNCF maintainers to participate in our maintainer circle meetings. So tag contributor strategy is more than just a place to develop resources. We're really creating a cross-project community of maintainers who can connect, exchange ideas, and support each other. Managing an open-source project can be really challenging, but a supportive community can provide resources, advice, or maybe just listen when you're struggling with something. And when you use our resources, please let your peers and other people know how useful they are. Join our community, you can meet our team, you can get involved, and we would love it if you would tell people about us, so feel free to share this link with whoever, social media team members, people who might be interested. Now what we've done is we've left a load of time at the end so that we can have discussion and Q&A. So if you want to ask questions about any of the stuff that we've talked about or have a discussion about any of this, we have plenty of time for that. So thank you. Questions, yes. Do you want the microphone, or is it quick? No, it's, we have a, we have a, being recorded. So either I can repeat it or you can. Yeah. There we go. I think he'll turn it on in the back. Maybe he'll turn it on in the back, I think. He's turning it on right now. Nope. Okay. Just go ahead, I'll repeat your question while he sorts out the microphone. Well, the question was regarding examples for the CRM, so I, well, basically the run book is, so I don't have like a particular project in mind. I know that several are using it, but I don't, yeah. But the CRM, basically what it's doing, we kind of got feedback from different people who are using it and to give advice on how they're using it. So yeah, I think like it's embedded in there and like I'm sure we can get some names and, but I don't, yeah. But the idea of the run book is basically that. So you have the CRM that you can use, but then you also get like how different projects have been using it specifically and. I muted myself. Yeah, the CRM run book, which is what I'm not showing at all on the screen, because it's in the wrong window. Nope. Nope, wa-wa. Okay, maybe another question while we wait for that. Anyone, do we have the mic or not? No, just go ahead or repeat it. Oh, okay, so generally like if users get like impatient and start like asking questions and then you get like plus one, plus one, plus one. So I don't know, I'm just gonna say my opinion and then we can say, so I think in general, it helps like, I mean, they're all humans, right? So sometimes it helps to explain that. I don't know if you're doing it full-time or not full-time or something. It's like, hey, I'm doing it also on my spare time. We're all like kind of doing it on the side and kind of explain a little bit that things take a little bit more time. Expectation management in general is kind of, is it like when they're asking for features or for help or in general, for features? Yeah, I think I would just explain a little bit like, hey, this is, we have all these things in the roadmap. So just ignoring it, not be good, but people don't have context. They don't know what's going on. So just explaining your situation, which is something that I would do in a very normal interaction too, I don't know. Yeah, absolutely, and the other thing can help if you have like a roadmap or a project board or something where people can see all of the other things that you're working on. That can also help because you can see that we've got this public roadmap or this project board or whatever it is. And these are the things we're working on now. This is where we've added your feature and it's gonna be another two releases because of all of these other things. And that can sometimes help people put things in context too. Any other suggestions from the audience? Cause this is a discussion. Yes, here, I'm gonna mic run. One thing we've done is offered them the contributors guide in terms of here's how you could contribute a patch. Here's kind of maybe have a mentor that's on the team that could help them and say, if you're interested and really want it, then this is kind of, cause basically you can't do it all and if you're really busy, sometimes it's like we will gladly help you maintain it or at least implement it. So that's another way of kind of suggesting to them if you really, really want it that bad, then maybe contributing to the project could get it in faster. Yeah, and encouraging all of those people who are plus wanting it. Maybe one of them would be willing to pick it up too. Other thoughts on that or other questions? Being a retainer is hard. There have to be other questions. Sorry, I'm not gonna let you all off the hook that easily. Yeah. So in this talk that I am seeing the screen, I see that there's something about gifts or stuff like that. Does that mean when we have a CRM, we could actually maintain a list of people's contact information in there for future interactions? Is it something we could do? Not necessarily contact information. So it does pull information from Twitter, Slack. So it's not like that you get their emails or anything. So it's not like a sales CRM, right? But you wanna have a full view of what people have done. You know what they have said in your Slack integration. So it starts creating profiles based on how people have interacted with your project. But it's not supposed to be something where you start emailing. So that's kind of like the difference because it's like for, yeah. Other questions, comments, thoughts, things you wanna discuss with your peer maintainers in the room? Something you're struggling with right now. People are tired. We're not used to all this face-to-face interaction, all this KubeCon. How much time do we have left? Does anybody know? Five minutes? 10 minutes, 10 minutes, Josh says. I missed the beginning of this session. So I'm just all right like this, but it comes to me a question. I was already at the maintainer circle and here there's like 7,000 people attending the conference and I was like seeing dozens of people and here I don't see many people. So is there like a major need to welcome more contributors? And if yes, are there areas where we could help like technical training regarding the Go programming language or other things or what is the major, is it that people don't have enough personal time to contribute? Is there like some technical barriers to contributing more to the CNCF Foundation? What are your feelings on this? I think yes to all of that, frankly. I mean, it's getting contributors for your project is hard, right? And we have a lot of people here at KubeCon, but there's only so many maintainers, there's only so many projects and only so many people who can contribute. And I think anything that we can do to reduce some of those barriers to contribution. So from a technical standpoint, having really good new contributor docs to get more people involved. I think also, we have a big issue right now in the CNCF with a lot of projects, Kubernetes in particular, where maintainers are just burnt out and we just don't have enough maintainers. And so it's getting to be a real problem and we really need to start thinking about, and it takes more time up front, right? To take those new B contributors and grow them into maintainers and into reviewers and approvers and kind of push them up the contributor ladder. But it's something I think we need to focus on and spend more time doing and particularly people from maybe other backgrounds who wouldn't necessarily be contributing. How do we find more of these people and how do we get them involved in our projects and how do we help them, even though it might take some time and might take a little bit of help, how do we get them into those maintainer positions? And so I would take a close look at all of your project docs and your contributing docs and you'll think about what you're doing to make it easier for new contributors and then also think about other programs you could put in place. So Kubernetes contributor experience, they got some fantastic ones. They have, you know, Kubernetes does a lot of shadowing. So the release team has shadows. So, you know, all of the various components within the release team, everybody has a shadow who will eventually, hopefully if they do well, then move up into that leadership position. We did the same thing for other parts of Kubernetes. And so, you know, think about whether you can put in place some shadowing programs for various elements of your community and where can you get people engaged? You know, honestly, Kubernetes, a lot of people get involved in SIG release because it's, you know, they can, they can shadow somebody and it's a relatively easy way to get involved in Kubernetes. And then they can eventually move on to other things within the project. So think about anything you can do to kind of reduce those barriers. What's on that? What's on that? Losing my microphone. Yeah. You have a comment and then Tim has one. One thing that I've noticed that if anybody else agrees that the maintainers of not the actual Kubernetes itself but the other sub projects don't get really recognition and it's a really hard job to do and most people do it out of passion. They could do it out of passion for two, three years, but if they keep doing it, they'll burn out eventually. And one thing I think is missing that we could give them a little bit more recognition, especially they could use that recognition in their day jobs to get their career growth goals as well. Because they would see their colleagues and their companies would, you know, get their career growth results than they are doing with the maintainers. I think we are missing something on recognizing the maintainers of not the actual Kubernetes but the other sub projects. Yeah, that's a really good point. I mean, anything that we can do to recognize the maintainers that are keeping all of our software running, I think would be helpful. I was gonna say something similar. As we try to get more awareness and visibility and connection, we talk about how do we grow our community, get more people into the maintainer ranks or just even reviewer before that. But that's trying to grow the community but sometimes we also need to think about how we grow ourselves. We often come into a leadership position because we're good at coding or that traditional side of things but you need to avoid burnout yourself. You need to spread the workload and pull other people in who can do different things. And also learn new skills about leadership. Part of that might be instead of writing code, writing a business case to encourage businesses to incentivize their employees to care about these things. And that's not natural for most of us. So we have to stretch to learn how to make those types of arguments. And then one other last thing I'd give a plug for CNCF. They do have marketing for, this isn't KubeCon, this is KubeCon CloudNativeCon. There's a whole bunch of projects and there is an effort to get the word out more about other projects and what they're doing and where they need help as well. So as maintainers leverage that, the CNCF is a foundation that exists for you. Yeah, that's a really good point because there are loads of other CNCF resources that you can tap into. There's actually a social media channel on the CNCF Slack. And if it's project related and it's neutral and it's not coming from a company account, they're generally happy to retweet lots of things. So if you need contributors for your project, your CNCF project, and maybe there's a specific area that you're looking for, you can get the CNCF social media to retweet things and you can tap into the CNCF marketing depending on what level your project is on. There's different support. Yeah, and the blog posts as well. If you wanna publish a blog post, you're super supportive, so it's, if it's a project. So you get a lot more visibility. Yeah, Catherine actually just went through this with our tag because we don't have very many people and we have lots of work to do. And so you did a few things to kind of promote it. Yeah, just like, I mean, like just reach out to them. They're, again, they're super supportive and said like, hey, can we do a blog post? And then they got us lots of opportunities as well. You had to just get a little bit more awareness. So they are very helpful. You just have to reach out. They just may not know that you need them right now. So I think the marketing in PR are the two areas where you can do a lot with them and they can do a lot. They can help a lot. Any final questions? Yeah, I'm gonna get my exercise this way. That's my goal. I could have asked why you were still here. I think there's a bit of a conflict between like the many things that maintainers already have on their plate and setting up additional processes and the governance structure where you have regular meetings and the board. And so I don't know how to overcome this, but it feels like extra work in addition to the work you already have and that's already too much. So I don't really know how to motivate a maintainer community to say, okay, we need these structures because they maybe take some work off of our plates. Did that make sense? I think Josh has an answer to this in the back. I work with a lot of the smaller projects in CNCF and the answer to this is look for ways to do this with minimal effort. I would say things like you should have a weekly community meeting and that doesn't mean that you should have a separate meeting that is specifically a community meeting. It means when you do your weekly development sync meeting or bi-weekly development sync meeting, make that open and recorded. Because actually it turns out your biggest problem with regular community meetings is that you don't have a lot of people other than your maintainers show up. And this way, at least you're getting some work done if nobody else shows up. And if somebody does show up, they're gonna immediately get drawn into whatever it is, whatever your current technical crisis is and maybe you might be able to help. And beyond that, Katherine and Dawn have just gone over a lot of the templates and stuff with the idea that, hey, you need to set these things up, but by set them up, you mean fill in some blanks and make a copy. Because for a small project, they don't actually need a lot, you know? Yeah, and the other thing you can do is kind of rotate some of the responsibilities around that can help too where it's not one person, one particular maintainer getting stuck with doing everything, but you can kind of shift things around so that different people are responsible for it at different times. That's worked pretty well with the Kubernetes community meeting in particular, where different people lead it every month. Any last questions? Okay, we're almost out of time, so I will let you off the hook at this point. So thank you everyone for coming. We really appreciate the discussion. Thank you.