 All right, looks like we've got a lot of folks on the line here. Hello, Liz. Hello. Excellent. Good mic check, too. So give people a few minutes to join. Slides, you're up and we'll wait a bit for folks to come on in. Hello. Excellent. Yeah, we've got plenty of folks on the line. Liz, I will let you start on your call whenever we are ready. We're only a minute past, so. Yeah, should we give it a couple more minutes just to make sure anybody who's coming is going to come? So you could get started with the preamble. Yeah, there's a crew. Thanks for putting the slides in. Yeah, I was just having a look to see who's here. All right, Amy, you're going to mark attendance and all that. Drop it into the working deck. We'll work from there. OK, cool. So I guess we can get started. Welcome, everyone. Normal rules apply. You've all found this meeting, presumably. So marvelous. I don't know why we have that logistics slide. Oh, it's mostly because for folks coming in and actually finding these slides ahead of time. But here is where we all are. Just so that you all know if you're not on this planet. Good luck. All right. And yeah, so mostly today, we're going to talk about the six. And then we're going to have a quick look at the couple of projects that are waiting for TOC folks. So we'll be hassling ourselves to look at those. And then hopefully Michelle is with us. Michelle here. Because I know she wanted to talk about the graduation process a little bit. Yeah, I'm here. Yay, awesome. All right, let's take the six in the order in which they're listed. So hello, Sig Storage. So last week, we did a couple reviews. One directly related to Sig Storage, which was for Rook. We're leaving the commenting open until tomorrow for a week to get make sure there's no outstanding issues. We personally don't have any concerns from the SIG for graduation. So we would recommend to graduate. Saad has volunteered to be the TOC sponsor for that. So we feel like that's in good hands. The second project was given to us from one of our SIGs to review Harbor as it has a storage aspect to it. We do have a couple of concerns around its graduation, mainly two of them. The first one being there are some external requirements to Redis and PostgreSQL. We know that in the past that's been one of the red flags of having that as being part of the base product. And then the other one is the default deployment is not HA out of the gate and the user must then go configure that separately. So it's not HA natively that somewhat worries us. That would of course need to be talked to with the TOC, but those were our two concerns that came out of our investigation of Harbor. And then for the backlog of Dragonfly, we've completed our review and send the feedback out and then we still have the same four things in progress and are continuing to work on them. And that is that. Are there any questions? That thing about high availability for Harbor, is it what you say it can be or it must be configured separately? Is it easily configured separately or is it user must jump through many hoops? So I can speak about that if you don't mind, Liz. So hi everybody, this is Michael. I'm one of the maintainers of Harbor. So essentially the Harbor has many components and Redis and PostgreSQL are the only two of them that we deploy out of the box without an HA configuration option. And we do that for a few very specific reasons. There are readily available operators and home charts that customers can use to deploy Redis and PostgreSQL in an HA way. So for the folks that actually do wanna deploy them in an HA way, they do that very, very easily. And the second reason is most of our customers don't really put a single instance of Harbor on one Kubernetes cluster because the cluster of Kubernetes becomes your unit of failure. And that's a problem for them, especially if you're using Harbor to be the vehicle for basically hosting all your cloud native artifacts. So what customers instead do, they deploy Harbor on two separate clusters and they use Harbor's replication which is a very widely used feature to replicate assets from one Harbor to the others. That way they have two highly available Harbor instances with each of them with their own copy of Redis and PostgreSQL and they put a global load balancer in front. So if you guys remember when we did the TOC presentation, one of our customers VP came on board to show you that architecture where there are two Harbor instances replicating each other and each of them being individually hosted. So that's the reality today. In addition to that Harbor team is working on an operator that will enable customers that are looking to deploy Redis and Postgres in an HA mode to enable them that. So we are also working on that. So that's basically where we are today. Thanks, Michael. And I didn't look at the PR this morning before this call and I noticed that a lot of this information has been updated. So thank you for doing that and contacting SOD directly to have that in the PR of our due diligence. Yeah, no problem. And my question now that obviously now Harbor has gone through the due diligence with the CX, I also wanna ask Liz what the next step is. And I was gonna just check with Erin or SixTorch generally, do you believe that SixTorch has finished its review or is it still an ongoing discussion? I don't feel like we would do as an exhaustive due diligence since we were just looking at a secondary piece of it. It looks like the concerns that we brought up have been noted and there's plans to fix that. Whether or not that meets the criteria for graduation I would have to yield to the TOC for it but I feel like we're done, our comments are put in, we don't need any extra time. Okay, that's cool. So I think Michelle will talk a bit later on about trying to streamline the kind of graduation process but it sounds to me as though for these projects we have the kind of documentation in place for the TOC to review and start forming our opinions on it and normally the way this works, I don't know if we have a TOC sponsor for Harbor yet. Yeah, we do, it's Jean, Jean was a TOC sponsor. Great, great, okay. So the way this would normally work is that person would be responsible for determining whether, basically saying, yeah, at this point I think we're ready to call a vote and normally by that point we will have discussed it and raised any questions we have. So yeah, I think the next step sounds like it's for us to review the comments and content that are in those two. I guess if I click on those issues or PRs we'll find all the documentation there. Yeah, just this is a small side note here. I think Harbor has been a bit of a special case because it's just being such a broad project that a number of different SIGs were involved. So it's probably had more feedback in separate PRs than traditional, than most graduation projects I guess. And that's a good thing, right? Getting input from across the community is a very, I think that's one of the nice things about having the SIGs work together. So thank you everyone who spent time looking at this. We reviewed it on SIG runtime. So I have a mini update a little bit later. Great, great, okay. Any other questions on SIG storage or should we move to whichever one is next? Which I didn't memorize. Okay, let's move to the next SIG. It is revealed to be SIG security. Sarah, I think I saw you here. Sorry, I was muted. Skip over the slide because I forgot to remove the placeholder. So we have a few new members. We have links here to some recent presentations. We had a really great presentation from the financial services user group about Kubernetes threat modeling. That video is well worth looking at. We're also thinking about can we take those assets and make them available more broadly because the threat modeling isn't unique to the financial services sector. The Spiffy Spire security assessment is in progress just kind of wrapping up. We're doing the, Brendan is leading that and doing the final PR with the team. And we had a great presentation just in February. And then we also wanted to highlight because we haven't had one of these meetings for a while that Cloud's custodian came in in December. And I just recently reviewed their presentation where they started through the assessment process. I really want to kind of call out to Cloud custodian for helping us and being patient with us through the process of kind of defining the project onboarding a little more clearly. So thanks to Liz's recent documentation, I caught that they hadn't had a, there was no record of their proposal interest in the TOC repo and they filed an issue and also wanted to call out there's an open issue now about it's not clear when the PR happens. So I think we'll roll with it with Cloud custodian we're in close communication and we'll figure out how to make that happen. And then update the docs so it's clear. So we're just test driving the new docs. Thank you everyone who participated in that. I think it will get better if we all chime in. So upcoming we've got cloud native security day at KubeCon Amsterdam. And then we had an election. Thank you everybody in the TOC who voted asynchronously. Justin and Brandon have prior commitments for today. Emily, if you're on board, maybe you could say hi. I didn't actually check the participants. But I was thinking it might be neat to have a like TOC meet the check leads. We could have like a virtual session if people are interested and just wanna call out that just these are three fabulous leaders who have been involved in making the SIG what it is. Justin Kapos was doing work on security for the TOC as a TOC contributor before the SIGs were a thing before our previously known as safe group got together. Emily Fox joined us last year and was with Michael Ducey led the very first cloud native security day at KubeCon San Diego. And has been incredibly contributing to our governance process and just came in and cleaned up all the docs where there are confusions which is great. And Brandon has been with us for a long time and really took leadership in terms of triaging the issues in the repo and has been a security reviewer on each of our initial assessments and is now leading Spiffy Spire. So just really excited to have these tech leads on board. Thank you, TOC. So a quick overview of our projects. We SIG security, so you can go to the product board at any time to see what's on deck. We have SIG security day and progress as well as the first five security assessment. This is not the only thing that SIG is doing but these are the things that we're trying to coordinate mostly across many peoples. So next slide. The security assessment queue, we have Cloud custodian should probably be moved into in progress and it's not there. Self-assessment is almost there. We've actually kicked it off and then Spiffy Spire is almost done. And next up is Falco, Falco is working on wrapping up their assessment. So we've been using this project board to kind of help us remember how we have to nudge things around and that's been kind of helpful. And just to remind everybody, we are collecting all of the little hiccups in the security assessment process and there's been a bunch of questions from the SIG about how did the security assessments and from the projects themselves, how does the security assessments work with, how does that relate to the TOC phases? And we've officially decided not to document that and finalize that until we've done five assessments and we can reliably say how long they're taking and how much effort from the project. And then once we have that settled, our current thinking is that the self-assessment would be required during the sandbox phase, but the review and the finalization of the security assessment wouldn't block any movement. So we want the project itself to be documenting its kind of risk profile, but not keeping it from progressing if it is maturing in other ways of the TOC is has no concerns and we haven't flagged anything that's big. So we're still working on exactly what that is, but that's our current thinking. Yeah, I feel like for sandbox projects, it's a nice thing to be able to start looking at the security posture of a project, but it shouldn't be a requirement. I don't know, maybe you should be looking at making that a requirement for incubation, so that it happens to a project that is in sandbox. Yeah, I think that we don't wanna put a big burden on the project, we just wanna figure out how we can relatively early get the project to kind of commit to its path towards actually having its security concerns met. And maybe we'll talk more about that before coming up with an actual detailed proposal or detailed process. Sounds reasonable, sounds very reasonable. So next slide I think is about cloud native security day. So we have a lot of registrations, hopefully everybody will stay healthy and this will stay on track. We won't have open spaces this time just due to constrained physical space, but we have a bunch of great sessions queued up and then we're also kind of looking at there are some people who from our, from security who can't travel due to restrictions. And so we're looking at maybe having some virtual sessions where people are gathering socially at KubeCon, maybe we can gather socially, virtually, people who can't make it there physically. So we're looking at augmenting KubeCon timing with some virtual something that doesn't get in the way of people who are there but kind of builds community outside of people who can travel to Amsterdam. So that's our update. I don't know if there are any questions or if you just want to keep moving Liz. If anyone has a question, please shout now. Otherwise, let's move on. Thank you very much, Sarah. Who's here for SIGAP delivery? I think I see Brian online, but he is not yet unmuted. I was, but Harry's gonna do it. Yeah. I'm ready to say something. Yes. Do you want to talk about SIGAP delivery? Actually, hi. Harry is here. So I will talk about SIGAP delivery. Great. Cool. Yeah. So in SIGAP delivery recently, we actually have three projects in the under review, which is which are Kudu, Kapton and BuildPax and BuildPax is for incubation. So it will maybe take a longer time than expected. So Kapton is under ongoing review very quickly. And we are discussing that maybe Kapton need another roundup presentation again, because it actually was presented in the SIG very early. And during that time, the process is not quite ready. And so we think that Kapton may need another roundup presentation, unless they think there's nothing changed during such a long time. I don't think that's the case. And for BuildPax, we need to start a job to their review documentation. Regarding to that part, we need to think with the project maintainers to get help from their perspective to start the recommendation documentation from their own template and from our existing template. And for Kudu project, we actually need some station from TOC. We have talked with our CTO contact person, I mean, Michelle and Kiki, and we can actually talk about more details during the TOC discussion. And on the other hand, we also need some, we also request some update, request some update from TOC about the Argo and Operative Framework, which you have already send the recommendations, I think for quite a while, but there's still no update yet. And regarding to the working groups, this is actually one of the most important thing we are recently doing and we actually created two working groups, which all have a lot of feedback. So the first one is ALGAP to working group. We have already put chapter this working group. We had our first meeting and agenda and we are now working on kicking off the charter documentation. And for Operative Working Group, we also put chapter, already put chapter the working group with many interesting parties. And now we have already begun to work to drafting the charter documentation. And we also call for contributors to finish that part of work. Yeah, this is pretty much about the state gap theory update. If you have any questions, please let us know. Great, so for Argo and Operative Framework, I think we're coming to both of those later on. So, yeah, there's a slide that covers both of those. Cudo, I think maybe falls into the same category as Operative Framework right now. So again, I think we'll come back to that. Argo is something I'm reviewing. If I can jump in here, Liz. Sure. So I have reviewed the recommendation and the proposal and I'll put my comments into the poll request. I think my main concern is like Argo is a great project, mature, lots of people are using it. It seems to meet all the criteria. My only hiccup here is, and this is something that was brought up by SIGAP delivery too, is that it's a collection of projects. And generally what we've seen is that the projects that go into the CNCF are, it's like one main project and then maybe there's an ecosystem of projects around it or maybe they have incubating projects to help the community or some notion like that. But Argo is this set of tools that are in a toolbox. So that's what makes it a little bit different and I think we just need to have a conversation around that. Other than that, I don't see any hiccups there. So I'll put that in the poll request and we can continue the conversation there. I've been reading the TOC principles document and reviewing the other projects just to make sure that I haven't missed an example like this one, but I haven't come across anything helpful so far. So just warrants a discussion, that's all. Am I right in thinking that Argo and Cortex are merging or intending to merge? It's a flux there. Flux, sorry. Yeah. Yeah. I knew I'd get the name wrong. Okay. Okay. All right. Hello, sick runtime. Hey, everyone. Yeah, so we have a few updates. We review a few projects. So first we have volcano, which is batch processing in Kubernetes. So we reviewed it and we went through the template and the original template that the six actually put together and we recommended it for sandbox. So right now it's looking for three sponsors. I think the Klaus was the maintainer sent out an email to the TOC mailing list, looking for sponsors. So if you're looking or interested in this project, hopefully you can sponsor. So that's for volcano. Then we had a presentation for Kata at our last meeting. We also reviewed that project and we really like it. It's basically Kubernetes event-driven autoscaling. So if it's well into the serverless ecosystem. So we need two sponsors now. So thank you, Liz, for stepping in. So yeah, this is a very interesting project that I think fits pretty well with the CNCF and how we can enable serverless with Kubernetes. So that's Kata and we also review Harvard for graduation and we also recommended it for graduation. So there was some talk about or some slides about six storage and so they reviewed it and they have some concerns. So I think it's more out to the TOC now to review it and find out if they want to vote for it. So I think Harvard looks pretty solid from the runtime point of view. So that's why we think it, all the comments were addressed on the due diligence document. So that's why we recommended it. And we have a virtual cube led coming up for review. So it's on the schedule in the next meetings. So we haven't had anybody step in and say that they're gonna present. So but we'll still have it in the schedule for discussion in the next meeting. Yeah, and then that's it for the update and any questions? Okay, sounds like that's pretty straightforward. We heard about Harvard before, so yeah, great. SIG Network, who do we have? SIG Network, all right. Hello, Lee. Good morning. All right, well, we have a few projects and actually, let me ask this, is it possible to do a refresh on the slide for those of us who are tardy on some of our notes? If that's too much hassle, no problem. Maybe, all right, let me see what happens when I do this. Let me stop and come on back. There, there's a price to be paid there. You are definitely not the only one here. So let me give it a quick refresh in here and we'll come on back. Give me a second to run back towards your slide directly. Everybody else, here we go. Oh, gosh, you just have plenty more in there. Go ahead. Everyone else can thank me later. Thank you now, it's all good. Very good, so there are three projects or four that are kind of under discussion. There are two that are currently under review. The first project on the list is Contour. Contour is proposed for incubation. As such, we've gone through a presentation in the SIG and the project representatives are preparing for due diligence. And so Michael Michael, who I think might still be on the call is focused on getting Harbor over the line and think it will be coming back to engage in due diligence with Ken Owens and take the project through that. The note there, Contour was proposed right around the time that we were having new board seats shifting around. And so of the two prior sponsors, Joe and Alexis, who are no longer on the TOC, that project is going to solicit new sponsors. And so in many respects, this is a public call for new sponsors for Contour. Yeah, thank you, Leigh, I'm still on the call. Yeah, absolutely. So since we lost two out of three of our sponsors, Matt Klein, being the last one, what we're working on is we'll finish up our due diligence with SIG Network and working with Leigh and Ken and we're also asking if anybody else is willing to sponsor the project. Remind me, this is for Sandbox, is it? It is for Incubation. Oh, it's for Incubation, okay. Yeah, so when we had talked about Sandbox, we had, at the time when that discussion happened, we had the three sponsors who have been accepted into the Sandbox immediately, but we decided to go for Incubation and which is why we started going down the path of the due diligence. All right, so we actually only need one TOC sponsor to, but they need to kind of step up doing that due diligence. That's right. So Sandbox were being a done deal, but we said, let's try for Incubation since we have a significant momentum in the industry. And so now, given the fact that TOC change is rotated, we might need new sponsors. Right. Hey Liz, it's Matt. I would be happy to do that. There you go. Self. Nice. Thank you, Matt. Very good. The other project that's under review right now is Service Mesh Interface or SMI. This project is aimed towards proposed for the Sandbox. And so the SIG network is hopefully, is finishing up review maybe later today or certainly by tomorrow. And it has its three TOC sponsors. And so we expect this might be the first project to kind of come through the SIG, should be great. There's a couple of projects on the backlog. First one up is CNI Genie. So I'm not sure if there's a representative of that project on the call today, but if there is or if you're listening later, please come and present at this Thursday's SIG network meeting. I'd love to go through the project and get familiarized. There are a couple and then another project, Mesh Review is kind of out there on the backlog as well. There are a couple of white paper initiatives, one of which is further along than the next potentially or not potentially, but is, one of them is Cloud Native Networking Principles. And so this is largely stewarded by Watson of the CNF conformance group within the Tug, the telecom users group had worked for what looks like quite some long time documenting, helping telecoms understand CNF and how they're described. And so there's been a proposal that that would be incorporated into SIG network. And so that folks are welcome to weigh in there and review those principles. On a related initiative, there's a patterns and reference architecture, kind of a working group that's been proposed within the CNCF. And this one, the content of it has an immediate focus towards service mesh, but I think it has an inclination for its charter to be brought across, essentially all of Cloud Native. And so there's a discussion that we need to have, we need to invite those constituents to SIG network to reconcile if we can't produce a single paper or set. And that's it. Thank you, Lee. Any questions on SIG network? Okay, so I think got a couple of new SIGs forming, which one's on the personal list? Paris, do you wanna give us a quick update? I'm here, not really a cave, but kind of a cave. I'm playing E.O.R. today. Hi, everyone, all 79 of you, welcome to my cave here that I have no light with. 101 second, let me get to the deck. All right. So really briefly about SIG contributor strategy. We've met a few times now. It's about two to three, including the meeting notes in the deck. I did go ahead and submit the charter, our work in progress charter. Amy kicked us out of that repo, wants us to start a new repo, yay. But I wanted to see- How do you do your own repo? Yay, I know, we're soaked, we're soaked. And wanted to see if the TOC could just vote on that and then we'll move the charter to the next repo. But if there was a couple of minutes, I wanted to just at a high level go through the charter verbally, is that okay? Yes, go ahead. Okay, cool. All right, so 101 second, let me get a link for those that don't have the deck and still wanna follow along. So 101 sec, I'm gonna add that in chat right now. All right, chat has the charter. All right, so again, for those that have not joined a previous TOC meeting, this is a contributor experience like SIG, but this would be high level advisory, focusing on things like community health checks for projects to make sure that they're doing really good things and making sure that they're thinking about certain contributor-related issues early on, so they don't have to get to that later on and retrofit it, something along those lines. So this is a big SIG, we have three stakeholders, CNCF projects and their contributors and maintainers, obviously that's the biggest one. But then next also would be the end users and the broader community event of member communities, our member companies, I'm sorry. And the reason why this is a stakeholder for us is we'd like to educate this population of people on multiple things, how to best contribute to projects that are currently in CNCF, as well as how projects can best get feedback from them and just help that process out a little bit more. The next stakeholder is obviously the TOC being an extension of the TOC and helping them with research as well as keep their own community groups and medic community group issues. Things that I wanted to call out, that would be in scope. Again, things like this idea of a quote, community health check, like what you've just seen with a couple of the other SIGs where they go through projects and give their due diligence and opinions, same thing here, and we would put that, Josh Berkus is on the call right now, Josh would be doing things like open governance checks and stuff along those lines. Things that I wanted to call out is out of scope that I've been calling out this entire time just so that there's no confusion. The day-to-day operations of CNCF SIGs, Kubernetes SIGs, or any community group of CNCF, this is not the place where you would get your day-to-day contributor experience stuff done, like you could not hire a community manager here, for instance, we could help you figure out how to hire a community manager, for instance, but we will not be your community managers. And then I went ahead and did a roadmap as well, just a really brief roadmap in the charter, just so you can see how we would get this bootstrapped. Mainly has to do with, obviously, discovery the formation of some working groups that we've already identified, and then also that start of that checklist and that due diligence for projects. Proposing myself and Josh Bergus as chairs at the TOC so allows us, and that's really it at a high level for the charter. Obviously, there's much more detail inside of the charter. And our first sort of kickoff, if you will, would be a work in progress issue, our first issue in that new repo that I linked inside of the deck. It's called the maintainer circle with the goals of training maintainers, collaboration points on size, large open source issues, camaraderie, bringing people together, listening, et cetera. So on the listening tip, I'll end there. Does anybody have any questions, concerns, comments? I have one question or thought, which is over the last couple of weeks, I think, or while I was on vacation, we had the idea of, well, the realization that maintainers and the TOC basically at the moment have no real kind of particular communication channel. And we talked about perhaps setting up a one-off or an infrequent kind of TOC maintainers call so that we could flush out issues or concerns from the maintainers. And I'm just wondering whether this should be, well, the maintainer circle should be that, or whether that's a separate thing. I think, I don't know, this feels like overlap. Yeah, yeah, no, I was gonna say, it sounds like this could be that for you. I mean, in many, I mean, there's something I folks on this call, I guarantee you, half of us have been to some kind of leadership circle thing before, right? Where we're like, we have all these distributed peers and we all are in our own silos, but we all come together and try to work on like open projects together. I feel like that's what open source is missing from leaders, right? Like we don't ever come together, really. I mean, I do in like at these like other external events like Ozcon and like maintainer Roddy and like open source summit, but it sort of CNCF is concerned. We don't necessarily have that like here, right? Like that community. So I think that like what you're trying to achieve and also I wanted to talk to like the GB reps too, because the GB reps obviously have that door too. So I think we could all get everything we want achieved under this umbrella and have like a really good micro community setup that has really good inputs and outputs of communication. That would be great. And I think it would streamline it if we just have the kind of one maintainer circle. I like that. Great. Any other comments or questions from anyone? Okay, thank you, Paris. And I think we've got Matt for sick observability. Hello, everybody. So I'll be kind of brief, right? And gone here in the chat is a poor quest over the last, or last month we've had three different meetings across community of folks that have come out. And I think we have a consensus on our charter. And so I've put in the actual poor quest as well as sort of a human readable or eyeball friendly link in the chat. Our next steps are to confirm the liaison to the TLC and then have the TLC have a look at our charter, give us feedback and or go to approve it. As I understand the processes, then the TLC selects and or approves chairs and then the TLC and the chairs together choose check tech leads. We have a lot of interest from both vendors, the user community and then the turnout's been very good and positive. And I think the working groups have been productive and we're all very excited to move this forward. So I think that's basically our update. We're in Slack at the CNCF Slack. There's a mailing list and there's a repository link there. So that's where we're at. That's our update. I think the charter is probably a little long to walk through in this call, but. All right, wonderful. So the charter is ready for TLC to review, right? Correct. Great. So TLC folks, please put your comments into that PR and then we can have a vote on it. I would also like to just give a shout out to say thank you to everyone that over the last month has contributed to it. It's a long list, so I won't read all the names here, but they're in the charter. So thanks again and I look forward to what comes next. Great. And I'm gonna just add to that and say thank you to everybody who's been enthusiastically getting involved in these six over the past few months. I feel like this has really expanded the scope of what I'm gonna say the TLC community can do because yeah, you're all taking on some really important work. So thank you very much. All right, is it? Question. Yeah. This observability charter that we want to approve. Is it in the TLC repo or is it in the sake of observability repo? It looks like it's in the sake of observability repo and I just wanna clarify some of the charter. I can take credit for accidentally pushing PR to the wrong place. So the link that I put in the slides as well as the chat is to the SIG observability repo that Amy recently created for us. And that's, I think that we're gonna, we'll shore up the other one, but the current versions in the link. Okay, great. Thank you. And there was a question in chat from Paris. I just was taking myself off mute to say, yes. If the contributor strategy charter is ready for us to review and vote on that, same deal for that one as well. So TLC folks, please put your comments in on that one as well. Amy, can you keep us honest and send us out a link to the charters for both of these to chase us all to review that? Wonderful. Which is good, because now we can move on to projects waiting for TLC input. Hooray. All right. Okay, so we heard about Volcano and Cater being reviewed by SIG Runtime earlier. So I went through the process. I think it feels to me like the first time that we've gone through actually this quite structured process of getting the recommendation. I reviewed the thing from Cater. I watched the presentation to SIG Runtime. I have to say I found it pretty helpful and straightforward the way all the information was collected together there. So felt to me like this process might actually be working. So I'm gonna just call on other TLC folks. If you do have any comments or questions on how that process is working so far any reservations about reviewing those projects for Sandbox? I think that it's unclear whether like two people from the same company can sponsor a project that was initiated in their company, or like I just don't know the rules around sponsoring and if I can sponsor the same project that someone from the same company can sponsor. If we could clarify that and document it, that'd be really helpful. I think there are some patterns we've been following. Like we try to make sure there's not a conflict of interest or anything, but we just really need to document it. So I just have a quick note that I caught on this. The reason we went to three TLC sponsors was the TLC could have two seats of people from a company and they didn't want any company to be able to choose it. So does that mean people from a company can then sponsor a project out of their own company because you still need more sponsors beyond the number of people who can be on the TLC? I think that was part of the discussion before. I don't think that there's an issue with sponsoring something from your company because there's multiple sponsors. I'm just curious about whether two out of the three sponsors can be from the same company. Sarah has very rightly pointed out the establish the conflict of interest guidelines issue that I think already exists. Great, never mind. So we absolutely should. So, yeah, sorry. No, go ahead, Sarah. Issue exists, but the resolution of that issue does not. And so we raised this from sick security and the TLC must have been very busy and didn't respond, which is fine. So we established a conflict of interest guidelines for the security review specifically. And it would be great if somebody on the TLC wanted to, or you wanted to nominate someone to like dig into this and figure this out generally. And so I think this is another example of, you know, like we just more specific details would be great. So maybe Paris could add the specific issue, like this specific issue. And I think that, you know, like there could be a number of different ways that this can be resolved. We can collect all the different minute things or maybe there could be like a general, when there is a decision to be had, let's make sure XYZ people from ABC companies do or don't do things. Awesome, thanks. I am happy to also just help this, assign this issue to myself and help chase this down if that's good for y'all. That sounds great. Do you folks on the call? Sorry, do you folks on the call have an opinion one way or the other? I think we don't want to be doing people a disservice or doing projects a disservice by saying, you know, you now have to get three out of nine sponsors rather than three out of 11. I don't know, there's an easy, yeah. I think it's just important to document it, so it's clear. I think all having it just not be documented that this is our conflict of interest guidelines and this is what we follow is probably more of the issue than what we end up deciding. Given that we don't have 50 people to choose from, I'm not sure that we can say you absolutely can't have two people from the same company. It makes sense to me. Me too. Okay. Yeah, we should close on this soon. Yeah, I think it's probably more important that there's nobody like in the direct line of like leadership of the project itself, right? Like that it's not like, the person isn't somehow like directly really representing the project, right? Like they didn't author it and architect it and write it and it's their baby. I mean, I'm not sure how we articulate that. I get it. So are you volunteering to create those guidelines, Sarah? Do we have someone assigned to that action item? I, so we have linked from that some guidelines to security. So I don't have time this month to draft this. I would be happy to like comment, review, whatever. But like I, I'd want some other input on like what it should be. You can work on that. Saad, if you wanna work on that together, maybe we can knock that out. Yeah, so yeah, you can ping me on Slack. Who's the saying I'd be happy to also? This is Saad. Saad, great. Wonderful. Thank you, Erin. Thank you, Saad. Thank you, Sarah. Great idea. Okay, so that aside, so operator framework. Framework. Yeah. Operator framework. There is some initiatives going on inside that Dan has kind of kicked off around like a kind of discovery mechanism. I think he's very close to actually publishing a document on what he's proposing there, but it has some overlap with operator hub. And he has at this point asked us to sort of hold off making a decision on operator framework until he publishes that. He, I think the whole coronavirus thing has rather taken some of his time. We were expecting that document to be published some time ago. Yeah, but that is the reason for the, something of a pause on operator framework right now. And then I'll go, Michelle, you're driving that, yeah? Yes, I am. Is there something that's requiring them to physically be there? I guess I don't understand the reference to that of why it's on hold. What more you guys need? So we need, so this is something that Dan convened with some folks from Helm. I'm not sure what other interested parties I have seen, but I've forgotten around operator discovery and Helm chart discovery. And because operator hub is part of operator framework, probably makes sense for us to at least have received that document before we make a decision on operator framework. There is a point to which, there is a point at which I feel like we just need to move ahead if we don't get that document, but hopefully it's a matter of days. In the meantime, Cady has volunteered to take up the TOC role of reviewing the due diligence and taking up any other responsibilities to move it forward, so. Wonderful. Progress. Cady, if you have anything to add, I didn't wanna, sorry if I spoke for you. Is Cady on the call? She is, and she's unmuted, and maybe she's having some technical issues. So just in the interest of making sure we have clear communication, the PR has Chris asking for a TOC vote. So if we are requiring this document, could we please add that to the PR so that we're being consistent about what we're asking for and why it's being held off since the PR indicates moving forward with a vote? And that was five days ago. Sure, okay, I'll add a comment about that. Okay, thank you. That's on three out of three, yeah. Yes, here, I can send you the link. I have it. I just know that sometimes not all the projects come to this call if they're not presenting, so I'm not sure they're necessarily getting the information when we talk about it outside of it. It's a very good point, yeah, yeah. All right, so hopefully we can make progress on at least those two sandbox ones in a matter of days rather than weeks and Operator Framework and Argo, Katie and Michelle own those to drive forward by the sounds of it. Yeah. Okay. Great. Do we have, what else do we have? We have four minutes for Michelle to talk a little bit about graduation. Wow, let's do it. Worry, this is going to happen, so go nuts. It's all good. Okay, so the graduation process as it stands in the process document that the community works on and Liz Help Drive and Sarah Help Drive, that document states that basically graduation follows incubation. When Liz and I were reviewing this the other day, we found that, or yesterday, we found that it like maybe could use a little bit more meat and maybe the incubation process is a little bit more hands-on than the graduation process needs to be or the proposal process, excuse me. So we came up with this and it's a proposal, it's in a PR, so we welcome community feedback. Essentially the project that wants to graduate would fill out the graduation proposal template which is exactly what projects have already been doing. Essentially it's a copy paste of the graduation criteria and at the bottom there's a spot to link the previous incubation DD document that the project has already completed and a section which allows the project to address any concerns that were brought up in incubation. So once that proposal gets pull requested into the CNTF TOC repo, that project would get scheduled for a presentation in front of the TOC and the rest of the community. This is just because it feels like everybody should be involved in the graduation process and have one place to talk about a project that is graduating, perhaps there are cross-state concerns that sig-chairs want to bring up here. Essentially it should just be highlighted in front of the entire community. Once the project gets scheduled, there's also time for the relevant SIGs to come up with a recommendation either via mailing list or within the SIG meeting. And that's up to the SIG. The project would present to the TOC. Essentially the project is to address how it's grown in incubation, address any concerns from the incubation DD document or from the SIG and then have case studies if they like and take Q and A from the community. After that, there will be a two-week period of time for a public comment on the TOC mailing list after which that would be turned into a TOC vote. So that's, if you go to the next slide, there is the proposal template that I've outlined here that's in the pull request as well. I think that's all of the main bits. I don't know what happened in chat, but there was like five things that happened in chat. So if somebody has any concerns, let me know. And also this is very, I mean, if we hate this as a community, it's completely okay. I just wanted to get something, get a proposed solution in there since folks are waiting to graduate and kind of go from there. Would love any thoughts? Should we include SIGs in the process somewhere? Yeah, so the SIGs are in the process. Amy, if you wouldn't mind going to the last slide. So once the project submits a PR and subsequently gets scheduled for a presentation, we're asking that SIGs review that project in the mailing list or in their SIG meeting to come up with any comments that they would want to bring up at the presentation. Okay, cool. Thank you. No problem. This is your last slide in here. Yeah, that's all I had. Oh, another slide that you were looking for to be able to review. Big pardon. Thank you. That's all I've got. Open to comments. Oh, we're at past time. Open to comments on the PR. This is important stuff. It is sounding like the March 17th meeting should be a conversation about graduation process as well as an invitation towards projects that think that they are ready to come present for the TOC meeting based on item number three. Liz, is that a fair reading? Yeah, I think that would be good. Yeah, assuming no objections to this process. Yeah, I don't want to throw too much out there because I didn't know if this process would be controversial or if people have issues with it. There are controversies or contentious points. Let's go ahead and raise them. But if there aren't, I'd really love to move this along in the next few days so we can get that graduation, get a presentation meeting up for graduation just because people look to graduate before KubeCon. We talked about this last KubeCon too and then prioritize reviews for graduation within the month before KubeCon. And if there is a way that we could alter the process a little bit so that these projects could kind of come across the line and celebrate at KubeCon, I don't know if that's a valid thing that we want to encourage or not, but I know it happens. So let's discuss it, again, I don't want to throw too much out there at one time. So let's discuss this proposal. And then once we've come to a consensus, let's see if there's a way to fast track or if there is sufficient time to get the projects in before KubeCon. It's happy. With all I've got. Sounds good. All right, we are slightly out of time. So thank you everyone for joining us today and we will talk very soon. Good to see you all. Please put comments in. Thank you. Thanks. Thank you. Thank you.