 Hello, everyone. Welcome to Friday, almost the end of the week. Welcome to the Kubernetes Steering Committee AMA session. My name is Christophe Lecker, and I'm joined by five of my colleagues on the steering committee. So just to introduce everybody to my immediate right, I have Nebroom, Tim, Ben, and then in front row, we have Stephen and Bob. We have a seventh member of the steering committee who wasn't able to join us today, Paris. And the seven of us lead the Kubernetes community. So a quick overview of where the steering committee kind of sits in the Kubernetes governance model. So if you have been around the Kubernetes community for even a moment, you'll probably know we have plenty of these things called special interest groups or SIGs. Each of these SIGs either has a domain-specific interest or they have a horizontal interest in the community. So domain-specific ones are things like node or network. SIGs that are responsible for a particular part of the Kubernetes code base and the Kubernetes stack. And then we also have horizontal SIGs that have more wide-reaching mandates across the community in order to collaborate between lots of different people doing lots of different things on a particular subject. Couple examples of those would be SIG architecture. So that's the architectural direction for the entire project or SIG contributor experience that is responsible for the contributing flow and both the experience of new contributors on boarding into the project, as well as providing services to experienced contributors like those who are leading these different SIGs. We also have bodies called working groups. Working groups are time-bound collaboration efforts within the community that are focused on a specific set of outcomes. Their goal is to spin up, to provide a forum to meet and collaborate on a particular effort, and then when they're complete in that effort, then they spin down. One of the key differences between SIGs and working groups is the fact that SIGs are long-lived and are ultimately responsible and own either parts of the code base or parts of our infrastructure. Whereas working groups are temporary efforts, they're designed to be spun down at the end of the day, so any artifacts that come out of those particular working groups will need to end up being owned by a SIG afterwards. So then we also have committees within the Kubernetes project. Committees are set bodies that have very specific governance mandates within the project. Three key examples are the Security Response Committee that is responsible for triaging and responding to security incidents and creating CVEs inside the project. We have the Code of Conduct Committee which is responsible for overseeing our Code of Conduct response efforts and doing things like helping resolve issues, provide resources and ultimately providing a place for people to go to ensure that we are a friendly, safe place for folks to collaborate. And then we have the Steering Committee. The Steering Committee is the top governance body within the project where we do two things. Number one, we are the key liaison between the Kubernetes community and the world at large. So those are things like our relationships with the CNCF, our relationships with other open source communities as well as anytime there's like an external query at somebody who doesn't know who to talk to within the community, they will typically come to kind of steering first and we can direct them to the right folks. The other thing that we do is we are ultimately the body that's responsible for governance inside the project. So that includes setting things like the rules around SIG charters, approving when new SIGs are created and any responsibility that we haven't delegated out to a SIG to ultimately be responsible for falls up to the Steering Committee. We are not a technical body. We do not make technical decisions on behalf of the project. We very purposefully delegate those out to SIGs and to communities within Kubernetes who are better suited to make those decisions. We strive basically across the board. Anything that we can find the right people and delegate to, we will. But for anything that there isn't a solution already and we need to kind of figure out a particular problem as far as who should or the right stakeholders to address it and things like that, those kind of all roll up to the Steering Committee. So after that kind of brief intro about who we are and what we do, we are going to open it up to questions. The group up here has many different experiences from years of work on different parts of the project and we're happy to kind of engage with the community and answer any questions that you might have. Thank you. Hi, thanks for having us, Amy. My name is Natalie. I represent SIG Snacks, also known as Docs. I want to give context that I asked the same question in the CNCF Code of Conduct Working Group brainstorm and I feel like it's worthwhile asking it here. I recognize that the majority of the membership of the Steering Committee, obviously it's community voted in but the majority other than number one, congratulations recently on being elected, is North American based and I'm wondering, is there any kind of room for having some kind of minimum requirement of having a member possibly from another geography outside of North America as the group is continued to be voted in by the community? I asked because there's a lot of different perspectives and a lot of different geographies that I feel like sometimes have to be fitted into a North American mindset that sometimes we're not really possibly looking at in the right way. I think there is a possibility because I'm here, Nikita was here a few years back so there is a possibility for people from other geographies to be involved and get elected to the Steering Committee. I think the mantra which works is like, keep on like contributing to other areas of the communities where you get more visibility and then you eventually like grow up the ladder and then. Yeah, I think my question is more so, are you willing to create a mandate that you want always one role that is outside of North America? Because I think, like I said in the code of conduct working group, there is one way to have an open door policy, which is great, but you have to engage by having a purposeful mandate with folks that maybe don't realize that they're welcome to actually put their hands up and take part but maybe the messaging of the community actively saying we always want a role filled by someone outside of North America and the community can vote on who that's going to be. So what I'd say is we are a representative democracy inside of Kubernetes. We have seven seats on the Steering Committee but we represent tens of thousands of developers. I don't think that there is necessarily a way to lock in and guarantee that specific groups within the project are going to be directly represented on this body. I think it would be restrictive on like we, the list of people that run for Steering. This is a, I'll say it's a very intense job. It's a job that ends up taking a lot of hours and that kind of stuff. And the folks that in my experience, all the folks that I've worked with on Steering are incredibly dedicated to this community and to represent all different facets of the community. But not, there isn't a guarantee that people from all the geographies that we have within the Kubernetes community are going to necessarily have the time to do it. We have had folks like Nibroon who have been elected in Nikita previously. So we have had folks outside of North America that have got elected for their contributions. But putting restrictions and guarantees is tough. The one restriction that we do have on Steering in order to make sure that we continue to represent the community's voices, there's maximal representation rules on the Steering Committee. So I believe it's no more than one third of the community. No more than one third of the committee can be from the same employer at the same time. So in a seven member body, that means no more than two seats can go to the same employer. While in our Kubernetes values document, one of the things that we say very clearly is community over company. Another very common saying that goes around is like different companies, but same team. We're here to represent the community and we all kind of like take off our corporate employer hats. We all have employers that at least to a degree pay us to be here, but we don't represent their interests at the Steering Committee level. We're here to represent and do what's right for the community. There are ways that we can better engage with folks. I'll always say there's always room for us to do better as far as engaging and encouraging more folks to run. But I personally would be concerned if we put restrictions on like, oh, the seventh seat on the committee has to go to somebody outside of North America, that it might not always go to the right person who has enough time to be able to fully execute on that job. I would be more kind of looking towards what can we do to more purposefully engage with folks so they know what we do and are interested in running. So yeah, so at the end of every Steering Committee election, what we do is a retrospective with the election officers, right? That gives us a time, an opportunity to reflect on, do we like the platform? Do we like how we engage with the community to get people involved and interested in running? One of the topics that came up is, do we feel that candidates who are maybe outside of North America or don't have maybe the same platform that certain people do have the same opportunity to serve on the committee? And can we do something better there? Again, I agree that these should be seats elected by the community. So what we can do in the community is try our best to diversify across geographic boundaries in each of our SIGs, our working groups, our sub-projects, what have you. I think, so I have been co-chair for SIG Release for a while, and one of the things that we do with the Release Team is it's geographic boundaries, it's employers, it's are you new to the Release Team? Have you been there a while? We try to get a kind of a nice blend between all of those people. If we're doing that across all of our, and I mean, if you look at new membership coordinators, if you look at areas in contributor experience where we do, like moderators say, we do want opportunities to kind of follow the sun in some of those duties. So I think providing people opportunities that are geographically diverse on the community level will naturally encourage more diversity across the steering committee level, too. I've got a couple of thoughts. First of all, thank you for raising this. I think it's an important issue. So you specifically called out North American. I'll jokingly refer to Kristoff. He's North American, but he's not US American. And on a few occasions though, this has come up where he has been able to represent an international audience in a way that us Americans weren't quite aware of. So there is a little bit, and Naurun also now brings a different perspective. But this has been a huge issue for the project. Even if we're all in the same nationality, exact same culture, we have different time zones. And it's a big problem. The Release Team and Cigar Lease have done a good job over the years of modeling, trying to shift the times around, but it's hard. I know on another committee, Naurun had a lot of challenges around time zone. I know Nikita with Steering had challenges. It's a big deal. We as a, like Steering is responsible for defining and defending the values of the project, but values become human squishy things. And we all have to step to valuing, having empathy for others who are somewhere different and sharing some of the consequences of that. And it's a challenge. I don't know that we can prescriptively define something, but I also kind of like the idea of maybe picking a few things and codifying them and seeing what happens. It wouldn't be a terrible thing to try. And then one last thing, looking at us here. Well, I was looking to see that you didn't show that, but looking at us here today, there's at least one thing that we don't represent very visibly. And we need to think about that and actively work to make sure that we are representing all of you, because it's fairly clear that there's some differences out there compared to up here on the panel. And that's important to address. And then one last thing on that, China. China's not here at this conference. We are no longer, with COVID, we haven't been having a ChinaCubeCon. It's a risk if we have a split there as well. So we need to actively step to these things and try to figure out some solutions. I'm new to Steering and I'm really interested in ideas for this. One thing I'd say is that, as long as it is a community elected position with only maximum representation from the employers for optics and so on, one of the difficult things is even getting people visibility from other employers. At our SIG testing talk that I gave, we wound up with four Googlers because one of them joined Google since we planned the talk. And it was hard to find other people that were willing to come do this. Even some people that want to come, their employers won't send them. I'm really interested in ideas. I've been working a lot to try to bring up leadership in my SIG. And I have mostly wound up with other people at Google because I'm struggling to get other people engaged. It's hard to get employers behind people. And some of the big employers are very North America based. So one least quick comment going back to the retro and some of the ideas we're originally brainstorming to try and get people more exposure. We've done sort of steering AMAs for people that are potentially running for steering to come ask questions, but there isn't really a good place for the community to ask the steering candidates, the people that are running to ask questions. So you do sort of naturally bias towards the people that you know. So hosting some AMAs for some of the panelists, some other ways of just like getting a bit broader exposure for the people that do want to run might be a way to try and like help work with that. But it is something like we are actively thinking about. Yeah, I think I'd just like to add one more thing. I've been talking to people like in this conference on how do we actually replicate what we did in SIG release and in the release team to other SIGs and can we as steering have, since we are a governance body, can we make some sort of policy, may not be a mandating policy, but suggestions to SIGs on how they can learn from what has been done already in the past to promote like people from other geographies to at least like come up, show up in the SIGs and just show up and then become like, and then even in this committee, we have to also work on like how do we work on asynchronous communication, how do we have lasigan sensors, sometimes some things become like really time bound, you have to like get decision maybe possibly in a couple of hours where you can't have like possibly include like everyone, but in most situations in all across the community, probably we can like replicate what has been done and like good learnings from running release teams, running mentorship programs. And I believe that is how we can have like representation across geographies and any other criteria that you define, geography is just one of them. I think Navarra answered the question that I was thinking about was, so we've been talking about this problems and like when I was on the steering committee, which was I don't know like two years ago, we mostly been talking about the problems. What ideas do you have in mind to solve this? Like there will be a next election coming, like another election coming up next year. How will you ensure that we have a diverse candidate for the election or be geographies, be I don't know, whatever, right? Like how do you ensure that? What is the solution? What are you thinking about? I don't have a solution, but I'll start with saying it's really important that we think about this over the next year because we can expect it to get worse. The economy's slowing down. We know that that tends to impact more people who are less represented. So this is a major looming problem that we should actively try to address over the coming year. I think NABROON brought up one important point that's been on my mind, which is making sure that more things are async or have like more meetings for other time zones or things. SIGRelease has done a really great job, but there are other parts of the project that are like very heavy on like mountain view centric meeting times and making decisions in meetings. So I think first, like one thing long term is we have to do better on making sure that anyone can participate and anything that isn't somehow tightly time-bound decisions. But also one thing is, so Syring has bound ourselves, you know, we can't like publicly endorse anyone else, but we can go talk to people and encourage them to participate. And I think that's something that we all need to be thinking about doing is like who do we go encourage to participate? And how do we help them understand like what to do to get to that point? I want to change one thing I said. I said underrepresented, I want to actually explicitly say historically excluded. Our practices in the project are excluding people and we need to change that. Yeah, as a Googler, we call, we even joke about this internally Google standard time because they used to literally even set the servers this way. It's just completely permeates and it's very hard to get people to undo these things, but we have to push on that. We need to, as the economy slows down, we cannot be picky about where people are from, where they're coming from, we need contributors from everywhere and we need to make it easier to participate. So one thing that we've experimented a bit with like in sick contributor experience, and this is something we could potentially consider, you know, codifying as policy is instead of, you know, having the mandatory recorded meeting requirement, we switched to doing Slack, like bi-weekly Slack stand-ups. And to be honest, we haven't done a great job of continuing them lately, mostly just because of lots of personal bandwidth issues, but when we were actively doing them more, like it was working out very well. It was also essentially, you know, we'd start the meeting on like, our normal meeting is Wednesday at noon, or CET, and then we'd start the meeting on Tuesday, the Slack meeting on Tuesday and it concluded on like Thursday night where each topic was basically a Slack thread and then we'd take all the Slack threads and roll them up into meeting notes to try and just be more sort of like async friendly. There are options for us to explore there. The other thing is like, I really think that the gateway to steering in general is our like SIG and working group leadership. So like making sure that we have a pipeline of getting diverse candidates into these leadership positions is the eventual path to like steering these other things. We've been trying to do it for like, we were thinking to experience as running a mentor, a leadership mentor cohort right now to try and bring more diverse people into our leadership positions. So that way like myself, Christoph and Nikita can eventually step down and we'd really like this to continue where we are intentionally trying to bring more people, more diverse views into leadership and that should like bubble up to steering. So yeah, again, I don't think we have any perfect solutions for this, but there are like when I was thinking about the SIG release stuff and the timing and for when Tim and I were doing it, I think for years we were just, we were like, okay, well the release meetings at this time and we didn't realize that we were just kind of biasing towards Google standard time without thinking about it. So like we refactored this a few years back, but going to trying to solution some of this active sponsorship, right? You need to like each of us have kind of an orbit, right? Within the community, within our various SIGs. You should be actively looking to sponsor leaders, right? Not just on the group level, but on a personal level. You do need that. By the time we get to the steering committee AMA, we're pretty deep into the process. And those are folks who already knew they wanted to do it and not so much the folks who needed the extra push to say that they can do it. So I think that we need to take a more active stance in doing that. I had more words, but they're gone now, so cool. One other thing that I'd like to mention there of something that is actively in process. So Bob was mentioning kind of a path. One very common path to steering is through our SIG leadership positions. One thing that we have been talking about and trying to push forward is the concept of terms in those leadership roles as well. So steering already has terms. There's like an election cycle and we all have a particular term that we're elected for and taking on. But in those SIG leadership positions, I will freely admit I'm guilty of this too. I've been a Contravex TL for six years, something like that, which is good from a stability standpoint. It's not great from mentoring folks into those positions. So like as Bob was mentioning, making sure that there's opportunities for folks to be able to take the reins themselves and to move up in the community and to have opportunities to gain trust, gain influence, gain reputation within the community and eventually maybe move up into a position like steering. And that concept of terms is more just having checkpoints for folks. And it's like when you take a role that this isn't indefinite forever and that until you like say uncle and actually give up. Like no, there should be more regular checkpoints for a lot of these leadership positions in order to say like, do you still want to do this? Or do you still have the time in bandwidth? Or should you start thinking about mentoring up somebody from within the SIG to take that position over for you and to be able to take that lovely, glorious title that married us and to take a step back? Do you want to continue? I ended up, I would briefly, thank you. Terms have been one of my pet issue for a while now. When I got nominated to SIG ever since then, I've realized that like this is broken. We have all this wonderful ranked choice voting, maximum representation, we have all these things for steering. But then steering turns around and delegates most things to the SIGs. And the way SIGs tend to run things is someone decides to step down, they nominate someone on the mailing list, it's a public announcement. No one's gonna show up and say no. That person is now the chair, that's it. And it is for as long as they want it. There's no way to rotate people out. So in lieu of that, with a close read of the charter, one thing that we tried this year, very recently in SIG testing, is that there isn't a actual hard cap set on these positions. So just trying to find some people willing to do it and add more people and not keep it to the same two or three while we figure out how we checkpoint and rotate out people, just go ahead and bring on some new ones immediately. I think that we have got to get people visibility, but I also need people willing to step up because even in these other positions reaching out to people that have been participating in the groups, it was hard to find people willing to take on these positions. And if you don't take on positions of visibility, you're not gonna get elected to steering. Yeah, so I want to shift gears a little bit here. So KubeCon Contributor Summit, these are great places to facilitate these broad community-wide discussions. But what I want to know is how can we keep that going because what I've noticed ever since KubeCon EU, that was my first KubeCon, so that's my point of reference. So whatever I've noticed since then is that we have these really important discussions, we have these real problems that we need to try and address, but once KubeCon is done, the broader community sort of either loses track, loses context, and then so on. So how do we keep that discussion going? Because I love the community and I wanna do my part in helping out with these problems in some small way or the other, right? So how do we facilitate that? How do we actually brainstorm the smallest possible way to actually do something about these problems, right? Like it shouldn't just be discussions over and over again and it shouldn't just be that we have problem A, problem B, factors C, factors D. How do I do something about it? So I think at least with KubeCon EU this year, the biggest thing is that we didn't assign note takers and we didn't actually record the AIs from the very good discussion. That was honestly like a, our bad is organizers. I think going forward, we do have those notes and we do need to like post-KubeCon actions and to turn them into issues, turn them into AIs and things like that that can be tracked and assigned and worked on. And I think that's going to be plus like, honestly just people to continually ping on them. And I think that's going to be at least the, one of the best path forwards for really teasing out the stuff that comes from those great in-person discussions. For terms, there's an issue from four months during the, it's open that we just need to bring the discussion back to if you're interested in that topic. I can also tell you that now that I can see kind of some of the backlog and talk to folks on steering about some of the things that they're, not publicly discussing or things have come up with like code of conduct or whatever, that unfortunately at the moment these folks are spending a lot of time doing very visible or non-visible firefighting. So we could use some help reminding us to keep coming back to these things as I can tell you my whole week this week has just been trying to stop the Kubernetes project from shutting down all of our infrastructure because we're about to exceed our GCP credits like next week and getting the CNCF and other folks to take this seriously and fix this and we're okay now but we have just been running around talking to people, trying to sort that out. And it's not very visible and it makes it easy to forget about the other things that were, the other important things we're working on. I don't know about everyone else but it's hard to keep on top of. So if you can come back to one of these things or file an issue or email steering or just anything to bring us back to these topics. I mean, some of it needs to be on us but also understand that like there's a lot of things going on that not everyone can see for various reasons talking to the CNCF and their closed governing board session or whatever that is very distracting. Just to clarify, it's not like wanting steering to come back, it's more like, okay, how do I put these discussions out for the broader community to also take a look and then let the community also help you solve it. There's a steering repo and GitHub, file an issue, public discussion, other very common ways to engage with us. So I've got some of them up on the screen as far as our email lists, when our meetings are, all our meetings are recorded, our Slack channel. There's also a couple, some of these broader discussions around like how should we govern like SIGs and to share thoughts and best practices between SIGs. There's a chairs and tech leads channel in Slack as well where all of our kind of different SIG leaders and that kind of stuff bounce ideas back and forth. Most of our SIGs are self-governing and kind of set some of these policies themselves but then there are discussions between, okay, how do we share best practice between everyone and how do we take a working best practice and codify and say, no, actually this is not a requirement because we need this kind of ubiquity across the community. Yeah, to Ben's point, I think there is a lot of time consuming and emotional work that happens behind the scenes. I would say that that is 70% if not more of the job. And like sometimes we're able to reveal what is actually happening and sometimes these are conversations that are happening over months, over years. That's until we get the resolution, we can't pop out, show work around it. I think in terms of if we're talking about not just steering, like one, we have our, again, we have the repos, we have the mailing lists. There is also the funding repo for specifically talking about funding something within the community. Steering helps, steering helps capture and execute on those actions. The, I think in terms of like any time you're coming to a talk, an event, a contributor summit, what have you, think about your outcomes, right? Not just outcomes for you, outcomes for the community. We are all in this together. So if there's something that you wanna see happening, keep pinging people about it. Make sure it's visible. Make sure you're vocal about it. There are lots of places to do it, depending on the, depending on the SAIG, the working group, what have you. But we do need to make sure that we are keeping the work as visible as possible and that we're all, like we should all know that we're empowered to help do that work. So it's not just a, it's not just a, we're missing out on note-takers and we didn't capture the AIs. It's everyone's responsibility, honestly. And we represent all of you, so hold us accountable. It's easy to open an issue on GitHub, drive conversation there. It's been, and Stephen have alluded to, and not really explicitly stated, is a body we try to operate from a consensus basis. So at the point that we make a statement on something on behalf of the project, we want it to carry weight and be authoritative. That can be a challenge. We may spend months on something that's visible or very frustrating and causing people even to leave the community. And we've struggled at how we efficiently arrive at a conclusive stance on something. I think we could probably do more of that on public GitHub issues, broad open discussion. That would be a good thing. But there are also some of these things that are quite fraught and we have to be a little careful and sensitive on how we discuss and explore the possibilities because we don't know everything and it's easy for each of us individually to put our foot in our mouth or perhaps do that on behalf of the project. So there's a weird balance there, but push us. We report to you, the community. Okay, I think we have time for one more question and then we'll have to wrap up for today. Sorry, I didn't mean to be the last one, but excuse me, just listening to what everyone is asking and you guys talking about those issues, the one question that comes to my mind is seven the right number of people. When the Kubernetes project started, we had a much larger committee. There was an original bootstrap committee that was just a whole bunch of different community leaders getting in a room to kind of set the initial charter and figure out how do we govern ourselves? Because we didn't really have a lot of past information to kind of go on. So we kind of had to blazer our own trail and figure out how we were going to govern ourselves. We eventually decided to scale down to seven seven as a special number within the Kubernetes community. So, and we wanted to have kind of an odd number. So if we needed to vote on things, that we would be able to kind of make a decision to move forward. It has actually come up before, do we need to add more people to the committee in order to expand the work that we've done? We've also had discussions around reducing the size of steering and having more people kind of out in the community doing things and reducing maybe the scope of what steering does. So we've had discussions kind of both ways, but every time we've had those discussions at least historically, we've always kind of come back to, no seven is the right number at least for now. But all of those things as far as like the membership and makeup of the community are all kind of open to us to kind of decide what our destiny is and do we have the right number of folks kind of on this committee. But unless we're going to have a committee of tens of thousands of folks, we're never going to be able to be 100% of the community. So there's always going to be some degree of like, we need the help from the community in order to drive things forward. I like the idea of having broader representation. It could also drive us more towards some of that asynchronous communication and written communication planning. As an example on a couple of occasions, and we've actually tried to set this as a regular meeting point, but the code of conduct and steering committees have tried to have joint meetings. And across those 12 people, it's almost never happened because it's impossible to get together. But that is the proof point that if we want to do more representation, we got to shift how we do it. And it's possible. So yeah, so I think there is no right answer and having been on this steering committee to do a group steering committee and like a few governing board things. The question comes up all the time, right? And I think with the, okay, yeah. And I think with the one, to Tim's point about driving consensus, like with seven people, we're already finding that like the glue is weird, right? So like, I don't know, like I honestly don't know the answer. I don't think more or less would be easier to drive consensus. More would bring in better viewpoints, different viewpoints. What's, you know, I guess what the hope is, is that we find mechanisms for driving consensus faster and bringing those issues into public when we do have resolutions faster. So also very few people ran this last time. We only had a few more people than seats. So if you're interested, please reach out to any of us and talk about it. Because at the moment, it would be hard to staff a larger one. It wouldn't be a vote. It would just be everyone that opted. Thank you so much everyone for joining us. If you have questions, again, here's how to find us. And we're also very friendly people. So just come up and ask. Thank you.