 Hey everyone. Michelle, how's it going? Pretty good. How about you? Not bad. I'm at the Cloud Foundry Summit, which has been really fantastic so far. Congratulations, Matt Klein and all the other Lyft folks. Thank you. What's up? When you in a cupboard last time. Me? Oh yeah, that's my usual, but I'm actually working out of the Boulder office today. So I've got some pretty mountain views. This is the view. Actual vitamin D, being taken in today. Yeah, in fresh air, Chris, mountain air. Very nice. I'm in Madrid, which is lovely. That is fancy. Yeah, Spain is so beautiful. I love Spain. Yeah, it's really good. I remember going to Madrid and being like, how is the fence gorgeous? And like the roads and every little thing is so beautiful. Hey, Chris. Howdy, howdy. Morning or afternoon, depending on what part of the world you're in. We'll get started in a few minutes. All right, might as well get started. Is Brian Grant here? I don't see him unless he's dialed in. I think he said he wasn't going to be able to make it. OK, cool. And I know Alexis and Brendan already sent their regrets. So that's fine. Cool. Maybe he didn't. Maybe I'm mistaken. Let me look. Yeah, I know Brendan said like maybe it's jet lag or something. Was it Brendan who's in Korea? Yeah, he was coming back from Korea or something. I could I could definitely understand the jet lag. So we've got six, six out of nine folks, so we have quorum. Let's go to the agenda. So a quick little agenda today. We'll have kind of the chair election results. We'll go over some of the kind of voting that's been going on with a variety of things from projects to SIGS. We have some discussions around kind of archiving projects. You know, we'll go through the community kind of backlog of which presentations to put on the schedule for next week and then open it up to any Q&A that folks have. So first first bit of news, let's go next slide. In terms of our TOC chair election results, Liz Rice has won the TOC chair seat, so that's awesome. Good news. She'll be leading these lovely meetings moving forward. So, you know, we'll be working together to make sure that she's prepared to take the position on. So I'm super excited. Liz, feel free to make any comments. Well, thanks very much. And, you know, obviously I won't be able to. It's not just me. It will be with the support of everybody on the TOC and the wider contributor community. But I am really excited. I'm also really glad, Chris, you're going to run this, right? Because I had half an hour's notice. Yeah, yeah, no worries. We'll we'll we'll we'll come up afterwards and then come up with a good plan to kind of work together on this. So that's good. Sounds good. Cool. Awesome. In terms of project voting updates, so OPA was announced to the incubator this morning. Voting for Creo and Fluent D are still going on. And those are for the incubation and graduation. Levels Creo coming in as a kind of a new project, even though technically lives under Kubernetes SIGs and then also CNCF SIGs have been recently approved and will be working on on those soon, which I'll cover in a little bit. But for TOC and community members, please get your votes in for Creo and Fluent D that I probably will close those this this week. Any other questions on on on the voting before moving on? Cool. All right. So, you know, one thing we have coming up is projects that live in the sandbox are essentially reviewed by the TOC on an annual basis based on the process. So this basically we almost have something every month for the rest of the rest of the year, kind of depending on how you look at it. But next month, cloud events and telepresence will be on kind of the review block. And then moving on, we have a bunch of other projects that are kind of scheduled throughout the year. I basically did it all the way up to the end of 20 2019 for folks. So any questions or concerns about this just kind of wanted to make the TOC in the wider community aware of kind of what's on the docket in the future. It's a, you know, it was about a year since we little over a year since we created the sandbox level. So a lot of these things are kind of finally finally up for for review. I have a quick question just to just to get an idea of precedence. There is a sandbox project who wants to be who wants to go for incubation. They asked me if they should wait till or like when that would be appropriate. And I'm just wondering in the past, how people waited till their sandbox like annual review. I know sandbox is new. So I don't even know if there is precedent here. But how does that work? They're able to basically do the incubation request at any time. There's no whatever they feel they're ready in the meet the requirements and want to posit the TOC voting on them. So great. I told them that. So I'm really glad I didn't lie. Thank you. The precedent is Harbor, which went from sandbox to incubation three or four months after they came in. OK, thank you. There's no no no timeline. And if they do that, then they potentially get out of an annual review since as part of that, it's basically good enough for a formal review. Any other questions from folks? Yeah, do we also have an annual review process for incubating projects? No, it's not it's not required, at least based on the current documentation of how things we have structured. You know, with over 30 projects now, you can imagine if we did that, it would eat up quite a bit of time. I think the TOC wants to do that. We're we're able to do it. I would just be worrisome about the amount of time that would take. I think it's OK for the TOC to say, hey, maybe this particular project, we would like to have them come and present to kind of see where things are. Maybe we feel things are a little bit shaky. You know, with the archiving discussion today, maybe that's something that could be an option if there's a project that we feel isn't doing well or or you would like more oversight on that that could be one route. But I'm all ears, like it's it's kind of hard to do this in a scalable fashion of prior reviews, I think from from I guess I have two thoughts on that. One is, yeah, my question was really triggered by the archiving question and whether we should have a bit of a more rigorous sort of reason to address possible archiving perhaps by review. And the other thing is just opening the question that if we're going to broaden the idea of having more sandbox projects, these annual reviews can't be very heavyweight. We're going to have to keep them pretty lightweight if we're going to make the admission priorteria low. So we might need to think about that. Yeah, I mean, I totally totally one one interesting thing about the archiving discussion is, you know, last year, I think it was Alexis brought up a lot of, you know, it would be great if we would have like a project help dashboard so you could kind of easily see the status of projects, right? If a project doesn't have a commit in the last, you know, three months or six months, is it because it's super mature or is it because the community is kind of dead? So we we took an initial stab at that and I put the link in the Zoom chat. They could kind of take a peek and, you know, that could potentially be used by the TOC and others to, you know, make that type of judgment call. But, you know, all years, I'm trying to figure out how to do this in a scalable fashion. Chris, I think that the proposed model for scaling, this is the SIGS and I think it would be perfectly reasonable to have the SIGS review every project every year, whether it's sandbox incubation or graduated for that matter and present the TOC for the very summarized, you know, we think it's fine to stay there. We think it should graduate. We think it should be archived, et cetera. I think I think that's the proposed way of scaling this. OK, I think Bob Wise has raised his hand. So yeah, I think maybe one thing that isn't clear is whether it's OK for projects to go into the sandbox and sit there for a long time. My my personal view is that that should be fine. I know of a number of projects that have been, at least, informally chatting about like, hey, we just need a neutral ground place to collaborate on a project between several companies. And I don't I don't necessarily think that the sandbox is a pipeline of projects headed to graduation. It's like there's going to be a lot of projects that probably sit there for a long time and maybe I'm not sure if it's clear to folks clear to the folks outside, whether that's OK and something we welcome or not. Yeah, that's a fair point. I think that is I'd have to do a second pass on the sandbox guidelines, but that that's probably not as clear as it should be. Well, one thing to Quintin's point is as someone that may have I want to say like PTSD from from the Apache Foundation, but doing kind of, you know, reports all the time from a project thing is a huge time sink. So my advice would be to try to automate that as much as possible. So whether it's, you know, improving the metrics from dev stats to take in more data, but like a lot a lot of the kind of review could be almost automated in my opinion. Versus asking project maintainers to manually submit reports. Yeah, yeah, that seems reasonable to me. I was just doing some math. So we got six SIGs and we got 12 months. So potentially every SIG could just have a report back twice a year to say, here's all the projects that we have and here's our take on, you know, the health of them in general and sort of call that a day. And that that could be a, you know, a 10 minute slot in the TOC, you know, once a month kind of a thing you would have one SIG come back and give you a summary of all of their projects with proposals as to, you know, things that might be put up for graduation or things that might be put up for archiving, et cetera, and most of the load of that would be, you know, inside the SIG. Yeah, I think I think that's that's fair. Any other thoughts on this particular topic? Cool, we'll move on to the next next slide. Cool. So a lot of you, I'm sure aware, you know, given that the schedule for KubeCon, PlanetiveCon, you know, Europe was posted that we have a big conference coming up where we should probably get around 10,000 folks, which is a little bit terrifying at some level, but it's awesome to see the community grow for the wider community. This is the final week for if you're interested in sponsoring at any level or doing like a little reception or whatever, whatever is all those little things in the prospectus. This is the final week to do it. So please reach out to, you know, our events team, events at CNCF.io, if you're interested in sponsoring. And of course, we have China and North America events recently. As an interesting note, we recently did a Kubernetes Day as kind of, you know, we've gotten some feedback from the community that we need, you know, we get to have like kind of smaller, more regional focused events. And we did one in India, which we posted the videos recently, which I think went pretty well. I know if Liz, you want to, you know, share some thoughts on that since you were, you know, there helping, helping run that. But I think it was a kind of a great way to, you know, grow the community, kind of more regional events that are a little bit smaller in focus. But, you know, since Liz, you were in control of the program. Feel free to give some thoughts. Yeah. I mean, for short, that was 900 people there who gave up their Saturday and seemed extremely excited about having an event, you know, local to them that they could, you know, they could, they could get to was accessible to them. We did it as a single track event. I think maybe going forward, we want to look at maybe having two tracks because there was definitely quite a spread of folks who are new to the whole cloud native world versus people who are really very experienced. So having a bit more spread of topics going forward. But the other thing is the sponsor bleeds were absolutely mobbed. Don't know if it's because they're giving away great swag, but you could not move for the people of that side. Yeah, it was it was very, very good. Yeah, we we plan on doing more of these types of things in the future and also will be bringing forth a plan for kind of cloud native days that are kind of more community run and Kubernetes days that will be run by foundation. So look for that news fairly soon. We're working on it. Cool. All right. Moving on. So so this has been a fun kind of effort that for some of the newer TFC members, you know, we've been kind of involved, brokering kind of a bridging these two communities that have kind of been a conflict for quite a while. But, you know, I'm kind of happy and announced that they finally have come to an agreement on merging the open census and open tracing projects under kind of one new brand that they're trying to come up with under the community. Haven't chosen this kind of new brand name, but it's hopefully going to be finalized, you know, fairly fairly soon. I offered open consensus, but I don't think they're going to go with that one, unfortunately, in terms of a process question, you know, you know, there is an opportunity for them to completely present to the TFC and wider community, go through the typical project. You know, approval process that we already have in place. The other kind of way to think about this is when the linker D project kind of merged in conduit as linker D to they essentially presented to the community about their plans, everyone kind of OK, there was no formal vote. You know, how does the TFC feel this should be approached with this kind of new merged entity because they intended to do this under under CNCF, so it could just be folded under open tracing and there's a new brand name or they kind of go through the formal process we have in place. I don't know how people feel about this. We've kind of done both types of things in the past. So I'd like to kind of learn from the TFC and maybe the water community how they how they feel about this from my perspective. It makes me a little uncomfortable to just assume that if a project changes major direction that they would automatically come in under under some other project. I mean, I think it can happen in certain cases and maybe this is one of those cases. But I think it's worth a larger discussion on on a case by case basis. Yeah, I'd I'd opt for the formal vote route and just kind of redo the process. It shouldn't be that difficult, but it makes sense. Yeah, because there's a question, you know, as to if if something wants to come back in, you know, and a project, let's say that they were incubation and they majorly changed direction, should they automatically come back in as incubation or should they go back to sandbox or something like that? So it does seem like having a process and and and doing a vote probably makes sense. I mean, this is a messy thing, because like I think, you know, you have the link or D conduit stuff. As an example, their conduit was not a CNCF project, if I'm correct. And so essentially, link or D invited conduit in. I mean, it was all buoyant, but you know, and sort of essentially implored a bunch of code into their project and it was a major change for the project. I think it is another example where essentially it was a rewrite re-implementation of a part of the project that, you know, was sort of a sub incubation inside of that project to actually do a new effort. And so I think, you know, there's sort of a what's the name of this sort of the boat where they replaced all the planks and it was like, is it still the same boat? Like as these projects evolve and as they sort of renew themselves, are they still the same project over time? What defines a project? And I mean, they're getting very philosophical here. No, no, it's actually not. I've thought about this a lot. And I think that those are interesting cases to look at. And I think in some of those cases, you can make a strong argument that those projects should have come in as a separate sandbox project. So I think my personal feeling is that we should do the process. And if they want to come in as an incubation, we should have a proposal and do a vote. Oh, Brian, it was there from the beginning. So maybe I'm incorrect. I seem to remember that it hit the the stage later. Correct. For conduit just in terms of correction, as they did present to the TOC of their plans of kind of merging at Lincoln D and there was a basically discussion of whether a formal vote was required or anyone would have any issues with this happening. No one objected. Hey, Joe, just for your classical references, it's the ship of Theseus. That's right. And Wally being the best contemporary example where he'd replaced all of his parts over time. But I would just say that to put a little bit finer point on it, I think everybody agrees that this couldn't happen in a stealth way or in a way that the community is not aware of. I think the key question is, what should the default be? So the precedent for Lincoln D and conduit, which the TOC is not bound by, but was that they presented to the TOC and the community. Everybody was aware of it, but it would have taken a proactive vote of the TOC to say this isn't allowed, as opposed to the other way of saying, oh, no, it takes six of six votes to allow it. And I would just point out that there is a tradition of deference to the projects. But again, it is up to the TOC to decide. I'm slightly leaning that way. And in that, so long as we get the information, we get the exposure to what the plan is, if we start saying, well, we have to have a vote at a point when somebody wants to import some code into a project, we're not going to go to the logic of that as we have a vote every time somebody wants to do a pull request. And we're not going to do that. We forced the Lincoln D project to vote amongst all of its maintainers that this was okay and so on. So it forced them to do that and make sure their community was okay with it and also present to the TOC to allow any objections. I mean, when the essence of the project evolves or changes the scope of the project changes, maybe we should ask for a vote then because then your end goal has changed. And it's more than just a pull request, which is just like modifying your code or like major version change, iterating on something you already have lots of architectural changes underneath the essence, they're still the same. But this merger is evolving the end goal of the project by emerging too. So in that scenario, I would like some understanding of what's going on and some transparency and just to make sure we're on the same page. I don't think it should be a big long process, but maybe it's an easier vote. So yeah. Okay. Just one last comment. So first of all, just to recognize, yeah, I think there's a big slippery slope here where certain things seem clear and other things like PRs seem clear that we shouldn't have reviewed those. And I think it's very difficult to sort of decide ahead of time on a general rule. And secondly, if the SIGs are going to be checking on the health of their projects every six months, usually these changes don't happen overnight. Like a big version, Kubernetes version one to Kubernetes version two, which one might argue is a major re-implementation and would require another vote by the TOC just to give an example. But that's something that the SIGs should presumably escalate as and when required rather than have every project that changes version number have to perhaps go through a vote. I don't know if that makes sense, but what I'm suggesting is that we put most of the responsibility on the SIGs to identify when things like this are happening and escalate them to the TOC when they think it is appropriate. Sounds good. I mean, I have definitely enough feedback from folks to bring it back to the projects when they're ready and then get them on the docket to present once they have more formal plans in place. Any other thoughts on this? I think it's great to actually see folks joining effort, so it's a good result regardless. I'll just put it this way. There was a very entertaining meeting I think was last October with Brian Cantrell and I kind of moderating them, but these two communities and it's nice to see the output of that finally. All right, I think that's enough discussion on this topic. Look forward to kind of an update soon from that. Next discussion point. We've been discussing this for a while. CNCF is over three years old now. I think it's healthy always for communities to essentially sometimes go through spring cleaning and archive. Things don't always have to exist within the project, especially as technology trends and maturities and communities of all over time. We've discussed the notion of formalizing archive projects and also related to that also having a transparent health metric, so it's easier to come to this discussion. There's a PR out there with a basic process for archiving projects. I would love the TOC and community to take a look at that since I think it needs fresh eyes since it's last been proposed and then just like with anything else out there, I think always having a pilot project or pilot something to go with with this type of process could be useful to kind of ensure that it works. So basically two questions. One, what should we do for archiving projects and two, do we have any candidate projects potentially that we'd want to run this through? I'll open it up to the TOC and community for discussion here. I think we all probably have rocket in mind as a possible archiving candidate. I think as far as the process is concerned, I think an important part of this should be going to the maintainers of a project and saying, is this something you want to come and present about? Do you consider yourself active? Is it something that you would continue to benefit from by being in the scenes? I feel like that should be the first step in any archiving process. Seems fair, it's almost like an appeal. Almost, yeah. Because if the maintainers actually say, you know what, that's going to be a relief, then there isn't a, you know, it's fine. Or they may need help. Yeah, it's complicated, right? Yeah. Any other questions, thoughts, concerns? You know, otherwise I'm happy to kind of move all the discussion to the pull request, but it would be good to kind of have like a 1.0 of the process in place, at least over the next, you know, month or two. I mean, I haven't read the pull request. Do you have like the TLDR on sort of what this means? Basically, the initial thought was, you know, two-thirds, you know, super maturity vote for the TOC to archive something. And then essentially what would happen is the project would essentially just live under the Linux Foundation and any CNCF branding, marketing support, dollars or whatever would be essentially removed from it. It would just kind of be an independent project that just lives under the LF with minimal support. Why under the LF? Because I think, you know, if somebody comes along and they're like, hey, we want to actually reboot this. We want to take this IP and move forward with it. But hey, can you transfer it to us? Or like, you know, maybe we don't, who gets to vote and decide on that? It would be essentially the TOC and the projects would have to come to a conclusion. Once things are technically in a non-for-profit, it's not really feasible for it to go back to a for-profit entity. Well, I mean, it could be, let's say that somebody wants to resurrect Rocket under the Apache Foundation. Yeah, that is fine. We could have a discussion. I think that would be a case by case. I mean, obviously, what I'm trying to say, though, is that if it's actually archived under the LF, then the TOC has no standing to actually help guide that stuff post archival. Like, why doesn't it remain archived under the CNCF? Yeah, that could be potentially, it depends what you want to mean by archive. Archive can mean like, you know, we shut down the repos or archive can mean we just dissociate any CNCF branding and the project continues, kind of run how it does, you know, whether it's, you know, they commit every once a year, once every six months. Yeah, I mean, just the thing is that like, you know, it's, you know, things don't always stay dead. And so the question is, you know, what happens after that who gets to decide? And so it seems like if somebody submits something to the CNCF, even if it is sort of in this, you know, atrophied state, it should still stay within the CNCF. Yeah, okay. That's fair. I think the key point is we don't want to, you know, if a project's archive, we decide to not actively promote it or market it. Right, exactly. And, you know, when we give more, you know, users the appropriate caveats around that. Correct. Are there any other foundations under the LF that do the archiving under LF? Is that their foundation? I mean, we have had projects that may have been in a umbrella organization have spun out to an independent thing. I don't know if that was necessarily an archival thing. I think the JS community has some notion of archiving. I'd have to go look at it. Okay, that's fine. It's not important. Thank you. A brief comment, the distinction between archived and sandbox doesn't seem very large in that we don't provide marketing or much support for sandbox projects either. Maybe archiving actually just means going back to sandbox. Just a thought. I would put that in the PR. I think sandbox projects still get access to like the CNCF service desk and staff. Occasionally, it's just they get very minimal marketing resources. In this case, archiving to me would mean they just don't get any support, period. Can you all hear? Yeah, someone's on the phone. Sorry. This is Dan Shaw, no JS land. So a couple of good examples in the now open JS foundation would be Jojo and jQuery. Those projects are continue on as projects that exist and are essentially in archival mode and have moved from the JS foundation to the JS foundation now to the open JS foundation continuing that ongoing coverage of having the governance of the foundation. Thanks, Dan. Any other thoughts, concerns on this? Otherwise, I think having the discussion on the pull request is probably the best way forward. All right, let's move discussion to the PR and we'll catch up on this and hopefully we could come to a conclusion for B10 for the archiving process. Project presentation meetings. So yeah, we started to do these last month for the first time. You know, we have a backlog that we're actually starting to chip away at, which is awesome. I think this is a good idea. So thank you to whoever proposed us to have a meeting dedicated to project presentations. The next one is coming up next week. I have one project slotted right now that already volunteered and sent a presentation. We have room for two more. So I don't know if there's anything that TFC would like to see on the docket, but I think this is the time to propose since we're only about a week away from that particular meeting. Any thoughts on the TFC based on the current backlog or something they would like to see? Not exactly. I don't know if this is the right time to make this point, but I think I mentioned on one of the mailing lists the idea that those backlog items that are allegedly in progress in the backlog, I really feel like they should have owners and it would be great if we could try to assign some owners and get those items actually kind of, well, having somebody who takes responsibility for pushing those through. Sounds, I think after this meeting we could sync up, given that you're chair now, we could kind of have a discussion on how to do this and essentially watch that backlog. Okay, well actually if there was other people on the TFC who felt that they wanted to drive forward some of those issues or take some kind of ownership, I think that would be really great. Yeah, feel free to let me in on that conversation was however you feel like delegating, nobody to help. Yeah, I can try and find time also, just send stuff my way. Great, yeah, I mean it's things like these graduation applications where just somebody needs to kind of make sure that it's really going to happen and that we're really doing the whatever due diligence we need to do. I feel like actually taking ownership of the PR would help clarify who's making these things happen. Sounds good, well we'll take a, I mean I will personally spend some time and kind of go through and then see if we could assign or find the ones with no assigns and paying TFC members. Super, thanks Chris. Yep, all right so we'll figure it out if there's a project that wants to volunteer for the next meeting, let me know but we at least have one schedule that I think already has meant the minimum sandbox sponsorship at least. Let's go on to the next slide. Oh, final call that if you know any students out there that are interested in having an opportunity to work on CNCF projects, there is summer code. The student applications are closing April 9th. We actually have a ton of projects participating on as part of this process. So it's an awesome program so highly recommend you do your best to share that CNCF is participating this and students apply given that the date for student applications closes on April 9th, which is pretty soon. Cool, all right CNCF SIGs, we discussed this that the vote kind of went through. One kind of new bit of information outside of the process being approved is we have tea of steel liaisons for the initial set of SIGs. Thank you Quinton and Alexis for driving a lot of this to get it off the ground. If you go to the next slide, the kind of proposed process here is we'll pilot it with one SIG first kind of in the governance security space and kind of get that going trying to figure out you know where we'll live, how we're going to kind of document it in GitHub and so on. We'll start there and then after that works well we'll follow on with all the rest of the SIGs. So anyone have any questions here? I was just curious about the choice of that particular SIG as the first one. You know in my opinion the folks in the governance security space have been more than willing to spend the time to kind of get this off the ground. They've actually volunteered so that's kind of how I've made the choice versus the others. Also the kind of safe security whatever the name they have for that current group has been kind of a pilot for a lot of the initial SIG process discussions and so on. Yeah I guess my main concern there is that that particular working group has not produced the white papers and things that the TOC requested and taken a while so I guess we just need to be very vigilant. Hi I'd like this is Sarah Allen. I'm one of the co-chairs of the Safe Working Group and we had some mixed messages from the TOC about priorities and so the white paper was many one of many things that we were working on and it was actually deprioritized because we were focused on you know rightly or wrongly on a process for evaluating projects and understanding how they fit into an ecosystem that would drive the safety and security of the whole community and so that was the approach that we were taking and we produced a number of artifacts the use cases and personas the administrator's bill of rights and we're working through a process for project evaluation so that was and then we had a number of conversations with other TOC members and started to prioritize the white paper so it was really a matter of you know perhaps it was a miscommunication on priorities of the TOC but we weren't at that time a TOC we weren't formally affiliated with the CNCS so we didn't focus on we focused on figuring out what that process would be rather than taking you know worrying about what the direction was I'm actually really in favor of using the safe kind of proposal processes and reviewing those working through those because those could be used as a model for other SIGs that haven't even started yet the white paper output is a valuable thing and an artifact in its own right but it won't help us with the scalability issue I think we get the processes right that really will help us and I know that the the folks at SAFE have got some some proposals of coming together that may help us with the other SIGs as well cool any other thoughts here otherwise now that the SIGs process is approved we'll we'll start piloting this and hopefully there'll be a fast follow effect after we kind of get the pilot done yeah I'd really like to see you know in fairly short order once the SAFE people are ready with it then presenting to us here's our process for reviewing project here's our proposed process rather and we can see whether that's something we want to use as a model cool any other thoughts otherwise you know we're pretty much wrapped up for this time uh we'll be meeting again next week for project presentations um any other anyone have any other topics or things to discuss any questions from the community I do want to bring up I mean there was a great discussion going on in the chat here about this sort of Fluent D Fluent Bit thing from earlier right um and you know I was totally wrong saying that like Fluent Bit wasn't part of the project from the start and I think there is an interesting discussion of like you know when we um when we promote we do it based on uh a main project but then there's these sub projects and sort of how do we separate out different maturity levels for sub projects versus the main project I think Kubernetes is a great example of this there's like a gazillion like sort of like sub projects sub efforts that are not at the same maturity level as the rest of Kubernetes um and so I don't know what the answer there is but I think you know to some degree all of our processes really sort of conflate the idea of project and and specific you know code and or artifacts out of that and and one project may be mature but it may have some parts of it that are not quite as mature so just something for us to to noodle on no definitely I think we kind of deferred all that you know sub project means to the top level projects themselves right and so I mean even yeah even Kubernetes landers a ton of too many and they're of all varying quality uh I'll put it that way so so yeah I just no disrespect to the to the to the Fluent Fluent Deep project I don't want to I was just using them as a foil as an example yeah Hi Chris this is Eduardo from Fluent BitProject from D and yeah basically as we as a maintainer I often get that question from the users in conferences several places a is Fluent Bit uh incubation project is a related project so I think that the thing is how we can try to find a good messaging for that and to avoid confusion yeah yeah so I don't know I don't have any proposals I just want to say that this is something that I think is is starting to emerge yeah or it's always been yeah is this a little bit like the um the Kubernetes incubator you know two other projects have their own incubators well so the Kubernetes incubator is no more um right what we did is we replaced it and then and Brendan wrote up a plan around this with SIGs can sponsor sort of side projects that are you know still within the Kubernetes scope they're not officially part of the Kubernetes release they're wholly within that SIG and so you know Brian in the comments here is saying something like an alternative scheduler right can be experimental feature even within Kubernetes there's some features or systems that are marked alpha versus beta versus GA so there's a maturity going on there um and then uh and then like the other thing we did with incubator is there's this idea of Kubernetes associated projects where it's like there can be you know if folks want to self-organize write some code you know discuss it on the Kubernetes Slack you know adopt the the CNCF COC all that type of stuff they're free to do so um but that doesn't come with any sort of endorsement from Kubernetes because one of the things we saw with the with the incubator I think we see a similar thing with with with the sandbox is that sometimes projects would want to be part of it just to get sort of that blessing that sort of marketing lift of being associated with it and we just didn't have the the the time or the capacity to be able to really render an opinion on all of these so yeah it's very much like that but I guess there's a question I think and this is also going to like like when does it go too far right like if you if a project comes in into doing x and over time it changes and it's doing something completely different and it pivots into y and it's a whole new code base does it still like you know I don't know we haven't hit that situation yet I don't think but it's it's you know theoretically possible yeah all right don't want to don't want to uh you know people's time I just wanted to correct the record there yeah no no it's yeah it's it's an interesting line where I think you know we've grown so much that projects essentially are doing their own stuff projects right and our kind of uh oversight there is very minimal once a project becomes accepted we kind of defer to them to to run with their own governance yeah and define what they are yeah all righty anything else while we have folks online otherwise we'll see each other next week I just want to add something real quick uh Liz I think brought up a good point around in one of our mailing lists around defining what it means for respect to graduate from the CNC or graduate from incubation and become a graduated project I'd love for us to noodle on that subject as Joe likes to call it um at some point uh with the wider community um if we have some time on the agenda at some point okay like like uh in spec you mean like something like a cloud events or it's tough okay yeah we have tough you know we have a case study here it'll be tough and it's kind of interesting to think what does it mean for spec to graduate I'll uh I'll file a GitHub issue on that just so we don't forget because it is a bit of a for a while we didn't treat specs versus like source code type projects differently and I don't know if we want to go down route but it's definitely a discussion that we should we should have yeah there are definitely some questions that I have um some things don't apply so I would love I would love to do that appreciate you filing an issue though thank you stories all right um I think uh I think we'll wrap it up for the day and give people about 10 minutes back so uh thank you and uh we'll see each other next week all right take care bye guys