 Hello, everyone. Welcome to Cloud Native Live, where we dive into the code and community behind Cloud Native. I'm Taylor Doulizal, Head of Ecosystem at the CNCF, where I work closely with teams as they navigate their cloud native journeys. Every week, we bring a new set of presenters to showcase how to work with cloud native technologies. They will build things. They will break things, and they will answer your questions. In today's session, we have quite the cloud native crowd. As you can see, Katherine, Dawn, Carolyn, and Josh have joined us to talk about tag contributor strategy. Now, tag, that's a fun game to play, but that's not what we're talking about here today. Tag stands for technical action group, so folks that get involved and work on different aspects throughout the cloud native community. This is an official live stream of the CNCF, and as such is subject to the CNCF code of conduct. So please don't add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful to all of your fellow participants and presenters. Be excellent to one another. With that, I would love to hand it off to the team to kick off today's presentation and discussion team. With that, please take it away. Welcome. Awesome. Well, thanks so much for the intro, Taylor. And so we are very, very excited to be able to spread the word about the tag contributor strategy today. And I am joined by a group of people who are really doing amazing work, and we really, really feel that more maintainers should know about this. So that's why today we're going to discuss why there is a tag contributor strategy. If you need one, hint, we do think you do, and how you can participate. So yeah, there is a lot that goes into successfully maintaining a project, and it all goes way beyond code and docs. You have mentoring, cultivating and promoting leaders, marketing your project, contributor recruitment, deciding on governance. There is a lot of things, right? And most of these things are not necessarily things that maintainers have previous experience with. So it can really feel overwhelming, but you cannot neglect any of these aspects because it will negatively impact your project. So how do you handle all that, right? You are a developer. You are really good at coding and docs, right? But the good news is you really don't have to figure it out by yourself, right? There are lots of projects that have been there before. Just look at the cloud-ended landscape, how many open source projects there are like, right? So no need to reinvent the wheel. Besides, we live and breathe open source and open source is about community, right? So not only within your project, but also across projects. And the CNCF is basically the home for all our projects, and it provides this amazing platform for us to connect to exchange ideas, learn from one another, and basically to build a thriving ecosystem of successful open source projects. And that is really what the tag contributor strategy is about. So we're all from a variety of CNCF projects and we're committed to helping your project succeed, right? And basically what the tag does is define strategies to build, scale, and retain contributor communities. So those are really important things. So our ask to you today is please, please, please, don't try to figure it out on your own. Let's connect and figure it out together because that way anyone can really benefit. So I'm gonna share my screen because I wanna show you our website. Here you'll see two options, right? Like contribute, it's the URL is contributed.CNCF.IO. And here you'll see two options. We're gonna see maintainers. Today's sessions is on maintainers. And I'm gonna show you a little bit about the community section. Here you will see some guides, high-level guides. You will see one of these three. Let's start with a community CRM run book. A lot of people don't really know that there are CRM community CRMs. You may know it from sales, but these can be really, really helpful to manage your project. So here you learn a little bit about what community CRMs are, a little bit like some tips on how to use tags and some recommendations on daily, weekly, and monthly activity. So these are based on what are other, if you're adopting a CRM, you don't have to start from scratch, right? Like just have a look here, see what has worked for others, and then adapt it for yourself, right? Same thing with project health, measuring your project health were important. So here you learn all about that and specifically how to make sense of death stats. We see a lot of people who kind of struggle with that. So here you will learn a little bit what to look at, right? And then you have things about responsiveness, how that impacts health, how to contribute a contributor activity, and lots more information. So really, really good place to start if you're interested in that area. Then there is the contributor growth framework, which is a high level guide on, yeah, that provides a high level overview of how to grow and your community and how to engage more with them. This is based on interviews with a bunch of people and you will learn about how to motivate users, the importance of honest and clear communication, documentation super important, why it's important, and the human factor. A lot of these things will sound very, very common sense and you were probably, you had a gut feeling about it too. But it's really important to see it first written out because it's really important. It's very fluffy, but it's very important because that's why people come, people come because they are connecting with people, right? And it's, so it's good to see it, it's good to see what other projects emphasize and so on. Then you'll hear about, like, you can read a little bit about PRs, like how to manage expectations and engagement. I'm not gonna go through all these, but incentivizing contributions, like the contributor ladder is very important. It's very important for people as they join a, where's it a site to which project to contribute? To kind of see like what, if I start contributing, where will it lead me, right? Like that's like having that visibility is really motivating, right? And then no code contribution, non-code contribution, super important. You don't want only people contributing code. That's important too, but you need people to help on Slack, right? To help tell the story. Those are really, really important too. And then long-term contributions. Okay, so I think I'm gonna, that's enough of this. So I'm gonna stop sharing. And basically what I have done, like, so I worked on the CRM and contributed growth guide. And it really was a great experience. I had just joined the LinkerD team and had lots and lots of questions, right? I needed guidance on how to grow my community, our community, how to engage with them. And there wasn't actually something ready to go, right? But what the tag allowed me to do is pick people's name that I would have otherwise not been able to do, to pick, right? Because so I decided to create a guide for me, right? Like, so it was basically for me that I created, but also it would be available for anyone who needed it. But my main motivation was for our project, right? But because the end result would benefit the community, maintainers were very, very happy to talk to me. And they were very generous with their time. And all those conversations were incredibly valuable. And I got a lot more out of it than anyone who was just going to read the guide. So if you need a resource that is not available, there really is an entire community to help you build it in. Because chances are if you need it, another project needs it too. So we should probably build it and make it available for anyone. And the whole process for me was a huge learning curve. And I really recommend anyone who needs something to kind of do it in kind of the tag context. Yes, you are probably wondering it will take some time, but honestly it wasn't a crazy amount of time. And you also have to consider that it will probably save you lots of time down the line because you gathered so much information that has been validated by other people that you're not flying blind anymore. So it is really worthwhile. So you put a little effort or some little more effort in the beginning, but it will really help you save time down the line. So even from a purely egoistic point of view, it's really worthwhile doing. It's good for your deck, it's good for the community. And it's a great way to become an active member of our cross-project community, which is the CNCF. So I hope that kind of got like provided a sense of what the tag contributed strategy is and why we think that you should get involved for a summary described and links to that point to how to connect and so on. I'm gonna share a blog post and yeah, I know anything that I missed Don, Carolyn, Josh. Well, I was going to say, we're gonna continue going through the projects of the tag here, but if you have any questions about things in the tag, about recruiting contributors and governance and running your project and connecting with other maintainers, et cetera, please ask them in chat and we will field them, we will work them in and field them as we see them. And I think it's also important to remember that we also spend a lot of time in some of the tag meetings and in the tag Slack channels, just answering questions from maintainers and projects. And so it's a great, I think we're a great resource if you have some questions, but also if you have some expertise around just growing your contribution base, even if you're not ready to develop a resource, you can still pop into our tag meetings or into our Slack channel and answer questions from other maintainers and other projects. Yeah, that's really the first way that I think most people get involved with the tag is you have a question, you're like, I've gotten to the point where I'm supposed to have a diverse group of maintainers and I have no idea how to get there. Like that's one of the big ones, to be honest then, understanding how to set up governance. And what we welcome people to do and what people have been doing so far is just coming to our meetings, we meet every Thursday. And you can see it on the CNCF calendar if you look for contributor strategy and just drop in and chat. It's pretty much office hours every week in addition to just like a standard agenda we run. So it's never an imposition. You can always just drop in, ask questions, just lurk and kind of listen and see what's going on. And oftentimes that's a great way to just realize we're asking questions about something that you may know. And that's how a lot of people eventually become contributors. They didn't like show up one day and they're like, look, I wrote this wonderful thing, here you go. Usually it's in a reaction to seeing the types of questions that projects are bringing or the things they're struggling with and realizing you've already thought about this a bit and have some suggestions. That's one question that I had. That's one question I had is kind of like you answered that quite a bit, Caroline, in terms of like what the usual pattern looks like for people getting involved. Does it kind of mirror what you see in open source in general as like pull something down, try it, demo it and then kind of step up your involvement in terms of as time goes on? Like have folks found that helpful or are there any other tips or tricks that you might be able to give to folks kind of looking to get more involved or those that are curious? I know that getting involved in open source and things like that, it's not like you have to jump in and immediately rewrite the orchestrator for Kubernetes. There are many other ways to help. Is that very much the same thing with tag contributor strategy as well? I think having experience being in an open source project is going to be really important, Kenny, great. Okay, so if you're a maintainer or an active contributor or you've participated in running a project, most likely you already have the experience needed to say this is what I've done, this is what's worked, this is what's gone horribly and maybe also just point out gaps where you're like, I don't have an answer but this seems like a common problem that multiple projects have. It's less about, okay, first I'm gonna run Kubernetes before I try to contribute to Kubernetes. It's not quite the same thing with the tag. Another difference is that oftentimes it's really easy to not make a commitment to being a contributor every week or all the time but to drop in, share your experience and that's valuable to us and it's not considered like a one-off low-value contribution. Every interaction is useful to us and even if it's just occasionally once or twice you share experiences, you point out a repo that maybe has worked well for you when you're automating things with your project. All that's useful or maybe you've come up with an amazing way to like curate good first issues for your project and you wanna share that. Just dropping that in chatting with us and getting that content even bootstrapped and started is a useful contribution even if you don't have the time to come back week after week and that's not really expected. Though obviously we love it if people have fun and wanna keep contributing. Awesome, thank you so much for that distinction. I think it's really helpful to know that and definitely want people to feel that sense of welcome to it with getting involved and kind of knowing like it's okay if you miss a meeting or two life happens but we still value having those conversations, cool. Thank you, thank you. Yeah, I think it starts just with as little as just having a conversation and sharing it there and then to like building guide or whatever, right? Like anything and anything in between. So I don't know, I feel like sometimes especially with smaller projects you probably feel alone with certain things. It's good just like also like I think it just feels good to just connect with other people and exchange ideas with anything else, right? So there is that value and I really like the idea of that cross-project community, right? Cause like we talk all about community and open source but it's like a lot of people keep in their own. It's like we can learn so much from one another, right? And like creating that internally I think that's incredibly valuable. And I think, so that's why I hope that more people learn about the tag, more people join whether it is just popping into a meeting or like actually getting hands on with something. I think there's lots of value to it. So I would like to talk about concrete ways that we need help right now. So you're like, I'd love to contribute but honestly, like this sounds a little vague. Let's like get specific here. I have a slide that kind of calls out where we're looking for help. We just started a new initiative called Community Infrastructure and the idea is that let's say for example that you wanna keep a list of contributors up to date on your read me or on a separate page in your repo and really call out and thank everyone who's helped your project out. If you've ever looked into this, you know, there's probably like 16 different solutions four of them are un-maintained. Each one has different quirks. These are the types of things that we'd like to look at and go which ones have been working well for people and maybe have a project, five projects say we've all been using this GitHub action or we've been using this workflow. This is why it works for us because we're a big project or a small project and you kind of call out what's unique about us and how this solution works well for us. And so we're looking for maintainers to share what they're using to support their community. Now I know that the acronym there is CI but we're definitely not talking about CI CD or build pipelines or anything like that. We're looking for your experiences and tips running an open source project and supporting the project itself, all the meta stuff that kind of just needs to happen, all the invisible work that goes into running your project. So for example, Kubernetes, huge, obviously they have lots of resources, lots of people to be able to help run the community. One of the things that they have is Pro. And if you've ever looked into like, wow, I wanna be like Kubernetes, Kubernetes has a great way for people who don't have right access to the repository to be able to do things like help label things, triage issues, review pull requests, just coordinate and figure out who are the three to five people who should be reviewing a PR. And I mean, gosh, just a million other things, right? Pro is definitely like a kitchen sink. But as a smaller project, when you think about, well, how do I have something like that? I can't run like, Pro on a cluster all by myself somewhere. So we're looking at, can we take the functionality of Pro and put it in a GitHub action, which is a lot easier and more practical for one to two maintainer projects to be able to run themselves and get some of the benefits of workflows and processes that things like Kubernetes has figured out, but scaled down for little projects. So we're looking for advice, processes, actual GitHub repos that are out there, like I found one that already existed that does Pro on a GitHub action. And so I've been contributing to it and trying to help get it to the point where it's a little closer to what Pro really does. And so we're looking for, do you have a pet project like that? Are you using one of these with your project? Let us know about it. So we can start aggregating, telling people about these, and then maybe crowdsourcing, getting more people to contribute and support these projects that could really help out a lot of CNCF projects. So even if you don't actually have solutions, maybe you just have, this is a problem for me and I don't know how to fix it and hear all the weird jinky things I do, but it sucks and it's horrible. That's great feedback. Cause if we hear that from two or three projects, we could go, hmm, maybe we should be looking for solutions in this area and then sharing that information back to the wider CNCF community. Laurentus is looking for, I guess PRs or issues around this that he can find. We don't have like good first issues and things. What would be the best way to start is coming to the contributor growth working group. I think we'll be able to post links, I think, to our calendar that would, I'll come over the link and put it in chat here. And so contributor growth, we're the ones who are kind of working on this initiative and we're still like the brainstorming phase of going, what projects should we be talking about? What projects are people using? We're still trying to just aggregate all that information and then pick out one or two places where we can focus. I can provide a link to the proud GitHub action in chat here. That's something I've been contributing to on and off for a couple of months, but I think it has a lot of promise and that's somewhere where we're gonna be focusing very soon, but I don't have like a PR or something we need help right now on. I'm just gonna pull up those links. Oh, I'm sorry, you're seeing the wrong thing. I just posted the CNCF community calendar. Thank you so much, Catherine, for sourcing that. I know that I'll post to students to a couple of different platforms. I think LinkedIn might not get these. I know Twitch and YouTube will. So for those of you watching on LinkedIn, recommend checking out CNCF.io slash calendar or feel free to reach out or drop questions if there's anything you want specifically and I'll try to help out on that front. But keep the questions coming, keep the conversations going, this is all fantastic. So I think, Dawn, did you wanna talk about templates next? We have some resources that kinda help people get started with making governance docs, contributing guides, things like that. Yes, I would love to share some templates. So Catherine earlier went over some of the resources that we have around community and we also have some similar resources around governance. So how do you come up with a governance model to select leadership? How do you build things like mission scope and values into your governance model? And so we have these resources along with the ones that Catherine mentioned and the templates really are kind of an artifact out of the resources that we've been building. So we have a number of different templates and you can see we have the broken down into the ones that are required for all projects, the ones that are recommended for all projects and some of those are kind of required once you hit a certain stage. Some of these actually come from the security tag, tag security, so things like the embargo policy and things like that come from tag security and so they have a lot of good templates as well. And what I wanted to start with, just kind of running lists, there are some that are really, really pretty important. So like the contributing template, for example, and we actually have a whole resource written around how to make a contributing guide. So we have a template that goes along with this, but this document itself explains exactly how to fill out the template, what to put in your document. It gives you some ideas for ways that people can contribute. It talks about meetings, finding an issue, asking for help, pull request lifecycle. So it gives you a lot of options for your contributing.md template because this is something that let's face it, no two projects are gonna have the exact same structure for a contributing guide. So this will help you with all of the things that you really need to put into your contributing.md development environment setup. This is something that I see missing from way too many contributing files and it's super important because if people want to contribute to your project, they probably need to set up their development environment. And then other kind of logistical things like signing your commits, pull request checklist. And we also have at the bottom of this file several really good examples that you can look at. So if you're a little more driven towards the examples, that's a good place to start. Hey, I'd love to call something out about those examples and how you can contribute to documents like this. The way this document was made actually started from these examples. The people who worked on this document went through and looked at existing CNCF projects and just open source projects in general and said, who do we think is a good model for this type of thing? Who has a really great contributing guide that's effective, that's helping people when they first come onto the project and enables them to just immediately start contributing. And we would compare and contrast a whole bunch and go, what's different? What's unique? What are the gaps? And that's kind of what this is, is a huge smoosh or like amalgamation of a bunch of different contributing guides from different projects, but there's a lot. There are a lot of CNCF projects and we may not know of all of them. You can see some of these were pay-popular, like Helm was maybe a Gimmie, Kubernetes obviously, but there may be smaller ones where maintainers have innovated and come up with new things or maybe you think your project is doing something different that you don't see represented here. That would be a welcome contribution to understand what other people are doing because it isn't a one size fits all. Yeah, absolutely. I think that's really important. There are loads of different ways to contribute to these guides. And we also really do love to see examples. And we have, there's a project template repo under the CNCF org. And you can see, so for the governance, we have several different governance options. So we've broken those down into three different templates because they're all very, very different. So we have the maintainer template, which is what we would consider sort of the standard governance practices that most projects should start with. But we do have other templates. So if you look at the elections template, for example, that is one for gigantic projects like Kubernetes who needs to have steering committee elections and technical oversight committees. So if you think of projects like Kubernetes and Knative, they have governance models that look a lot more like the elections template. And then we also have a sub-projects template, which is good if you've got an umbrella project like conveyor, for example, or Prometheus. And you've got this big umbrella project with lots of little sub-projects that need to be represented in your governance model, then the sub-projects template is a good place to start. But the elections and the sub-projects templates are actually quite rare. So I'll run pretty quickly through the maintainer template so you can see what that looks like. And right now we do have, you kind of have to view it and view the raw version of it because we have comments and instructions embedded here in the documents. So we recommend that when you actually look at it for your project that you view the raw one, but we're in the process of actually taking those comments and augmenting them and moving them to a how-to document like I showed you earlier for the contributor template. So that's something that Carolyn started doing and we think it's a fantastic idea. So we've been working on that for some of the other templates as well. So that's another thing that's coming soon. It's also another thing that people could help out with. But most of the other... Go Josh. Yeah, I was gonna say, if you've used one of these templates, I mean, the thing is that a lot of these templates were kind of first or second drafts. So if we used one of these templates, we could really use you jumping in A to help us documenting the template for what people need to know based on your own experience with it and also helping us improve the template. Yeah, for sure. That's a great way to contribute and help us make the resources that we have even better. So all of the templates have a value section. We've got some examples, but you need to replace these with your actual values for your project. We have a section on maintainers. It talks about how to become a maintainer, meetings, CNCF resources, codes of conduct, how you do voting, so how you make decisions in the project. And all of this can be found in the template. And it's really designed to be used along with the contributor ladder, which we mentioned earlier, but we also have a contributor ladder template. So as Catherine mentioned, this is a really fantastic way for contributors to be able to see how they might move up into a project. So the contributor ladder is really designed to go along right with and all of the governance templates. So we recommend that you pair the governance template with the contributor ladder template as well. And it talks about all the different levels in your project and what it takes you to move to the next level, which is really important. And I think we've kind of talked about this earlier, but one of the best ways to learn about something is to help teach others. And we're always looking for help and improvements for the templates and the how-to guides. So if you have a passion for governance, contributor growth, any of the areas that we're working in, we encourage you to come out and join us. Yeah, I think sometimes it's easy to see a template like this and think it's done, but that's definitely not the case for basically anything that our group produces. You know, the CNCF is in static. None of the projects that we work on is like, all right, this is the way to do it. This is our governance structure from here on out, never change it. You know, essentially all of our projects evolve and change every day. So the guidance that the tag should be providing needs to change all the time. So if you see something and you're like, this is really cool, but for a project like mine, half of this isn't applicable, we wanna know. Maybe we should make a separate template that looks a little different for the different type of projects that we have in the CNCF. But yeah, just don't look at it and think, oh, well, I would have contributed to the contribution ladder, but it's already done. That's definitely not the case. We can always keep improving and involving these documents. Yeah, absolutely. Even just suggestions of things to put in, because like the way that we ended up with a value section in all the government templates was that Ava, I think, came by and said basically this needs a value section, right? We need to communicate values of the project in the governance. Yeah, you're right, it does need one. And then, but we didn't know what to put there and then somebody from another project had a very nice sort of generic value section for their project that we borrowed. Yeah, I think these should be seen really as living documents, right? Like they're never going to stay that way. Cause it's like, even if they're just new, for instance, with a CRM run book, right? That is like the feedback or like the input of a few people who did it, but it's probably missing a lot of other things, right? So it's like, it's the first start to put it there. We only got feedback from certain people, but there may be lots of ways how you can use a CRM, a community CRM that are valuable that are not there, right? And that applies to everything. So it's like, and that's another thing. Like whenever we contribute something to the tag, it doesn't have to be this full thing. It's like, okay, this is to my best knowledge, right? Like what I've learned and what other people have told me, put it out there. And then like ideally as people use it, cause there's a everywhere there's like a, like a contribute or edit or, you know, like button. So to make it really easy. So it's like, if you see something, you know, like, and even if it's just like an issue cause you don't want to do the whole PR, it's like making a comment. It's like, oh, we've done this and this. So it should be ideally as more people use it, it will improve over time, right? So it should improve. Like there are none of these like perfect probably. So any little feedback or whatever is highly appreciated and is also valuable contribution. And I think the CRM Runbook in particular is a really good example because it's not something that we talk about in a lot of open source projects. So I saw this as a really innovative addition to the tag. And it's something that, you know, Catherine is really, really passionate about and brought to us. And so, you know, I would say, you know, look through the resources. And if there's something that you're doing that's maybe innovative that you think other people can learn from, that's a really good way, I think, to contribute new material to the tag. You know, and we talked about kind of, you know, sharing ideas and one way that, you know, being a maintainer is hard, right? So we need support, you know, maintainer to maintainer. So I think next Josh is up, he's going to talk a little bit about the maintainer stuff at all. Yeah, so, you know, honestly, one of the things we talked about was like guidance and that sort of thing and different people sharing advice and resources. But honestly, there, when you're a project maintainer, there are problems that you deal with that there aren't any, like a document can't help you resolve those or maybe they're honestly not resolvable at all. Maybe you just want to talk to other maintainers who have the same kind of problems that you have. I, maybe just to commiserate. I'm going to go ahead and share this. So I want to highlight that, yeah. And that's actually why we have maintainer circle. So maintainer circle is periodic a few times a year, either online or in person at KubeCon CloudNativeCon. We get together a group of maintainers to talk about things. This is a picture from the last one in Valencia. And this was a conversation about reviewers. Reviewing, how to do good reviewing, how to mentor new reviewers, how to deal with problems that come up in reviewing other people's submissions. We got together for about two hours in Valencia for a lot of people to talk about this. We periodically scheduled these about all kinds of topics, including things like mentorship, burnout, handling code of conduct issues, handling security issues, all kinds of the other things that are really, honestly, very part of what makes being a maintainer of a project really difficult. So if you are a maintainer of the project, and I'm saying, and you don't have to be an accredited CNCF maintainer on the CNCF maintainer list, honestly, you just have to consider yourself a maintainer. Are you responsible? If you go away, does something bad happen to the project? If the answer to that is yes, then you're a maintainer. That's a great one in this test. Yeah. And we would be really interested in having you join us. And by joining us, I would say you can either, the main communication happens on the maintainer circle Slack channel and CNCF Slack. And the, or you can just join, we have the tag contributor strategy mailing list. We mainly use the mailing list only for announcements. So if you just want to keep track of what we're doing, including announcements of new maintainer circles, you can join that. It is, it's not a discussion list. We do most of our discussion on Slack. So you don't have to worry about getting too many posts from that. Now for maintainer circle, please show up and participate. Particularly interesting, if you are a maintainer, not on Kubernetes, overwhelmingly the people who've been turning out for our maintainer circles are Kubernetes maintainers because there's a lot of them. But we really, really want to reach the other CNCF projects for one thing, because I think you guys are going to have more different perspectives. You would probably, particularly if you're one of only three maintainers on a project, you could probably use the peer support even more than your Kubernetes peers. So please join us and participate. Make use of that resource. And importantly, if you have either an idea in area of expertise or a problem, so either something that you figure out how to do and you want to share with other maintainers or something you haven't figured out how to do and you want to talk to other maintainers about how you resolve this, please come to us, suggest it as a topic. If it's a problem, we'll actually try to find domain experts to sort of guide the conversation. But do come to us in tag contributor strategy and we will help set it up. I think my, oh, sorry. Yeah, go ahead. I was going to say my favorite part about participating in maintainer circle is that as you said, a lot of these, they're awkward. They don't always have clear solutions or they're not easy to discuss in public without having to be very careful what you say and how you explain the situation and all that. A lot of it's a little sensitive, right? And what I really liked about it is we had small breakouts where I'd be with three other maintainers and whatever we said amongst each other, we all understood because we're dealing with similar things. And it was explicit understanding that we weren't sharing who said what or spill in the tea or anything. Like it just stayed in the group which made it feel very comfortable. Like I could just open up and say, yeah, it's hard when things are like this. I can't talk about it publicly because it just doesn't sound great, but it's still a thing I have to figure out how to respond to. And people were really great at giving suggestions for how to deal with situations like that. For conduct situations, for example. Yeah, and the maintainer circles really are a safe space to have these discussions. I mean, this is why we don't record them. This is why we don't share notes from them. It really is kind of a support group for maintainers to use to talk to each other. Okay, I'm gonna talk about one other thing that we're actually going on now and another sort of newish initiative which is the mentoring working group. So there are a bunch of mentoring programs supported by the CNCF. And the CNCF staff actually started this because they wanted an official place within the CNCF community for mentoring initiatives to live. I partly because they really want greater project involvement in this. The, I'm gonna go ahead and share my screen again. So this is a new working group. You can actually find the information in the tag constructure strategy repo with links off a lot of them into the mentoring repo which has existed for a while. This is an easy place for you to get involved from either of two sides. One is if you are a project maintainer, reviewer, sub-project owner, a regular contributor anywhere else, obviously we're looking for mentors and project ideas. One thing that's particularly going on right now that the mentoring working group folks wanted me to call out is that for the LFX mentorship program which is the one run by the Linux Foundation, project idea, mentee applications are due, well, project proposals will do this Friday and then mentee applications open the following week. So they're really looking for more project proposals and so this is a proposal for something in your project that could take a funded mentee with a stipend to have them work on it for four months. The, stop sharing here. I, as an example of what that went through is, for example, a year ago we decided that we actually needed better election software for Kubernetes and for a couple of other cloud native projects. And so we created an LFX project and recruited a terrific mentee who helped put together the scaffold of that election system in Flask which has continued developing as the electoral project for GitHub-driven elections for projects. So you can think outside of, obviously, recruit mentees for hacking on the main things for your project, for your project code but also think about things that you need around your project that you're never gonna get to yourself but you could motivate yourself to mentor somebody to do them. One of the things I've really found is that, yes, could I've written the code myself? I could have, but would I have? It's another question entirely, whereas if you're doing a mentorship and you have a schedule and deadlines and you have to meet with your mentee twice a week, then that actually makes sure that things happen. Now, the other side of that is, if you are a new contributor and not a project owner of any kind, please look at this because lots of mentor your ships, lots of mentorship opportunities come up through LFX, through Google Summer Code, through Google Summer Docs, through a lot of other projects. There are always mentorship opportunities all the time. And particularly I'm going to say for new contributors who are non-male, we try to promote diversity through these programs and we don't actually get as many non-male candidates as we would like. So if that's you, please look at the internship opportunities that are available. Dash, I had a question for you about this. If I'm a project and I'm trying to think, what could people work on? What's the experience and kind of skill level that I should be anticipating for most of the mentees? Yeah, and that's the question. Obviously, things that require lower skill levels, you're going to get more applicants, right? So if all of it requires is a freshman college knowledge of Python or Java, then you're going to get lots of applicants, but that shouldn't restrict you because the truth is you only need one qualified mentee, right? And honestly, sometimes people enter into this kind of knowing who the mentee already is, right? Because you have somebody who's a student who's involved in your project or somebody who otherwise qualifies for one of these programs because LFX and outreach, you don't strictly need to be students. And effectively using the mentorship to get them the time to work on the project, which they otherwise wouldn't have because maybe they need to look for a job. But go ahead and also file the things that require specialized skills, right? Because I've seen grad students in the application pool and if somebody's a grad student, then filing that project about, hey, now that Kubernetes supports full dual stack, we need to actually support dual stack in our security monitoring tool is not out of the question for a mentorship program, for a mentorship thing. The main thing about it is you need to look for tasks that are completable in a three to four month period and the most important thing is you need to look for tasks that you have a mentor for, right? That's your scarce thing, right? Is that generally, if you can find somebody who's willing to mentor a particular project, it's a lot easier to find them in T than to find the mentor. Yeah. Is a mentor helping just with project things? Are they also helping with how to do open source, get that type of stuff too? Often yes. Okay. Particularly when we end up recruiting students because they don't, you know, if you're going to, even like Cal Poly or IIT, they don't necessarily teach you how to contribute to a public open source project, right? They may teach you how to put your own stuff on GitHub, but they don't teach you how to participate in a public open source project that already has rules. And a lot of our projects, a lot of the cognitive projects actually have very specific rules. So that's often like your first week, right? This is how you do a pull request against this project. This is where the docs are. This is, you know, you need to have your docs tied to your pull request submission, et cetera, et cetera. I would say do plan to have regular meetings with your mentee, you know, since we're talking about like an eight week period for a lot of these mentoring programs, think about even more than once a week. Also Slack or other chat channels are wonderful. There really is no, I've been an administrator for a lot of mentoring things where I'm supervising the mentors and the number one reason for mentorship projects to fail is that the mentor fell out of contact with the mentee. Okay. And sometimes that's on the mentee side, but often it's on the mentor side because the mentors tend to be very busy people. Like you said, I can't agree more. There is something I was reading just the other day talking specifically about education and student teacher and family relationships. And it was shown like repeatedly that the more interactions happen the daily, the weekly, the monthly recaps of what's going on, the better the students actually did in school. So like you said, if it's an eight week program and you meet once every eight weeks, that's not gonna work out. Yeah. Now there are some other things. So one of the other things that we're trying to get out of this, and this is again, maintainers helping other maintainers and mentees helping other mentees is that the mentoring working group is going to create some forums, channels, whatever they need to actually figure out the format for this, both for mentors across all cloud native projects and for mentees across all cloud native projects. Because particularly again, we have projects of all different sizes, right? And yes, we have these big pools of people in say Kubernetes, but not necessarily in Cortex to take an example. And so being able to have your mentors share notes with mentors from other cloud native projects can really help. You end up having to deal with a lot of people issues if you're a mentor, because you're talking about students, other people who are new to the project and being able to bounce ideas of other mentors for advice, particularly if you're the only mentor for your project is super helpful. Same thing with mentees who are looking for and potential mentees who are looking to sort of break into contributing to cloud native. It can be really useful to collaborate with other mentees and share notes. And on top of which to get sort of all this in there, keep an eye on CNCF announcements and Twitter, et cetera, because we're going to have a survey of people who have mentored for CNCF projects across these various formal programs. Because we wanna start building a body of advice and shared knowledge that's public for mentors. Yeah, there was just a question in chat that I feel is slightly related to this actually, which is, you know, when people join a Slack channel on a specific project and they ask, how can I contribute? And they mentioned, I love this, a hello world on how to contribute. This is actually content that I produce for my project Porter. And it's been wildly successful and I have it to do, but if anyone would like to help is to promote this concept at the tag level as a general thing that projects can do. Oops, sorry. Yeah. Let me, I'm gonna send a link of just what we've done in Porter here, but we've created a tutorial page that walks you through everything you need. So say it's Friday night and you're super inspired and you're like, I'm gonna work on this project. And to be honest, no one's probably around on Slack to chat or like help you out or give feedback or anything. So this tutorial, the concept is regardless of the project it should give you enough information so that you can get started and get familiar with working on the project. So for example, mine here walks you through how to clone the repository, how to get any necessary tools that you need to have a working development environment helps you navigate through the code a little bit, understand what are some common commands you're gonna run with the build scripts like what are the make commands? Like make build, make test, what should I be doing? And then it walks them through making a common type of change to the code base. So even if there's no good first issue at the moment, they have something that they can try in practice going through, okay, I'm going to add a new command to the CLI or a new endpoint to this API, figure out how to test it, build the code, try it out myself and go, okay, this is everything I should do. Now here's the checklist of what I should run before I would submit this as a PR if this was a real issue as opposed to practice. And it's really helped my project, one, writing all this down is great because otherwise you're trying to like brain dump it haphazardly for each person who asks, which is hard. And then it's timely, right? Because they're gonna be asking you for help for a lot of us off hours. And this is really great with time zones so I can have someone who's 13 hours off from me benefit and be able to contribute without kind of being at a disadvantage because we're not able to talk synchronously. So I really encourage projects to have something like this. And if you're interested, we need help taking something like this that Porter has and putting it up at the uncontribute.cncf.io is an example of what people could create for their own projects. Okay, with all that, we're almost the end of our time. So let me go ahead and share how to keep in touch with us for all of these initiatives and more. The, so, so there we go. So Slack channel, obviously first landing spot, tag contributor strategy Slack channel on the CNCF Slack is a good way to find us. There's a mailing list. And like I said, we use that almost entirely for announcements of upcoming activities. Also for announcements of things like new guides, new documents, new templates that we've put up. There's a talkify link that filters all of our meetings are on the CNCF public calendar, but there's a talkify link that actually filters it to the specific contributor strategy links. And again, somebody said this earlier, but for most of our meetings, we tend to leave 20 to 30 minutes at the end of every meeting for people who work on projects to just drop by and ask questions, right? So if you have a governance, if you're overhauling the governance on your project, feel free to drop by the monthly governance meeting and just put yourself on the agenda. Also the maintainer circle Slack there. And again, you can find all of these links off of the dedicated link blog post. So if any of what we said interested you, you wanna get involved in it, you need to use it, whatever it is, those are the places to get in touch and find us. Awesome, thank you so much. I shared that to the respective chats, so please be sure to check that out. I think we might have time for just one more question if anyone wants to raise up anything in particular. Otherwise, really do want to thank y'all for stopping on by. No, it was a long drive to get here, but I really appreciate everyone was able to make it. Great, thanks for having me. I'd also make a UDP joke right now, but some of you might not get it. Thanks for facilitating Taylor, we appreciate it. Absolutely, always fantastic to chat with y'all. I really appreciate you making the time. Thank you everybody for joining the latest episode of Cloud Native Live. It was wonderful to learn from the Tag contributor strategy team. Hope that you are able to take some of these lessons and apply them to your own lives, teams, jobs, et cetera. And we'd love to see you around the Cloud Native water cooler, so to speak. The questions and interactions from everyone was fantastic today. Thank you so much for joining us. We hope to see you again soon. And yeah, keep your head in the clouds. Thanks everybody. Have a good one. Thanks everyone. Thanks.