 Okay, hi. So my name is Madhav. I'm one of the tech leads for Sick Contrabex and we'll do a round of intros, but we are gonna talk a little bit about lessons from community growth, sustainability, and a few things we've learned along the way, as we've seen in Contrabex. So who are we? As I said, my name's Madhav. I'm one of the tech leads of Sick Contrabex. I have with me Priyanka and Kesslin. So Priyanka, do you wanna? Hey, everyone. My name is Priyanka Sagu. I work at Suze as a Kubernetes Integration Engineer and I'm also one of the tech leads for Sick Contrabex. And I'm Kesslin Fields. I'm a developer advocate at Google Cloud where I focus on GKE and open-source Kubernetes and I'm also a co-chair of Sick Contributor Experience and a CNCF ambassador. All right, so before we start, right? Just a call to help. We need help migrating proud jobs to community clusters. If you're interested in that sort of thing, if you're into infrastructure management, development, migrations and all of that, check out the issue that's linked there. We definitely need all the help we can get. So that being said, this is the title of our talk. It's kinda long. So we thought it might be a good idea to structure the talk around the title itself. So that being said, let's start off with what is Sick Contrabex? One of my favorite things, Madhav. Thank you. So first off, one of the first questions anyone asks about getting involved with Kubernetes is like, how do I get involved? Where do I get involved? And an important thing to understand about Kubernetes is that it breaks down its work into special interest groups, which Contrabex is one of them. There are many. And then work is further broken down into sub-projects. So the way that Contrabex gets its work done is through these sub-projects. And we're gonna list them. There are a lot. I went to two other maintainer track sessions today and they had like four each and that was just all they talked about. We can't do that. So we have the community sub-project, the community management sub-project, the contributor documentation sub-project, the dev stats sub-project. So community and community management, community is all about the overall community repo, community group documentation operations, management manages operations and policy for upstream community group communication platforms. Like, yeah, we'll get to it in a second. Rights and maintains, the contributor documentation group writes and maintains documentation around contributing to Kubernetes, also one of the first things that people ask about. And dev stats is, I feel like little known, but a great resource for understanding the Kubernetes community as an at a glance through numbers. We also have the election sub-project, which is a new sub-project and oversees running elections in the community. It also maintains documentation and software that is used for elections. It can be used beyond Kubernetes. I don't know if it actually is used by any other projects, but it can be. We also have events for contributor focused events like the contributor summit that happened here at KubeCon and happens at each KubeCon. GitHub management, which does all kinds of things with managing how Kubernetes works on GitHub. Kubernetes is huge, so that's a huge job. Mentoring, helping new folks get involved with the project, lots of things that we have to do there. Slack infrastructure. Of course, the Kubernetes community operates on Slack, so there are all sorts of tools and automation as well as moderation for Slack. And we also have the contributor comms group, which manages the Cades contributors account on Mastodon and Twitter, and all sorts of other ways of communicating with contributors, such as blogs and emails. Next. Let's talk about code quality, stability and security. SIG Contribute helps there as well. We have the sub-project called GitHub administration that could collaborate with other different parts of Kubernetes project, security response committee, code of conduct committee to handle security incidents that take place in our GitHub infrastructure just in general and around the community. Post this, the admins also provide direct feedback. To GitHub, we have a monthly meeting with the GitHub team, so we provide direct feedbacks there. Contribute also helps other SIGs if they are in need of legal compliance reviews for their design document. For example, we recently have one from SIG testing, where we needed to work with code of conduct committee Kubernetes, CNCF, and also get some advice from GitHub. Moving forward to non-code contributions, we recently revitalized initiative on non-code contributions. We have no higher prams in the room. Thank you to him for doing all the great work there. Folks working to make non-contributions more actionable and developing generalized takeaways for CNCF project as a whole. There is a meeting running in that. We usually get notifications in our SIG Contributes channel, so look for them. I think we have a schedule here. It's on second and fourth Tuesday of each month. And if you need more help, please reach out to us in SIG Contributes. Oh yes, community growth. Let's talk a little bit about it. I mentioned earlier that GitHub is really hard for us to manage because the Kubernetes community is ridiculously enormous. And this is an example of that. This is a graph that I pulled from a report from 2019. And this just shows all the way from 2014 when the project first started to kind of exist. And you can see how incredibly fast that growth curve is from 2014 to 2019, where it looks like it ends around 35,000 contributors in 2019. Today, judging by DevStats, when I went to it two days ago, we have around 83,000 contributors who are making around 3.9 million contributions. And all of that, by the way, is reviewed by only like 6,000 reviewers. So you can see that we have scale problems. Let's talk about how we address those. So we have some automation and tooling around that to embrace this growth we have in our community and we are continuously working on improving our tools. These tools we have for managing our membership or membership management all the way to our collaboration communication tools. First up, we have Perigolos. This is a tool we use to manage our GitHub or our management. It is for all our new membership or a request as well as managing all our GitHub permissions across the SIGs. So how does this work? Just a brief diagram here, we have it's similar to what Kubernetes does. We have our declared members declared in a YAML file format and Perigolos take that as a source of truth and tries to match our declared configuration in our GitHub course. Recently, we made some progress, made some improvements on our Perigolos tooling. We also added functionality to manage what GitHub teams people are part of. We can manage that functionality as well as with Perigolos now. Big shout out to Nigel. He helped us a lot with bringing some automation for us to automate all our Zoom meetings that we have across all our SIGs to bring automation to upload them to YouTube. And if you're interested in learning about that automation, it's another place we would love to have help. Yeah. And reach out to us and see what we can do next. Another one we are currently working on is a mailing list migration functionality. Currently, we are moving away from our Google mailing list groups to bring them under Kubernetes mailing list. So we are working on some functionality to improve our already existing groups tooling to add some features to migrate. A huge list of members we have from one mailing list to the destination mailing list. We outgrew it and we had to get something bigger. So I think based on that, it's pretty evident that Kubernetes community is growing at a rapid pace. It's already pretty big. It's starting to grow even more. So as and when that happens, past constructs of what we had to manage new contributors to help new contributors, terminologies and concepts start becoming oversaturated. Terminology starts becoming overloaded. So recently, previously we had a Slack channel on the Kubernetes Slack to help new contributors and new members, but that sort of became overloaded in terms of what it meant. So we did like a whole overall of what our contributor-centric Slack channels look like. So Bob Killen, who was also one of the chairs for Contrabex and a steering committee member did a lot of this work, migrated all of them over to the new channel, added automation to let people know what these channels are for as and when they join them. So as and when we talk, you see like a theme emerge. Whatever work we do, we do it, but then we back it up by automation so we don't have to do it again. So this way we have a documented and auditable way of doing things and making sure that if things go wrong, we know how it went wrong, why it went wrong, and in the future, how we prevent it from not going wrong. So that's community growth. We also have a huge aspect that we are spending a lot of time thinking about around community sustainability. So in the Kubernetes project, as and when you contribute, you can apply for org membership. And the way org memberships work is you send in and you open a GitHub issue as your application and then you just need sponsors from the people who have you worked with who are already org members. And then once you meet those requirements, a PRS created and a bot sends you that org membership invite and that gives you elevated privileges, the Kubernetes GitHub org. But now more than 50% of those org members that we have right now are inactive. They haven't been active for years. So that means elevated org privileges lie in the hands of people who are not yet active. So in order to sort of try and improve that situation, we are doing a two-step solution. The first step is how do we define better requirements for org membership to begin with? And then finally, how do we identify and provide a consistent way to handle stale contributors or people who moved on to other projects or who've become emeritus approvers and emeritus reviewers and so on. So we recently updated our org membership requirements to be more specific, to be more current and to adapt better to our decent situation. So what that means is we updated our inactivity period which was we defined our member to be inactive if they were inactive for 21 months. Now we have defined them to be inactive if they are inactive for a period of 12 months. And criteria for what constitutes an org member is also more well-defined now. Subsequently, as I said, whatever we do is backed by automating that process. So we're working on automating, auditing all of our Kubernetes org members. So this particular piece of work done by Nabarron, so he's also another chair of Contrabex. Scrapes, DevStats, Scrapes, GitHub, collates all of these insights and tells us that, okay, we have X, Y, Z. These are the set of folks that have potential of people to reach out to and remove from the org altogether. Again, the verification of that list is done manually because automation is never trusted, is never full proof, and these are things that we don't wanna get wrong. Awesome, so as I said, the way you apply for an org membership is to create a GitHub issue and we have roles in the community called new membership coordinators who sort of evaluate these requests and create pull requests to add you into the org. Recently, we've had a few new membership coordinators and the process of all of this was sort of institutional. It was in our own minds till now. So Jason Braganza has done a lot of work in documenting that process for new people who want to help out with this sort of work in the community, so thank you so much, Jason. That's really amazing. Okay, so yeah. Another thing I wanna talk about with community sustainability is something that's very important to me. Making sure that contributors are recognized for their work. One piece of that in Kubernetes is named roles. So the benefit of having named roles within an open source project is that it's a formal recognition of someone's effort and skill and time that they've poured into this project. It formally gives contributors ownership of certain areas of the project. It can also, since they have a title, they have connections at the same level, kind of within the contributor ladder. It gives them other avenues to seek help when they need some help in the project. And it means that once you become a leader of a certain area, you need to train the next person who's gonna come after you. So that role gives you a responsibility to train others and pay it forward. So there's a lot of great things about implementing roles. And I am also a sub-project lead of the contributor comms sub-project, contributor communications. And we did this whole thing where we spent months working with our regular contributors to decide what roles we thought we needed within our team. So we established several different roles. The one that I really wanna point out is the sub-project lead role, which the special interest group for contributor experience, which was on the last slide, actually. This little issue here in the corner is that we made it an official part of the special interest group's governance that sub-project leads are a role that exists within our SIG. The other ones are just kind of ones that our group came up with. They're not officially mandated by the SIG, but we did it anyway. So roles are a great thing to help with contributor sustainability. Awesome, so now that we have an official role called sub-project lead across all SIGs in the Kubernetes community, so the PR that you saw was by Nambarun again, who was one of our coaches, and a Kubernetes steering member. Now that we have things like that in place, we are in a better position to understand where Kubernetes is right now and where it's headed in the future. And a few very interesting patterns start to emerge as we sort of think about this a little bit. So reflecting that on that part a little bit, right? So in any open-source project, open-source projects are always in a need of help. No matter how many people you have, they always are going to need help, which is what makes them really amazing. It makes them a great avenue to be a part of, it makes them a great avenue to have a sense of belonging in. Now the way you get new help is you do outreach or folks find you in an organic manner, however it may be, so you have new contributors entering into what is called a contributor funnel, and project maintainers are happy to help new folks in the way they best know how to and provided what their bandwidths are like, because project maintainers aren't always free and available to provide all the help that a person might need. So they help out as best they can. And eventually these new contributors become what are called as episodic contributors, so ECs, right? These contributors are folks who've crossed the threshold of effort. They've put in the effort, they've made certain contributions, and these are the people who are potential maintainers in the future. So these are the people who need the help to grow from where they are to become maintainers in the future. And ideally, if that sort of cycle continues, we are good, but that is not what we see happening. And as a result of which, episodic contributors who are, by the way, potential maintainers, they've shown that they are capable of doing the work, they've put in the hours, they've put in the work, and now they've hit a roadblock, because after a certain point, after a certain number of contributions and you wanna work on bigger things, you need that much more help. But since that is not happening, this sort of start to leave, right? And these potential maintainers you have, you don't have them anymore. But we still need new folks, so let's do more outreach. But the thing is, maintain a bandwidth is still constant. That still has not increased. So we have all these new folks coming in, we have the contributor funnel filled with new contributors, but the maintainer bandwidth is still constant while the episodic contributors are also decreasing. And because Kubernetes is huge as it is, the maintainer bandwidth is stretched thin and new contributors also start to drop off, because the maintainers aren't able to help them out, the maintainers aren't able to adequately help the episodic contributors out, so we don't know what's going on. And this isn't just some theory that I'm making up. This is from actual data, right? And as Katherine mentioned, we have DevStats. So DevStats is a great source to see all of these contributor statistics of any project in the CNCF landscape. So you see two lines there, I don't know if it's very visible, but one of the lines is for new contributors year after year on the Kubernetes project, and one of the lines is for episodic contributors year after year on the Kubernetes project, and both are on a decline. Okay, so the solution to this is that we need to spend time nurturing episodic contributors more. It is better for the project, it is better for the new contributors, because now you have more people to help them out, which again is better for the project. So we've tried one-on-one mentoring in the Kubernetes project, we've had one-on-one mentoring hours as a mentoring sub-project initiative in the past, but one-on-one mentoring does not scale. Kubernetes or any moderately large open source project cannot afford to have one-on-one mentoring as it's only way to help new people grow, it does not scale. So we started to do mentoring cohorts. So cohorts started off about a year and a half ago. We started off with a couple of sub-projects. All of us standing here became leads of counterbecks through a mentoring cohort itself, which is kind of amazing in my opinion. But since then we've had so many of the mentoring cohorts happen, we've had a mentoring cohort for six CLINC gaps, we had a mentoring cohort for external DNS, we've had a mentoring cohort most recently for Customize, and all of these mentoring cohorts have resulted in new reviewers and approvers being added for that project. So this is a proven method for your project or your sub-project to grow new people in, and counterbecks can help you do just that. So I would really highly encourage if you are a six sub-project lead, or if you're a person maintaining a sub-project in a SIG, and you are one of the only people doing it, reach out to counterbecks, help us help you start a mentoring cohort, and let's grow more people in your project. So this is a quote from Natasha Sarkar, who is a CLI customized maintainer. This is from the latest mentoring cohort. So she said that they had five active participants, and one of them is on the way to become an official maintainer in January, which is amazing. Natasha also had some really good insights as to what worked well for them and what didn't. So one of the things that she said that really stood out to me was, an open admission of a need for help went a long way for that project. So accepting the fact that you need the help, your project needs the help of new maintainers, and the need for newer reviewers and newer approvers, set the tone for when they started this mentoring cohort. Again, as a community grows, so does the undocumented context in it. So that can prove to be a huge barrier for folks who hope to grow in the community, because you have discussions with people in person, you have discussions on Slack, which just get lost at the end of the day, and crucially technical points are lost. So as a result of which it becomes very hard to help document this and create sort of what is known as common knowledge in the community. So as part of that, we try and have avenues to document some of this undocumented context that proves to be a barrier for contributors. So we have what is last week in Kubernetes development, which is a newsletter that goes out. It's part of the Contravex comms that Kastlin leads here. Recently we also started an interactive Getting Started with Kubernetes course online. So you can spin up a GitHub code space with the Kubernetes code base. You can run unit tests in it, get familiar with how the CI works right in your browser itself. You can get familiar with how labels work in the Kubernetes community, how you can apply labels, how you can interact with the GitHub bot, all of that as an interactive course on the kubernetes.dev website. So we don't need to do sort of new mental, new contributor workshops anymore. All of this is again documented and automated. Yeah, and again you have contributor summits all across the globe, which is again a great way of sharing knowledge. All of these summits now, every room that a session is in has a note taker, and all of these notes are then put back into the kubernetes.dev site. So all of it is again available for people to go and take a look at. And that's it. That's all we have for you today. That's all the updates we have for the counter-back session. Thank you so much for listening, and if you have any questions, you have to answer it. And if you do have any questions we would ask, if you could please go over to the mic, even though it's very far away from many of you, most of you. There are people watching online and this is recorded, so if we can get them on the mic, that would be great, if you don't mind. Though I highly encourage you to ask questions, and if you're too afraid to go all the way to the mic, I will repeat it for you. The first question is actually, can you go back to a slide so that I can ask my question intelligently? Of course. The one on different types of project roles. I've been thinking about this a lot in terms of how we can take time back from maintainers, doing things that are not special to their own skill and expertise and role, and I'm curious if that's how this is working in practice, or is this just taking on additional overhead. So the idea that maintainers are often doing a lot of extra things that don't necessarily require their specific knowledge to maintain the code base, but if we can kind of portion off some of those activities into other types of roles that can pick up and say do issue triage versus leaving that all to the single maintainer. And so when I saw this slide and thinking about how you're encouraging different types of roles, I'm curious if that's emerging from the immense overhead that is the Kubernetes broader project, this needs these other types of functions, or are you able to extract additional labor being done by maintainers that doesn't have to be done by maintainers? Awesome, I'm excited about this question. So this was the slide, right? So the way that we came up with these roles within contributor comms, like I said, we took months just talking with our contributors about like what work are we doing right now and how could we organize that? So it wasn't something that we immediately knew or understood about our work, but over time we kind of figured out, well we have these tasks that are all on social media, so we'll put those all in a bucket. We have all of these tasks which are regarding working with the blog and that's a big enough chunk by itself that it's different from social media, it involves working with another group within the project, it should be its own bucket. All of our automation, most of the team does not know how to manage, many of our contributors are non-code and they're not very familiar with the types of code that are used within Kubernetes and honestly our automation has nothing to do with the rest of the code in Kubernetes. We've just kind of figured things out that worked for us. So maintaining that code, understanding it and also figuring out new tools when we need them, also a separate role. We did also have another role that isn't on here anymore that we've actually deprecated since we did this whole project which was the events lead role because the SIG contributes, of course we do the contributor summits, we used to also have meet the contributors events that would happen regularly and like an open meet the contributor community call, I don't remember exactly what it was called now because one of those moments, but we used to have more events where people could meet the community and so we had someone specifically dedicated, hey, make sure that that event is happening, that it has everything that it needs, that we are communicating that that event is happening to contributors but we got rid of a lot of those events so we don't have that anymore. Now events have their own events lead that can talk to us if they need comms. Yeah, so that's kind of how we figured those roles out. Hopefully that's helpful insight. We have another great example from the community SIG docs. They have done a great job creating named roles. I think they have a role called PR triager, something like that and they found great success in that role and out of that role a new role came up that that is issue triager, I think something like that. So yeah, a lot of SIGs are doing this trying to chunk out the major these kind of grand tasks and put them into a named role so that people who are actually doing that task are recognized under a title and yeah, that's helping us. So I have two points there. First is sort of unrelated. So Thursday we have Meet the Kubernetes contributor community thing that's happening. I don't remember which room exactly but it's happening on Thursday. So all the maintainers of all the SIGs and all the contributors are gonna be there. So stop by, talk to us, we are also gonna be there. Second point is as initially we showed there are multiple sub projects under each SIG. Now the thing with sub projects is that yes, sub projects divides what work needs to be done but the maintainers of these sub projects often overlap with multiple of them. So if I'm a maintainer of sub project A, there's a very good chance I'm a maintainer of sub project B, C and D as well. So the idea with sub project leads was that if we can provide a named role for these sub projects and this is by the way work that Staring did for the most part, Staring committee. If we can provide a role and one of the benefits of doing this is if we can provide a named role then there's a clear person to go and talk to apart from all the formal recognition you get there's a clear person that you can go and talk to if you have questions about these things. And if I am a maintainer for sub projects A, B and C and let's say a fellow contributor of mine is a project lead of sub project A then I don't need to be the point of contact for that because that person probably has way more context than I do and I'm just listed as a maintainer there because of past historical context. So it's sort of like offloading a little bit offloading and also better defining. So yeah, another question? Yeah. Love the work that you guys are doing. So Taylor Donzall, Jonah Bacon and myself we recently ran the zero to merge cohort and we took the first group through and we want to continue to do that 365 I think we're in the first cohort. We want to continue that into 2024 but there's another wave coming that we've started to think about and would love to collaborate with you around maintainers. How do we build? So zero to merge is about building the funnel of new contributors and the second wave is how do we build from that pipeline the path to maintainer and a path to maintainer is a whole set of steps which you guys are deep in. Part of that is giving the contributors the confidence that they can eventually become maintainers because you see those ECs that you call them sort of drop out over time because they either don't know how to continue and stay engaged and evolved and hopefully stick around to become the maintainers. So the confidence that they should and can actually get there that's what our next cohort around in this maintainer bootcamp. I don't know if that's the right word but this maintainer bootcamp is how do we take those contributors that have shown promise and then guide them with, you know with I don't think it's gonna be one on one but it's like you did the maintainer cohorts to match them up and sort of show them the path give them the confidence to stick around. So we'd love to collaborate on this and we're thinking about launching it in 2024. Oh, that's awesome. Let's talk for sure. Yeah, I'll connect with Taylor on that. When he talked about that program this morning I was like, ooh. Any other questions? We have a couple more minutes. Dumb questions, welcome. We are SIG ContribX. Our whole thing is helping people do stuff that they want to do, helping contributors do fun stuff. Awesome. You can always find us obviously right here now but you can also always find us on slack.gates.io if you're on the Kubernetes Slack in SIG ContribX or ping us directly. We're always happy to help anybody who wants to get involved with the project. Yeah, and get involved with SIG meetings if you're trying to get involved with Kubernetes you can find them on kates.dev slash calendar. Scan the QR code and leave feedback if you have any. Also happy to talk whenever feel free to ping any one of us. Okay, have a good rest of the conference. Thank you. Thank you for attending.