 All right, Alexis, go for it, it's all you. Thank you very much. So I hope today we could go through the helping projects discussion and talk about, what is it we care about here? What do we feel is generally being done? What's perhaps not being done? And I saw there was a long discussion on email on the public TOC list between many people, some of who may be on the call today, some of whom may not, with suggestions as to what we could do with projects. So why don't we start, Chris, with you just telling everybody a little bit about, what is the short, medium, and long-term picture for helping projects? What have you learned? What can you share? Sure, so we have a resource available for projects to request help via the service desk. So we've had about a hundred or so folks use that since we started that about, it's probably been almost a year since that was formed. We offer a variety of services from tech writing, event management, it's all pretty much spelled out there on the service desk. So I don't know where you want to dive in particular, Alexis here, so this is... Why don't you tell us what you think the main asks coming through the service desk have been almost in play so far? Yeah, I mean, I would say most of the requests probably have to deal with either website, tech docs, logo help, or probably the majority of the requests. Other things that have come up probably second up is help with either sponsoring travel to speak at an event or sponsoring like an outreachy internship or something around that type of line or actually host an event. So whether it's like a prom con or a GRPC conference that we're gonna be hosting next year for the GRPC community. So it generally falls in those kind of three things of, hey, we need help with docs, B, we need funding to send someone to an event or something to that nature of sponsor. And in turn through this program or third, we need help running some type of event or community meeting or gathering generally kind of fall in those three main type of categories. Would you be able to say kind of what is the total expenditure from the CNCF that's gone into these things? Not off hand, it would be hard to, I mean, I could try to formulate the interns of like, there is a handful of staff available for CNCF projects that kind of counts expenditure. Are you asking for expenditures on interns, tech docs? How do you like? Yeah, I mean, just generally out of the total budget in the CNCF, what are the things that we, or would be the kind of rough amount that you think is kind of going towards helping projects at the moment? Yeah, and I would say more generally, you'll be useful to on some regular cadence, get a break, like a quarterly cadence, get a breakdown report of here's how much money we've spent, here's the projects we've spent it on, here are the resources we've spent it on, just to communicate it broadly to the TSE, to the community, because I'm sure there are projects that are unaware or that are projects that are unaware that this really is just available to them. Sure, yeah, I mean, we do survey our projects at least twice a year. So we just start finalizing that exercise now, at least for the second half of this year. So I'm happy to kind of share some of those results for you, but for, you know, most projects are aware of this resources, some are not aware of the service desk, but generally I find that projects that take meetings with the CNCF staff as they are onboarding, onboarded tend to be more aware than those who just kind of want to be left alone through their own devices, if that makes sense, so. Yeah, so let me repeat the request. It would be great to get a quarterly report on the requests that we are dealing with and what we're doing and for whom. That's what I'm asking for, not surveying the projects, but really asking for a regular report to the TOC of a total breakdown, a written report of what Alexis is asking. Sure, I mean, we're happy to dump service desk data for you. So it's all available there. I think it would be very helpful. I mean, you know, it's more, I appreciate that in the surveys, we're seeing that many of the people who respond either responding with three, four or five out of a maximum of five, and they're happily on that many threes. However, you know, that's a slightly different thing from, hey, look, these are the things that we've tried that are successful and people seem to be having progress with. Yeah. You know, make it public and then everybody else who is either in a current project or in potentially a future project looking in can go, ah, okay, they did that for this project. That was a good thing. Why don't we ask for that too? Yeah, I mean, it makes sense. I mean, we'll like for next TSC meeting we'll have kind of the finalized survey results, takeaways and all that stuff kind of in digestible form. But I'm pretty happy with the results this time around because we've actually, it looks like we just about have every project has responded in some form or another. So that's pretty good for us compared to last time. Mm-hmm. So I'm going to just mention though it is a self-selecting group and I've talked to a couple of people who are like, why would I bother to do it? The list is the same as last time. So there's, we have a disconnect between what's happening with the CNCF and the projects because I've had a number of people say that to me. Like, I'll just, okay, fine, I'll go submit the maintainer survey but I'm going to put the same list. Sarah, what do you mean by put the same list in? I'm sorry. The same list of things that they'd like changed or fixed or addressed. Like there's a disconnect in the, we're happy with you and the people who are less happy are not submitting the survey. Yeah, I'm worried about that too. I mean, and also, you know, being a kind of generally glass half empty sort of person, I look at three or four and I think, oh no, why is it not a five? You know, so I do think that, you know, one of the things that we were trying to do is have projects with communities with generally positive, warm, welcoming, friendly, diverse people. And those people may not necessarily be the first to, you know, to feel that it's a good thing to mode, to feel like they're moaning about something. So I think we do need to kind of encourage people to speak up if they want things more than perhaps we are doing. I will speak to me and my team, hassling developers constantly fill up surveys is a pain in the ass. And we've tried, like, we deliberately went out to every project this time to try to get at least 100% feedback from every project and we're on track to do that. So it's hard. And, you know, developers are keeping in shape. I know it's hard. I know it's hard. I know it's hard. I know it's a lot of effort in response to these things. That's why I think that structuring a report about what we're doing for those projects is a way to push that out to them and for them, for folks just to be aware and I think it's gonna be very helpful to get that information out there. Again, what we're spending on and the types of requests that we're dealing with, how we resolve it. Okay. We also had a long thread on the list about some sort of specific suggestions for things that people wanted. I'm just looking at it now, but I believe, Chris, did you take some of the issues and copy paste them into a document? Yeah, there's a doc. Let me go find it. Also, is anyone taking minutes for the in the document? Anyone like to take minutes in the document? I'm happy to take minutes as much as possible, yeah. Yeah, I'll try. I'll try. Thank you. We can both do it. Yeah. One thing I'll try to add to that I just thought about because I had a very frustrating meeting this morning and it worked around metrics for open source projects. I think we should probably come up with a set of metrics for each of the projects. Well, one set of metrics within measure each project against that set of metrics, if that makes any sense. I'll add that to the document later. Cool. And this is outside of what we have via Dev Stats, correct? Correct, correct, yeah. More on like health and growth and maintainability and support and security, all those types of, those might be moved to specific to master cut issues, but some of them might be helpful as well for what we're trying to measure in terms of health. Yeah, I also, I made a similar request a few weeks ago and I forgot to reply to Chris's response. I think that the survey that we do is very useful but it provides a kind of an overall view across all the projects and it doesn't identify the distinctions between perhaps the high scoring ones and the low scoring ones. And it also only really looks at areas where multiple choice questions work. So I think it'd be good to get a per project breakdown to whatever extent that's possible. I don't know if your survey provides that breakdown. Does it kind of break the project? Sorry, I'm sorry. Yeah, we could do per project. Yeah, that's not that problem. It's not the hard to do this time around. But imagining things or was that not in the results that we got last time? I thought that was just average across all the projects. For the first survey, we could deduce it based on emails and affinity and stuff like that. But the second survey, we asked which projects folks are affiliated with so it's easier to get that data. So I'm happy for the next November 6th meeting to do that breakdown for you. Awesome, thanks. So I'm just not saying disappearing in the minutes yet. So we have a few things. One is a link to the document that Chris has just pasted in the chat. The next is Ken's point about health metrics, discussion around that. On the metrics, I think there's a real peril there. I'd want us to be very careful about... The last thing I want us to do is stack rank our projects based on some arbitrary criteria or even worse, perversely incentivize our projects to act not in their best interest, but in the best interest of the metrics because they feel they need to. So before we blindly accept that, because I feel that we should be spending much more time measuring what we are doing for our projects than measuring how our projects are doing, which I think is a much more of a qualitative judgment. I think that's a good point. For me, health metrics would be something like... I mean, I'm sure Ken has a bunch of things that he's just been discussing with his colleagues as you mentioned. But for me, I would like to ask a member of each project, so a question like this, if we did a poll of everybody who's a maintainer in your project, would you expect them to say the project is healthier or unhealthy? Yes, I think that is a good idea. I think metrics that focus on how the maintainers themselves view the project, view the future of the project, that way we're not imposing any metric about commits or stars or forks or anything else that we are allowing the maintainer. We are deferring that to how the maintainers feel about their own project. So there were a couple of points made earlier, which are not in the minutes yet. Brian Tranterill requested a breakdown on a periodic, perhaps quarterly basis of what are the things that have been done for what has been requested, what has been approved and what has been actually executed upon by the service desk mechanism. What is the rough, if any? I don't know whether it's the appropriate question, but is there a budget number we can put on that? Okey-doke, thank you. So if you go back to, if you look in Chris's document, which is linked to in the chat window there, you'll see there is a summary of the thread from the mailing list, including contributions from Jesse, Ben Siegelman, my client at Walo Silver, myself and a few other people, I think. Yes. So one of the things that I've seen come up a lot in discussions is the need for community management. Is this something, Chris, that you've seen coming up through the maintainer service desk request mechanism? What are your thoughts upon it? What do you mean by community management? It's kind of a broad. Well, good question. I mean, remember we had some conversations with a couple of the projects like Committees trying to, you know, how the community functions and whether it's helpful to provide a funded part person who could wrangle some of the community issues. That's what I'm talking about, that kind of thing. Yeah, I mean, that hasn't been formally requested at least, but we do have folks on staff, you know, Luke Perkin, Zach and others that kind of, Ewhor that kind of do this role somewhat already. Like Ewhor does it for Kubernetes quite a bit. But it hasn't been formally requested. Community management is a broad term, right? Like do you mean GitHub rankling? Do you mean taking minutes? Like it's kind of all in one type job. One of the things that we've been trying to do at Weaveworks with open source projects is have one of the community managers spend time encouraging contributions, talking about them on Twitter and other places and generally trying to bring more people into the project. It's quite a, it's a proactive activity. It requires somebody to actually go out and do that. Now, some of these projects, open source projects have very charismatic or energised leads who just do that anyway. A good example would be Open FAS. What about the projects where we think some help could be provided? Yeah, I mean, we have folks on staff that just has to be requested. So we have Luke doing examples for Prometheus, for example, Ewhor goes around, speaks on all sorts of Kubernetes topics. So it hasn't been formally requested, but if a project wants someone to help out, like, I mean, part of what you're saying is also a bit of a, could be considered like a developer marketing function or even marketing function. Right. And it's been a sensitive topic in the past of how much marketing we do for certain projects. So I think it's a line we have to be careful of. I think having a community manager helping ensure that projects are healthy or, you know, spoken to in a way that they understand what service available is a good thing. But I think we have to be wary about marketing, maybe more of our early stage projects inadvertently, which has been- That's true, that's true. I mean, it could be a service for incubated projects and graduated. You know, there's things like maintaining hygiene in the conversation on GitHub. You know, we've had that issue with a few places. I just, you know, because obviously, if that doesn't get done by somebody, you'll have to be done by a volunteer in the project or by Chris, that means you, or by somebody else in the TOC who wants to stick their nose in. And I think neither of those is the right answer. So that was an example of something where I think a proactive suggestion would be helpful. I mean, there were others as well. Would anyone like to speak to any of the issues in this page from contributions from Matt, Eduardo, Jesse, Ben and so on? So Matt raised the point about GitHub experience around DCO, bots, issue management to the CI. He said, I suspect there is easily a full-time tooling job across all of CNCF-CI, and we're going to see what event is for the right amount of staff. Yeah, I was going to make a brief comment, which is that, you know, many of these projects don't actually know what they need and they don't know what they're missing. And I think, again, restating what you've said, Alexis, if we could take the lessons learned from the successful projects, for example, Kubernetes is big and well-established and has, you know, community hangouts and a whole bunch of other things, that smaller projects, and I'm not talking about the Sandbox projects, I'm talking about the incubating and graduated projects would benefit from, we can actually put packages together and sell them or give them to these projects as opposed to put them to ask for something. Yeah, it's like a tiered offering on a SaaS. If you upgrade to the Community Manager Edition, you'll get. No, I think that's a good idea. I mean, again, it goes back to Brian's point about sharing information about what the projects are doing and what we're doing for the projects. So if we could somehow create a table of, I know that Chris has tried some of these things before, create a table of, here are some things that we are seeing the projects do, like this project has a Community Manager, this project doesn't, this project has a full-time dox team, this project doesn't, and then try and focus on what are the gaps that can be filled for all the projects and make them really super successful. Yeah, and I'll just speak up real quick here. We talk about the automation and tooling and when Helm was under Kubernetes, we used a bit of that and now that we're out, instead of continuing to use Kubernetes, we're actually starting to write some of our own. So it's a little different because we're just, there's certain things we wanna do a little differently about it, but it's the same idea. I think there might be a certain amount of tooling and if there was an easy way to share it, and I mean, a simple one that Kubernetes has and we're bringing back over on Helm is doing a quick analysis of PR size and to look as it's small, medium, large, extra large and that kind of thing. So at a glance, we can get that via labels and is that something others would want? I don't know, but it's something, do we know what these kinds of things are across project because if one person does it, it might be nice to share it amongst a bunch of the projects and make it easy to reuse. And is this something the CNCF could host for a bunch of projects to use? Yeah. I mean, if it's something that seems to be applicable to other projects, I see no reason why it couldn't be funded, discussed. I don't know what the right conclusion would be, but we should certainly be considering such things, surely. What about the issue of, are there any projects that feel like they have asked for stuff, Chris, and not got a minute? What is our story on that? Yeah, I mean, I'll have the concrete survey data next time around. So I don't, I haven't dived through each response yet since the survey just closed yesterday. What do you think would be a good way of putting together a plan of action, Chris, on some of the activities which have been minuted, and also responding to specific negative issues coming out of the survey, things that people feel like they didn't get, or they asked for what they didn't get, that we could actually set out as a plan and execute on. Yeah, I know. I mean, for the next TSC meeting, I plan to share all the results, including the takeaways and negatives and so on, and concrete actions from any of the negative responses. Okay. So here's another issue that is in here. That's come up on another part of the mailing list is the topic of mid-sized community-scale camp, as Matt called them, camp-style meetings. What are your feelings on that, Chris? Do you think that's something that we can make systematic? Do you want to do it reactively? What's your feeling? We've already talked to our marketing team to explore the topic for next year. We've already had ideas around doing smaller, more regional events for CNCS next year, and areas that we haven't been to before, like India or South America, or doing a three-city-type tour in Europe. Doing these self-service, word camp-style events for the community is something I'm open to exploring. Our events team is basically looking at this now and seeing if we could do a cloud-native event in a box or CNCS in a box for folks to hit that sweet spot between a small meetup to large KubeCon-style events. We've definitely heard the feedback and we're working on it to come up with a solution for folks. I don't know how many are gonna take us up on it, but we could see if we offer a CNCS event in a box for folks like a word camp-style thing outside of our already plans for regional, smaller regional events next year, kind of one-day regional events. Yeah. Yeah, happy to hear any more feedback on that. So there's many ways to kind of do these things, so. Can we, let's find out the kind of like an ad hoc doc, but we thought about maybe offering up some kind of like a joint TLC slash project day at like one of the events, all the events we have. You mean at like the KubeCon's or the? Yeah, like a KubeCon type of event, like at the major events or having like a basis so that we could sit down with the, you know how the projects kind of rotate through like half hour to kind of just see what we can do to help them and how things are going but to help so we're giving them that kind of a correct perspective slash joint collaboration type of exercises. Yeah, I mean we could either, I mean we've tried the panel route before, but if you kind of want to do, I think what you're proposing is like office hours-esque. Is that kind of what you're saying Ken? Like hey, people could just sign up and chat with a member of the TLC to give feedback. Right. Cool. If you want to do that, I'm happy to enable it for KubeCon Shanghai in Seattle and get the events team to kind of do an office hours depending on your schedule essentially and maybe have folks rotate 30 minute slots or an hour if you think that's best. Totally flexible and how, I know you're super busy at these events too so it's always hard to schedule things. If there's no objection to that, then consider it done for the two upcoming KubeCons. Does that sound okay to other TLC members? I don't want to speak for everyone. Sounds great. Does anyone else want to raise any issues around what's in the document? There's a few other things we haven't talked about in that document like bug bounties and user research is another one. Would anyone like to advocate for either of those two things? I definitely like the bug bounty idea a lot. Yeah, what do you think about that one Chris? That's more of a- Yeah, I mean so- Complex. Yeah, it's a little more complex. So on the Kubernetes front, we're actually working with the Kubernetes community to essentially select a vendor for this. There's some meetings on Fridays. So I think the Kubernetes community is gonna eventually pick a vendor to do this. If that experience goes well, open to kind of offering this as a service for other projects, but you know these bug bounty platforms always have their own pros and cons in terms of false positives and just being a potential drain on maintainers and dealing with issues. So, but yeah, we're exploring it for Kubernetes. I think the Kubernetes community is gonna make a decision fairly soon over the next few weeks on a vendor. You know, just to jump in here, I like this for like released versions in graduated projects or something like that because I know it's costly and you already have to prove yourself. And so not throwing it out there for everyone, but security bug bounties, I think it's a big deal. And quite frankly, I don't think many of the projects and I've worked on Helm and Kubernetes. So I can at least speak to those, spend enough time dealing with security and threat analysis and truly understanding what's going on. So I'm sure many of the members, especially the end users are really concerned with security. And so if there's some way that we can help put carrots out there and help egg this along in the projects, I really like being able to put that out there, especially for graduated projects. You mean just the straight up security bounty? For security bugs, something like that. Yeah, you know, not so much a bug bounty, but a security going after that to try to improve the security of these projects. And I've asked about some things and folks are saying, well, we're moving too fast or we're too busy to do this. And as somebody who's gonna use this stuff, I don't like hearing that. I'd like to kind of put a carrot out there and incentivize security. Yeah, totally with you. I mean, one thing we try to do is have projects go kind of through the CII badging process, which helps you basically at least start with a security disclosure process for your project. And then, but that's just a very kind of, you know, good thing to have in early days. We've done security. We spent quite a bit of money on security audits also, which kind of helped. But the whole bug, like the security bounties, bug bounties, it's a different problem. Yeah, I like ideas on how to improve security for projects. So just keep them coming and we'll see. I really hope with the Kubernetes experience we're able to kind of offer this for other projects. And maybe we just make it for graduated only, given that it is fairly like these vendors aren't cheap, like you said. Well, yeah, I think the question is, how do we foster a culture of security in these projects? You can't inflict security on a project that doesn't have that cultural value. So I think that that's kind of what we wanna figure out how to do and bug bounties can be a useful part of that because I think my experience, the thing that most readily gets that culture is the discovery that your software can actually be exploited in ways that are very creative and things that you do not intend can be done with it. And that can be a big wake up call for a project. So a bug bounty can kind of get them to that point, but I think we need to focus on how to foster that culture of security. What's your thought about doing like the security audits, Brian, because for some projects like core DNS, they found a couple of surprise issues and it basically forced them to make sure their security disclosure process was good. It's probably easier for us to fund a security audits than it is like a third party bug bounty type vendor. But I think if I, and again, I would be in kind of conversation with the project. I think if they've already got a culture of security, a security audit is probably a great thing. It's something that will be welcome. I think if they don't have that as a value, the security audit might be perceived as someone, it's an IRS audit, it might not be very welcome. So I think we would just need to work with the project. And I think that what we wanna see, which I think is very reasonable, is that for graduated projects, security is one of the values of the project. It's more important, it's much more important to me that security is one of the values than it is quote unquote secure because software by its nature is can't be completely secured. So it's much more important that they have that cultural value. And of course, demonstrating that it is difficult and fostering that is difficult and so on. But that's really what the high order is. Okay, cool. It looks like Bob Wise has a question since he's raising his hand and I feel bad for, not saying something, Bob, do you have something to say? You're on mute right now. Yeah, I wanted to make this suggestion that I've run across the situation a couple of times where a company is interested in say better security for Project X because they use Project X or having bug bounties on something they're dependent on. And if there were a mechanism to allow companies who don't wanna set up their own bounties to be able to inject funding that's project specific, I think the CNCF could be a great place for kind of managing that. That was it. Awesome, cool, yep. Suggestion noted. Yeah, I think that's a great idea. One brief comment about security audits. I've put many projects through many security audits and there's a wide range of usefulness of these things ranging from complete irritation, useless security audit, didn't tell us anything and just got in the way to, wow, that's amazing. We didn't know that stuff about our project and we're gonna jump on it and fix it up. And I think it's, again, a service the CNCF can provide is to, what's the right word? Try to run these things and be very sure that the security audit process and team and whatever vendors we select, we can stand behind and say these guys are great and almost everybody who's used them in the CNCF is very happy with the outcome as opposed to the far other extreme which is we impose this useless audit on all projects and they just get irritated. Yeah, definitely. I think most people or most projects that have been through our kind of pilot for the security audit have been fairly happy with the results and it's also had an odd side effect where we've actually had some, let's say end user members reach out and have been thankful for public security audits because let's say they're looking to adopt a piece of software and based on their regulated environment or something, this is a requirement for them to have before they could adopt something. So it's kind of had an odd side effect bonus. Matt, you have a question, sorry. I do, I haven't been through the security audit process and haven't looked at it. How does it compare to something like a threat analysis where you go figure out the different threats and understand them and that kind of thing? It depends kind of on the vendor use and how detailed you want it. We essentially have a two week pen test such threat analysis that is done by a vendor and they go and try to basically poke as much holes, write a report, beta test your security disclosure process and so on to see that it's actually effective because we have CNCF projects as they get the CI best practices badge or requires them to define a disclosure process but many of these projects don't actually, they haven't like tested it to see that it actually works. So it kind of does have its benefit there. So I'm happy to set up a, if you want to talk to a couple of our kind of vendors that we've used, I'm happy to set up a conversation with them if you want more details. And there's, we have a bunch of reports they produced too that I could share also. Okay, I'd be curious to see what they have because I know we'll be doing that in Helm with Helm three at some point and then hopefully not too distant future. Okay, when you're ready, when you're ready, let us know because it's usually a two to three month kind of lead time to schedule. So just keep that in mind and send something to the service desk. Okay. Okay. Hey, listen, I actually have to drop out so I've got to run to a meeting and I'm sorry about that. I would either Ken or Quinton be able to finish the last 20 minutes. Yeah, I'm happy to. Go for it, Ken. All right, thank you. Thanks a lot, Ken. Bye-bye, everybody. And I would really like us to make progress on the GitHub issue, please. I think now that GitHub is getting its approvals from the EU to be part of Microsoft, et cetera. It's a great time to ask Microsoft to make a few changes. Okay, bye-bye. Take care, Alexis. Take care. All right. So I guess I should have asked for like a slap, but we are following the presentation. You sent out that question. Yeah, well, there's a presentation and kind of agenda note. So I mean, there's a big project slash review backlog. I created a project board for us. I don't know if that's an area that to give you. Yeah, let's look at that real quick. Really the major things for you as a TOC to decide is we have a new incubation proposal from the Harbor project that's requesting a vote on that. There's still the security working group proposal. There's an SED and fluency thing in flight. And then there's a huge backlog of projects that either want to present to the TOC or have to be told no, or they have to write a formal proposal. So that's something for you to all kind of decide upon. Yeah, I think we need to make a distinction between the proposed sandbox projects and the proposed incubation projects, because the sense I got, and I'm not sure where we landed on this, is that we do want to hear from incubation projects, but we don't necessarily have the bandwidth to hear from all those sandbox projects, or certainly not in this session, but there would possibly be an optional separate session for those who wanted to find out about sandbox projects. But, you know, those don't get voted on generally, and there's perhaps less interest from the TOC than specifically in those projects. Yeah, well, generally I think more about the, if I kind of read into the emails, right? I think there's really more on the lines of what kind of holding them up and slowing them down to have them come in and present to us, right? When, and the most probably you said there's not a vote, we haven't really said, I mean, look at the bar to get into the sandbox, it's not super high. So, thank you, we're doing more, making them wait to present to us all this time than to just allow them to go into the sandbox and document, you know, have it documented correctly, but also we want to kind of cut back on some of the marketing that was going on by these projects, by being in the sandbox, right? Because it's only not a statement by the CNTF that these projects are, you know, necessarily, you know, the projects that we are backing as a community, but we're not, also not backing them. So it's kind of a, we have to kind of figure out how we want to word that. It's kind of a, an odd way we're looking at the sandbox, just we need to clarify that a little bit better. Ken, I don't know that this is gonna totally satisfy you or the TOC, but I did just want to mention that we updated the way we present the sandbox in our overview deck, and we explicitly do it context. I've just pasted it into a Zoom of the cliche of crossing the chasm. And so on the previous slide, we list our graduated and our incubating projects and we describe those as matching up for suitable for early pragmatists. And we make the argument that Kubernetes crossed the chasm in 2018, and then incubating is suitable for early adopters or visionaries, but we make this idea that sandbox is for innovators or techies. So it's the very small leading edge there. Yeah, post it in Slack too, if you want to see the picture. Yeah, I think it's just, I like the, I like the direction you're going with this, Dan. I think it's something that maybe as a TOC, we can sort of look at this deck and maybe give feedback to you guys on it. In general, I like that. Sure, we happy to hear it on that. I like the direction that was setting. But I did, we did based on the feedback the last couple of weeks, just separate the sandbox onto a different slide at the very least. I thought there was some statements you guys made about sandbox projects too. It's like, what do you guys like the marketing and things like that too? Well, we stopped doing blog posts. Yeah, I mean, we've been taking all the feedback very seriously. Dan, there was actually a press release just this morning, which clearly carried CNCF endorsement of a sandbox project. Is that a, what are we doing to stop that? Chris, can you comment on that one? Yeah, I'd have to go see what the actual, I haven't seen that one yet. So... Was that something that we published? Or is that something that the project? It was something that the project published, but it had a lot of quotes explicitly from Dan and CNCF. Yeah, that could have been a mistake or something, I have to look at it. So I apologize right now. I think that one was, I remember correctly. I remember, if I remember correctly. Yeah, I believe it's just Shig and Falco. In Falco, but I mean, we can, well, I can take the feedback about asking that they not do a press release. It wasn't the fact that they did a press release. It was the fact that the press release was... I think they quoted you. I see your email now, Quinton, sorry. Yeah. With Falco. Okay, no, yeah, this wasn't, I believe I had a journalist asked me a question that I was quoted in. But I'm very happy to refine what we're doing here and just do less of it. I think it would be helpful to kind of look at that and how we, because it's, I know I'm getting, I was asked by one of the projects to talk with a journalist also about, not the project, but just in general. And I can see based on this email, Quinton, that we had to be kind of careful with this because it could definitely lead to the things we're not intending. So I think it's a good feedback, not just for you, Dan, but I think for all of us that should probably think about what we're, who we're talking to and what we're saying to them. Well, and I think the way to resolve this is just to lower the bar in terms of talking about allowing projects into the sandbox with the approval of one or two TLC members. If we do that consistently, that will have the effect that we want because the projects will realize that actually, this is attainable to, this actually doesn't actually mean anything. This is kind of like, I mean, it doesn't mean anything, but it is akin to hosting your project on GitHub. Just because you host your project on GitHub does not mean that Microsoft endorses what you're doing. And that's what we want. I mean, I think we want to provide, yeah, you host your project on GitHub because you have all of these services that are available to you, but it doesn't mean that GitHub is making an endorsement about what you're doing. And I think that's what we want to approach. I see that Bob Wise also has a question, so he's got his hand up. Yeah, I think I was just gonna make sort of a similar point in another way, which is even describing sandbox projects as somehow being like the leading edge or the thought innovators is actually pretty highly endorsive. And if the intention is, and I think I understand that the intention is to provide an area for people to collaborate and experiment, that's different than saying this is the leading edge of open source projects. Yeah, I agree. And I think the way Bob just described it is the way that we want to think about it. It's a place for people to collaborate and experiment and get some of the resources of the CNCF in the most abstract sense. Does that mean we're asking Dan to upgrade his docs on what a sandbox project is to change it? Or downgrade, yes. Or downgrade to essentially change the way we describe sandbox. Sandbox isn't early adopters, that's incubating. The sandbox is for techies, meaning trying out new things. I mean, there's nothing magic about this. I mean, I'm willing to change it, but it's trying to make the point that it's the smallest possible market of folks should be looking at these or using them. It's trying to. This is all for techies. So that's a very peculiar way of describing it. Let's just go with Bob's description, which I think is pretty concise. And unless other members of the TOC object, I think that that captures the spirit of what we're trying to do. It's the sandbox projects create a place for the community to experiment, yes. Cool. I posted what we have on the website and the readme. So I'll send a note to the TOC on it, but if you have updates on language changes, happy to make them done. I think we say what you're trying to say, Brian, in the actual sandbox proposal that we initially did. But please take a look at it. Yeah. We definitely, we should clean. We need to try to clean this up. And I know there's been a lot of good input from Brian and Camille and others on the TOC on this and Quentin. So appreciate your responsiveness, Dan and Chris. Another thing to think about is, I don't know what you want on the agenda for November 6th, so given that that's coming up. So given that we only have about eight minutes left, do you want to discuss that? Yeah, definitely. I think that we're not doing any project proposals. There was one in the slide, that was a mistake, right? Yeah. There may be potential graduation reviews and stuff because there's some projects that I've expressed interest in doing a graduation review. I believe Envoy is interested, so but they haven't finalized it yet. So I could add those as they come up. And also the maintainer survey results and finalized forms of takeaway. I will also add it for the agenda November 6th. And then Patrick just said container D wants to be proposed for graduation November 6th. So I think we're gonna see a few or two handful of requests. Yeah. Yeah. I think that makes sense. Cool. And then maybe we can have a, try to bring the discussion we had earlier to completion. On the agenda as well. The helping projects discussion. And I noticed this thing like key focus that was not meant for today or was that meant for today? No, we don't, so the TOC needs to decide whether you want to invite them to present or just have them formalize the proposal and go on the hunt for TOC sponsors. So if it's the latter, like which I think you're pushing for sandbox protection projects to do, I'm happy to just tell them come back with their project proposal and okay, yeah, we'll also all just do that if no one objects. Just one variant on that. I thought that there was some interest from the community and some members of the TOC in some of the sandbox projects. And so one possibility would be to have a separate completely optional forum where sandbox projects could optionally present and TOC members or the community could optionally attend and handle it that way, rather than just saying there are none or there are some at the TOC meeting. I think the answer is there are no sandbox presentations at the formal TOC meeting. There is a separate scheduled session where those can be presented and you don't have to do one of those presentations to get into the sandbox. I think it's good idea maybe record that presentation as well. It just gives a perfect opportunity to form a narrative about itself. So I think it's a good idea. Yeah. I think one thing we could do Chris is maybe, are there any TOC members that would like to reach out to this or have the Red Hat team here at doing the key project reach out to you and sponsoring this? Yeah, I'll reach out to them and let them know on the proposal front. If there's any TOC sponsors that want to sponsor key cloak, let me know. I'm happy to help them with the proposal. Yeah, I think it'd be good to kind of have, we can maybe use these types of meetings to identify those as well. Okay. So in the future, you can maybe list the projects that are looking to go into this sandbox and please give TOC members a heads up as to what's being requested that way we can then kind of figure out the sponsorship piece. And I love Brian's idea about recording the discussion so that we can have a record of it. And I guess there's only a few minutes left. Are there any topics that the TOC members want to bring up? Okay, cool. I guess I'll give you guys a few minutes back then. And we'll meet again on the 6th of November. All right. So take care all. Cheers all.