 It's good to see all of you. Welcome. You have made it to the TOC open meeting at KubeCon. I am Amy Skibarta-Paran, Director of Developer Programs, standing in for Chris Anacheck, and it's lovely to be able to see all of you. We're here to be able to talk about TOC, and I'll let them introduce themselves. The Technical Oversight Committee. Emily, take us off. I'm Emily Fox. I'm the Chair of the TOC. I'm Kathy Jo. I'm the TOC member. Ricardo, also a TOC member. Yeah, go ahead. Katie Gumanji, TOC liaison for up-tech delivery, as well working for Apple in my other team job. Hi everyone, I'm Nikita Raghunath. I was newly elected to the TOC like two months ago, maybe, so I'm still very new at this. Welcome. Welcome. Welcome. My name is Robert Z. We are aware. I'm also a Kubernetes maintainer, and I am a liaison for tag runtime and tag storage. I'm Richie. He's also a TOC member. Yes. No, he's not. He's here on purpose. So what I'll do is I'll kind of give a quick overview of how this all works. And as I do this, feel free to be able to put up hands, to be able to tell us like, you know, anything you want us to be able to cover, I'm happy to be able to pause and do that. But as we get started, how many of you, this is your first time at KubeCon? Okay. All right. And for those who have been here before, how many of you was just your first time at a TOC meeting? All right. So we're going to start from the top then. You've seen all of these lovely people. There are a few more that haven't been able to join us today. Don't worry, the slides are online. It's fine. And all of these people are all volunteers. They are elected by the communities and various different groups, and they all come from the community as well. So they have deep background as engineers and security research and people working in the community with the projects. And in order to be able to talk about that, I kind of have to talk a little bit about structure here. So we kind of have three different areas within the Cloud Native Computing Foundation. We've got a governing board that then has a marketing committee underneath, the technical oversight committee, which really kind of oversees projects, then focuses on being able to build out technical advisory groups. I'll get to that next, but these are kind of our top 11 technical folks as far as being able to engage with projects. They help admit new projects. They help move projects around levels. We'll talk a lot about all the work that they get to be able to do day to day, and sometimes they work with kind of other initiatives within CNCF. The way that people are elected are they're coming from governing board and user and developer kind of communities, and happy to be able to go into that further, but that's kind of the important part. And on the side, we've got kind of the end user community, which also comes in to play and brings out other initiatives as well. So talking about tags, tags are our technical advisory groups. This group also gets to be able to work with those technical advisory groups. You don't have to be a member of like a company. You can just come and participate in those groups. And these were tags. We have storage, security, app delivery, network, runtime, contributed strategy, observability, and environmental sustainability. So kind of where we're getting started. Other piece, before we get into this, we have three different levels of projects in CNCF. You've seen some of our graduated projects, our incubating projects, and our sandbox projects. And we can talk about what all of that means as well. So I'm now going to kind of come back in here and kind of kick us off about you as TOC members. What do you wish the community knew about your role and how this all works? And Richie, because the mic is closest to you, I'll start with you. Well, actually, let me pause and kind of like set some of the stage here as we, because not everyone that's watching the recording is going to be able to see that show of hands that we did in the beginning. And roughly half the room was their very first time at a KubeCon, and maybe like 15%, that's their very first time at a technical oversight meeting. Maybe 30%. Maybe how much thankless TV is worth this, actually. It's not very glamorous. You're putting a great spin on it. Thank you. Yeah, I think that's it. Just probably just some context about like what we, so CNCF has a ton of projects, and if you're recording, like, you know, the morning, you're probably familiar that we have like 150 plus projects in the CNCF landscape, and it can be very confusing. There's so many projects, it's just a little too much. And the TOC is responsible for, so like Amy said, the sandbox incubating and graduated projects, and the TOC is responsible for deciding which projects get into the CNCF and how they move between levels. So our job is to do due diligence on all of these projects when they get inside the CNCF sandbox and also like when they move between levels. And the due diligence work, like it's a lot of work. Definitely. We also talk to adopters of all of these projects, like we do adopter interviews during the due diligence process itself. There's also like the health of all of these sandbox projects, we do sandbox annual reviews. We can actually talk a lot about annual reviews and the work we're doing currently. And just like any escalations that come up between like among all of these projects is also something we handle. So there's like a lot of things going on. Go ahead. I think that's a very great encapsulation of the overall workload we have to go through as the TOCs. I think we are at a stage where I think everyone here is worried that we are a very skilled growing community. And this means that we actually need to put processes in place to be able to sustain that growth. Everyone is familiar with the landscape. I think it's shown as a meme most of the time. It's shown to kind of highlight the size and complexity of our landscape. However, for the TOC, this actually means that we are one of the fastest growing open source communities out there. And we need to put in place all of these processes and to evolve these processes accordingly. So I think we are as a community, we are at the stage if you think about Kubernetes, because I presume most of us are familiar, we're at the phase where you need to introduce HPA, horizontal part of the scaling, vertical part of the scale, like we are the scaling phase. And this is where we need to do that not for containers, but for people and processes. All right. So I will let another view, which is if you would ask me what I would like people to know about the TOC that I didn't know at the start, I would say that how rewarding it can be. It's true that it can be quite a bit of work. But actually you get exposed to a lot of different areas that are very far from your day job, probably, because there's so much diversity in the landscape. Maybe you are focusing more on storage or more on runtimes, but you end up working with a lot of different projects, not only the projects, but also the end users. As Nikita was explaining, the due diligence involves a lot of contact with the end users to understand how the projects are used. All of this is extremely rewarding. It will broaden your view of the whole landscape and the experience as well. Yeah, I think they already summarized very well what we do. I think I would like to add that is we also, if we see in the process or in the criteria of a party moving level, it's not clear. I think we're working on that to make it more clear and also consistent so that people think when we evaluate the project or prove a project to move from one level to another level, it's kind of like objective. The last thing I'll add on to that is I wish everyone knew that the TOC is more than just a lot of work. It's also more than just a lot of rewards. It's also about striking a good balance. A lot of the things that we do is not going to satisfy everybody's needs. It's not going to make everybody happy, but we're trying to do what's in the best interests of our projects, of our community members, and to the doctors of these projects, which means we have to consider a lot of different factors. We also need to design our processes for the most common lower denominator, meaning what's going to work for the most amount of projects and where can we have subjectivity that makes sense for them because not every project is the same. Their maturity and their growth life cycles and how they do development and releases is going to be very different and that's going to be even more different depending on the technical domain that they follow. Security projects don't necessarily like apt a little bit of projects, so it's all very different and we have to weigh all of these considerations together when projects are moving levels. All right, happy to take questions from the room. I'm happy to make up questions too. Yeah, go ahead. So hello. First of all, thank you very much for holding this public session of the TOC. I was wondering, could you like zoom in a little bit on this balance because I get a bit of a mixed feelings here at KubeCon. On one hand, we are all very happy here and it's a community and we're friends and so on. And then you go to the sponsor booth and you notice that, well, not everybody's friends here or not at the same level. And I assume that this must be putting a horrible pressure on the technical oversight committee, right? I mean, there might be money at the table, investments waiting, which are quote, blocked potentially by you promoting a project. How do you, what are your thoughts around this and how have you felt this kind of constant challenge to between community and still making businesses work? That is an excellent question and something that I couldn't have made that up. That was wonderful. Thank you. You started us off with the spiciest topic of the day, I think. This is actually something that we're currently working on and still trying to solve. There is a lot of companies and invested individuals behind a lot of our open source projects, but not all of them. Let's be clear about that. And many of them are very interested in seeking graduation, getting to that point, because that is a huge milestone for them. They've grown. It's basically like releasing a brand new product, in some cases, because you've put in the hard work, you've put it out there in the community, and somebody has said, this is a fantastic thing, it's mature, it's stable, it's working. And you want to get there as fast as you can. But you can't just run headfirst into that wall. First you got to learn how to crawl and then walk and then run and that's really important. And for us, we're trying to see what those stages are with the existing projects that we have and figure out what works and what's not working. So right now we're seeing a lot of stuff that's not working as we originally intended or as was designed as part of the ecosystem. And we need to be able to pivot and change because projects needs eight years ago in CNCF when it came in are not the same as project needs today, and they're not the same as a doctor needs from then to now. So that's where the balance is and we're trying to figure out how to stand on either side of that balance beam and make sure we don't fall off. The only thing I would have to what Emily said is that I think that's one of the good things of having also a diverse set of members in the TOC is that what you describe is mostly about projects, but actually some of the members of the TOC come from end users, not necessarily from projects. And this gives us different views to kind of balance, like you said, the interests of both the adopters and end users from the other side of course the projects because there's a lot of things involved, but this diversity really helps with getting this balance. I actually walked us back in the slides to be able to highlight this because the technical oversight committee is actually composed of like a bunch of different people like pulled from these groups. I think maybe to highlight the message here is about setting the expectations right because we have a bunch of projects that would really like to have big announcements around KIPKON and they would like to showcase the latest work, which is great. We're not against that. The only thing is they come to us, all of us, with all of these due diligence processes that we need to do just before KIPKON or just two months or three months before KIPKON, which is completely unattainable for us to do. And going back to the point that we want to set the right expectations and to actually perhaps take some of the pressure from the TOC to deal with a lot of work like in a spike kind of level. It's not something that's consistently done, it's something that we need to spike around. We want that to be distributed around our work time because we are here volunteers who work, well it's not work, it's like we do this in a way part-time, but we need to do this consistently to not burn out because we still have full-time jobs. So going back to the point of setting the expectations right, I think what we've done we actually introduced the notion of a freezing period before KIPKON, so the TOCs will not be able to vote for a project. And this is actually helpful for us because it does set the expectations right for the projects, but at the same time it does make sure that we have a very kind of uniform and consistent workload in between KIPKONs, not just before KIPKONs. And I'd echo that. It definitely is a work in progress. We are constantly trying to iterate and change how we're actually like basically participating with the community. Other questions from the room? Yes, here, we'll give you a mic. And you can come to the center as well, that's fine. So for those of us who are in the backlog of projects that you're evaluating and working on, it can often be difficult for us to see progress. You guys may be hard at work or you may be looking at something entirely differently, we just don't have a lot of visibility into that. So how can we stay informed as to the progress without absolutely drowning you in status update requests? Very quickly, I think the easiest plan is public TOC meetings. I think this is where we get the latest updates. We actually try to improve our transference in the processes, Github. We try to move a lot of conversations there so we don't have to wait for a meeting once a month. We can do them as soon as much as possible. So Github for the TOC, Github, public meeting and then have the meetings as well. So I think these are the three ones I would recommend. We also have a TOC channel in Slack and I would also add on to that that we're aware that you all would like to get better transparency into where you're at. We're trying to institute some smaller initial changes at least to convey where projects are at in an evaluation if we're reviewing you or if there is a backlog, we're trying to get everybody organized so that you know where you're at in the process or when you're coming up. It's not ideal right now. We are trying to look at different ways of increasing that transparency, doing things more in like an open source project kind of style, maybe leveraging our project boards a little bit more accurately because I don't think that we use them quite as well as we could be. We started that with Sandbox projects, so you'll see those changes. We do have a project board for that. We'll probably do a little bit better there, but we're trying to figure a lot of these things out. It's a lot of work in addition to just doing the moving levels and the due diligence associated with projects. Yeah, actually that brings me towards one of the good slides here. So we have regular meetings. We have meetings on the first and the third Tuesdays and one of the things that we've implemented and I will absolutely pass to Nikita in a moment. We've started implementing being able to say each TOC member goes through the projects that currently are on deck and we give updates at those meetings as well so that the community does know where things are moving and yes that's once every two weeks, but that's once every two weeks. Nikita? Yeah, just want to add on like the kind of actions that we're taking because we're also aware of this. So for projects that want to move between levels, we hear the frustration and that contributed strategy is also actually helping us to collect community feedback from maintainers and community members. So they're spinning up a short term group to do this and they're looking for like leaders who can step in to lead initiatives like this. But this is absolutely going to happen and we're looking to collect feedback in a more structured and organized manner as well. Great question. Thank you. So we're looking for your feedback. As part of that, we're extreme as well. Anything else? We're good? Okay. Oh, okay. We have a mic. We're running around. We're happy to be able to take questions. It's for the recording. Okay. So what's the difference and what does it mean from founding perspectives to be part of incubating project or sandbox projects from the funding? Why would I come with my projects and my contribution to this? What resources I can have? Yeah. So everyone joins at sandbox level. And at sandbox level, you're basically a part of the CNCF. So you can say that you're part of the CNCF. You also at this point have to transfer all copyrights and everything in the GitHub organization, everything to CNCF. So there is the stewardship and you can't just pull it back out of them. So we have a certainty of continuity of the thing. But you don't get much else. So you don't get any marketing support or any other major support at that phase. And this is by design, because a lot of, for most of the projects are in the sandbox phase. And a lot of them will also probably stay in the sandbox phase for the entirety of the lifetime. At incubation and at graduation, you actually start getting marketing support. You start getting more resources from CNCF. You start getting, for example, maintainers updates. You're in QCon where you can talk about the project. This time during the keynotes, we have the graduate projects giving five minutes updates on their recent progress. So basically, you just get more and more support as you progress. The other thing which this does, it signals to the end users that the TOC and the wider CNCF community looked at those projects and they actually gave them a certain stamp of approval. In particular, once you've graduated or once you have used a graduating project or the project you use is graduated, that's the right term. You know that they did cross the path and you know that this project is very unlikely to just go away. It's going to be stable and you can use it for production if you don't have to have too much concern about what's happening within the project. So for sandbox party, you can think of as a very starting stage. So that's, you know, the stage you start to build the community to have, you know, more diverse community, right? For incubating, it's more mature. You will have some, you know, not just as, you know, more diverse community with different people from different companies, right? And also some end user adoption. For graduating, it's more mature. So we have the criteria that these 15 of the different projects in different stages with the criteria. I think marketing support, that's a very important point. The sandbox is like, you think about it, it's not like, maybe I can say it's not very officially kind of. Um, the sandbox projects are really like, we think of them as like good experimental things to be like trying on, like the, it might work, it might not, we're not totally sure, but we think it's an interesting direction to kind of like look down and kind of like follow that road down. If it doesn't work out, okay, that's fine. There's not a lot of attachment to that. Yeah. There's a follow up question, positive for follow up. Go ahead. So I think in the sandbox, it's you're offering like a protection from outside, since you said copyrights and open, um, like an organic organizational point of view. If I reframe it, it's more about this project is going to be here in some form. It's protected in its space. Like it's, it's protected in this little like snow globe sort of thing. You're allowed to be able to build out more, but it's going to be here at least for a bit. Yeah. Thank you. Yeah, of course. Can I, I think, I think it's going to pass around the mic a bit. I think going back to the reason why you should be CNCF. The thing is open source is very difficult and challenging to accomplish. And CNCF is one of the ways to get a platform of support for your project. And this means that, first of all, we have, excuse me, first of all, you have all of the tags that will be able to provide guidance and support in these sources for the project to mature, because ideally we all want projects to be successful and do the next maturity level. But at the same time, um, it's, it's up to the, the sandbox to get all of that kind of work and out to the tags and work with the feedback and implement that and slowly grow. Um, as well from the end user perspective, it does bring some sort of confidence as well that this project is within the foundation and there is like some projection for the project to an evolution. Um, so I think it's not necessarily, yes, you have to use this project necessarily, but there is a level of compromise this build around that. Just one quick point that it also provides a wider neutral space for contributors to work on the project. Like there are a lot of projects which I don't get how which are open sourced, but then, uh, like you mentioned, like end users might sometimes not be confident to use that because they're like, eh, it's like single vendor driven, maybe it's driven by a single company, but if it's in the CNCF, uh, they can be confident that's a wider neutral space and other companies would also be interested in contributing and collaborating on it. So I want to just highlight real quick here that not every project in open source needs to be cloud native. Um, that's kind of important. The whole point of the CNCF is to make cloud native ubiquitous and that's something that we're really trying to do. However, we also understand that not every technology fits cloud native model. Um, that means when we're reviewing projects, both at Sandbox and at other phases of their life cycle, we're trying to figure out whether or not they're still headed in that direction. Are they still cloud native? Are they still applying our values and our principles when we're looking at them, when they're engaging with our community, when they're designing our projects and building their architecture to ensure that their project is going to meet the needs of the use case that their potential adopters are going to be looking for. And if a project comes to us and they're not cloud native, we'll tell them and we'll probably recommend an appropriate foundation for them to belong. But one of the nice things about cloud native is it is actually extending outside of our ecosystem. We're starting to see more projects that are interested in reaching deeper into the infrastructure stack down into the networking layer, understanding what's going on within the kernel, as well as all the way back up to the application layer that doesn't really apply in cloud native, but it is a user level kind of experience. And we want to ensure that we're considering all of those areas when we're looking at projects. So some decisions that we make in the past about whether or not to accept or reject a project might change as we continue to move forward. Yes, question from the room. Come on in. You talked about shifting conversations to GitHub. And I really appreciate that written culture and it adds an element of both asynchronous and accessibility and inclusion. I was curious if you've considered, and I know from the few of you that I know up there, you represent at least three different continents, and this is fairly impossible. But when you're not asynchronous, high bandwidth conversations are super useful. But have you thought about having varied meeting times? Like you've got two meetings are both at 8am Pacific. I'm going to say that most of us joined the TOC when that time was fixed. Yes. So it's not something that we have ever thought of. It doesn't mean that we couldn't. It's mostly because, yeah, that one, the people in front of you represent a very busy group in ways that their calendar doesn't always allow for space to be able to change things. What I think I hear more in that is not so much being able to do varied meeting times. It's how can you expand the high bandwidth conversations into something that's more accessible? So we do make sure that all of the public meetings are put onto YouTube. So there is a recorded video to be able to come and participate. But I am thinking about how can we make more of the information that we have here more available and accessible? So even though I don't necessarily say, yes, more meetings, more meetings to the answer, I'd love to be able to hear more feedback from the community on what else we can do beyond moving more to a written culture of communication, which I think is one of the threads running through this. We understand that in order to be able to scale even further, we're going to have to change some of the processes that we've been really reliant on. We've been reliant on a meeting culture and moving forward, I think we need to rely more on a process and a more automation driven. So expect to see more project boards, expect to see more bite size updates of where pieces are moving. What do they miss? Okay. One curiosity, which is there's also good things about this, which is for example, when we have to reach out to end users during due diligence, we can easily spread the load across where the end users are located. That helps quite a bit instead of having to have like crazy time meetings because where the users are located, we can actually spread between ourselves according to locality. That's one of the good things of being distributed. Other questions from the room? Thank you, Bill. Quick one. Will we see more archived projects in the future, or will we just keep growing? I'm going to tell you right now the answer is yes. There are some processes that don't yet exist that we are currently trying to figure out how to pull off. We have a lot of projects. 159 was the last count. They're distributed across all forms of the life cycle. And the only thing that we're doing annual reviews on right now are sandbox. We are very aware that as projects move through their lifespan, particularly when they get graduated, there are not a lot of checks and balances on how they're doing. They could be doing excellent. They could be doing amazing things, but we don't really know until we get a cute kind of graduate project updates. However, in a lot of cases, they're not quite doing as well as we would hope. We want to be able to reach back into the projects and understand what are their challenges? What are some of the successes that they're having and where we could potentially help them with their maturity? And the same thing applies for incubating projects. We need to be able to ask them those questions and also understand what indicators are going on with the projects, where they might be too busy dealing with something that they can't reach out and ask for help. And that's for us to reach into the project and say, hey, what's going on? We saw this was happening. How can we help you? How can we get you all set up for success and be a little bit more proactive instead of reactive? Because that takes up a lot more of our time. So I got a procedure specific question. So I still remember in really early days of the TLC, back then, we had the concept of SIGs and working groups. Like, tech security was the first proposed as a safe working group than security, SIG, and tech. And remember, at the time, we positioned SIGs as more like eternal things and working group as more ephemeral settings. I'm wondering if TLC is still considering the working group set up now? Because I talked with Chris A. back in March. Maybe we are thinking about to propose a LLM, a larger language model related in CNCI because we are seeing people are using cognitive infrastructure to training and inference other things. So we think it might be a good idea to have a community effort in CNCI. And Chris A. back then says maybe we can look at a working group proposal. So I'm asking if the working group is still part of the procedure or tag is all we have now. So a while ago, we made some changes where working groups don't exist at the TLC level. And the reason for that was because we would be required to provide the oversight for them and with all of the other things that we have, part of those working groups would probably be best served within a tag that's closer to that domain. But we understand that that model doesn't exactly fit. And that's kind of like the story of tag environmental sustainability. We wanted to start them off as a working group. We didn't really have a good place for them to get started initially. So we tried something out. It didn't quite work as we intended. However, they are a new tag now. We do need to do a lot more in our processes of defining how do we take some of these exploratory concept areas in a technical domain and bring them up into a tag once they fully fleshed out what that scope looks like, what their deliverables could potentially look like, whether or not there's projects within the landscape that they could potentially oversee. And I think that's a good case for one of them. Well, I can add an example of a recent working group, which is the Batch HPC or the CNCF Batch working group. So this is very similar to the description you have, which is to have a place where all the projects in this area can get together and even know each other better to see where commonalities exist and how they could collaborate. This is a very good example and it's been formed, I think, a couple of months ago. They're working on rolling. And it's kicking off that we had the Batch HPC day here where a lot of the people from that working group attended and a lot of discussion and now they have a place to talk to, to talk to each other. They don't necessarily report directly to the TUC, but they are very involved with the tag in this case. I just wanted to point out that working groups are still very much things. So tag runtime session yesterday, we discussed about like spinning up to additional working groups. So there's already one proposal for a wasm working group. And then folks from like a few other container OSs reached out, like they want a space to discuss more about container operating systems. So we're going to spin up one for that. There was also one around MLops that we're going to do it. So there's definitely active things going on. There's plenty of ways to be able to make this work. Yeah. We have time for one more question. Can I just add a very quick question? Yes, of course. Okay. I think the spin out of the working group from a process perspective is not the difficult thing or the challenging thing. I think where the difficulty comes is to actually get enough momentum in people leading the effort. And I think this is where we really need people to champion a lot of this. For example, thank you for actually championing this working group, well the creation of this working group. And hopefully we're going to get more people to be part of this effort. So I think this is the challenging part really. We just need members, we need interest and we need them to be involved as much as possible. First, I want to say thanks to organize this public meeting. It's very helpful, especially for myself. And this is Andy from AWS. I actually have two questions, very short and one technical, one where we have the service tech. So second question, how I can join the TOC? So I'm going to start with your second question, which was how do you join the TOC? We do have elections. However, what has often worked well for the existing TOC members is being an active member and a contributing member to a project or to a tag or being somebody in the ecosystem that is doing things. A lot of what it is that we do is what I consider glue work. It's not glamorous, but it is the thing that needs to get done to enable our projects to be successful. So working within the community, taking on some of the uglier, like more challenging areas of work, not necessarily always technical, is a good way for you to identify yourself within the ecosystem and put yourself forward as being interested in more and more of those leadership positions. And then those nominations are likely to follow. I think, you know, starting from a tag, you contribute from a tag, that's a good way to start. And what was the first question again? Yeah, the first question is one where we have the serverless tag. Oh, well, a serverless tag. When a community member stands up and wants to be able to do it, there. Back to my point, we need people to champion. The champion is for experiencing tags. Yeah, nearly all of our tags came from people that were really involved in community and they came. Yeah, actually, I think that's a very good question. I think serverless is a very good area. Yeah, people to start to form an active community. Yeah, to drive this. And with that, we are at time. I want to be able to acknowledge all of these wonderful people for the work that they do, both now and in all of the meetings that we do. So thank you. Thank you very, very much. And thank you to the audience for coming in today. It's been a pleasure.