 Oh, there's an idea. I like it. All right, we're five past. Let me do a quick roll call here. So I have Alexis, Joe, Liz, Matt, Jiang. Is Brendan, Brian, Jeff, or Michelle here? Did I miss? Oh, it was Brian Grant. Okay, I see Brian. Cool. Jeff or Michelle? I don't see you right now. Okay, but we have six. We have quorum, so we're good. Let's go kick it off to Liz for the agenda. Okay. Hi, everyone. We will move very swiftly on to welcoming Amy, who I hope is on the call. Amy, are you here? Sure am. Hello. Awesome. So welcoming, Amy, who is going to be the driving force behind projects to help us in the CNCF. Do you want to introduce yourself and say a little bit about your focus? Sure. Yeah, I'm Amy Scavarda. You can find me at Amy on Twitter. You can find me at Amy at Linux Foundation. My focus right now is going to be kind of building more of the SIGs, building out our project services. And you might have known me from my previous role at Red Hat, where I was the Gluster Community Lead. So, come on. Good to see you all. Big welcome to Amy. Yay. Welcome, Amy. How do we do applause on this thing? Yeah. Yeah, slash applause. I would just say it. I just said it into the chat. Awesome. All right. You've gone. Yeah, Chris, do you want to talk about this? Yeah, sure. I'll do the shameless shake down. So, China is coming up in a few weeks. It's a little bit hard to believe that we're doing another QCon so quickly, but hope to see many of you there. It's a great program. Final kind of call for CFP and sponsorships for North America are open and will close in about a month from now on, I think, July 12th, end of day. So, if you're interested in speaking or sponsoring, please feel free to contact us. And then for Europe next year, we'll be in Amsterdam on March 30th through April 2nd. So, kind of exciting to be in a new city in Europe. The final kind of thing is, I know many of you were at QCon recently in Barcelona. And, you know, generally, we've been talking to a lot of our kind of members and attendees, trying to get feedback on how to consistently and constantly improve the program. So, I kind of like to open up, you know, the TOC call, not only TOC members, but also community members on this call to kind of give any feedback on what went well, what would you like to see improved, and so on. So, we are going to be producing a transparency report in, I think, we're going to try to get it out by the end of this month that will basically, you know, fully showcase, you know, what people's, you know, feedback were on different talks, the overall program, yada yada from surveys that we do after the event. But I'd like to open up now to just get any feedback from the kind of wider group here in the TOC on how things went. Well, I'll start, because you know me, I never hesitate on this stuff. Sure. So, I got three things. So, number one, I think it felt a lot less vendery this time around, which I thought was really good. There were, especially the keynotes, I think, were very much focused on users and use cases. I think calling out sponsored keynotes helped make them be a little bit less sponsored for, you know, if that makes sense. So, I really like that change in that, you know, it was, you know, the venue was problematic. You know, I say this because, like, VMware holds VMworld year up there every year, and a lot of people at VMware love the venue, but I think, you know, there was a lot of walking, the food was crap, and some of those big sort of warehouse size, hanger size rooms with the partitions didn't do a great job of sound isolation. Okay. And then the second thing, and I don't know the right answer to this, is that my busiest day at KubeCon is the Monday before KubeCon, because we end up with all these, like, co-located events. And so, I feel like that's where I'm actually getting dragged into, like, 12 different directions. And so, I don't know if there's an answer to that, because I think just naturally everybody wants to co-locate stuff with KubeCon. But, like, that Monday feels like it's gotten overloaded to the point of being really hard for at least me to manage. Okay. Do you, on the sponsored keynote thing, do you think explicitly calling them out as sponsored keynotes forced the keynotes to be better? Because I did notice that this year they were way better than they have been in previous times. That's just because I spoke as I spoke. No, actually, for what it's worth, I think that they, I think that they, you know, for whatever reason, they came across as less sort of, like, come by my shed and more, like, you know, let's talk about how we were, like, community, which I think is a good change. Yeah. And I'm just wondering if that was related to them being explicitly called out that way, where people may have decided to change things up. But yeah, I didn't notice. I would guess so. I think most of the credit actually goes to Brian Lyles and Janet Cua who did pre-calls with all the regular keynote speakers and the sponsored keynote speakers and talked about what the community was expecting. We try that all the time, but yeah, maybe Brian and Janet cracked the code this time. Well, I think also it might be good to collect the ones that were particularly good. And not only from, like, from maybe the survey content has that, but there might be something more qualitative. Like, I particularly liked, I have personally found the landscape a little problematic in its categories, not particularly being helpful to me. However, the one, I can't remember who it was that used it to show what things that they were using in their deployment. And I found that to be really helpful. Like, somebody's actually saying, we're using these particular things in these buckets. And that, I don't know, I found that format to be appealing, informative, also revealing of things that companies often don't tell you. And so that kind of opening up and sharing things that are not about their, what they're selling or providing. I found particularly just like, it felt genuine and it felt educational. And it was also a great call back to the landscape. So I think picking out some formats that are appealing and suggesting that they pick one of those formats or propose a format might help because then the format leads them towards presenting something that's educational in a value as opposed to a pitch. Yeah. Anything, I see Suga said about track hosts. How do people, people generally pretty positive about that? I thought that was great, actually. I mean, good. I mean, we had a track host in our team for two tracks. And he was a little bit, he felt very much kind of in the background, which may have been a good thing. So he was kind of unsure what the track host was supposed to do. So I think in the future, clear a guidance on what your expectations are for track hosts would be good. Okay. Duly noted, Alexis. So, I mean, one thing that I think on the track host thing, I think it might be worthwhile to explore doubling down on that idea. I know like QCon, which is different from QCon, because this isn't confusing at all, like actually has the track host help curate the talks and actually sort of bring speakers in. And it creates a much more curated feel for the talks. Because I think we do have the problem where there's just way too many submissions across way too many topics. There's duplication. I think that's just a matter of scale. So maybe sharding out some of the sort of picking the talks responsibilities, you know, might be something to explore. And I think also just from a SIG perspective, it was an incredible opportunity to of gathering people together. I think that if there were some kind of a, I didn't think about this in advance, but some kind of like after the intros and deep dives, a space for people to overflow to it could help with that community building. And then also we kind of retroactively are pulling together all of the security based talks. And I wonder whether we could do that, you know, in advance in the future, whether whether it be a formal track or not, I think pulling together a thread of these are all talks along a theme could really help people with maybe some spaces that are allocated towards discussions around a theme so people couldn't gather. I think that would be really helpful because it was kind of hard to connect to people. You always had to create meeting spots and miss something, you know, like, I think some kind of less formal gathering spaces would be really helpful. On the topic of talks themselves, one of the things that really jumped out me during the serverless practitioner summit was that, you know, people get up there and they talk about what they submitted for CFP. So it's basically what people want to talk about because sort of gets pushed on the community. And it'd be really nice if there was some way if we could sort of allow that to be sort of turned around and allow the community to tell us what do they want to hear relative to talks, right, just because, you know, we may have a whole bunch of talks out there for any of the particular tracks that they're they interested into themselves, but there may be a gap in terms of what the community actually wants to hear about. And I don't know what the mechanism would be, but it'd be really great if we could come up with some way for the community to say, for the next coupon, I would like to hear talks on this topic of that topic of that topic. And then I'll encourage people to do CFPs on those particular topics, hopefully. I second that. I think that's a great idea. Yeah, Lewis, I didn't I didn't hear you well. So if you're mic, yeah, we hear you now. Okay, yeah, I was just thinking that I second that I participated a lot in OpenStack. I know there's a plus or minus to that model also. But I feel that the community changes every six months. And I from my point of view, I see that the community, again, I've been participating in KubeCon since one point, sorry, within is one point three. And I've noticed now specifically in KubeCon Barcelona that persistence is changed is something that people are looking into. And I feel that maybe it's something that we can talk about, or allow them, you know, get more feedback from the users to see what they would like to see in talks. Okay, I think some of the feedback. Yeah, I know, I heard a lot of clear. I think we could expand a little bit of our post conference survey to maybe include more of, you know, what what you didn't hear, or what would you like to hear? So we get some more of that concrete data from books. I think it's a good first step. Yeah. And to echo what Sarah was saying, the very last day in the Kubernetes storage SIG, the last question was, well, what, what is the difference between the SIGs in, you know, CNCF and this SIG? And that was a bummer that that was the very last day of the conference, the very last question, you know, where people could have gotten involved at the beginning. So I don't know, maybe we could have like a want to be involved booth, you know, that the maybe co-chairs can recruit people and have them better understand it, because it still seems like there's a lot of fog around what, you know, what value there is, what happens in those, how do people get involved? I'm not sure how to communicate that better. Okay. Thanks. I think one of the things Amy, you know, and I will be working on is as the CNCF SIGs get booted up, we'll try to be a little bit more clear on kind of the marketing and delineation between, you know, what they do versus the Kubernetes SIGs and just overall, you know, the role in the wider ecosystem. But that's something for us to kind of work on in the coming months. That's reminding me that I had good things about the project booths, I think they were well received. Yeah, no, the Prometheus, I talked to the Prometheus maintainers, they loved it. And just like nonstop traffic, which sometimes is challenging as a maintainer, juggling everything, but they were able to do it. So I think we're going to expand our project maintainer booths for KubeCon San Diego is the plan, because the feedback's been so positive. Yeah, same with the work. I talked to them quite a bit, and they were very pleased to be able to talk to so many people and have that opportunity. And it really brought in, you know, a diverse people, you know, set of committers, different companies to represent that. So that was neat to see. One factor for the CNCF SIGs is that they'll get their own maintainer track talks in San Diego, just like the projects do. Yeah, can we make sure we do that earlier in the schedule rather than later? Because maybe that would spark some people's desire to be part of that and communicate with those people throughout the week, rather than the very last day of the conference. Can you elaborate on what the maintainer track is? That, you know, like, we can be offline, I'm just not really familiar with that or point me to some of it. No, there's a long blog post on it, but in summary, we had the call for papers track, which is about two thirds of the talks at the event. And that goes through a program committee of about 100 people as organized by the co-chairs. And then separately, every CNCF project and Kubernetes SIG and now CNCF SIG also gets an intro and deep dive talk. And those are listed as the maintainer track talks. And so there's about five or six of them going on in parallel two to three days. Great. We actually participated in it. Just didn't quite realize the track format. Thank you. No worries. Sure. To reflect a little bit on Joe's point earlier, you know, a lot of people have expressed there's a lot to get done in day zero with like the Kubernetes community, you know, you know, media or contributor meeting and, you know, all the, you know, cloud native storage day. If that was spread over two days, would that be beneficial for folks? Or it's just like two days of just a lot to attend to because it's, it's, there's a lot of going on in day zero. But, you know, I don't know if we want to extend KubeCon to be the full week, essentially. So, no. It's too much. When I was there for Cephalocon starting on Sunday and by Thursday, I would just, yeah. So I mean, so one thing I would say Chris is, is, you know, there's co-located events that are sponsored by companies very vendor centric. Correct. Those take attention in time. I know they're a revenue source, but they also take time and attention away from things that are more community focused. And so if we're looking to slim down the number of things going on at KubeCon so that it actually is more focused on the projects, moving away from the vendor days, you know, on that Monday might be, might be a good way to go. Yeah. One, one other thing that might be worth considering is, is maybe just breaking up some of those co-located events so that they're either shorter or they're sort of split into sections so that people could attend multiple co-located events because one consistent bit of feedback I got was that, you know, people wanted to attend maybe more than one co-located event, but that's what prevents it from doing so. Yeah. So it's a, it's a, it's a tough scheduling problem with multiple constituents that all have different views on, on this. So yeah, if you have ideas on, you know, how to improve things versus, you know, maybe forcing things to be half days or across multiple days, front end, tail end, just please send it our way. It's just, it's a tough problem. Just a thing I'd like to add is, is there a, can you hear me okay? Yeah, I hear you. You're a little bit light, but I could hear you. Okay. Is there, one of the things that I, I feel that it could be dangerous, not dangerous, but we have to be careful of is the amount of time we allocate to CNCF projects themselves. It may be at the sandbox level at the, at the next levels up. I just want to be careful with, with those types of talks that they, and how they compare to, as a normal CFP, and how they compete with each other. I'm concerned that there may be more introduction to projects becoming sandboxes just to get talks in, because otherwise they wouldn't get a talking, right? We have to be careful how we manage that, because if not, we're gonna get that view, in my opinion. Okay. Yeah, the previous TLC actually made an explicit decision not to promote any sandbox projects at all. And I think we should stick to that or at least officially change it. And I don't think that is actually happening in practice. We, for example, had a sandbox project presented on a, at a keynote presentation. So I think that this TLC should make a clear decision whether they can stick with the plan to not actively promote sandbox projects. And if so, we just, we just have an actual sandbox and put them in there and then everyone else can have a normal booth. Yeah, I think it's, I think giving that clear feedback to the program committee could be, could be good, because it is challenging sometimes if you had a sponsored keynote or something, they could kind of choose what they do. I don't know what the specific context was in this case, but I think that's clear feedback that TLC could give to open SDS and it was in Brian's keynote. So there was obviously some miscommunication around that. Okay. Yeah, we'll circle with the program committee. I mentioned that to Brian. Okay. Oh, already. So, so he's, he's aware of that, that you won't see the project overviews mention the sandbox going forward. And small thing on the schedule, I think maybe delineating like sandbox projects explicitly calling them out as such could be useful on the schedule now that I think about it, but okay. Any other Just to be clear, I think they should not be on the schedule. I mean, they should not be, they should not receive maintain a track. Interesting. Because that constitutes the promotion that we've decided not to do. I guess it depends how you define marketing versus event space. Yeah, I think, I think that TLC would have to be clear on, on that specific thing, giving them like an event, event space to have their own little session and do an intro and deep dive. I don't think it would necessarily constitute over marketing, but that, that's my, that's my opinion. I think we have this constant challenge and this constant compromise between, you know, the levels of two diligence for sandbox projects versus the amount of airtime they get from the CNCF and the events. The challenge is if we, if we give them a lot of airtime, that's the factor promoting them and, you know, perhaps putting them at the stage where they're not yet ready on the, you know, and that should perhaps reply then more due diligence. But if we want to keep the bar low, which I think is a good idea, then we should probably minimize some of those things. Yeah, I agree. Like I've always said, like on the keynote stage or stuff like that, there should be no sandbox projects, but giving them like an intro or deep dive always seemed reasonable. But I think maybe the TLC needs to have a discussion on, on kind of their stance on this and maybe come back with a statement to the, to the program committee. Yeah, I am wondering whether Sandbox should at least only have one rather than two slots. That could be a compromise also. Yeah. So, so maybe we could kind of create an action item for the TLC to kind of discuss this over the next, you know, a bit to come up with some formal feedback to the program committee and what kind of work from there. Sounds good. All right, we're about almost halfway through. I think we should try to go to, yeah, if you have any other feedback on KubeCon, you could always send an email to events at CNCF.io paying Dan or I. We're always happy to kind of hear from you. So, all right, SIGs, go headless. All right, so we have two SIGs now. I believe they're both solid, right? Chris, are we looking for a formal vote here for these TLC approval? Yeah, so storage has added some essentially co-chairs and tech leads and based on the governance process, we need essentially a formal vote, but we have quorum on the TLC today. So, if there's no opposition for Erin Boyd to take an additional co-chair roll and Bradley Childs for the tech lead role for SIG storage, then, you know, we could kind of consider that approved and not do like a formal email vote. So, if there's no one opposed to this on the TLC right now, I'll consider it approved and go. Any other statements or SIG storage, maybe Alex or someone from SIG storage wants to make the case why they're doing this? So, we're doing this for two reasons. One, we had a vacant co-chair slot and Erin has sort of put her hat in the ring. And I think, you know, she would be extremely well qualified to do this role. Plus, she's also, you know, very well known in the community. Similarly, Brad would be extremely valuable in a tech lead role and currently co-chairs the Kubernetes storage SIG as well. So, it just brings a lot of experience to the team and helps with the projects that we're looking at. So, is there, you know, in the SIG charters or in the when we define the SIGs, is there a set number of chairs and tech leads? Because I know with the Kubernetes SIGs, we kind of leave it up to the SIGs to figure out how they want to structure themselves. I'm just curious, I mean. My recollection is it's defined for three co-chairs but I'm not sure there's a definition on tech leads. Yeah, I recall that being similar, but I have to look at it. Yeah, the SIG charter says three co-chairs but doesn't specify a limit on or doesn't specify any number of tech leads. Okay. Is that the SIG charter for this SIG or is that for all SIGs? I'm just, okay, I don't remember seeing that. Okay, cool. And this is Luis. I'm just a little bit concerned about two people in the SIG company and the same, you know. So, if you need another tech lead, I throw my head in there. So, let me know. We can discuss that after, Alex. I knew you were going to spot Luis. I was waiting. So, any of the other current co-chairs, I don't believe either of the current co-chairs are red hats. I don't believe any of the current tech leads are. Okay, so it'll be two out of seven. So, yeah, I also think, and I think Amy can step into this role, but it would be great to actually look up at whether we're following the rules. So, we went through a bunch of thrash or iterations in getting our material together. And then I realized yesterday that Dan hadn't pull requested himself into a TOC contributor. So, I think, like, let's, you know, like, I think having everybody double check. It's on the agenda. Don't worry. Amy and I will be on it soon. Awesome. Yeah, I would suggest we give this another two weeks or so just to let everyone weigh in because I'm not sure that everyone's given it full consideration. Okay. Well, in terms of the tech leads. Yes. Okay. I'm fine deferring it to next time and letting SIG storage come back. So, that works for me too. Okay. Go. All right. We had a great suggestion, what came to me through Alexis. I know some other people were involved. Sarah was one of those people around encouraging diversity by using the SIGs as a nurturing ground to get more underrepresented groups into roles within those SIGs. I think that was an awesome idea. Unless anybody has any kind of objections to that, I want to just try and get that incorporated into the SIG. I can't remember what we call it, the process or charter whatever it is. So, if anybody has any comments on that, I think it was a really good email discussion about it. Otherwise, I think we should incorporate that. And then the last question on this slide is, what SIG would like to be formed next? And I saw in the agenda document, I think, Ken, I don't know if Ken is on the call, but he was suggesting ah, I've forgotten what the name of it was, traffic. Yeah, that's right, Liz. We've been a little bit slow. I think when just as soon as the SIGs where the documentation was formed for what those are, we were excited to you go over and reincarnate the networking working group into well, either between SIG traffic or SIG network, or maybe the both of them. But anyway, it was to expand the scope. The networking goes deep and wide. There's a backlog of things to review. Things like SMI were just announced. It's a happen in space. Ken and I have been co-chairing the networking working group for some time. We spoke with Matt earlier on and gotten a draft proposal that's yet to be PR, an issue yet to be created. So, yeah, I think we're raising our hand there in terms of up next. Fantastic. I think maybe in the interest of time offline, I would like to request that co-chairs from SIG Storage and SIG Security, having been through the process of forming your SIGs, if you have feedback on the process and if there's anything we need to tie up, let's do that sooner rather than later. So, let us know. All right. And I think there's no reason why we have to only form one SIG at a time. So, if anybody else is out there thinking, I also have a SIG that I want to form. You are also welcome to start drafting your proposal. I think that Michelle and I will be trying to put something together on apps and app delivery. So, I want to mention this because there are a few other folks who are involved in drafting some ideas around that back in November and December. So, if you want to be involved in this, get in touch with me or Michelle or both of us by email, please. Yeah, I was going to suggest that we get the core and applied architectures together as well. And I can assist with that if needed. Seems like one of the more necessary of the CNC of SIGs and we can start putting all together sooner rather than later. Can you do a formal call on the TOC list, both Alexis and Quinton, just to raise awareness? Not everyone attends this call. Sure, we'll do. All right. I'm just opening the issue, T213. This is the archiving process, right? Sorry, it should be... No, it isn't. Oh, it's the... It's Brandon, CVE process, right? Did I link the wrong issue? Sorry, one second. No, no, no. It was my memory. Do we have Brandon on the call? I don't want to go check one sec. If there's a critical Brandon exception. Yeah, no. If he's on the phone, what is it? Star, Star... I forgot how to unmute on Zoom, but... Brandon, do you read me? If not, I'm happy to summarize kind of the issue. Yeah, Star 6 to unmute in case you're there, Brandon. All right, let's assume he is not, but the issue at hand was basically as our projects get kind of more mature, you have to develop some process to do security disclosures, CVEs, and so on. And so some of our projects have gone through this, and it is a bit of a somewhat of manual process to get an actual CVE ID and file something and publicly disclose it. So we started a kind of discussion of whether it makes sense for CNCF to kind of be a CNA, which kind of could produce these IDs or use other tools out there. You know, I think the discussion's been a little bit mixed. Also, just I think last week, GitHub announced a bunch of kind of features in this space that kind of help us out quite a bit. I don't know if people have any strong feelings on kind of where we should go with this, but you know, I've had personally a lot of conversations with GitHub and being giving them a lot of feedback on kind of how they can improve security disclosures, and they've been taking a lot of that to heart and are going to have features in the future like producing CVE IDs. So it'd be a decision where we just kind of continue to wait for GitHub and work with them to make sure the tools work for us, or we could do something else. So I don't know how people strongly feel about this, but I think it's gotten a lot better with their new tooling announcements, at least in my opinion. I've got to agree that the things that GitHub have been doing in this space are great. I don't think what they've done so far actually gives the CNA problem a solution yet. Not yet. I know there was a question raised about what the other Linux foundations are doing. Yeah, a lot of them either there's two approaches. One, they will just go through like a respective company that can produce CNAs, like you know, that is a CNA like Red Hat or something, could do it for their respective projects. Some will use Hacker One to do the disclosure process and create the CVE ID from that. So those are kind of, or some will just do the MITRE form, essentially, or the equivalent of that to create the ID. Yeah, I think one thing I was hoping Brandon might be able to share with us, or maybe anybody else on the call might know, if there are any examples where using relying on the MITRE process has been insufficient or caused problems for us. I mean, yeah, the most recent case, I don't know if Matt is on the call, but when on-point through it, I think generating the ID didn't take super long, but all the other shit that you have to do with downstream dependencies, all that stuff was painful. But that's not really the ID generation, but it's just notified. Yeah, I mean, our experience was that it was not very much work to get the ID. I mean, there was some latency, like you have to fill out the web form, and then it takes a day to get the ID back. And then there's some latency again, when you go to finalize the CVE, it takes another day or two for them to update the text. But per what Chris said, I mean, in our experience, that time is dwarfed by all of the other stuff. So at least from our perspective, we don't have a problem with what we did. And okay, I mean, we could make a call to other projects, but I think GitHub is very interested in solving this problem from my conversations with them, at least on the ID generation part in the future. The other parts are just notifying all your downstream folks. That's just a hard problem in general. I don't know how to do that automatically. Yeah, I think I am fine with that kind of status quo, leading towards being able to use these GitHub solutions, unless and until we come up with some reason why it really isn't good enough, I'm happy with it. Anyone else? Okay, I think maybe we should sort of document this and kind of close that issue two on three then. Yeah, I saw a comment from DIMMS. Yeah, if there's specific things on why it doesn't work well for Kubernetes, please let us know DIMMS and we'll try to address it. So I didn't know, I thought for Kubernetes, the CVEs were generated through either someone at Google or Red Hat who had basically access to do that as a CNA. So I don't know if the ID generation was a problem or something else. So please comment on that issue before we close it out, okay? That's fair enough. Cool. What's next? Oh yeah, cool. What's it take this one? I'm happy to take this one actually. Yeah, so I think it's been pretty public over the last few days that Rocket is being kind of archived by Red Hat and personally I would like us to well take a vote on archiving, exercising our new archiving process and moving Rocket into the CNCF archives as well. I have reached out to most of the maintainers and I would say the general feeling is that that is from what they've said to me. I think that's the right move. I think they agree that is the right move. And yeah, so let's open that up for discussion. Any thoughts, concerns, questions? They did actually raise some interesting points about the kind of wording on the archiving process where we say things like we're not going to take service desk requests but we're also going to support transitional documentation. So we need to kind of clarify that but I think the spirit is understood even if the wording is not. The only thing about the process that I thought was a bit weird is it doesn't include a presentation to the CNCF. Even if that's effectively an exit interview, I think there ought to be a presentation from the maintainers about what went right, what went wrong, any kind of potential future and a place for people to ask questions because at the moment there's a at least two weeks email come issue discussion but no formal presentation. Do you think that could be an optional presentation? I mean I can obviously imagine a scenario where the maintainers do not want to do that. Yeah, that's a cool idea but I think doing it as an option would be nice. I think in this case it's relatively straightforward but there could be cases where it's a more complicated process and certainly there are possible discussions about other people who might want to take over the project and you can imagine in other situations it might be even more complex. I was going to raise a similar question and I don't know if this got resolved but there was some question as to where the IP goes when things get archived. I think Joe raised the question and then the counter question is what happens if it wants to come out of archive. Has that all been resolved and if so what is the final decision there? The default it lives with the Linux Foundation just like anything in CNCF per se. If there is a desire to move somewhere else maybe like another non-profit we're happy to support it as long as the project wants to do it. It could never go to like a for-profit entity but like hey I don't know maybe I want to you know go to the patchy or something we could try to happily arrange that it takes definitely some work on our end but as long as a project wants to do that we're happy to support it. Just to be clear are we moving it are we moving the ownership from the CNCF to the Linux Foundation or are we not moving the initial? It's all part of the Linux Foundation anyway CNCF is directly under the LF. I understand but does the IP stay in exactly the same place when we archive the project or does it move? In this case it stays exactly where it is. Okay makes sense I thought it was moving. I mean just one thing as we roll this out you know as this is the first project that's being archived there's going to be a lot of questions there's going to be like probably some press around it you know there may be some confusion I think we just got to be ready to sort of like you know make sure that we can clear up any confusion direct people to the right folks be sort of authoritative about any answers that type of thing. Yeah I think we don't rush this let's let's be diligent do it do it slow come up you know basically everyone on the same page but I totally agree with you Joe let's let's not rush this get everything documented get a fact created and and do our best and set the example for for projects moving forward. I think that sounds great and I think the timeline in the process it says at least two weeks so there's no there's no reason to rush. Did you think they're open for a presentation by the way Liz I know the Rocket folks fairly well I don't it's a little bit ask them right like you know yeah let's let's ask them let's ask them if they would like to volunteer you know. All right any other comments from anyone around Rocket okay okay is Michelle here yeah I don't see her yeah that's a shame uh looks like she'd made some really great points here we want to try and clarify what graduation criteria for spec projects in particular um I think this has been the question has originally been raised around graduation criteria because of projects like TAF but I can understand for other projects that want to move out of the sandbox I think some of the the measures will be the same so things like what do we mean by an end user um yeah so this is this is Doug from the cloud events perspective we're very interested in this there are actually two different questions that popped up because we're considering going from sandbox to incubator and the first question which is the easier one is is there a requirement that the spec have to be at a certain level right can it be alpha or beta or does have to be 1.0 my assumption has been that there is no version number requirement on us but I wanted clarification from the TSE on that first and then the second question is that what you talking about Liz is what does end user mean for a spec perspective right is it just three products are using the spec or that they're end users of those products using the spec yeah I think to that first point Michelle made a very good uh statement there about wanting to see that the spec is stable and unambiguous uh I feel that taking that to the point where you say and therefore must be at version 1.0 might encourage people to uh use a number that may or may not be appropriate to the actual state of the spec right you don't want to force them to go one point or prematurely right right I think incubation products products are not required to be at 1.0 either so it seems asymmetric yeah but I what's interesting is I don't think the document says anything about version numbers at any at any level even graduation which I think is kind of interesting I suppose it would be reasonable to expect that at graduation it was at at least 1.0 but I mean that's kind of for some definition of 1.0 isn't it okay version numbers mean nothing in this industry so yeah okay so I take away from that it's then there is no requirement of version number which is what I assumed that that's okay I think the bigger question is end user well actually I think there is also the points about stable and unambiguous spec how do we judge I mean both at graduation level and that's incubation level like how stable and well I guess we'd all hope that any spec is unambiguous um I guess one thing we could do is we could ask the sigs to you know or you know the appropriate sig to review it and decide that it is or isn't unambiguous and we could also be looking at I don't know time since last change um well I would also I'd ask how could you possibly consider it to be stable and unambiguous if there's no applications that have used it right if it's just vendors who have mutually agreed that their implementation is good but they themselves don't have users that are interoperable I don't see how one could say it is unambiguous like you just sorry yeah yeah I wasn't meaning to say that would be the only criteria I was just looking at the bullets in front of me and working through them one at a time I completely agree with you so I mean at the end of the day you know sandbox incubation is about the fact that you know something has wide participation beyond single vendor it's in production being used by users and I think that same like that in general that's what we're looking for I think that applies to specs also um one thing we might want to explore is our requirements for some sort of test suite against the spec right because that's that's one way to start you know uh it's a level of maturity that you know we expect in terms of projects as they move towards graduation in terms of testing and it also is is helpful with respect to interoperability between implementations I was under the impression that we only housed specs with reference implementations is that true or are we considering being home to specs that do not have come along with a reference implementation which would be presumably that some sort of test suite I don't think that's mentioned in the criteria as of right now but I think even if we have something that has a reference implementation with it I mean like a versus fire I think it's still worthwhile to have a test suite associated with the spec that's different from the test suite against the against the implementation fair enough fair enough I'm just not sure that it's possible to write a test suite against the spec that doesn't have a reference implementation but yeah I would I would encourage us to mandate a reference implementation with the specs but I don't know what that how that sits with the TSE well I think what we can say is that for any spec you know before it moves past sandbox we want to see at least one you know open source implementation of that spec right doesn't have to be in the cncf but at least you know open source to some definition of open source might be might be another requirement that we want to talk about so just from a procedural perspective because I know this this issue has been lingering for quite a while now um would it be all great topics but would it be possible for us to circle back around to the end user discussion because that's the one topic that I really need to get clarity on for the cloud events project before they can move forward on whether they want a good incubator or not um I just want to get a read from the TSE on what their definition of end user means I would say real users using it in production so it's not just yes it's not just like the spec is implemented by somebody it's people are actually using that implementation of the spec like through foxy say like through like the cloud provider offering the implementation of said spec through and and it being used by its respective end users would be good enough okay that's that's why I assume but it's fine okay thank you yeah do you actually need like company names are people using it or just sort of a statement that says we have three users but I can't tell you who they are I know that that is a problem that um Tufts have raised as well where I think they do have you know several nameable end users now but um you know there would be a number where that becomes hard um but I think yeah we have to maybe take it on a case-by-case basis and there are some private like companies that don't want to be publicly listed and if that's the case maybe for like the case of Tuft maybe that can privately share it with the TSE to um at least prove that there are end users but I know there's some sensitivities about where Tuft is being used okay sounds reasonable thank you one other thing that I'd be interested in you know one scenario that I'm not saying this is happening but just thinking about this problem in general is that if we have a spec and all the users are using a proprietary implementation and then the open source implementation of that spec ends up being sort of window dressing that isn't actually used in production that to me seems like an anti-pattern and something that we don't want to support we don't want like I like we don't want the CNCF to actually sort of be a way to sort of like you know open wash stuff right we want to see real true usage of open systems um so as we think about these criteria that might be something we want to think about yep so does that say that the vendor implementation needs to pass the open source test suite so you kind of prove that it is an implementation of the open source spec well I guess what I'm what I'm trying to say is like you know if we have like a spec and the only implementations that are being used in production are commercial implementations yeah I'm not sure that's a place where we want to be I think it's worth having that discussion I also think we you know you want to think about like if you have two vendors who each say that they implemented and their end users use it that doesn't mean it's actually like there's different ways to to assert that you conform to the spec right like so just because you have a test suite that passes for both vendors doesn't mean the end users that would try to switch vendors would be able to right and so I think there has to be some you know and I would encourage that the project themselves has to assert why they think they're fulfilling this criteria not just ask the TOC to be more specific about the criteria like elaborate a little bit and then we can like and then the TOC can kind of evaluate like okay here's what more of what we'd like to see in this direction yeah and then I think you know it's worth reiterating that there's always a level of judgment with respect to the TOC in these things and so there is no sort of like if you check all the boxes then like everybody hands are tied you automatically get promoted here I think that you know these you know the criteria there are a guideline I think it's a guideline both for the TOC and for the projects but I you know I don't think we're trying to foresee every situation and every you know every possible eventuality here. In your case Joe if there's like a particular spec that you're worried about in that case it would be good to explicitly um I mean nothing off the top of my head I mean as we look at sort of like the the the open traces census stuff I think um you know we had Yeager you know which is our sort of open implementation of this I mean you know I think that making sure that we stay true to that versus actually having this essentially be and again I don't want to call out anybody specifically I don't know all the details there but I think that that's a place where we're seeing a lot of interrupt a lot of vendor you know commercial products associated with it that's all fine and good but I think we we want to make sure that there's at least a path around independent utility that's that's completely open around this thing okay all right I think that's uh added a bit more clarity that we can start trying to write up a bit more clearer yeah all right is that the end I think so when what's what's next yeah q and a I think we have one minute left um the only thing to note is next week we have our project presentation our community presentation session right now there's only weave uh flocks I believe signed up I need to double check but if there's other projects that want to uh take some slots to present next week please reach out to me or Liz and we'll do our best to include you in that project presentation uh meeting next week we actually need to um figure out how we get presentations to the six yeah the other things are getting down yeah yeah it's actually using the six Amy we have Amy well I think once we get more six going it'll be easier to delegate down because we've the the kind of compromise we said is every day now it's just like whatever projects want to show up essentially and and present to kind of get through the backlog at least okay for what it's worth we're going to have um a proof point of this where Longhorn is going to be just looking to present through the search uh in a couple of weeks and then present to the talk straight after that awesome fantastic that's good to hear all right bang on time thank you very much everyone all right bye girl