 Good morning. How's it going? Hello. Hello. President's Day in the US, that was yesterday, right? Yep. And is that like a national holiday? It is, yeah. Because I know some of those holidays are like kind of some places have it and some places don't. No, this is one of the ones that everybody does. Years ago, when I was a kid, we had Washington's birthday and Lincoln's birthday and they were both in February and then they kind of merged them together into a single President's Day. Okay. Sometimes a federal holiday, not all businesses observe it. Yeah. Most do. I find that most do. Sometimes they choose between March and Luther King Day or President's Day. I can tell you which one I'd pick any day of the week. The former, I think we all should, MLK Day is far less observed than President's Day. I didn't chat Jim saying it's a Tudor snow holiday because of snow caused power outages. Lee had said he can't make it due to power failures. A lot of folks in Austin have no power or intermittent power today and yesterday as well, so we'll see how it goes. Yeah. My son works in Austin. Yeah. Reminds me of KubeCon. My son is a software engineer working out of Denver, but they do remote desktop and for development and all of their servers are in Texas. So no dev yesterday. Well, that's the joy of the public cloud. Except for, I don't think it's very public cloud. I think it's, he works for Raytheon. I think it's very much Raytheon data center. Oh, okay. Yes. If it was public cloud, he probably would have been coding yesterday. We're going to get. So yeah, let's go ahead. Yeah. Should we get started? I think it's a fairly light agenda, right? So welcome everyone. Normal rules apply and you've made it to the meeting already and it's being recorded and Amy will no doubt mark off who is here with us. Now we have our agenda. Yeah. So one thing that we will need to sort out is TSC liaison. So I thought it might be a good idea. We've had a little bit of a chat about that amongst ourselves, which I'm just going to try and bring up. I should have opened the right slack. Some up here. This is what I think we knew. Yes. Does that sound right to everyone? Anyone wants to say no, that's wrong. I think historically, when the rules were drawn up, there needs to be at least one liaison. I think that having two has actually turned out to be quite a good thing for kind of redundancy, high availability, bit of handover between one. You're unlikely to lose both liaisons at once. So I think if we can set up to that seems like a good idea to have two liaisons per SIG. So I guess from the TSC folks who are here, I see one or two. Do we have one or two? It's more than one or two. I see quite a few of you. Do we have any volunteers or people who had already mentioned being a SIG liaison that we should add into this? Yeah. So I had, this is Cornelia, I had mentioned that I would absolutely, of course, be to be this suggested. Also given that there are none down on observability, I would also be willing to do one or the other. I don't think I can do both. But I'd be willing to be SIG observability if that's where the greater need is at the moment. I'll mute myself. That's great. Thank you, Cornelia. I can see a lot of sense in you having a relationship with that delivery background. That does make a lot of sense. The other thing we should bear in mind is that we will be appointing one more person to the TSC. There's the TSC appointed seat when Michelle's seat expires. Amy, do you have to hand when that happens? I'm honestly not going to wake that up until at least the end of the week and this person will be seated before, I believe it's March 29th. So, but you get to the next time. Yeah. So it's next month. So yeah, we don't have to press gang anybody into being a liaison if we win that person joins. I'm wondering, Cornelia, if we could at least temporarily have you take on observability as well, just as a sort of so that if there was some urgent need, or if anybody else wanted to take that on as well from the TSC folks. Yeah. I mean, I'd love to have somebody who does their day in, day out on observability if they want to be the main one and then I can do app delivery. But observability, you know, there's definitely connection and an interest from my side, even to my day job. So I'm more than happy to do SIG observability until somebody better qualified comes along. That sounds pretty cool. Isn't Saad also on storage? Or have I imagined that? Because he used to be a storage co-chair, didn't he? I think he's still technically the co-chair and not the liaison, which seems a little weird. And I'm sure we could move him from one to the other. I think that's a really great point. We should, I don't know if we have a definition of what happens when a co-chair becomes a TOC member. Kind of makes sense to me that, well, that might mean there would be a good signal liaison, but I think it probably means that the SIG should appoint a new chair in that case. Yeah, I think that's going to be the case with Li Zhang as well, because he's one of the co-chairs, Ian Alois. Yeah. Yeah. And Erin is also on storage, if I remember rightly. Yeah. Erin is co-chair of storage and Saad used to be a tech lead, so they would be either Saad or Erin or both could be great liaisons because they already know the landscape pretty well. I think that makes an awful lot of sense. Yeah. Does anybody think it would be a bad idea to say that TAC members should really kind of concentrate on being on the TSE and the SIGs should really try to fill that space and appoint new co-chairs? Yeah, I think that makes a lot of sense because it gives new people an opportunity to do things on the SIG. And I think having a pipeline of people who have been through those roles is really helpful. I mean, as we found with SIG security, finding new people takes a bit of time. It's good to have that process happen more often. And it's really great that people move from SIGs to TSE, so you should encourage that and encourage the fresh people to move up. Yeah. I think that makes a lot of sense in terms of developing people's roles and the backfilling, encouraging new people to get involved in SIG roles is, yeah, makes total sense. All right. So in that case, if you are a SIG chair who's here and you know that one of your co-chairs has moved up to becoming a TSE member, now would be a good time to start thinking about candidates for being co-chairs on your SIGs. All right. So probably it makes sense for Saad and or Erin to be the liaison for storage. I guess that leaves network lives. Yeah. I don't really want to be networked by myself, but I could potentially be a, you know, take on. I can share it with you. I mean, like I said in our earlier conversation, I'm not necessarily working in network a lot, but I'm happy to share that with someone and I'll have trouble making all the meetings. So I definitely would need to share it with someone, but maybe between the two of us, we can make it work. I think that, should we pencil that in? And these things, you know, don't have to be set in stone. We can rework them when we have, you know, our full complement of TSE members. And I'm happy to do the storage liaison, Liz. Great. Thank you. I wasn't sure you were here, Erin. So that's good. Sorry. I don't know why I didn't have it on my calendar. Apologies. It's fine. You're here. It's great. Wonderful. So I've written some notes here that says, Erin's storage, possibly also Saad. Saad here. Guess not. Cornelia on app delivery, hopefully a second on observability. Dave and myself doing network. And then I think that means at least everything is sort of at least partially covered temporarily. Yeah. Okay. I think that's probably everything we need to that. So we have kind of open floor time for anyone to raise anything they would like to raise. I have something. So I think maybe before I joined, Liz, you said you thought maybe the TOC members shouldn't be co-chairs of SIGs anymore. Is there, can we discuss why that is? Sure. Yeah. Sorry. Maybe you missed that bit. Yes. So Justin, do you want to say what you said? Repeat what you said. I think you phrased it very well. Basically say that it gives people an opportunity to step up and work in the SIG and the, I mean, we have the liaison role. And I think it's a really good path for people to, I mean, it's really nice to see so many people moving from working on SIG to being on TOC, but like giving more people opportunities to rotate. I think one of the things we found on security was that succession, we hadn't really thought about succession and new members much. And it was really, we had some people, I think the first SIG type people stepped down the end of their terms, because we were one of the earliest SIGs. But I think having some of those people coming up earlier, so there's a bigger pool of people who've done those roles is really, really good. Normally, yeah, I would agree. I think we're also one of the first SIGs and Alex and Quentin and I have always been co-chairs. But we have really had a hard time finding people to even be tech leads within the SIG. So I guess, is that a suggestion or a mandate? Is that something that we should go back is the storage SIG co-chairs and figure out how we want to proceed or are we going to make that part of kind of the TOC responsibilities to give up that role? I think it's desirable. I think like a lot of things in CNCF, we should have a little bit of judgment and flex. We don't have to be rigid for just rigidity's sake. But I think it's desirable. I guess I'm wondering whether if we have a SIG that is struggling to kind of staff its roles, its chair positions and its tech lead positions. What can we do to sort of help backfill it? I'm not sure that the solution is to not kind of promote people on. I feel like the solution is to try and figure out how we can expand that pool of people. I appreciate is a difficult problem, but I feel like that would be a better to try and make sure we're sort of pulling people in from the from the grassroots. Yeah. Okay. Yeah, I get both sides of it. We'll see what we can do. Great. Anybody else want to throw in any thoughts on that? Just a short sort of echo of what Erin just mentioned. It would be good if we had a little bit of flexibility, even if it was for a temporary basis, not to kind of lose Erin as a co-chair just now, until we managed to find some other people, if that's where we're going. But it would be a big loss for us. I definitely think that TSE members can and should be as involved as they want as members of SIGS, if they have the time and capacity to do that. Definitely not. I don't think anybody's saying they shouldn't be involved in SIGS. I think it's more just trying to spread out the responsibilities and give the opportunities for roles to more people if we can. Yeah. That makes sense. Great. I also see in chat, Elena volunteering to be the second liaison for Contributor Strategy. Lovely. Okay. So yes, open floor. Anyone got any topics they would like to bring up? So I got one topic. So on the fact that maybe some SIGS are having a hard time trying to find more contributors or more people to become SIG chairs, I don't know if it might be a good idea for the SIG Contributor Strategy SIG to help out and maybe reach out to more places. So we get more people involved and people more trying to get into those roles of SIG chair and tech leads. So we'll be great to hear any thoughts from the SIG Contributor Strategy if they have any. Hey. Oh, wow. I realized how my webcam was all the way. I was like, hey. Hey, everyone. I think a good first step would just be outreach. I don't think the community at large knows a lot of work that is done within the SIGS unless they've produced white papers or something. And to be very explicit with your needs, I've found in open source that when we say, hey, we're looking for contributors, it's ambiguous and no one has the time for that. So I think if we can do some outreach and even blog posts featuring you all and interviews and talking about your roadmaps and stuff like that, I think that would get people excited to hear about what you want to see as far as the future of your groups. I think that could be a good first step. Great. Yeah. That sounds good to me. Yeah. I'm also curious whether this is Sarah Allen from SIG Security, whether the SIGS that are having trouble finding people to step up into leadership roles, is it that people like are your meetings? Do you have very few people at all involved in the community in the SIG or is it that there's a lot of people who will show up at a meeting or participate in some way but don't want to take on a leadership role? Because those are very different problems to solve. Well, for storage in particular, plenty of people participate, but they don't have time to put in the work to do the tech lead roles or to lead meetings. It's just a time thing. They don't want to step up into that role necessarily. It's still a healthy SIG. I would say we're not floundering by any stretch. I want to clarify that. It's absolutely lots of people, good attendance, but it's just, it's not for everyone, right? Everyone doesn't have the time they can volunteer off their schedule to be able to be in that position. Yeah, and we might take this offline, but I mean, we talked a while back about like some sort of very detailed things that we do that have helped people take on leadership roles before tech lead, right? So having lots of little things to do. I don't know, maybe you're already doing some of these things, but it might be worth talking again about that stuff. Because I think that hearing that about SIG security strikes me that it's not an outreach thing so much as a fostering the group perhaps. And you might also consider bringing people from the outside. That's how we all got here, right? I suppose another question would be if the roles as defined turn out to be too onerous for people to take them on, maybe thinking about how they could be split into pieces if that's possible. I mean, there's nothing, we've defined the SIG chair roles and the tech lead roles, but they're fairly loose definitions, right? And I think it would be totally reasonable to say, actually, you know, these roles could be job shared or something. Now, there's another thought that I keep having, which is that I think that maybe for some individuals, they feel like the work that they would put into the SIG would be, you know, personal time work. And I wonder if there's anything that we can do to help individuals who are interested sell their employers on the value to their employer of them participating more significantly. So some type of a blog post or something that says, you know, here's how to talk to your manager about getting more involved in the CNCF or taking on a leadership role, participating more fully in SIGs. That feels like something that could be helpful as well. Yeah, I think that would be really helpful. But I think it would also be helpful to tie some of these things to the business of the different companies or see how that's valuable to the bottom line of whatever company the individuals are working in. So I mean, it's kind of difficult because every business is different, right? But if you can find some common ground that says, well, if people contribute more to open source and they take on these leadership roles, they can make these projects more successful. And then the company can use these as end users, for example, I'm talking about end users. And then, you know, the projects will be more sustainable, you know, and then over the long run, we, you know, the whatever the business will be more successful because maybe all the systems are running on top of these open source projects, right? And then if they go down or if they fail, then the business fails. Yeah, it feels a little bit like, you know, making the argument for open source. But maybe we can, you know, tailor it a little bit more specifically to, okay, you know, even if you, as a company, understand the overall value of open source, here's what's in it for you if you have individuals that are more, you know, actively engaged rather than just, yeah, we'll continue to just ride on the coattails of this open source movement. Yeah, it's another sort of way of looking at the contributions don't have to just be about code, right? They can be about fields that you're bringing to the community. This does seem like a really good topic for a blog post, I think. Yeah, I thought I forgot, I've forgotten the name I'm looking. Individual who made the really great point about contributor. When you were speaking initially, my initial thought was that a lot of people when they hear contributor think code. And they think, Oh, well, I don't have the cycles to, you know, be issuing PRs against this. But even just helping them recognize that contribution doesn't just mean code, as you just said, Liz, I think is really key. Yeah, I think you were referring to me to Ricardo. No, it was somebody else. It was a woman and I'm scrolling through my page. She's either dropped, Sarah, contributor. Yeah. Yeah. Sorry, I didn't catch you. No, I think it was Paris. It was Paris. It was Paris. Yep. Does anybody want to volunteer to write this blog post because I think it is a great, great bit of information that we could try and share or even co-author it. I will help write it if somebody else will co-author it. Oh, Richie H. Paris. Fantastic. Thank you, Paris. Thank you, Richie. Brilliant. We can take that offline. Right. And before I throw in ideas, does anyone else have anything that they wanted to bring to the open floor? I have one more thing. So I think there was an issue open on renaming the six. Has there been any traction on that? So I think the initial thought was not to make him not to be confused with Kubernetes six. So then it generates confusion maybe in some communities. What is this? I think I've gotten some of that in the past for sick runtime, people asking, what does sick runtime do and how is that different from Kubernetes or the six in Kubernetes? So yeah. Any thoughts on that? Thank you for reminding us of that. Yeah. I think we could be called almost anything just to avoid the confusion with Kubernetes six. I massively plus one. Anyone got any ideas for what we should call six? So it's about renaming the sick itself, right? Not the what comes after sick, like runtime or storage. Yeah, sort of runtime. I don't know if it's going to help thinking of the ways to advertise sakes and various not working group either something. Yeah, it's not a working group. It's not a tank technical advisory groups. I like that. I like amazing unicorns as well, Paris. So I feel like we just like six just got created. And when they were created, they were like the likeness to Kubernetes six was strongly advocated for. And it could be that after, you know, it settled in then, you know, that's that changes people's perspective on it. But I feel like people are just starting to hear about sick security even within the CNCF. And, you know, unless like, I don't know, to me, it doesn't I didn't love the title to begin with. I really thought working group was fine. So I'd just be a proponent of like, let's not rename things. But that's just me. That's just one opinion. 100% know that it is causing confusion constantly. Josh is just said before, was it Josh? Yeah, saying CNCF, SIG network, not Kubernetes SIG network. I have the same thing with SIG security. Yeah, we have two SIG security. Yeah, it is definitely. Do we have any like domain names or anything that associate with SIG names that we would need to worry about? It's all good hub. Yeah, it's just repose. Repose, maybe some branding on the CNCF website, I guess. Probably some logos. So it's not absolutely trivial, but it's hard. It's not hard, right? Yeah, nothing we can't take care of. All right. Do we have a broad consensus for tag? That seemed to be going quite... Oh, that's a good point. Paris saying doing a rename blog with a contributor definition would be cool. That's actually nice. Yeah. I just, I don't think tag says the same thing at all. It seems to redefine what the SIG is. Like, who are we advising? I'm just, I don't, it didn't resonate with me. And maybe somebody can speak more about why that's a great name. I think, I mean, we're advising the TOC, the projects, the contributors, and the community at large through white papers and guidance, guidelines, and advice. It's the first line of the charter in all the SIGs. We advise the TOC. I think it's a really appropriate name. And special interest is quite broad. Technical advisory group does sound quite well defined around what the SIGs are actually doing today. Any other ideas that people want to throw out there, alternative to tag? All right. I wonder if we've got enough people to vote on this, Amy? I think so. And I really, really, really want to be able to do this in the issue instead, as I come back on there. So I will put the issue over into the chat, as well as being able to put it on the public meeting notes. Okay. So do you want us to plus one the issue? Please. Okay. So much easier. Then I've got a record that's much more straightforward. That seems very cool to me. Yeah. That's actually an interesting point. Should we do more votes as GitHub rather than mailing list discussions? And there's probably all sorts of cultural changes if we were to change voting to be, you know, people would have to realize that things are happening on GitHub. We need to make sure that the issues are shared on the mailing list and what have you, but does seem pretty good from a tracking and maintaining history point of view. Yes. I believe everyone is probably in violent agreement about, yes, we should move to GitHub. I think the logistics are how? The one thing would be to announce those votes maybe on the TOC mailing list, but else I can see it being much easier to track if they're on GitHub and for people to see the status of them. You know, I think from a logistics perspective and tracking, I totally buy that it would be easier. I think that there's an awful lot of people who aren't going to go into the issue, but we'll just get the email and can get a sense of what's going on with the vote and see the discussion. And so I do feel like there's a little something lost if we go over to the issues because there are people who like I said, they aren't going to go into GitHub all the time and look at, oh, we're voting on something. Let me see what people are voting on. So I kind of, you know, I'm one of those where I sometimes like to just see, oh, look at look at all the enthusiasm or look, it's kind of quiet over here or something like that. So I don't wouldn't strenuously object, but Dimms has put in the chat about people can subscribe to GitHub notifications. I think actually that's a really interesting point that you probably don't want to subscribe to all the GitHub notifications in TOC because it covers gazillion repos. And as we've seen from that TOC Slack channel, like any actual discussion gets lost in the noise. We don't have too many issues on GitHub for the ones we have to. But I think the real key thing here is making sure that people know the issue is there so they can see it and they can comment on it and create a label for it. Okay. I feel like this is sufficiently, you know, there might be some details here that maybe we should write it up into a proposal before we actually just say, yeah, let's move everything to GitHub. So would anybody like to volunteer to write a proposal for that? It's less appealing now there's some work involved. Amy, is it something that you could potentially write up? Paris is actually saying she wants to write this one too. Oh, she is. Yeah. But I don't have the hours. I can work with them, Paris, on this one. That's fine. It should be pretty straightforward when we actually put it down into paper. Paris and Erin, cool. I have also put a note onto the TOC issue for rename, noting that Alex has proposed renaming for technical advisory group and then people can come in and vote in there. I'm sorry, Amy, can you say it again? I missed that. I wanted to be able to make sure that we were documenting like here's who actually proposed the rename and the issue was updated. That was all. Make sense? Yep. All right. Moving on. All right. Any other administrative naming things we should cover while we're thinking about things like that? All right. One of the things that has come up actually kind of came up today was security. I think this is not something we're going to want to close today, but supply chain security being a huge concern and we want to make sure that the CNCF projects are as secure as they can be and don't contain vulnerabilities. There's work going on within the Linux Foundation to kind of enable some vulnerability scanning and so on for the projects which I think SIG Security have been looking at and I think it's not a completed, it's a work in progress. But I think the more important question is right now the graduation criteria for projects kind of punts the question of security processes into that CII best practices badge and it was suggested to me today and I think I agree with this that perhaps it's sufficiently important that we should be explicitly saying, we shouldn't be saying what people's security processes should be, but we should be explicitly saying a graduation. We expect a project to have some stated policy on how they handle security security and their security issues. This might be related to, I mean we do that through the security assessments and like one of the things we audit, we look at is do they actually have a security team, do they have somebody, do they have a process for and what we'll typically do is we'll write up issues if they don't have it and we'll coach people who have less big teams, who have experience with security or help spread the word if they need more participants and the group itself is good at people are like, oh I could help with that. So it's not like we have everybody willing to raise their hand but it's a good exchange of information. So we're sort of jumping the gun here but we're working through a retrospective on the process and then what comes next is alignment with the stages of the project. So that may help answer this question but I think certainly graduated projects should have a process for handling security issues. So the assessment work that the security are doing to help a project, I guess maybe we need a more, I think I would like to see something in the graduation criteria that kind of just spells that out a little bit more clearly as a requirement, which he's saying seeming to remember that having a process was required. So I think it is inside that CII badge requirement but I'm not sure, it just feels to, it's sort of hidden there and I want to make it something that people know we want to pay attention to. So this might have changed but at least back then we had to have a, like there was an explicit thing around having a process about having an email address where people can send stuff to and I think the first review which CNCF sponsored happened before graduation to basically avoid having a major thing pop up right after graduation. So I think that was even part of the graduation project process back then but that might have changed. The security audit is part of it but I think this is something broader than, because the audit is a sort of snapshot point in time of like did we find any? All the processes we put in place, I know of course I rewrote them back then we had to do for graduation. So maybe it just was dropped or something but it used to be in there at least but we were like the second project so it's been years. It also could have been that the whoever was doing the due diligence asked about it rather than it being the criteria right because a lot of things are at a little ad hoc especially for the first few projects. Very true. All right so it doesn't sound like anybody thinks it would be a bad idea if and I don't mind taking this action to just propose some wording for adding an explicit requirement for a process not any specific process into the graduation criteria. Okay cool. All right I have a question about that so that would mean more like a process like an automated process for security checks on a non-goin basis. Something that would raise the awareness of the security in the project and you know once it's graduated then other people know that okay this is secure and would also having like some sort of batch help to like a security batch and a yearly security batch help. I think you are raising this because of some of the stuff that has happened like with the SolarWinds hack and then yeah so people want to have when they're using an open source project they want to make sure that yeah it doesn't have any security holds. Yes I think as Josh says that there is already the CII batch and the CII batch is supposed to cover this. I just feel like so a lot of the CII stuff is projects self-declaring that they do a thing and I think we should be a little bit more explicit as part of the assessment just saying okay you know have you got a clear security process and I don't think it has to be automated. I think it's more about saying if this project has CVEs how do we deal with it? How do we know like if somebody reports a security issue how do we know it's going to get fixed? Yeah so I interpret it when people even report it. Yeah I was I thought you were discussing the reporting and handling of issues brought from the outside which is you know there may be a automated documentation thing once it's been reported but there's a human thing which is the evaluation of it like that some human who's knowledgeable says I am going to look at these issues and there's a way to get to that human and then a way to subscribe to the outputs. I think yes is that clearly what you were talking about? Yes that's more what I was talking about that the people can report security issues and that there should be some process for handling those and I I would say that should be at incubation not graduation not necessarily that it would be mature but like and a way like if there's a security flaw what do you do from the outside for a project like this isn't people are using it right at incubation. Yeah yeah it's true. Does anyone think that adding it at an incubation level would be a bad idea? I think we need to revisit all of those criteria before we make a decision on it. Maybe this is good motivation to do that but it would then see what it's going to change for the you know all the projects that are in flight right now. I don't think it's a bad idea but. Josh is asking CII incubation no I think just specifically this security process part is what I'm picturing it's quite you know it is quite a big ask for projects really to say you know you have to have somebody who's going to handle these security requests but I think it's important. I would say most projects already have it it's maybe not surfaced or documented sometimes it's like it's different for projects you know like a lot of times you've been like well maybe you should put that in the read me but like they're like oh yeah we have a process so you know like I would advocate for Liz if you're up for writing it up and then you know like maybe there aren't that many incubation projects maybe we could get a volunteer to do from sick security to do like a sweep and be like let's look at them and see do you know are there are there any that don't have it right like it can always be improved but just nearly a way to report security issues and a way to track them. The only thing which in my experience can be an undue burden is if you put timing constraints on things so you say you have to reply in X amount of time or me even have a qualified reply in X amount of time that's something which I don't think should be put on incubated projects but beyond that just having a process defined and and easy to find is absolutely par for the course. And to be clear I don't think we should be telling projects what the process should be like if they want to put in like some kind of timeframes or whatever great that's up to them if they want to say you have to report it by I don't know semaphore that's kind of you know but by calling Aaron's phone number it's a security process. Exactly that's not the process we want to follow that's the apple security hotline right um yeah so but more just saying that I have to have some documented process we're not necessarily going to make a judgment on what the process is just that it should be there then then why go through it I guess I mean I guess graduation should be like you have everything perfectly aligned and it has our stamp of approval there's still a possibility though hopefully slim that a project doesn't go from incubation incubation to graduation so are we saying what would this provide to people that we don't have today I guess is what I'm asking if we moved it to incubation more confidence in the project more confidence in the security does it really change anything the one important property of this is that there is a defined non-public way of having direct contact to the developers that is the one thing which is actually different if you have a process because if you just have issues mailing lists blah blah blah you need to reach out you need to say hey I want to talk about this where can I reach you privately that might add delay blah blah blah blah and by having an email address or web form or whatever already set up at least that step is taken away and that should potentially be a hard requirement that it actually reaches the relevant developers in a private manner and that should probably be the only requirement on this process at incubation stage I think that makes sense this would not prevent projects from reaching incubating just you want to expand on that a bit I'm saying it wouldn't be a blocker what because it's reasonable for them to be because yeah because reasonable for them and the ones who haven't set it up is honestly just because nobody asked them to yeah and I think that's the wind from it is that you know not every project necessarily thought about it it's you know okay Tim's is saying there's a process at the foundation level so is this that you can report a security issue through a central ASF point that feels quite onerous on feels like a level of indirection between the reporter and the relevant project well I mean I think it would be a kindness to the people outside like if we have this at the incubation level and we made sure that you know we swept through and made sure all the projects were compliant but we're not saying how to do it then every project is going to be a little different and if you're using multiple cncf projects where you know like I we actually had somebody from the government be like can't we just tell cncf that there's a security issue with one of their projects right we didn't pick it up at that time because we were like not the highest priority but but I think that's one of the it would it's how much are we serving our own community versus how much are we like from a security perspective you don't use exclusively cncf projects in the wild right and so it's just would be a facility like I think it's a minor detail that would come after we did this provided that it goes through that makes sense Josh just suggesting that having a backstop security address at cncf level would help projects I feel like yeah that might maybe that's a next level thing we can talk about and maybe think about whether that could be staffed by you know somebody at the cncf even if what they're doing is turning that message you know redirecting that message to the appropriate maintainers but yeah that feels like a level more than I was necessarily thinking of for this stage baby steps yeah indeed all right we have about five more minutes left anybody else got anything they would like to raise say and Paris you're raising your hand I saved it for last because it's about a party called maintainer circle I'm just kidding it's not necessarily a party but anyway we had our third maintainer circle recently Jerome came on and talked and gave a little accidental evangelist talk and we did breakouts and I just wanted to let everybody know to get the word out to the projects we still have people coming in that are like I didn't know this was a thing but anyway so yeah please get the word out the next maintainer circle will be I think in three weeks three to four weeks but we always post in the maintainer circle channel on slack and of course Amy will get the no doubt to the maintainers list as well but the next session will be with Sarah Novotny and she will talk about values and principles and why it's good for you and your project and how to change those and it'll be really cool um and also we are up for other suggestions so if maintainers want to learn something or talk about something amongst their peers uh that don't necessarily that doesn't necessarily get covered uh either in textbooks or kubecon talks come talk to us and we can figure it out so that's really just sort of an announcement uh and see if anybody had any feedback about maintainers circle or questions or anything like that I definitely want to catch up on the video of that talk it sounded really interesting I could make the time but it sounded really good hey I think that's a wrap then thank you very much everyone enjoy the rest of your day or evening thank you bye y'all