 Hey, everyone. Happy Friday, and welcome to this really early morning session on contributor experience. And what we do in a SIG where we almost have fun with people in the community. Moving ahead, I'd like to introduce all of us. Kathleen, do you want to introduce yourself? Sure. Hello, everyone. I'm Kathleen Fields. And I am a developer advocate at Google Cloud, where I focus on GKE and open source Kubernetes. And I'll be telling you more about my work in the open source project today. Madhav. Hi. My name is Madhav. I am a software developer at VMware. I work on open source Kubernetes things. And I help out with Contravex, wherever I can. And I'm Nabarun. I'm a senior engineer at VMware. Mostly work on open source projects in the day and some size projects in the night where I don't use Kubernetes. And I contribute to some areas in the community and I'm a steering committee member. So let's get started. So let's talk about how big is the Kubernetes community or who constitutes the Kubernetes community. So one of the figures that I want to really talk about here is the number of contributors that we have. We have almost like 73,000 contributors and it's growing year on year. In the last one year, we have had 10,000 new contributors. These are unique contributors who have ever touched the code base. The number of active contributors keeps on varying as we change the definition. And we are the number six OSS project by developer activity in the ecosystem. These are based on numbers published until the start of this month. Moving over. Who are we? And we here up here are all members of SIG Contributor Experience. We'll be talking more about what the Special Interest Group for Contributor Experience does. The last slide, by the way, was a picture of our contributor summit and all of the folks in the contributor community. So while we're focusing today on the Special Interest Group for Contributor Experience, we all focus very much on our contributor community. So everyone within the project, whatever they may work on within Kubernetes, our goal is to serve them, as we kind of say on the slide. So our goal is to make sure that we're creating useful processes and making sure that our contributors in the community basically have a good time. Over time, our community changes, as we said. It's always growing. So we always have need for new processes for contributors to be able to do their work more efficiently and more smoothly. Also, sometimes we grow out of processes. So we need to make sure that we are retiring old processes that don't work for the community anymore and replacing them with new ones. So we cover a variety of different areas that we'll go over here in a minute. But first, I want to mention how you can get involved with us a little bit, where you can find us. If you are interested in joining our group, you can find the various SIGs and working groups on kates.dev. kates.dev is our contributor website. So we try to post a lot of contributor resources and information there. So check that out for our list of groups of community within our community. And for the meeting list, so one of the big recommendations, if you're one of those folks who's trying to get involved with the community, or if you've ever been one of those folks, as we all have, you've probably heard a million times, join us at our regular meeting. And you're like, where do I find these meetings? We do have a list of all of the meetings that are happening within the Kubernetes community, not just a single SIG, but all of them kind of in one place. And you can also find that on kates.dev. So very useful website. So within SIG contributor experience, like I said, there's a lot of different areas that we focus on. It's kind of nebulous to say we help our contributor community do the best work that they can and do it smoothly. So here are a few of the areas that we focus on. And really, though, the way that we accomplish this is with sub-projects, which we're going to cover in a little bit more detail. So considering the scope of SIG contributor experience is cross-sig, and we have a gigantic amount of work that we do, we try to do this efficiently by breaking our work down into what are known as sub-projects. And each sub-project has an amazing set of contributors who take it forward, define roadmaps, help new contributors, and so on. So skimming over a list of our sub-projects before we dive deep into each one of them, we have the community sub-project which, as the name suggests, owns and manages the overall community. We have a Kubernetes community repository, and this is what the sub-project helps manage, take forward, even deprecate a few things. Then we have community management, which manages, defines policies, changes policies for the upstream community group. And we have contributor documentation, which is one of my personal favorites, writes and maintains documentation around contributing to Kubernetes. So this involves things like, how do I run tests? This involves things like, how do I onboard new contributors, and so on. Then we have contributor comms, who we have Castlin for here, amplifying the success and distributing information on Kubernetes contributions, which is essential considering the scale of the Kubernetes project and the outreach we need to get the information to where we want it to go. We have events which creates and plans events. We have GitHub management, which manages and controls GitHub permissions for repos. We have Nabaroneer, who is also a GitHub admin for the Kubernetes project. We have Mentoring, which is probably one of the most crucial sub-projects we have as of now, which oversees and develops mentoring programs. We have Slack infrastructure and elections, which is our newest sub-project that people soon talk about. Okay, so before I talk a little bit about Mentoring, we have what is known as the contributor ladder defined in the community. So we sat off with non-member contributors, so these are any folks who have just come into the community who want to get started. From non-member contributors, you contribute, you help out, and then you can become a member of the Kubernetes org. What this essentially allows you to do is, it allows you to move ahead in your contributor journey to becoming a reviewer, to becoming a reviewer who is essentially reviewing PRs, review code, non-code doesn't really matter, not just PRs, you are also helping review documents, you're also helping review policies which eventually make it to one of the GitHub repositories that we might have. Beyond the reviewer, we have the approver who is responsible for approving certain changes, who has the final sign-off in terms of, okay, this is a valid change, this makes sense for our community, considering what's happened in the past, considering what we want to do in the future, and considering where we are as of now as well. So that's the approver, and then we have the sub-project owner. These are folks who set priorities and approve proposals for sub-projects. They are tasked with leadership responsibilities and for the entire repository essentially. So in the mentoring sub-project, we have a few programs and initiatives. Firstly, and this is really exciting, we have group mentoring cohorts. So these are semi-structured group mentoring initiatives with a small set of people who are paired with existing reviewers or approvers from a particular group. Very interestingly, in the past month, we had six CLI and SIG apps kickoff group mentoring cohorts, which was a really big milestone. And thank you Paris, Atharva and Purneshwar for helping drive this forward. We need more SIGs and working groups to do this essentially. So if you are a SIG or a working group or help maintain a sub-project that would want to run one of these group mentoring cohorts to foster the next set of reviewers and approvers for your project, please, please feel free to reach out to us on the SIG Contrabex Slack channel, email list, wherever you see fit. We are more than happy to help out. And then we have shadow programs, which are scalable apprenticeship programs. So most famously, the release team ran really, really well-defined and well-run shadow programs. And most recently, SIG Contrabex also is running a shadow program. All of us are shadows here standing in front of you. So if your SIG wants to run a shadow program, we have some experience, please reach out, run shadow programs, foster the next generation of contributors. We also defined a third-party mentorship coordinator role recently, who essentially helps coordinate what third-party mentorship programs that exist. So Google Summer of Code, LFX, Outreach, so on and so forth. But these programs can only be done if we have sufficient help. So, you know, help is always wanted. So if you are willing to coordinate some of these efforts, reach out. You know, like, just reach out regardless. Doesn't really matter. We are nice people. A big win was we worked on hands-on labs for onboarding new contributors. So this wasn't introduction to Kubernetes, but this was introduction to how to contribute to Kubernetes. So things like, how do I run tests on changes that I introduced into the Kubernetes project? How do I see these changes in effect? How do I test these changes out? And so on and so forth. And these are sort of tips and tricks that existing contributors and maintainers have used. And these were compiled by our LFX mentee, Harshata. So thank you, Harshata, for working on this. And please, we need more approvers and sub-project owners with bandwidth to be able to assist in these mentoring efforts. So anything at all, if you are available, if you are interested, we are more than happy to help out and find a way to move forward. GitHub management, Kubernetes loves GitHub because of which we do cool things like this. We have Prow, which is our internal CI-CD system, CI system. And you can do, we didn't know, Nikita is commenting slash Woof here. This is one of my favorite things. So our GitHub management project manages and controls GitHub permissions for repos and groups. It essentially helps define a consistent contributor workflow. And it works on streamlining org and team membership, which also is responsible, which leads us to our next role, which is the new membership coordinator role, which is essentially, these are friendly faces in the community who bring in new folks to the GitHub organization of Kubernetes, Kubernetes 6, and so on and so forth. So Nabarun here is one of the new membership coordinators. In GitHub management, we've been trying to improve the experience of auto-closing issues. So in Kubernetes, we auto-close issues that are stale for more than 30 days without any activity. We auto-close PRs as well, but this leads to, understandably, leads to some friction in terms of, why was this closed? What can we do better? And so on and so forth. So we've been trying to improve on that. Part of that was adding support for closing issues as not planned and better handling support requests. One of the biggest things that we're working on right now is the Approve to Plugin. This helps us granularly approve code changes rather than doing a blanket approval for each directory. This lets us approve on a file level. So helps us delegate reviewing and approving better, helps us delegate reviewing and approving better, helps us handle cases such as how do we approve dependency changes, how do we approve root directory changes, and so on and so forth. And then finally, one more thing we're working on is how do we automate team repo permissions through our in-house built tool called Periwodos. Awesome. So moving on, we have community management. Kastan is going to talk to us about that. I sure am. So there are a variety of ways that we kind of keep the community moving together and visible. So any contributors that want to get involved with us, you should certainly check out our mailing lists. We mentioned the calendar earlier. So on kates.dev, we have the community calendar where you can see all of the meetings going on throughout the project. We also have our infamous, perhaps, KDEV, which is our mailing list that we send messages out to basically all of the active contributors to. So join KDEV if you want to see the chatter kind of going on in the contributor community on email. Of course, Slack is our primary method of asynchronous communication, or synchronous, I guess, our primary method of synchronous communication because we mainly use it for chatting. So if you're ever interested in a special interest group, definitely go find them on Slack. Not really mentioned here, but I wanted to mention it anyway. We recently migrated our mailing list. So it has been updated and is better than ever. Highly recommend joining. Another thing I wanted to mention is YouTube. If you've ever been to any of these contribution meetings or been told that you should join a contribution meeting, you've probably heard that they're all recorded and that we share all of the work that we're doing publicly. So that's what we're talking about with YouTube. So every community meeting that we do, we record it. We have a small group of folks who take care of making sure that those get uploaded to YouTube. So if you ever want to find something, you ever miss something, everything is up there as well. We also have a community repo. As with any open source project, we do a lot of our work in GitHub. And that's not just for code contribution. That's not just the Kubernetes project itself. Here in contributor experience, a lot of our work is documented in GitHub as well. So definitely check out the community repo. It's fairly large. It has a lot of different areas in it. I've learned a lot by just exploring that repo. We use Zoom primarily for our meetings. So I mentioned that we record them. We record them over Zoom and we host most of our meetings over Zoom. We are always looking for help to automate the publishing of those videos to YouTube to make that process smoother. So if that sounds like something you might be interested in, let us know. We have discuss.kates.io, which is a community forum where you can talk about all sorts of things Kubernetes related. And I also mentioned in here that we have some folks who help to make sure that the videos from all of our meetings get into YouTube. That's one form of moderator. We also of course have our Slack. Like I mentioned, we need moderators in there. So there are moderator opportunities all throughout the community if you're interested in helping to moderate discussion in the community. Specifically, I want to talk a little bit more about YouTube moderation. So we have our Kubernetes YouTube channel and it has separate playlists for special interest groups, working groups and user groups. The meetings from all of those different communities are organized into these playlists. So that's a lot of recordings to deal with and a lot of organization that goes into it. We also do recordings of regular events. We mentioned the events group. So one regular event is the Kubernetes community meeting which is a monthly thing-ish. Not this month because we're at KubeCon. We also do office hours and we like to do meet our contributors sessions where we'll regularly have prominent contributors or any contributors on to talk with the community and answer questions. So we record all of these things. All of this adds up to a lot and it all needs to be somewhat organized and somewhat checked to make sure that it's not the wrong thing or something. So moderation is really important for us for our YouTube videos. That being said, it's not as heavy of a lift as you might think it would be. YouTube admins, like there's not a lot of video editing that you're gonna have to do. A lot of it is making sure that we collect all of these files and get it onto the YouTube page, checking for anything particularly egregious and maybe working together to make sure that those parts get edited out. But it's a relatively few simple steps. There's not as much really intense, complex time involved in it like you would have to do with editing as you might think. So if you're interested in YouTube administration we could really use some help and would love to have you. So do let us know if you're interested in being a YouTube administrator or admin or moderator, all of those. And I am the sub-project lead for contributor comms. We mentioned this a little bit earlier when we were doing the overview of some of the sub-projects. So in contributor comms our focus is on making sure that the contributor community knows what's going on and also that folks externally can see the awesome work that contributors are doing. The Kubernetes project of course has our regular releases. We talk about the features that we've done but there are all sorts of really awesome things that contributors are doing both during release and between release cycles. So we wanna make sure that people are being recognized for their awesome work and that contributors know about contributor events like the community meeting and changes that are happening to processes that might affect contributors. So we do a lot of work around that. One way that we communicate is with Twitter. If you haven't already, please follow the Kate's contributors handle on Twitter. We're doing a bunch of tweeting during the conference. We actually have a way to schedule tweets onto that account, not really schedule, to get tweets onto that account using GitHub. Like I mentioned, a lot of contributor work is through GitHub so we wanna make our methods of communication as accessible to our contributors as possible. And our goal with this Twitter account is for any contributor to be able to submit a tweet to be posted there. So we have a GitHub-based process where you can submit an issue, it'll turn it into a PR and once that PR gets merged, it'll be tweeted. So that's pretty cool. We also have a new tool called Buffer which we're using for more complex requests for tweeting. So if you get involved with the group, we can get you familiar with that tool. Contributor-focused content and stories sometimes will write blog posts or create videos or create other content to promote contributor activities, bring attention to areas that need help in the community when the annual report comes out every year. We try to make sure to highlight the help wanted sections. So every year we have this annual report and we talk about what the different special interest groups are doing and why it's awesome and what they really need help with. So we try to really amplify that this is what we need help with message. We just implemented a new shadowing program. So we would love to have you for any of our newer leadership roles and shadowing opportunities. And we've done a few talks about our team. So if you wanna go deeper into detail, look up those talks. So we also have an event sub-project where we essentially plan and execute a successful event such as contributor summit that we had earlier this week on Monday. Contributor summit is the primary event for Kubernetes contributors to get together, collaborate, just catch up. And also we also host a steering AMA in the contributor summit where we have questions focused more towards the broader health of the community, more towards what is the way forward in the next year, what do we need help with, and so on and so forth. We also, this, the earlier, the contributor summit that we just had, we had topics such as our new registry.ks.io, which is a big change and a big win for the community. Sustainable quality topics, mentoring topics, tying back into sustainable quality and improving the website tooling, stateful workloads, many more, and many more topics such as gateway API, pod lifecycle management, so on and so forth. Yeah, elections. Okay, so this is a very new sub project that we started very recently. To give you some context, every year we run one public election where every contributor votes and it's the steering committee elections because the part of the steering committee rotates every year. And back in history, we used to conduct the election using a tool called SIVS, which is the condorsed internet voting system. But the operations around the system was a little difficult to manage for the community as in how do we sustainably manage them and are there like concrete processes to do it? What we instead started to work on was, I think a couple of years back, was a tool called elective. It's a Flask app written to basically manage elections using Git artifacts. So if you want to run an election in the communities community, all you need is a Git repo where you store the metadata for the elections. And I've also pushed a screenshot. For example, on the right hand side, you can see that the last steering committee elections happened and I can just log in with GitHub and see whether I'm eligible to vote. And it also shows me which elections did I vote earlier in. It's like an end-to-end management of elections using Git artifacts. And it has helped a lot in like gaining more velocity. But we do have a lot of things that we need help with. These are like good to have improvements. So if you know Python, Flask, or in general, if you want to write docs around the election system, feel free to like join us in the SIG Contribacks elections channel and start discussing with us like, how can we solve? No, that's not all. If you have been a member of the community and know of the elections already, every year when the election happens, we need certain number of election officers. So if you want to help, do come to us right away because even though the next elections are almost like 10 months away, we really like to start preparing early. For example, Kathleen was one of the election officers. This year, Josh used to be an election officer until last year. And Electo has been created by Manish who has been, and I think in Elefix-20, or in one of the mentorship programs, and by Josh. Thanks to all of the contributors who have contributed, I just could name two, but I think there are like eight or nine contributors who have contributed to Electo. This is a really great thing as we say like, not all of the Kubernetes community requires go knowledge. If you know Python, it's a great thing to contribute to. Moving ahead, contributed documentation. So, Kastin mentioned the Kubernetes community repo where you can come and see like what community groups we have, what is the structure. Now, I want to mention the contributor guide, which is in the community repo. That helps people know the overall architecture of the community. Now, what about if you want to get like in-depth knowledge of how do you run tests? How do you set up the project? How do you run end-to-end tests? What are end-to-end tests? What are integration tests? You look at the developer guide, which is in the community repo itself. Now back couple of years back, what we realized was we need to have a central repository or a portal or a website or a front-end where, which caters to contributors of the community and we do have it now at katers.dev. You can go there, have a look at what community events are happening. There is a calendar as well where you can go and see which events are scheduled every day. If you want to join them, you can have a track. We have, we don't have the contributor guide really right now, but we will soon have it if you want to help. That's another thing you can help with. What you need to know is probably about Hugo and a little bit of like how do you add headers to markdown files and have them imported in websites. There is one certain help that we need in the contributor site is right now a lot of the content is generated using bash and we generate redirects using bash. Now if you know bash and go, that would be a real help to us if you can come understand what we have written and reimplement it in something that more people understand and which is like more testable. I think that's the mantra that we go by in the community. Like if we just write something and then if it flies, we want to write more tests, make it sustainable, just come on board. We have been working on contributor course to make people like go through scenarios of how do you contribute to Kubernetes. We do have a category scenario for this, but the thing is category is deprecated. So we are exploring GitHub code spaces right now. I think this would be done in the next couple of months so we should have an update soon for everyone. Beyond that, I'll talk about big wins. What we have achieved in the last six months since we gave the update in Valencia. Caps website. So a lot of the people in the community have been asking, hey, have been asking this question. You keep on talking about caps. Every contributor keeps on talking about caps and we know what are those. But if I have to go through history and look at what got implemented when, do I really need to go to a GitHub repo or maybe use search engine but then the results may not be indexed like you want? We did have a solution to this all this while but it's just that we needed to have it repackaged as a good front end that can be consumed by end users. It can be anyone as like a product manager or there are like different personas who can consume this website. This is just a alpha iteration you can say or the first iteration of the website where you can come and see a list of caps which have been implemented through history. And if you want, you can have a simple search. For example, here I saw like what caps went to stable stage in the one to five release. You can just do a plain simple search and it will return you all the caps that are there. Now we need a lot of help in this as well. So this is just the first iteration. On the top of my mind, one improvement that I can speak about is that right now this doesn't search through the cap contents. So we need help like enabling that feature or implementing that or thinking through how do we design such a feature? Also, we need help in like improving the metadata here. Not strictly related to six contrabex but it's like a general community thing. For example, if you see here for one cap we don't have the last updated metadata. So things like this, we need to improve over time to have a great caps website. I will let mother talk about the maintenance automation. Yeah, so I'm gonna go a little faster since we have approximately five minutes left. Mainteners is probably one of the most exciting areas that I'm looking forward to in the next year. So this is a tool that one of our community members, Dimz, a lot of you might know him, wrote. This is a tool to provide cognitive statistics to try and help gauge broader community health. It passes owners files in Kubernetes or any repository within the Kubernetes org. Owners files, owner aliases. It also queries GitHub and DevStats to try and see how many folks are active, what folks are present as reviewers or approvers who have not been active for a certain amount of time. And doing this is important because these are folks that you might assign to your contribution in order to get it approved. But if they are not active, your PR goes stale and that's probably not the best thing to do. We are also trying to get and run this maintenance tool as a periodic in our community in order to try and see if we can automate some of these things and basically give better signal to SIGs in terms of what do we need to do next. And so all that being said explicitly, how can you contribute, right? We have an excellent community. We have, especially like SIG Contributex is one of our favorite ones, favorite SIGs in the community getting involved. The first step is attending a SIG meeting. So we do have a variety of SIG meetings. There is one main one for the contributor experience SIG which we have, what is it, bi-weekly, bi-weekly. So if you are interested in hearing about the SIG kind of as a whole in a kind of general sense, attend that bi-weekly meeting. Our sub-projects also have their own regular meetings. Contributor comms, for example, meets every week on Fridays. So check out that community calendar for all of them or go to the specific sub-projects to learn more. All meetings are uploaded to YouTube so you can always find them there. I don't know why you would watch the recorded meetings if you're not familiar with the group. Sounds like a heavy lift, but you could do it. And of course, there's the mailing list. So any important information should go out to that mailing list. Make sure you check that out. So if you wanna attend your first SIG meeting, here are a few tips to make it worth your while and to help you continue contributing. If you can go with a buddy, sometimes it's useful to be able to talk about the meeting afterwards with someone else that you know. That can be really helpful for remembering what happened and for keeping each other honest if you wanna really start contributing regularly. Regularly is always the hardest thing. Volunteer to take notes. I know I for one have a horrible memory so I need to take notes in order to remember what happened. It's also a huge help to the community because a lot of people have that issue. It's useful to be able to go back to the notes and see what happened. And you'll have your name on the notes in a particularly prominent place so you'll get more recognition. Attend regularly. My advice to new contributors is always just to be stubborn. If you wanna contribute regularly and you start going to meetings and you're not really sure what's going on and you're not sure how you can help, nobody gave you anything to do, that's how it always starts. But the more of those meetings you attend, the more regular of a face you are, the more stuff you'll get assigned to you and the more you'll become a part of that community. So be stubborn and just keep attending. Small dependable contributions are what we're built on and SIGs generally try to have good first issues. There's a label in GitHub. So if you're looking for something to do, you can look for those. Oftentimes they don't use that label as consistently as they should. So definitely chat with the SIGs, don't be afraid, lots of folks are really friendly. So reach out if you want something to do. Next. There are also non-code related paths available like we mentioned in contributor comms. We have Twitter and we have a variety of other things that we do that don't involve coding. We also mentioned a few other projects like Electo where you can do more code contribution or the website contribution. So there's a variety of opportunities available. Don't let your feelings about your skill set keep you from getting involved with this community. Next. What are the most important areas that you can help with? Like we said, mentoring really needs help right now. It's so important that we get new folks onboarded onto the project who want to be involved. So if you can help out with any of our mentoring initiatives, we would really, really appreciate it. Help with running the community meeting is also something that we're looking for right now. Like we said, we run those meetings monthly. There's a little bit to coordinate there because we try to have folks from various parts within the Kubernetes community, not just the SIG presented those. So we could use some help with that coordination. More immediate areas, the Kubernetes annual report. So the annual report is really, really important to us. And it involves a lot of coordination as well. So if you're interested, we could use some help there as well. So the Kubernetes annual report. So this is a document that's been worked on and produced by the community. Most importantly, we have the help wanted section. So these are areas where you can go to to see what SIGs have been up to. And also these are areas where you can see if you want to aid conversations with your employers in terms of what do you need to do. And this is where you can find us. And thank you so much for attending, listening, collaborating, feel free to reach out to any one of us for any form of help needed. And we're happy to help out. Make sure to join the mailing list and the Slack. Thank you. Thanks. Okay, I'd like to take one question from online real quickly. Which is, do you have some additional tips or instructions for getting started in contributing? Like I said, my number one tip is to be stubborn. If you want to be a consistent contributor, find a spot. Docs or my group, contributor comms, I think are particularly good areas for new folks. In contributor comms, we do a lot of stuff that's very broad with the project. So you get more of a sense for how the project works. Same is often true for docs. You get a pretty broad overview and you can always move from one group to another. So don't feel stuck. I'll just add one thing. If you want to get started contributing to CIG Contribux or any other CIG, the community repo is essentially the source of truth. So head on to the community slash community repo, see what CIGs are out there, see what areas they work on. Next step is join the Slack channels and the email lists. Joining the email lists will get you an invite to their weekly meetings or bi-weekly meetings or monthly meetings depending on what the CIG is doing. And essentially, my personal tip would be to try and ask questions or ask or have discussions in public as much as possible and not in private, mainly because this creates common knowledge, it helps other folks as well, and it also reduces burden on existing maintenance. In addition, I would ask people to be sustainable, decide on a time that you want to commit to the community, but don't think like you would be able to commit like a lot of hours every week. It's important to be like regular across time and not like sporadic. That's really important in the community. So even if you can give like four hours or five hours a week or even a couple of hours a week, that's very good, but you should be consistent. And the clearer you are about your contribution boundaries, the better the community can help you stick with them. And time zones are always an issue, so don't feel free, don't feel the need to attend all meetings because some might be late for you, some might be really early for you. That's why we have the YouTube channel, that's why we have the notes, all of that. Async is more than okay. Async is almost preferred at this point. So totally okay, no matter where, what time zone you're in. Yeah, thank you. Do we have any more questions? Any additional questions? Didn't think we'd have time for more questions, but we do. Anyone over here? I don't think so. Oh, it's a question. Okay, never mind. Okay, sorry about that. You can always catch us in the hallway. Yeah, feel free to reach out, love chatting. Thank you so much. Thank you everyone. Thank you. Thank you.