 Good morning, we will give everybody a few more minutes to be able to come on in. Happy Tuesday, everyone. Let's wait another minute or two. Amy. I don't think we're going to get that many people today, but that's fine. Yes. That that's great. If we don't get that many people today. It means there is vacation happening in open source 14. I think this is who we're getting. So that works for me. All right. Hello, everyone. Happy Tuesday. It is December 19th and you are here at the meeting, which means you have made it next slide as always. If you are here, you're complying with the anti trust policy notice and you're familiar with the meeting logistics. Okay, let's go next side. Got a bunch of members present today. And ultimately, this is a working session. So folks on the call. If you have questions for the TOC, we do have elections coming up. Feel free to ask them, but largely it's going to be TOC working through our queue of things that we need to get done or understanding where things are currently sitting for our projects. So I guess we can start with anybody that's got questions. So I have a question about asking questions, which means I checked the document and I wanted to add something like a question and in advance, but it requires edit access edit access. So, uh, I didn't know how to do that. But my question is basically the projects applying to move levels. Um, task force any updates on that one or what's the road ahead? So I have to, um, So there is George on the call. Yes, I am. Yes. So George, why don't you give us an update real quick on where things are at? Yeah, I actually submitted a pull request of the. Uh, so we started off with one document and then instead we split it into three documents, one for a sandbox, one for incubation, and then one for graduation based on the criteria that we had found. It was the document that you had. I just reformatted it. And then I PR that before I went on my trip two weeks ago to the TOC directory. And so that's the first half. The second half is going to be what you want the issue template to look like when a project like applies to do the thing. Um, but I hadn't gotten around to that yet. And as I was stubbing that out, I realized that there's going to be discussion that needs to happen there on what people are going to want the form to look like. Um, so I hadn't gotten around to that yet. And I kind of focused on the things that were already kind of finished and PR. Let me get you the pull request here. Was it 1216? That one is still listed in draft. Ah, yes. Um, I'd like feedback on that. Or if you want, I could take the draft off. It's up to you. Um, that's where we are at tactically strategically. I'm hoping someone. So there's the documentation that is currently in draft being generated to support the recommendations from the task force. The next steps beyond that are the TOC needs to make a decision to accept the recommendations as they exist or accept them with modifications. Um, one way that we can go about doing that is through the templates that are being suggested as PRs on the repo. Um, this is actually one of the topic areas that the TOC is going to be exploring in February. So that we can make a decision and start moving forward with this. So there is generating the guides, the documentation, the instructional material to assist anybody that's moving levels with what the work is that needs to happen. Part of that is making sure templates are available for use, but also writing the guides to go along with it, both for maintainers and for the TOC. Um, and for the tags as well. And then the next step beyond that is the actual acceptance or ratification of those recommendations and merging them into the repo from there. Um, beyond that, it'll be determining if there are existing projects that have applied to move levels that we would like to trial the new criteria against or at least the new process against. Um, deciding on a cut off date to transition to that new process based off of the evaluation and feedback from any trials that happen if the TOC chooses to go down that. So you still have a lot of work ahead of us. Um, ideally we would have this done by May at the latest is having everything done merged and complete with a path forward. Um, but again, this is largely going to be a much longer conversation with the TOC on where we're going next. Did that answer your question, Ali? Yeah, it did. I was going to ask about the, um, applications in progress, but you already answered. So yeah, they're preparing for a graduation application for Knative. Um, that's the root cause. Thank you. George? Yeah, just, just to get the simple explanation here to kind of explain the workflow, the way it would work is you would file an issue, like your project would file an issue using that template and it would say we are applying to move whatever. And then that, that issue would remain open. Then you would open a PR into the proposals repo using one of these templates and you would fill out that and that would be your PR. And then the places in that template where it says talk fills out, that's where the back and forth between your project and the talk and stuff would happen. And then once that PR is merged, the issue would be closed and then you would open the new issue for your next level. So we would say like your project would have an issue open for whatever its next level is going to be. So I hope that kind of understands where we're coming from. But that's what it's looking like so far. We can always change it. Sounds good to me. Thank you. And that's all I have. Um, other questions. I mean, there was a question in chat also to George about how was the, uh, the conference that the AI dev conference just happened. So. It was like Ricardo, I think has as we'll probably have more information, but I was. Um, the amount of stuff that's already in production, like. The, the talk with Tim Hawking at. At KubeCon where it kind of felt where it was like, Hey, we better get moving. Otherwise, you know, we need to get the stuff ready so people can build stuff on top. There's so much stuff already in production and so much work happening. That it's very, um, I found it very motivational to understand that end user companies are really like running with the ball. Uh, Joseph Sandoval walked me through their whole setup at Adobe and I was just like the amount of progress they made in the past 18 months. It was just awesome. Ricardo, you have anything you want to add there? Yeah, I think a lot of conversations around LLMS, um, how folks are running LLMS in production, um. You know, different applications of LLMS. Uh, so we had a booth like a CNC. I've had a booth and, um, I think, uh, one of the interesting things is, you know, how you can. Uh, bridge data scientists and infrastructure people, you know, together, right? So I think there's a gap there. So I think a lot of infrastructure people are wanting to learn what machine learning is and what goes behind the scenes and, you know, how these things work, how the models are machine learning models are created or LLMS are created. Uh, what the scale problems are. Uh, and then you have data scientists trying to learn, you know, what Kubernetes is and what cloud native is. So I think one of the things we want to do is with this working group to is continue to bridge this and so we can work together and advance both fields together. Does that make sense to us? Awesome. Thank you, Ricardo. Thank you, George. That was great information sharing about AI.dev. I know a lot of folks couldn't make it. So thank you. Okay. Yeah. Happy to chat more. Uh, I want to chat one on one. Happy to talk about it. I'm excited about this. So there's a lot of stuff happening. So then we'll see a lot of changes too. And, you know, how, how people work and because they're using generative AI. To do things faster, right? So how maybe you can apply generative AI to cloud native, for example, for security purposes to see security gaps and in your infrastructure or your Kubernetes environments. How to use that to maybe see other gaps like, like you can optimize for workloads or you can actually help with the carbon neutral or net zero goals. A lot of people talking about sustainability too. Interesting. Very cool. Um, so if we want to move on, there's some kind of questions in Slack that are in chat that I want to address. We don't have a good way of ensuring that folks that attend this meeting can ask questions of the TOC. Amy, do you have a preferred mechanism that way we can pull those in and make sure the TOC is addressing them as part of these meetings or asynchronously? Um, I don't know that I do. I mean, like the, like there are so many right now. I think if we're talking about like the discussion pieces out there that I'd rather us focus on at least like two of them ahead of time. So like really just like adding them to the agenda is I think the most appropriate way to be able to handle this that we know what would actually is going to be discussed. Okay. Okay. Um, given that the public agenda is access controlled, how would you like folks to get them added? I guess at this point it's basically like, um, uh, flagging it over in like the TOC Slack channel. Um, we've not done this very, like, very effectively. So I'll take, I'll take feedback from like what might make the most sense because yes, the agenda is locked. We haven't had a good way to be able to do this. What would make sense? Uh, so there's a couple of different options. What are, what are folks interested in? We can have this as a just post a message in the TOC public channel with what the question is for, um, and Amy can scrape those down. So we ensure that they're being covered or at least answering them asynchronously. Um, another option is we can create an issue for the TOC public meetings that folks can comment with questions on and then we can close it at the end of the meeting. What other suggestions? So you're on giving a plus one for a message in the TOC Slack. See some head nods. Okay, let's try that for right now. Um, Amy, is that something that we could do a quick PR on the TOC repo on the read me just to say if you've got questions for the TOC, um, drop a message in the TOC public channel so we can ensure they're addressed at public meetings. So I'm actually thinking about like making sure they're over in discussions first so we have a place to be able to like focus. Um, like, and that's where I'm going towards like I want to be able to have them over in and I've got discussions pulled up here and I can interrupt over in chat. Okay. And so, like, it's a little bit more direct than, um, like just, just a like a question over in TOC. This is something about like, if you have something you want to be able to discuss and go through, like, putting it over into discussions. Okay, it's probably best because right now, like the, like the questions that are happening over in the TOC channel over in Slack are really things like, um, where is my project moving around that's not quite where I want us to go towards. I want us to be able to have, like, a really just a better conversation. So. Okay. Drinks got some peace in here as well. Yeah. Converting discussions and do an issue if there's an actionable follow up. Okay. So that sounds probably. I'll put in the PR for being able to say here's the work that like, like. Discussions for TOC happen over in discussions. Go play over in there and then we'll see where that goes. Okay. That sounds good. Well, he came in. Yeah. Okay. Nothing from it. Moving on. Um, so let's see here. Do we want to start with discussions today so we can work through them or do we want to go to pull requests? How does the TOC want to work today? Well, we can certainly start with discussions. Duffy, do you have a preference? I don't. Okay. Um, so let's go through the discussions listing. We'll start at the oldest ones. See if we can bring some of these to closure. Josh on November 10th. Apologies for the delay and getting to this. I have joined a tab. How can we coordinate tab and tags together such that and use your feedback or just tags projects. Quickly, but it makes sense to recommend tab members join and participate in relevant tags. So let's coordinate. I think we actually have an issue on this. Or an, or yet another discussion on this topic. It sounds very familiar to me. What about others? All right. Can you post the discussion link? Cause we're not seeing on the screen. Yeah, I dropped screen sharing could be like going anywhere with these slides. So. Yes. I got it right here. Thank you. Okay. Well, hopefully this screen sharing helps now. Is this good? You are stuck on a desktop. Oh, yeah. Let me see if I can find the right one. It might be just not my day for screen sharing. And it does not look to be the case. Here we go. Give me a second. I'll see if I can bring it back. Oh, you've got it. Perfect. Okay. You've got it. Excellent. All right. So this is the discussion. I thought we had a TOC issue on this for tags and tab feedback. I know I tagged Ricardo Roka on providing a response here. And I know that this is on the tabs agenda. So for this one, I think just a summarization of what the expected next steps from the tab are to establish that process. Once they meet in the new year would be sufficient to close this out. How do others feel? Yep. Yep. So what's the, sorry question. What's the follow up? Is it a meeting or between the tax and the tab or this is just some document or. I think, first off, it's going to be the tab needs to meet and then figure out how they want to do tag engagement. We've already put it on their agenda that this is something that they need to do and they've already confirmed awareness of it. So it's really probably just timing and waiting on them to get bootstrapped up and running so that they can start figuring out what an engagement with the tags looks like. And then reach back out, but it might be prudent to put a check in with the tab, maybe around April or May once they, they're up and running and have a few months under their belt. Does that answer your question? Okay. Yeah, it sounds like we just need to put a comment there or something. Okay. Is there a TOC member that can take that on to summarize? Actually, I was going to suggest Ricardo because like, you're already engaged and we don't need to limit it down, but. That's true. Here we go. Broca, right? Yeah. Sweet. That one is done. So Josh also started this one. This was part of kind of the tag talk, cube con discussion around what are the objectives of each tag, governing projects, providing documentation and recommendations to adopters on how to use cloud technologies, best practices associated with it, building awareness to enable users of the projects across multiple domains, patterns and standards and getting feedback and kind of facilitating that back to projects. So these are just a few areas. What do the tags feel and what does the TOC feel? Because I know those are two very different perspectives. We might have different expectations than the tags are currently operating on, but part of this is to kind of lay it all out there. What sorts of feedback or opinions do you all have? Or is this something that tag chairs would like to do asynchronously and just come in here and document what it is that each tag wants to pursue. And if there's chat, I cannot read it right now. Ricardo. I feel like we have some of this in the charter of the tags, right? So as a summary. But it sounds like this is more, I mean, like a follow up engagement with maybe the tag leads chairs and tech leads and provide more of an updated, you know, maybe description of what the tag is doing. Yeah. And this is one of the things that we talked about at KubeCon is whether or not the current charters in the scope of work that the tags have is sufficient for the work that's being requested of them or the work that they're pursuing just to kind of like level set and potentially increase the consistency across tags and those expectations. Matt. I was going to say, I've been, Alelita and I have talked about this as well. I can pull up the GitHub issue in the tag observability repo around kind of clarifying and identifying and needing to understand the expectations for a tag co-chair from the TOC and from the tag itself. Just as a discussion point, I'll pull up that issue and put it in the chat. I was going to say that as context. So we've been talking about this topic. I personally think that a good, I don't say forcing function, but opportunity to communicate or collaborate is would be to have sort of a show and tell maybe once a year where all the tag chairs kind of give a lightning talk on what is the tag and why do you care? And why might you want to show up and create and contribute? And I want to say contribute, but oftentimes that's an ask for like, hey, come do stuff. It's like, hey, you get to come make stuff, right? Or you get to join us. You know, some kind of something like that. Maybe around one of the coupons, like the maybe coupony in the spring, right? Flowers are coming up. Everybody can't go to the North America coupons that are dialing in and paying attention. That might be a good time to capitalize on eyeballs. And then we'll do a show and tell. So I think this one definitely came out of conversations over in like, sometimes the charters have not been fully updated. I'm actually going to pass into Rayon to talk about like, because this actually directs his works pretty directly. I think also charters having written myself are aspirational. Like when you're making this group, you don't want to eliminate and scope to what I or whomever can personally do. You want to say, this is the domain and this isn't this is a useful category of thought to coalesce around. You know, and so, so the charters to your point are oftentimes, I think really broad and they probably should be and they have some like, I put in the interview, we put in the interability one. You know, here are some first activities that are prioritized that might make sense, some of which we still haven't accomplished for resourcing reasons. So like, I'd like to see those lightning talks talk about what the charter is in spirit what is meant to be the shape of the domain and how it relates to other things and why it's relevant and question now. Right. Like to present that. And then like, and here's what we really think is the right thing to do. We could, you know, help wanted to know, by the way, if you are super crazy passionate about this other thing. That's in scope. We might have already thought about it. And in some cases, how many years of starting point. The landscape for example is basically the target durability bunch of that stuff. So maybe it's maybe a format. Well, no, no, I'm going to stop you here because like, like truly like we do actually have someone within CNCF now who's like focus is going to be helping and like bringing out all of the tags so that would be me. Sorry. My video lightning suck I moved in your new office so it's terrible. I'll work on that. Okay. So what I've been doing for the last four weeks is read through tag repose. It is very interesting. It's very disjointed and many tags have a charter in two or three different places and they're not the same for one tag and across tags is not the same. And there's a lot of documentation that's very old and outdated leadership that's not updated. So there's really a lot of work needed for standardization of what is a tag a lot of the charters is as old as the tag and as I've been touched. I think it would be a good time to generate a framework of the outline of a tags charter should contain this information. And then step by step go through all the tags and work with them because what I discussed with Amy if you go tell the tags. Your charters are dated make it better. It's not unfair because they already is volunteer people already overloaded already a lot of work so we'll have to help them through this process will have to choose the low hanging fruits work with those first and try and work out the outline of a charter and then go do them one by one and assist them in updating and not just throw out more work in their direction that's kind of where I'm going so I'm busy. Working on a document which I hope would be done probably by end of January saying these are the outline things that we should be doing, which also ties in somebody mentioned landscape. One of the things that I also noted across many tags summer referred to the landscape some refer to an old version of all the information. And then there's an open issue in CNCF about how to link landscape to do tags to also like in the work of tags trying to keep abreast with these are my projects or rather have a link that says these are my projects if you click on you can see them and if one it was added last week it's also there and nobody have to go do that. Well, a lot of automation and also leadership keep it in one place, a lot of leading up like that and I'm probably talking too much about cleaning up. I would totally agree, but briefly also say bear in mind that many of the tag chairs probably weren't around when those charters were worked on. And they don't they're probably missing some of the why, in some cases. So, I think that that that sort of format, I think, has a lot better, better chance of doing good pragmatically then sort of just crack a whip and a tag chairs go into the redefine. Right. Because what are what's going to happen with everyone will snap to their current resourcing and the definitions of our domains will shrink. Would be the potential. Maybe that's a good thing. I mean, kind of experimenting a little bit definition of what they're doing can shrink. Right, but we don't want to throw up the baby with the bad. That's terrible. You know, I don't want to lose the definitions of like what are the discipline from a discipline perspective and then a technical domain perspective. What are the boundaries of that that makes sense versus. Matt. So that's all right. And I think it's good because you do touch on a point right like let's take something like tag security, just because they're currently focused on these five things doesn't mean that there's these other things in the security realm that are part of the charter and the scope. And I'll be honest, I do like the idea of, you know, revisiting the scope of the tags and documenting it, but adding that context to be clear. So much of what we do is an insider's club and people put it in thinking everybody gets it, and then you can do people coming in older people go you didn't have that nice clear mentoring along the way, and then context and scope is lost. You ask, why are we doing this? Why are we going in this direction? Why is it open this way? And there's no context there. And maybe there wasn't any to begin with and it was just throwing stuff at a wall. And that's useful to know to say, we threw these out there as initial ideas and somebody in the future needs to come back and revisit this. Now we're in that future needs to be revisited. So I think it's a useful exercise to do this for the tags to look at that and to document what we can. Just for that contact sharing. Yep. I appreciate that and I want to touch on briefly that I don't think it's necessarily around altering the discipline. I think it's more of understanding how the discipline has changed or shifted. I'm thinking back, since we've been talking about security, security 20 years ago was not what security has been in the last five years, let alone 10. So it certainly as a field of study has shifted dynamically and I could probably say the same for most of the other technical focus areas that we currently have defined by tags within the CNCF. But there is, as we've seen in the past year alone with AI, there is a number of other areas of interest and skill set and alignment that has some overlap with what we currently have, but not necessarily in all cases. And I think it's important that we continuously kind of reevaluate or reassess if what we currently have is what's working for us for the next year or two years, three years, five years. And we rely on our tag leadership and our tag communities to help inform and guide us along that respective domain. So this conversation is still open. I would encourage all of the tag chairs and their members to kind of chime in here and understand a little bit potentially around what it is that they're looking for out of the tag. So what is the work that they're currently pursuing? What things are they not getting traction on? Like, I know in the tag security charter there is at least one third area that doesn't get a lot of visibility or discussion. And it's usually around enabling auditors to be able to reason around the components of cloud native systems and technologies. And that's just not something that we as an industry have really focused on. So next discussion point also from Josh in the same vein of updates from Kubernetes SIGs, it would be nice to provide an update from CNCF tags about new and updated projects as part of their as part of the KubeCon keynotes. I know that this is something the KubeCon keynote portion and it was something that Nikita has been kind of strategizing around with the events team. So I'm going to leave that with the KubeCon co-chairs to potentially resolve. We do have some communication path there, having a TOC member as a co-chair is always a nice perk. But relatedly, each tag should hold a project meeting at KubeCon and bring together sandbox projects for awareness and discussions. So for this discussion item, I would recommend that if there are tag chairs that have strong opinions about this to put them here and then we can share that with the CNCF events team and see if there's potentially opportunities for them to provide those resources to tags. How do others feel? And Amy, does that sound like the right path for this one? Yes, and George has some good ideas about how to be able to improve like just kind of overall experience for tags and projects here. And I'll wait for him to come off mute unless he is stuck. Here he comes. Yeah, I'm still catching up on second. I'm still reading this one. But yes, in general. Yeah. With that, like, you know, it's a KubeCon talking about tags, but I think this is maybe expanding on that a little bit. But yeah, so it sounds good. And he does already working on it. And the KubeCon co-chairs. For this one, would it be beneficial to request the tags? To provide perspective and opinion here by like, let's say, February, so before KubeCon so that we can make sure that the events team has that going into North America later on. I was going to say, I'm like, February is a little late for being able to get like things together for Paris. Happy to be able to see options for like how we want to be able to do this for North America and happy to be able to see like what people think is missing. And a Jan might be better. Yeah, I know we're working on this somewhere because one of the feedback we have was that the lunch tables seem to be a hit with the tags and we definitely want to like start growing from there to get them a little bit more. Tables or like the last thing we could do for for Chicago. But I attended a few and it seemed like a lot of people were engaged. I don't know how others, others of you felt. I think the lunch tables. Overall, like, I would describe them as a mild success. We did have a few folks that stopped by and seem genuinely interested but the difficulty in finding the locate the tables and then finding seating where everybody at the tables and in some cases we carried conversations from that meeting to the table which made it difficult for potential contributors to kind of chime in and understand the context of the discussion. So there's a lot of opportunities there. So yes feedback in the issue. We'll keep an eye on this one. If we can do it. Yes, if we can't do it for like this one, North America. Yep. Okay. Check ins with tags as part of the sandbox annual review. And Ricardo, you kind of had a comment about this as well and chat earlier. Which one. Like this kind of relates back in toward like the tag health check but maybe like that's a step too far. I mean, my comment was related to the charters, you know, the how we do the communication about what the tags are doing at a specific moment. Yeah, yeah, and yeah, one comment about that is just that we're as tags. I think we should think about being at the forefront of defining what cloud native is right so. And that's part of like keeping the charter up today. Some of these stuff hasn't been created yet. And I think as a goal for tags and the CNCF and the TOC just to be at the forefront of defining things and what people are going to be using also with, you know, two years down the road, for example, two or three years down the road. Yep, I agree. So since this one is largely going to be driven by those charter updates and deltas for the kind of where the tags are headed and the work that they're going to do. I think getting the charter discussion underway needs to happen first and then we can kind of explore not just sandbox but also incubating and graduation reengagement with some of these projects. So beyond just the ones that are very early stage and experimental largely looking also at the ones that are on their way to a higher higher level of maturity and production readiness. Were there any other thoughts on that one before I jump to the next one. This one is likely to be a little spicy. And it's a long one. So I'm going to try to summarize this. And this kind of came out of the project moving levels task force as a point of discussion. It was one that we couldn't reach consensus on with a single solution because it warranted larger tag and community engagement. But the current criteria for graduation requires that the project maintainers are from at least two organizations to demonstrate survivability. That kind of falls into two different categories. Openness, meaning that the maintainership of their project has a distribution of accountability for their decision making so that no single entity is responsible for the entirety of the direction of a project. It's consensus based or it's collaborative. The intent is that there is a structure that allows voices to be heard and for the community around a project or the leadership of a project to make a decision that doesn't necessarily favor one organization or the other. It's in the best interest of the project to move forward. The other side of that is sustainability and this one we've had a significant amount of discussion on and that the if the primary contributing organization were to dissolve to attach itself from the project be acquired disappear those maintainers move on. What is the likelihood that the project itself can sustain its momentum and moving forward or even kind of limp by until it gets that momentum back but ultimately if the company were to disappear that was the primary driving force behind a project will the project continue. This is especially important as projects reach graduation and we're encouraging adopters to leverage in them leverage them within their infrastructure. We don't want them to become a single point of failure for an entire enterprise when the main maintainers disappear as the project has just lost that level of momentum. So there there's some kind of discussion points here. I don't know that it's worthwhile to get into a lengthy discussion here, but I want to make sure that folks are aware of this and that they have the opportunity to read through it and express some of their opinions. We're hopeful that the end user technical advisory board will provide insights here, but from the tanks perspective. I'm sure, as you all have engaged with sandbox projects or incubating and graduated projects if they are checking back in, you have some understanding and around the different models around maintenance and meeting this requirements and I know 10 contributor strategy definitely has opinions here. Are any of them on the call. I don't believe so. Okay. That's actually, yeah, I don't think anybody's here from them. Sorry. Does anybody have any quick thoughts on this or is this one of those definitely async. Ricardo. Yeah, the only thing about graduate projects, having a single organization as the maintainer. The project can be graduated stage, even if that's the case. When you have a lot of end users supporting it. So, and a lot of end users are aware of that. Because maybe a lot of end users say like if that maintainer is not able to maintain the project anymore. Okay, we're going to step in and maintain the project right so or we're going to have at that point they're fine with a single maintainer but later on, they're aware of, you know, maybe that maintainer not being available anymore and then can just say okay, we're ready to step in and maintain the project right so that's the only exception that I see right. So that that's something to keep in mind, I think. So it sounds like more of a risk decision for the adopter to be mindful and aware that there is there could potentially be a single organization behind a project. Right, right, right. And because it could be like a very mature project right it could be like, you know, being used by a lot of end users and in running in production, but it just happens to have a single maintainer right so Matt Frina then Matt Young. I've got a lot of thoughts on this and I'm only going to share two right now. The first is, you know, I want to agree with Ricardo that this is a risk decision, but it's also one of those things where if you've got one maintainer who's working on it, and then they go away. It's incredibly hard for other people to pick it up and run with it, because that context is missing. And so from a business decision it may look oh it's easy, we'll have these other people do it, but from a practical perspective, usually when you have one maintainer on it knowledge is kept in your head when it's one company knowledge is kept in your organization. That means that transition to the outside because things really aren't as open becomes really really difficult to do, and it's hard for those other people to pick it up and effectively when they're not part of that discussion you don't have that culture to begin with. So I think just saying that this is okay actually ends up bringing risk in that people don't realize is often there at that decision maker level. So it's better to have multiple organizations upfront, because that forces this context to be in the open. I think that this is an important discussion for us to have right now, because contributors to CNCF projects is a risk. If you go to things like the landscape, the new landscape B2 and you go to the contributions, you go to dev stats which are actually going to be the overall contributors across the CNCF are down, even though the number of projects we have has gone up. And we're kind of shifting from a phase where you had the crazy creators going up building all the new things. And you've got the long term sustainable maintainers who need to be involved. It's a different context, different scope, different set of people, many of the creators are running off creating new things, a lot of them in the AI space. But these things that are now foundational for us need the long term maintainers, and we need to invest in building that up. And that is probably one of the next big challenges for the TOC, and the two org requirement kind of highlights part of that, because if you can't get maintainers in the first place, how do you get the two word maintainers? How do you fill this space? How do you make this work? And this may be part end users. This may be some vendors who build on top of it. But really I think solving for it is part of that larger context of we need to get maintainers in who aren't those same creators we had before. They're the long term maintainers and what does that mean? All right, that's my two cents. But I do think this is one of the pivotal things to deal with. Those are great points. I'll just briefly say I think we have a precedent and a concrete example of a complementary way to achieve the same ends that I think that the two org requirement attempts, what it needs to do. And that is when linker D was really maintained just by buoyant and you know buoyant being the time a small company still is and it could be acquired, right? That happens all the time. So in order to prevent an acquisition from potentially tanking the project if they're not understood by, right, they created a buoyant consumer advisory board. At the time I was an end user actually. And so they had approached it as well. I didn't have that to participate, but I was running linker D in production, right? And so the idea was to provide somebody like that. That that could provide that context and something that would live on. Outside the context of an actual corporate organization, even if one organization was primarily hiring actively, you know, the maintainers for a particular project, but they wanted to mitigate that. And so, so to provide something workable that also provided like a forum where end users could show and tell their success and, you know, it means just I think, I think there's a good example there that you could talk to William Morgan about. And he might have now that it's a couple years old for you, I think you might have some, you might have some feedback on what's going on, but I think it's an approach that could also work in concert with this. Yeah, I don't disagree, but I want to provide a quick caveat and then I'll turn it over to Ricardo Roca. Well, having some form of governing body can address some of the concerns. There is still the fact that there are individuals with administrative access to these repositories. And as much as I believe in good humans doing good work, there's still a risk for attacking those maintainer accounts that have administrative privileges and we need to ensure that there is some form of kind of dual ownership in those administrative rights. Ricardo Roca and then Ricardo Aravena. I actually had more of a question is, there was a project, considering applying for graduation where they wouldn't meet to work, maintain a requirement today. And to fix that, because finding a vendor for the project and a different vendor would be harder, they would actually engaging with end users to come forward and become maintainers as well. So we have any thoughts on differentiating maintainers if they come from vendors or end users, right? We just consider the same. But I guess the risks are different, right? We can imagine that an end user changing a project is harder than a company backing and making money out of a project moving somewhere else. Is this something that makes sense to consider or I don't know, I was just wondering when they asked. That's a good question. I don't know that we have any strong opinions one way or another yet. Like is there, is, does it make sense to like describe this as a criteria that we measure like with temperature, right? Like where we say like taking into account these variables. This is the risk assessment for the project as it relates to, as it relates to the overall risk assessment for developers or for the development of the project, right? Because there are multiple, it's definitely like a multiple input kind of thing, it's not. Yeah, I was also thinking, it really depends on the case like you said. If we consider a large organization betting on something like Argo to manage all their platforms, they will probably be very interested in making sure the project stays and investing in the end maintainers. It's just a company where the project maybe isn't that critical, but they still got someone as a maintainer probably this maintainer working to do something else is quite easy and replacing not priorities. It's actually very, it's also very likely that if you're an organization, say you're like, you know, a big organization that's using an open source project and an open source project goes on life support. If you plan to continue it, it doesn't mean that you're going to do that in open source. Right. I mean, it's also very true just for local patches. Ricardo or Vina, you have a hand. Yeah, so there's a lot of history around this with the Nats project. So I think we can actually revisit this. From three or four years ago and I think they've been trying to graduate but then Cynadia or Cynadia is the only organization as a maintainer. So we might be able to revisit that. I think they've been trying to graduate and trying to come up with something. I'm pretty sure this, but the status with Nats, if they've actually found more maintainers, but you know, something that we can take a look. Okay. So, so a lot of things yet to figure out to see, is there any additional information that would be beneficial for us to arrive at better clarity on this existing criteria and how it's been interpreted. I think right now the recommendation from the moving levels task force is really to break these into two separate criteria, so that they can be addressed uniquely in the course of evaluating projects and their governance structure. Yes, need to have the discussion not clear on what additional information we need to have we just needed kind of talk through it. Okay. There's probably a lot of this that we could that we could actually gather from the work that we're doing around automating things about like understanding the health of projects, like. Agreed. Okay, so let's go back over here. We're going to switch topics again we got eight minutes left. I think I want to touch the TOC tag follow up how can we support each other to share vocabulary looks like we've got two of those together. Yeah, Matt because you're on the call like I wanted to kind of focus on like those first. Because yeah, like they look very similar. Yeah. I took this one to tag contributor strategy last week. And we talked about this and some other stuff to this one. Yeah. And, but you was only in passing and it was the very talent of their, their meeting. We actually talked about others the first but what this was was, you know, ads, we expect working groups to bridge tags, as we expect tag leadership to roll over kind of consistent with what we're talking about before, you know, a shared vocabulary even if in perfect takes that and I want to be clear that I don't. I'm not asking to be all about this as like the one true religious way to think about things but it does define some nouns that are somewhat uncontroversial. I would like to say that. The purpose is a very valid point in tag contributor strategy as well as when we talked to around some of the labels used in the actual book, like toys that they could be perceived as pejorative that that not what's standing. I think the monarchist should probably change the book. Make choices. But I think the definitions of them are at least a useful place to start a discussion that doesn't demand. You know, start from zero. And I mean, I'm in the process of the landscape practice of working branch their firm from could come and hacking on. That actually looks at the landscape and then and tries to apply these just to see where things quadrant out. Yeah, I think this sounds good to me I mean the the terms don't need to be defined. They can be changed basically it's not that we can work on the definitions rates. So it's some folks and the community might have a. Yeah, so I have a problem with some of the specific terms right but like, you know, in the end, we want to also think about the definitions and we can change those terms right to accommodate the specific specific problems to related to the projects and and the cncf. Yes, I also want to make sure I reiterate Josh Josh purposes point that kind of what that distilled sounding when you talk about the meeting is what the type contributor strategy to working with the maturity model is complimentary to what I'm proposing or suggesting for discussion here because it's qualitative in its assessment. I'm actually looking for something that we can augment that qualitative assessment of this quantitative based on behavior and activity of the project. Is it a bunch of people is just two people, it's a growing or shrinking, you know, as it calmed down and is that okay, you know, like that that kind of thing. You know, are there outstanding security patches like these the ability to build up some kind of index for lies on just a no man's nature as a starting point. But what I'm hearing it sounds like there's there's more than just these kinds of terms that are introduced here, particularly on this discussion we've also talked about domains verticals and workloads as potential definition areas so it sounds like in the context of cloud native, we do, we have a cloud native glossary which kind of touches on a lot of these but we've not actually gone through and, and expanded that to a more specific cncf glossary in the context of tag into the operations and what it is that we're doing and that might be beneficial here. Seeing some head nods. So is this something that's worthwhile to pursue resolution on soon or later, or let's get the project moving levels recommendations confirmed and finalized and then we can revisit this at that point in time. Just thinking about like workload of the to see and all of the ash that we've placed on the tags recently. So the idea of being able to engage with the glossary folks and being able to expand that and having that be kind of a spring conversation like April ish as we get through project moving levels. Okay. Ali Ali. Well, just paste something in the chat. So, in time contribute strategy we created a glossary, but you can find in the chat, but that doesn't categorize projects or that doesn't discuss some some things like what were those things. Like passive users, active users, those kind of things, but we have some stuff. So this could be another destination for these kind of terms. Yep, that sounds good. Thank you for sharing the link Ali. I think this would be a good opportunity to leverage the cloud native glossary and providing some of these definitions and expanding it more. I know the TOC maintains the definition of an adopter for instance on our repository. So it would also be beneficial to understand where some of these definitions are going to be kept moving forward since we do have the glossary having that centrally linked out wherever its reference would be beneficial. All right, so we got two minutes left. I'm going to go ahead and stop sharing. I do have some comments I still need to make on those discussions is there one minute left. Any other last seconds from anyone. No. Okay, I believe this is the last meeting of the year. Ricardo, go ahead. Yeah, when I thought something that I thought of. We're looking at this discussions and somebody mentioned that for action items, we can actually create tickets. We can also make use of road maps on on GitHub. Right. So, so I think for timelines, right. So we can track these like with, for example, we're going to take a look at this after April, or maybe after June. Right. So that I think it's good to visualize so we can make use of that. Awesome. I appreciate the feedback. I'm still learning about road maps and how they work on GitHub. So that'll be a fun and interesting project to figure out. It's sort of like a project management tool. Right. So you can, you can actually your items and set up timeline basically. Yeah. Okay. All right. Well, we're at time. So this is the last one of these for the calendar year. Thank you all so much for joining. We really appreciate it. I wish you all the very happiest of holidays and a wonderful new year. Please do try to take some time off from open source. Well, you're either working or spending time with your friends and family over the holidays. All right. Thanks everyone for a wonderful year. Bye bye.