 from automation to community, a deep dive into SIG contributor experience. And a reminder, we do have a code of conduct in place, so please be respectful and excellent to each other. I know the one for Kubernetes basically says to be respectful of your fellow attendees. I would assume this one's the same. There is a closed captioning available if you are on virtually, so hopefully at this point you've figured that out. If not, here's a little bit of information about that. I'm not going to sit here, though. I'm going to move on. And we will introduce ourselves. Priyanka, would you like to start? Hey, everyone. My name is Priyanka. I work at SUSE as Kubernetes Integration Engineer and been part of the project, Kubernetes project, for a while now in SIG release, and now in Contribux area. Hi. My name is Madhav. I work at VMware. Currently, I'm our technical lead for SIG Contributor experience. Other than Contribux in the community, I work a little bit on API machinery and architecture. And I'm Kazlin Fields. I'm a developer advocate at Google Cloud, where I focus on Google Kubernetes Engine and open source Kubernetes, and recently nominated as one of the new co-chairs of SIG Contribux. And I've been working with open source since 2020. And I am also the sub-project lead of the contributor comm sub-project, which we'll talk a little bit more about later. But before we start, we have a very important thing that we want to make sure that everyone is aware of. If you haven't seen it yet, has everyone seen this so far? Yeah? A few people haven't. A few people didn't raise their hands anyway. So now, hopefully, you will be aware, we are making some changes to the way our registry works. If you have been using kates.gcr.io to get Kubernetes-hosted container images, we do need you to move over to registry.kates.io. This is a new community-owned URL for you to be able to get your container images from. It helps out the project a whole lot in terms of back-end infrastructure and billing. So it'd be really, really helpful if you and if you could tell all of your friends to please change any references to kates.gcr.io to registry.kates.io. We have frozenkates.gcr.io for some images at least. And you should not expect it to live forever. You should expect that you will need to move to the registry.kates.io registry at some point. There's a lot more information on our blog about the redirect and the changes that we're doing here. Don't expect it to go away on its own. Please make those changes yourself. They will save you in the long run. If you'd like to ask more questions about that later, we can talk about it more later. But first, let's actually get into the meat of our presentation for today talking about the Special Interest Group for Contributor Experience in the Kubernetes Project. How do we do the work that we do, whatever that work is, if you are familiar or unfamiliar? The way that we do all of our work really is through subprojects. We break all of the stuff that we kind of own in the project down into these subunits. And Priyanka is going to walk us through the first set. Yeah, so the first subproject we have is community. And this project owns and manages the overall community repo we have, which also include our community groups, documentation, and any operations there. Next, we have community management, which also manages all the operations and policies that we have for the upstream community, communication platforms. Then we have documentation, contributor documentation. So we also manage and maintains rights, documentation around contributing to Kubernetes and subprojects in general, and which also includes everything within here, Contributor's Guide, Developer's Guide, and the website we have for Contributor. Okay. This is a really interesting part of the community that we sort of help maintain called DevStats. If you don't already know, DevStats, as the name suggests, stands for Developer Stats. It gives, if you go to that link, it's a Grafana dashboard with a bunch of developer metrics of the CNCF, or more specifically, the Kubernetes landscape. So we have things like distribution of contributors across companies, distribution of contributors across projects, very, very interesting things, like what's the median time for a PR to merge in Kubernetes. Spoiler alert, it's three and a half to four weeks. So if you're frustrated with how long it takes, it's normal. We have a new subproject called Elections, and we have Josh Berkis here who's the lead for that subproject. The Elections subproject is critical to our community because it helps run elections in the community, maintains documentation for it, and also maintains the tool that runs these elections securely and confidentially. That's called Electo, so that project always needs help, so if that's of interest to you, reach out to Josh Berkis or on the CIC Contributex channel. We have the Events subproject, which is responsible for all the events that the Kubernetes project specifically does. For example, the Contributor Summit that took place yesterday. We have GitHub Management, which we'll be talking a lot about today and giving you some insights into how we do things in the community, and maybe you can adopt that for your projects as well. So, Managers, Controls, GitHub Permissions, Repos, and Groups. We try to automate all of this in a way that is consistent for users across the community so that it's scalable, it's secure, and overall a good contributed experience, as the name of our group is. Handing it over to Kaslin. We also have a subproject for mentoring within the project. If you checked out the keynotes earlier, there was a shout out to how important it is to do mentoring in open source projects. So our mentoring group helps to interface with the CNCF with some of the mentoring programs that the CNCF is involved with that Kubernetes also participates in, things like the Linux Foundation Mentoring Program, which LFX Mentorships, I think is what it's called, and Google Summer of Code, so programs like that. Also having some mentoring activities within the contributor community, like having mentoring meetings, and helping folks get involved like that. This subproject is in particular need of help, so if you're interested in mentoring, definitely reach out. We could particularly use some help with kind of coordination activities that that group needs to do, so if that sounds interesting at all to you, please let us know. We also have the Slack Infra subproject, so this is gonna be the group that does a lot of management and maintenance of our Slack tooling. We have an enormous Slack instance, because we have so many contributors. We have all sorts of automation going on in it, so there's a lot that's involved with Slack Infra maintenance and management. And of course, contributor comms. I mentioned this earlier, but the contributor communications group is all about making sure that folks within the contributor community understand what's going on for the community and also making sure that folks outside of the community hear about the awesome work that contributors are doing. So we run a Twitter account at Kates Contributors. We recently created a master non account which we're working on getting set up, and we help with emails. Sometimes messages go out on Slack via the Slack bot that we also work with Slack Infra on. We have a variety of different ways that we get in touch with the community. If you're interested in that, join us. Fridays at 8 a.m. Pacific. So I wanted to talk a little bit more about mentoring. We also got a shout out, which was lovely in the keynotes, about the concept of a ladder for contributors. So here is a bit of a look at the ladder that we have for Kubernetes contributors. So a lot of the folks that come in to contribute to Kubernetes are folks who just wanna do one thing and be done with it and not really do anything else. Or honestly, most of the folks that I interact with are folks that are trying to figure out how to get involved with the community. Usually takes a few tries. The first time you go and find a good first issue and maybe it was labeled as a good first issue but it wasn't a great good first issue. All sorts of things can happen. So most of the folks who contribute are non-member contributors. They're not members of the Kubernetes org. It's their first time attempting to contribute. Maybe something will go wrong, maybe it won't, maybe they'll do what they came there for and move on. So a lot of folks stop there. But if you want to continue and become a member of the Kubernetes org, then of course you'll become a member contributor. There's a process to apply for org membership. I don't think there's an actual requirement for two pull requests. We used to use that as like a general baseline. But really the idea of applying for membership is that we get a sense that you're here to stay. You're not one of the folks that's just there to do one thing and go away. You're looking for a way to get involved with the community. Once you can show that to folks who are already in the community, they can help you get org membership by sponsoring you. That's kind of the general concept. Then once you've been a member for a while and you start taking on more responsibility, you'll become a reviewer. Someone who has privileges on certain repos to be able to review submissions to those. And then of course you become an approver. So a reviewer can give like an LGTM. And an approver would be someone who says, yes, this is ready to go in. And can be that final last step before a change actually happens. So there are two levels there that you might not think to separate. And then above that is sub-project owner. So this is another level of responsibility where you may be in charge of group activities like running meetings and organizing tasks and activities for the group. So it has a bit more process to it as well. So you can kind of see how this builds a ladder of starting out, contributing, and becoming a more ingrained part of the project. Here's a little bit more about the mentoring sub-project that we mentioned earlier. They do group mentoring cohorts theoretically. They try to help encourage other SIGs and working groups to work mentoring into the way that they do things. And they also help some folks establish shadowing programs. So one of our most popular teams to work with is the release team, because the release team has a wonderful shadowing process in place. More groups within the Kubernetes project are trying to establish these shadow programs as well. We also have a few projects submitted for Google Summer of Code. We always try to get involved with that mentorship program. And there are some other programs that we also try to be involved with, like Outreachy. I mentioned the Linux Foundation one earlier. We also try to run a Meet Our Contributors kind of office hours session where folks who are new to the community can meet folks who have been involved for a while. Like I said, getting to membership is all about getting to know someone in the community and showing them that you're there to stay. And we need help. I mentioned that already. All right, and so that's all I'm gonna say about mentorship for now. And now I wanna start with the deep dives into a GitHub management update. So we've recently made an update to the way that we do our issue auto close workflows. So there's a lot of automation in GitHub, like we mentioned, for managing all the issues, because Kubernetes is such a huge project. We're getting so many issues, so many PRs all the time. We need some automation to help us manage all of this. So we've recently made some changes to the way this workflow works. Here's how it worked in the past. Basically, you submit an issue. That immediately, through an automated tool, gets the tag needs triage. That says, okay, SIG just got this issue. You need someone to look at this issue and see if you actually wanna do it or not. So it's kind of a holding state. Then, hopefully, someone will look at that issue and add the label triage accepted. That just means somebody looked at it. Hopefully, they'll do something with it eventually. So in the past, at this point, if the issue has triage accepted on it, if it just sits there for 90 days and nothing happens, then it would go to a lifecycle stale. That means it's been sitting around for a while, nobody's doing anything with it. You might wanna take a look at this again, theoretically, if anybody ever thinks that when they see stale. And then if there are 30 more days of inactivity, then it will go to lifecycle rotten. This thing has been sitting there for way too long. Somebody needs to do something with it, or it's about to be closed. And then another 30 days of inactivity and it will be closed. So the issue with this, that sounds pretty reasonable, but the issue with this is that a lot of issues in the Kubernetes space do take a very long time to deal with. For example, Kubernetes enhancement proposals, CEPs are really big issues and proposals that take a very long time to talk through and decide what to do with. So sometimes this isn't enough time for us to work with an issue. So we needed more control over how this worked so that some of the important issues that just take a really long time don't get closed while we're still trying to work on them. So here's the new process. Still needs triage gets applied immediately to a new issue. And hopefully someone will add a triage accepted label to it once they've seen it. If triage accepted is added to the issue, then we aren't going to market as stale or rotten at any point. That way it doesn't get auto-closed. If you have accepted this item and you say that you're gonna do it at some point, it can stick around forever. If it does not have triage accepted, then the same way that things were working before would kick in. After 90 days, it'll be stale. After another 30, it'll be rotten. And after another 30, it'll be closed. And then assuming that it has triage accepted and we have another label that defines the priority, what is it called again? Priority. Oh yeah, priority important long term. So we're saying this is something that's important and we're gonna get to it eventually, but it's gonna take a while. So after one year of inactivity, then triage accepted will be removed from that. So you can see that we're just delaying the start of the closing process. If you say it was important, then we can delay this process where we'll close it for at least a year, really a year and three, four months. And there's also another label. Priority, thank you, important soon. So important long term, obviously something that's gonna be around for a while. If you say you're gonna get to this relatively soon, then that's what we expect from you. After 90 days of inactivity, then we'll remove triage accepted and you'll start into that rotten stale closing workflow. And if it has, thank you, priority critical, what was it, urgent. So if it's urgent, then that means that it needs to be dealt with in a very short timeframe. And if it isn't dealt with in a very short timeframe, then hopefully it doesn't matter anymore. So after 30 days of inactivity, then remove, it will remove triage accepted and go back to the regular workflow. And then there's also priority backlog. After one year of inactivity, something on your backlog will go back to the regular workflow of potentially being closed. So this is the new workflow. I think there's one more thing here, yes. So essentially, if it doesn't have triage accepted, then it will be closed at some point. And we kind of use that triage accepted flag as a way to manage how quickly that closing happens. So, yeah, question. Oh, what did I say? So if you remove triage accepted, it just kicks in. Any issue which is labeled with the priority label that is not backlog, those won't be auto-closed. Only the issues with either backlog or no priority, those are the ones that are going to be auto-closed. And yes, if it's important long-term or important soon or critical urgent, those will not be auto-closed. Because for some reason they are marked the way that they are. And the prompt to re-evaluate the priority is essentially, you know, you get a notification saying that it needs triage. And then as part of the triage process, you re-evaluate your priority then. Good catch, thank you. It will be seen again, I'm not sure. So, yes, important just alone. That was my mistake that Tim was pointing out. It doesn't go all the way back to the closing workflow. It just starts changing the status, right? But it maintains the important label. It just might also get the sale label sale, right? Just it will never reach closed. That was my mistake, sorry about that. Oh, some additional labels that are also affecting this new workflow, good first issue. If it has good first issue or help wanted, then they will be excluded from the lifecycle process so that those can hang around until somebody gets to them. And thank you for Tim Alcler and Ben the Elder who made these changes. Yeah, so on to the next deep dive, right? So as you might know, it's annual report season in the community, all sick chairs are sort of busy cramming up info about what their sick has been up to in the last year and preparing annual reports. So as contributor experience, we sort of try and make the process of annual reports seamless for SIGs. So before we start talking about what we've worked on to do that, let's give a little bit context about what annual reports themselves are. So the Kubernetes annual report is a document that is worked on and produced by the community every year. So every SIG and working group puts together a bunch of information about what they've been up to along with questions that are asked such as how many reviewers and approvers does your SIG have? How many sub-projects does your SIG have? Are there new sub-projects that were introduced? So the point of having these sort of questions is to try and get telemetry on what the health of your SIG is essentially. There's still a long way to go in order to accurately gauge what the health of a sub-project or a SIG is, but this is a great starting point. So why are they important, right? Another important, really I think noteworthy section of the annual reports is the health wanted section. So every SIG sort of lists and notes down things that they think they need help in based on what their experiences have been in their past year. And an indirect consequence of the health wanted section is that since these annual reports are then ultimately published at the CNCF level at a CNCF.io slash reports, one can use these annual reports to say that it can go to that employer and say that, hey, I'm using Kubernetes, since we do care about Kubernetes and this particular area of Kubernetes, like let's say SIG X, has needs help in these sections and we do have expertise in them and we face problems in them. Why don't we go ahead and contribute to them? So this also helps you sort of convince folks to let you contribute upstream. So that's an indirect consequence of this. Yeah, with that being said, let's let with a little bit of context on what annual reports are, let's talk about the process of generating annual reports and the automation that we worked on towards that. Thank you. So currently we have a tool called annual report generator, which sits in Kubernetes slash community repo. And that is a tool we use currently to generate templates for our annual reports. Simple, we clone our Kubernetes community repo, we go inside that and we run this make target, make annual reports equals true. So what it does for us is it creates a lot many things. So it creates empty annual report templates for SIGs and working groups that we have under Kubernetes org and those empty reports template looks like something like this. And it also create issue templates so somebody can use those issue templates, open issues and use them to get some help from the community to start filling the annual report. We have some automation here. The templates that we just created here for issues, we can run this command to actually even automatically bulk create issues, GitHub issues, and that would look something like this. Now, so far in our templates, we had a lot of sections, but from our previous generator tool, we did not have much information already filled in there, but since there is a lot of information like enhancements that have been worked upon or how many projects that were added or retired last year or previous year, those kind of information, the community felt we can use some automation there to improve our annual report generator tool. So that's what we did. We tried to do this time. We have done some automation on auto generating list of our kept. So all the kept Kubernetes enhancement proposal that have been worked on during the previous year, annual year, so three cycles. We tried to grab all that information and put that in our annual report templates automatically. So here we see, for example, we have API machinery here. We can see these are all the kept work done in 2022 and across all those 124, 125, 126 releases and they're also categorized under what milestone they graduated to during that time. We also added some automation to grab a list of which of the sub projects were retired under a particular sake, which one are continuing and which one are new. So we have some examples here for that. And before we move to the next example, there is also some work being done for the reviewers and approval count. Thanks, mother, we'll also be including that in our generator too, thank you. Awesome, thanks. Since we are, I think, about nine minutes left for the talk, I'm gonna try and make this very quick. So before we start, there is, we have amazing automation in the community that folks have worked on, but there are some problems with it. The way that Kubernetes PRs are merged as of today, we have a set of reviewers and we have a set of approvers that can do these things. So that information is encapsulated into an owner file, which is, it looks like that. If you have a bunch of reviewers and you have a bunch of approvers. If you look at the current approval process, it looks like this. If those are the set of files that are changed in a PR, and let's say X, who is our owner in package API, says slash approve, everything in API gets approved. Now if B says slash approve, everything in registry even under apps gets approved. Now this might be fine, but what if B only has expertise on testing, but the remaining expertise on apps and the file first.go lies with A and C. That essentially does not give enough confidence for B to approve a single file which reduces velocity of PRs, which aggregates approval privileges onto a specific set of people as well. So what we sort of are trying to work towards is a granular approval mechanism. So we can, oh yeah. So to illustrate what I mean, we have changes that bump dependencies in Kubernetes. And whenever a dependency is bumped, you can see that's the size of a PR. So 32,000 additions and things like that. So dependency bumps are huge. And dependency owners are root approvers, which means they sit at the top of the Kubernetes wrapper and they have approval privileges over everything in the Kubernetes wrapper. So if they sort of approve a dependency change and if that same PR is making another unrelated change, that'll also get approved with that. So what we're working towards is sort of like a granular approval mechanism where you can do slash approve files and you can approve a single file only, or you can approve a set of files that match a particular reg X or just a particular directory if you want to. What this sort of does is it breaks down approval privilege among set of folks and gives more confidence to people with certain set of expertise. So what that looks like is something like this. So if B comments, since X commented approve, let's say API is approved. Now if B comments slash approve star underscore test.go, only test will be approved. Now if C comments slash approve everything under registry apps, you see one.go is approved and apps is fully done. And the plugin is now tracking what directories are approved and what is left to be approved. And unless everything is approved, the PR is not eligible to be merged. And finally, A comments approve, everything is approved and you're good to go. So this is something that we're currently working towards. The work on it is more or less done. If you find the final things to iron out then hopefully we'll have this feature for our users to use by next KubeCon. Yeah, and finally we have our declarative team management that we are doing for GitHub, Bianca. I'll try to be quick. So PeriPollos is also another plugin to our very own CI CD system we have called Proud. How it works is we take the traditional approach here of Kubernetes, how things work in Kubernetes. We have a declared state and Kubernetes try to match it, observe it and tries to match our declared state. So similarly, what we are trying to do with PeriPollos is the same, but for our GitHub resource permissions, everything management there. So this is one example where we have a Yaman config file we have declared so and so should be the members of such and such GitHub organization. So PeriPollos will read that config file and it will try to match it to the actual applied configuration in GitHub. So if there are some members there who are not already part of the organization it will try to invite them or promote them to the specified permissions. And same we repeated for all other GitHub stuff as well for GitHub teams or other metadata. So that's exactly what we discussed. PeriPollos enables the declaration of GitHub org, settings, teams and membership in a Yaman format and then GitHub is then updated to match what we just defined in our config file. So this is how a config file looks like at the very top we have the org's key and under that we give the name of the org and we define all the org settings there. And under that we also define our members or say these many we are adding them as just members or so and so we are listing them as admins. Plus we can also define teams here so we can collect people under certain team and we can say ABC or here like and Jane they are part of team one. And along with being members, being part of team one they also have access to these specified repos here. So they have admin access to some repo and read access to other repo. That's how it's written here. So we don't have to create this file on our own. It can be very tricky to generate, create it. So we have this PeriPollos tool that actually can create this file for us. So all we have to give is the name of the organization and a GitHub token. And if we have admin access for that GitHub organization it will dump the org config for us. And then we can make changes in our old config to however we like it and ask PeriPollos to match it now what we just asked. So the present state, we are already using PeriPollos but we are not using it for defining repo permissions under teams. So there is an issue open there for a while now which is asking us to also automate that manual part since PeriPollos has that capability already. And along with you starting to use the repo setting repo permissions under teams, they're also asking to propose a restriction model. So for example, if we have ABC folks under a team have access to say Kubernetes repo as we do not want them to use their privileges to maybe escalate anything. So we have a work in progress solution PR open that's going to implement that start using also automating to use team repo permissions using PeriPollos. This PR also adds a binary called restrictions that will give us this restriction model. Yeah, so this is a restriction file we are calling Kubernetes six dog teams.yaml can only specify permissions for website and not for test infra because that's not just defined how it's defined there. Yeah, so we're almost at the end of it. If you'd like to get involved with some of the work we're doing if you think something can be done better if you have ideas of your own feel free to get involved with us. We have a Slack channel, we have an email list we maintain meeting notes and the regular weekly bi-weekly meetings as well. Tips for your first sick meeting. I just want to highlight two things. Just be stubborn and that's the best way to go about it. It might not be the best way forward. Sometimes time zones might be an issue but it's okay. There are folks who've done the work who've been here and we can't wait to welcome you. There are lots of things that you can do that don't involve writing code there are also lots of things to do that do involve writing code. There's a huge variety of opportunities available. Here are some important areas that we need some help with mainly mentoring. Like I said, we could really use some coordination help there if that's something you're interested in. Here are a bunch of folks involved with SIG contribex that you can reach out to. If you want to ping us directly I know I'm open to pings directly I'm at Caslin on Slack. You can also ping us all on SIG contribex the channel. Thank you and maybe this is you next. Feel free like all of us are stepping into leadership positions with the intention of being replaced. So you know, come replace us as soon as possible. Awesome. Yep. So Josh who is here might not be on the name might not be on the next one. So, you know. Emeritus is the goal. Emeritus is the goal. Yes. Awesome. Thank you so much and folks have questions. Thank you. I thought you had a question, sorry. I know there was some confusion about the life cycle things. If you still have questions, let's talk because you know, like there's obviously better ways to do it that we didn't think of and our contribe doesn't think of. So let's please talk. Okay. If there are no questions, we are around here or outside if you want to chat. Happy to chat. Thanks. Thank you.