 Hello, everyone, and welcome to learnings from sustainability steering sustainability. I can't say it, so I'm just gonna say sustainability steering at the Kubernetes project. My name is Bob Killen. I am known as Mr. Bobby Tables across all the things. I am a program manager for Google's open source programs office, and I'm a member of the Kubernetes Steering Committee. Hey, everyone, I am Navarune. I work as a staff engineer at VMware, and I am also one of the members of the Steering Committee, and also chair of the Kubernetes Contributor Experience. To start with, I want to welcome our new members who recently joined us, Machie, Paco, and Patrick, who have a term until the end of September 295, and they will be joining us. Stephen got re-elected for another term, and they will be joining us again, like Ben, myself, and Bob, and we have a few people here in the audience as well. Ben. Yeah, Machie, and with that, we want to thank our previous steering committee members, Kristoff, who is in the audience, Tim and Carlos, and with that, this is the first time in the history of the steering committee that we have more members from outside North America than inside North America. That's the first time we've had representation from China as well. Yes. And with that comes a unique set of challenges. Since we are spread over so many time zones, we can't have a very good meeting time to talk about, and then we have to do a lot of our stuff async, but this is a very good problem to have, and we are very delighted to solve this problem. Try and move more async. You might already know, the Kubernetes org is really big. We have 83,000 plus contributors, 1800 plus org members, which contribute to 354 repositories combining all of the Kubernetes orgs, and we have 34 community groups. We'll talk more about what we have been doing about the community groups, their life cycle shutting some groups down because they have ended their lifespan or spinning up new groups in a later section. With that. Okay. So, to begin this, what does steering do? Well, the formal definition, and if you don't mind, I am actually just going to read it. The Kubernetes steering committee is the governing body of the Kubernetes project, providing decision-making and oversight pertaining to the Kubernetes project by-laws, sub-organizations, and financial planning. The steering committee also defines the project values and structure. It's honestly a pretty good TLDR. That was weird. What we actually really do is, review charters from our sub-projects, we look at their scopes, their responsibilities. Overall, we sort of define and evolve a non-technical vision for the project. We need to sort of evolve with the state of the project. Kubernetes is just about 10 years old, and what it does today is very different from 10 years ago. We need to determine the types of groups, roles, and structure that are most appropriate for us at this point in time and will help us have a sustainable future. We also are the primary group that interacts with the CNCF, so if there is a financial request or if there is some need to interact with them for one reason or another, that we are the body that does it. But really, what does steering really do? Well, really, we plan for the long-term sustainability of Kubernetes. A lot of the things that we actually do might not have an impact until we are done with our term, but our goal is to just make sure that the project itself can outlast us and outlast our terms. And the way steering does this is through governance and policy, that the changes that we make, again, are slow, might not be effective for a while, but we also spend a lot of time on these things. And steering tends to move pretty slow, but that is intentional. We are trying to put a lot of thought into what we do and their impact. Now, we actually have a few recent changes that we'll go over, and these kind of went into effect over the past year. Some changes to subproject leads and our chair and TL split, as well as revisiting some of our groups. So, to you first, before we dive into it, this is what is known as our contributor ladder. We have this as sort of a path of growth for people to enter the project and go from contributor to org member, and then we have a reviewer approver and subproject owner. A reviewer is someone that is added to an owner's file and it's sort of the first, wrong on the ladder, where they are tagged in first to do first line review of PRs and things of that nature. As they become more familiar with the code base and more trusted, they will then go to approver, where they are then allowed to merge code in their specific area, and then they move up to subproject owner, where they are sort of a root approver for that area. And this is what we had before. So, I'm going to talk about something, a change that we did really recently. So, what time we realized that we need one more level as a stepping stone into becoming, or coming into the contributor ladder or the leadership ladder. So, Bob mentioned the ladder in which people grow from becoming a non-cubinities org member to a subproject owner. But what do we really mean in that process, right? So, we sat and we thought about like, how do we make that role really formal? So, we did have subproject owner for a long time, but what we wanted to do was make it a formal part of our contributor ladder. So, we introduced a role called subproject lead. The key difference being, the subproject lead has more responsibilities compared to just being a subproject owner. So, subproject owners are essentially owners of code, but then subproject leads are also expected to have some technical direction for the area that they are lead-off. And you can think of like, it to be a more bubble-down version of a technical lead. A technical lead is, a SIG technical lead is supposed to handle like multiple areas or all areas of the SIG that they are a technical lead-off. And a subproject lead is only needed to supervise areas in the area that they are in their subproject essentially. So, there are a lot of differences between like a technical lead and a subproject lead, but these are like, it is designed to be a funnel to eventually become a technical lead inside a SIG. And this also gives the opportunity for the SIG chairs and technical leads to essentially grow contributors through a well-defined funnel. So, if someone is a SIG technical lead, they can essentially identify people who can be future technical leads through the subproject leads of the subprojects inside that SIG. And this gives a really good structured way for people to grow. For the most part, it's honestly just recognizing a lot of the people that are already doing the work. We have people that have been standouts in these roles for a while, now we are just giving them a title. The other thing that sort of complements this is the chair and TL split. So, before we've had like two top-level roles of a chair, which is usually the one that does like, I don't wanna say like all the administrative work, but they're the ones that organize the SIG, the group, and make sure everything is functioning as they should, making sure all the like, they're handling all the transparency requirements. The SIG is in good health, looking out for the various areas that might need to grow future people. And the tech lead role was specifically focused on sort of the stewardship of the code or the area that it owns. And before the tech lead role would roll up to the chair if no tech lead was explicitly defined. And this actually caused a lot of confusion because you had some people that were chairs that were also TLs and other places where they were chairs with separate TLs. And there was a lot of both confusion from people that needed to seek certain approvals as well as like when it comes to growing someone into a future role with them being conflated. It was really hard to sort of find people that could satisfy all of the above where it's a lot easier to find people that could do just one of the two roles. I should have pressed this slide or pressed this earlier. That was my mistake. This essentially just summarizes what I was saying. The other big thing to go sort of along with this out of revisiting our roles and how things sort of split the, we've also been like revisiting our groups and our requirements for our groups. Governance should change with the project and to like best achieve the project's goals at that point in time. And the current state of both Kubernetes and sort of the cloud native landscape as a whole is quite a bit different from when our governance is first drafted. And a large portion of our governance is like how we divide and essentially self-manage ourselves and we do that through management of groups. So we've been looking at a lot of our groups and looking at does this group continue to serve the goals of the project? Is it active? Is it, does it have enough people interested in it to sustain it in the future? Are there any reasonable changes that can be made to it to help it succeed or should we spin it down? And with the current state of things we just kind of need to like marry conduit and if it doesn't spark joy, eat it out of the org. This led us to recently retire our user groups. Years ago there were SIGs for like the big cloud providers, Google, Amazon, VMware, et cetera, et cetera. And it was determined that it really didn't make sense for them to continue as independent SIGs and there wasn't really like a long enough like long-term work to justify them as those independent groups. And it just like didn't really align to have like again the provider-specific groups in there. So those wound up being moved under like one Umbrella SIG cloud provider but there's still like a gap in there where users of those cloud providers could previously engage and provide feedback that would then be used by the groups and that sort of bore our idea of creating a user group back in the day. Unfortunately those groups were never really taken up on like there was one group, like a VMware user group, there's also a big data user group but they never really took off and didn't really help the project overall. They did have their own little communities and things but they weren't helpful to the project as a whole. And there's other things where like these days there were better alignment with them interacting at the CNCF level than the Kubernetes project level. So for us, it just made sense for us to spin them down. We did this largely like it just removed extra overhead and streamlined our own governance to honestly just help us manage things at this current point in time. So it also wasn't just user groups that we retired. In the past year, we've retired several SIGs and working groups. SIG usability was created with the intent to improve the overall user experience and accessibility of Kubernetes. But like it honestly wound up being fairly difficult to attract people to do that kind of work. It just frankly it wasn't incentivized by a lot of people who was really carried by a few people that were really passionate about it but it was hard to get them support. And in the end, it just made the most sense to spin it down. Another was SIG service catalog. Again, there's a few very passionate people in it but like the latest release hadn't been updated in several years. And again, it just kind of made sense for us to spin it down. Others, the multi-tenancy working group had a very similar story. One actual highlight is the reliability working group. While that spun down, it did actually succeed at its mission. We introduced, like its goal was to increase the reliability bar of Kubernetes so we could have more reliable release practices. And we wound up introducing a process called the production readiness review as part of our release process and it's now just baked into every release. Everything is looked at and evaluated to make sure that every feature is evaluated for its ability to, you know, is it implementing the right amount of observability? Is there a feature flags that makes it easy for it to roll back if needed? And that process, you know, once the reliability working group had succeeded at its mission and it was spun down. Then the last one, the IoT Edge working group is a case where another sort of successful one, you know, it didn't make a lot of sense for it to exist at the Kubernetes level, but it made sense for it to exist at the CNCF level because it was interacting with a lot of the IoT Edge projects. So we've been working on transferring it from Kubernetes to the CNCF just to, you know, give everything the best fit and best chance to succeed overall. But that, we spin down groups, but doesn't mean that we don't accept new groups. So in the past one year, or the past six months, actually. Raise the microphone a little bit. In the past six months, we had two new groups. We have HCD now and working group LTS, working towards their mission. They aren't really new per se, but have some backstory behind their recent additions back to the project. Coming to HCD, so we have to realize like what's the backstory behind it. So here you can see like one issue created by DIMMS in, if I remember this is the TOC group. The TOC have a report talking about the health of the HCD project. Now it's really good that projects are, projects raise flags when they feel like the traction is low or they need more maintainers or more contributors to even sustain their growth. And it's more so important for projects like HCD which serve as the storage backbone of Kubernetes. Without HCD, Kubernetes will not exist at this point. We might need to like invest in or find a new storage engine for our APIs, for our API objects. And it's very fair that sometimes due to such issues, projects can go into a crisis mode and people are already burnt out because of that. So what happened after that was, HCD was actually proposed as a Kubernetes SIG to help HCD gain more traction and HCD get the resources that we have in the Kubernetes community and align more. It made more sense because the goals of HCD or why HCD exists is very closely tied to Kubernetes's resource model and how Kubernetes talks to its storage back end. And with that, it was put into vote and we had unanimous approval to accept HCD into the Kubernetes project. And we did add HCD back into the project, talking about LTS. So what is the backstory behind LTS? So way back in 2017 or 2018, if I remember correctly, LTS was something that was thought of and a working group started back then with the goal of identifying how do you support Kubernetes for a longer duration. In 2020-ish, we spun down the group by achieving certain things, specifically increasing the support of Kubernetes from nine months to one year, like aligning with the business life cycles of the vendors. But then during KubeCon EU this year, discussions about supporting Kubernetes for a long term again began picking up traction. And more so because vendors started doing it on their own in that timeframe and it made a lot of sense for everyone to align efforts and align with the community goals on how LTS should be done. An unconference at the Kubernetes contributor summit during Amsterdam resulted in WGLTS to be reformed and here we see an issue from Jeremy to essentially describe the conclusions which were achieved at the end of that unconference and proposing LTS to be back as a working group. That's all on the new groups front. There are a few more activities that we do in the Staining Committee. One of those is, okay, sorry. Sorry for the snafu. One of the activities that we do is conducting the Code of Conduct Committee elections in the Kubernetes project. This year, we did change the process a little bit. Instead of doing a private voting using SIVs, we started using Electo, which is our in-house voting project that also conducts the Kubernetes Staining Committee elections to run the Code of Conduct Committee elections as well. We had like 11 amazing candidates for the two open slots in the Code of Conduct Committee. What, after the elections, what we decided was we should probably improve the process a little more. So right now the process is like the candidates who want to run for the Code of Conduct Committee, they submit their candidacy using a Google form and then we go ahead and populate the election mechanism. But what we want to do for next year is actually have the candidates nominate themselves directly on the GitHub repo and then the election app will take their candidacy up automatically. The other thing that we want to change is we also want to change the dates of the Code of Conduct Committee elections to closely align with the Staining Committee elections. What is it, though? It's the opposite. They're too close right now. Okay, so right now the big issue is the Code of Conduct Committee elections and Staining Committee elections essentially butt up to each other and that has honestly been rather difficult to manage just from like an administrative side plus what winds up happening is if a person that's running for the Code of Conduct Committee is potentially interested in running the Staining Committee, they have to basically decline that role and then run again for steering. What we would like to do is actually move, change the duration and change the date which the Code of Conduct Collections occur to after the Staining Committee elections which currently happen in like September, October and move them to say like January just so that there isn't such heavy overlap and that also gives an opportunity for any former steering members to run for the Code of Conduct Committee elections. So the next big thing that we are actively working on is looking at annual reports. One of the previous governance changes made by the Staining Committee was actually meant to like reduce the amount of public check-ins. We previously required our groups to check-in like once a quarter and this was bumping it and also doing it like live on camera with like a deck and this bumped it down to just checking in once a year with filling out a document with some information about the status of their group. You know, this was, ideally this is seen as like less work overall because you'd only be doing it once a year instead of once a quarter. You know, it would serve as a good way for steering to check-in with the group still and sort of get a pulse of the group's overall health. But like outside, the other thing that we wanted to do with them outside of checking on their health is also gave us a better way to surface the achievements and risks of that group to a larger audience with it being an actual document instead of something that is essentially in a recorded community meeting call. Now, as someone not working in a project every day, how you learn about those sort of, you know, recent changes in things that are struggling to keep help or keep up with, again, has been very difficult. We, after these annual reports were completed, we surfaced these up to the CNCF and a larger roll-up report was then served on the CNCF report site and was advertised by them. Now, you might think that all makes sense and that it's like less work overall, but the reality has actually been something quite different. We have had a lot of issues with people working on the annual reports. So first, this year's results, I know that numbers don't quite line up with what we said earlier in terms of our toll groups, but the annual report process doesn't exactly align with calendar years right now, so things are a little bit a tad off. The other thing you might notice right off the bat is only two-thirds of the groups actually completed and had a merged report. You know, that isn't great, and especially for something that's supposed to be easier. Now, especially, let's see. So, sorry, I don't wanna like dig into the specifics of this quite yet, but we'll look at a few things. So there are a few things I wanna highlight from this year's report and the previous year's report. And from what you're seeing here, it's a lot of red and yellow and that doesn't paint a great picture, but there's a lot of progress from red to yellow, so that is a nice iterative growth. So in 2021, there was a lot of areas that were not doing well, and they needed more reviewers, more approvers, just more people in the pipeline. So in 2022, we started to do several mentor cohorts to try and help bring people up into targeted areas. And frankly, we did have mixed results. Some worked out quite well, others, not so much, but we did learn a lot and have continued to make improvements. Our most recent mentor cohort has been wildly successful. Let's see. So similar on the next thing in 2021, still at this point, we're still mid-pandemic. There was a lot of burnout amongst our maintainer community. A lot of maintainers had less time and less good headspace to work on things, but things did seem to improve in 2022 from general conversations with them. And the reports from what the leads gave us. But I'll leave a little asterisk there since a bunch of sakes didn't actually complete the reports. So from the data that we have, things are looking a little bit better. This last thing I want to highlight is up until last year, the Kubernetes infrastructure costs have only really been fronted by Google. And so that's about nine years of supporting everything in the project. And we're talking multiple millions of dollars per year. And in 2021, things were starting to get bad. We came close to actually running out of funds. And at the rate that we were growing, we would definitely run out by the end of 2022. So Steering worked with the CNCF to help establish the cloud credits program and start to try and bring on more vendors to help support our infrastructure costs. This did succeed like long-term. We did get more vendors interested, but at the rate of growth that we were having and we weren't able to get vendors on board fast enough, we actually came close to a point of having to decide, do we turn off CI or do we stop serving images and break all our users? Thankfully, we did get an extension and were able to get enough coverage to get us through 2022. And you might remember at this time last year, AWS announced that they were going to start participating in the program. So things are now looking good. Now the costs are split between Google and Amazon for our CI and image hosting. Fastly has actually gotten involved and given us 50 petabytes of traffic a month of their CDN services for serving our binaries. Susie has also donated their resources for their open-build service, also letting us use them. And in 2024, it's looking likely that more vendors will be coming on board. So things are looking good now. There is some green, I swear. Let's see. The one thing that did, honestly kind of suck out of this entire situation, is it really did take a crisis for us to get all this additional engagement. We are trying to find ways to surface this information better and earlier to avoid us coming to a point where, again, we're having to potentially make the call of, say, shutting down CI or stopping to serve images and just breaking a bunch of people. So, but yeah, things are looking good. So with all the insights that Bob has talked about, you have seen a common pattern that we derive a lot of insights from how our community is working and shaping up through the annual reports. And the survey, really great way to know what the six are up to. But the problem is, the annual report process has not been very great, and several sigleads have bubbled this up to us that some of the points in the annual report that they have to mention are kind of repetitive, can kind of be automated, and hence it results in a lot of toil for them, but the returns are less on that end. So we know that the reports are very useful, and both the leads and contributors have used them to justify what they work on in the community to their employers just because of these reports. So we want them to continue. But the thing is, we want the reports to be having as less overhead on our community leaders as much as possible. So the question is, what are the meaningful parts that we should keep in the reports, and what are the things that don't serve much value? And those are the parts that we should take out of the reports, and the parts that are generated or can be generated from metrics that are already there in the community, they should probably be generated and not be gathered by the community leads and put into the reports. So we want is, we want to know what works for you. We want to know from the audience and from our community leaders on what has been working for them in the annual reports and what hasn't been working for them. So that we as steering committee can change or improve the process for the next cycles. And you saw that we got only two-thirds or 70% involvement from the SIGs in terms of filling the annual reports. We really want all the SIGs to fill in the annual reports because that serves a real great value. And one value I personally think is very important is that getting the annual reports and showing them to your managers or your company's leadership lets them invest in you so that you can come to the community and work in the community and grow the community. If you have thoughts, please reach out to steering. And with that, we are kind of, at the end of the agenda, we'll come to Q&A. We actually are pretty close on time. I'm kind of surprised. Oh, wow. But before we move on to Q&A, we just wanted to let you know how do you reach us. We are in the public Slack channel called Steering Committee on the Kubernetes Slack. You can join the Kubernetes Slack by going to slack.caters.io and get an invite for yourself. It doesn't take much. Or you can join our mailing list, steering at dritkubanities.io. If you go to groups.google.com slash g slash steering, I think you can join the mailing list. But then if you just go to the GitHub repo, kubanitieslash community, you will find all the details on how to join the mailing list, how to join our meetings. And if you want something from us, you can always file an issue in kubanitieslash steering. Big, big, big thing is we do really, really want to know what is useful to you in these reports. Not just our community members, but like as an end user, or potentially someone that is a employer of people that might be contributing. What sort of information would be useful to you to help continue to justify a commitment to the project? So if you have any ideas, please, please, please, please reach out. We have one minute left, so I think we can take one. Yeah, we can probably go over to you. Does anyone actually have any questions? That was also kind of a whirlwind and I'm sorry. We can also freely take stuff after this too, if you want to talk privately. We have more steering community members. We got one, we got one. Hey, not really a question, just more of an answer to your previous question. So I'm a tech lead for SIG cluster lifecycle. We recently did a sub-project survey. So we kind of inspired ourselves from the SIG survey, but because cluster lifecycle is just made up of so many sub-projects, usually when we answer the SIG survey, it's like it depends on the project. So we try to do something similar so that we as SIG chairs and tech leads could have a better idea into what's actually going on in the projects. And one thing that I found really useful that I think it would be good to emphasize when we do these surveys is to encourage the SIGs to not have the chairs and tech leads answer it in their corner, but instead have like a meeting where they do kind of like a retrospective and then they talk about it. I have literally brought that up in every chair and tail meeting I've been in and talked about in reports. Yeah, because I sat in those meetings where sub-projects did that and everyone was like, whoa, we should do this more often. So I think, yeah, that would be a really great way to make it a conversation starter instead of a chore that people feel like they have to do on top of the million things that they have to do. The other thing that I've encouraged, like if you have someone in your SIG that is you're potentially thinking about promoting to a lead is to try and get them to lead that conversation. Because it's a great way for them to just get to know all the various sub-projects more and just get to know the people better. Yeah, I know a couple of SIGs where the chairs and tails have not written the report and someone else in the SIG who is contributing has written the report. And that's a great way to involve contributors. And this also removes confirmation bias. Okay, with that I think we can take it async. Thank you. Thank you everyone.