 So, welcome to CNCF Consig Contributor Strategy Meeting. As usual, we are under the CNCF Code of Conduct, so be excellent to each other. This one is getting organized a little last minute, so if anybody has additional items for discussion, please add them to the agenda there. Let me paste it into the chat again. And with that, let's get started with discussion. We do not have any new people here, so it seems like we can skip the round of introductions since we all see each other fairly frequently. Oh, hey, Karen. Hello. Hello. Sorry. I do have a voice. Thanks for... Yep. So, okay, we're just getting started. If you have anything additional for the agenda, please add it. And so, introductions being skipped, let's move on. So one of the things that's come up in... We had this discussion... Started this discussion on contributor growth working group, but it really needs to be in the main meeting here, which is... We're busy generating a lot of content via contributor strategy. And one of the questions is, what is our publication path for the various kinds of content? I mean, for the templates, it's obvious, right? We just update the main branch of the template's repository and anything that's in the main branch is basically done. Am I correct with that, Carolyn? Yeah. Well, I mean, we haven't published anything yet. Okay. So, Wednesday, we have a process out there. But for other stuff like feedback and additional material and requirements, the various advisory documents, in terms of, hey, here's how to select project. Here's ways to select project leadership, et cetera, that we've been busy writing. You know, what's the path to go from work draft slash work in progress to... This is a official resource for the CNCF, and none of that has been defined. Josh, you just made me realize that project template repo was made before master main switch. So, this afternoon, I'll fix that. Okay. So, just a note for project, for the repo switches in general, I think GitHub is going to officially switch that stuff over, starting on October 1st. We were actually talking about this in the GitHub management meeting in Kubernetes earlier today. And, yes, you should switch the template. Yeah. Yeah. I just don't have anything in it. I think we just made... I mean, it has, like, what do we mean stuff? I think it's just we made the repo before... You saying I'm going to switch to default? Is that what it is on October 1st? No, it'll be switched. The default will become main, as of October 1st. Yeah. But that's only for net new repositories, not existing ones. So, we want to make sure that that's changed for the template. Perfect. All right. So, we're going to switch this up again before we start making PRs. So, do we want to actually talk about how we transition documentation? Yeah. So, we had also mentioned this little discussion from working group naming in Kubernetes. Our general idea was, at least for our documentation specifically, was providing a set of recommendations and a very controlled space. So, whether it be a repo, subdirectory, somewhere that will eventually be proposed to some body in the CNCF, maybe that, maybe we call that the TOC, and then at the point at which that higher body approves the documentation for use across the project or foundation, we'd move it into somewhere more official. So, maybe that is contribute. Maybe that is the CNCF foundation repo, I think the foundation's name of it. So, there are a few options, but we do want to make sure that the documentation that we say is under review, do we want to have a separate under review section that eventually gets graduated or a set of decisions to potentially make, like these are in review, these are newly proposed, these are graduated decisions, and now live in some canonical place. Yeah. And that's something, particularly for requirements material, that very definitely needs to have an official approval chain, I mean, advice is advice, and it's really, it's more important for it just to be noted which items are finished rather than which items are approved if you follow me, because it's not like, you know, it's not like we're going to cause major political problems with general advice, but knowing the TOC, I will say we will get a lot further if we come to them and we suggest a specific path than say, where do you want us to put this? Yeah, for sure. So, and I'm not sure what makes sense because I feel like we don't, like, we don't already have a place within the CNCF where this sort of content would live that I know of. Well, I mean, you could always put it in like the TOC repo under the SIGs. I could probably go under process, but use more words about what kind of content we are thinking about. So things like, you know, things like, you know, we've got within governance, we've documents on ways to select project leadership, you know, and another one on, you know, on basic forms of governance. And within contributor growth, we have one on how to build a contributor ladder. The, so, you know, those are the advisory documents, you know, so the, I think the requirements, the requirements would require a small structural change. The requirements would at least right now go under the TOC directory because that's where the sort of general requirements documents are. The concern about that would be that those would need to turn into directories instead of single documents because right now they're single documents. Right now there's this Omnibus document that is project maturity. I forget exactly what the file name is. Within CNCF that covers the whole maturity cycle. Yeah, and it doesn't make sense to make that single document 150 pages long in order to include all the backing material that we will eventually generate. So, you know, so we'll need to approach the TOC with the idea that hey, this should actually be directory with multiple different documents. In the meantime, couldn't just go in like your own repo? Don't you have a repo? Yes, we do. Yeah, then like work in there and then have the proposal process kind of move out to the TOC when you're ready. It's already in our own repo. Okay. My, this whole discussion is what happens next. Ah, so when, when, when you are ready to be able to publish things. Um, if you want, well, okay, I'll let discussion continue because I have like a possible place to be able to surface this for. So, I guess for the, so because it's in the repo, it's technically published already. What we want is the once it has been approved or ratified or, you know, becomes law, where should it live? Right. Maybe that's TOC. Do we feel that the TOC repo is the most representative of where we want this information to be? Yeah, I don't know. I mean, I feel like, didn't know, wasn't there some discussion of a contribute repo? Does that actually exist? Yeah. So there's a contribute repo. There's a foundation repo. I feel like some of the things that we're proposing are not, are maybe not either of those. Maybe this is a new repo. Put our stuff in the contribute repo. I already approached people about this. Yeah. I'll also say this, that it's kind of. It's kind of awkward and undiscoverable to have just a bunch of random markdown files in a GitHub repo. Yeah. I have something that's. Collected together and actually. Published like a website as opposed to. Like I said, just. Here's some markdown files have fun reading them. You'll never find them if they're just randomly in the TOC repo, unless you are already heavily involved in everything I knew where they were to begin with. Yeah. So I would say. Yeah, I would agree with that. I mean, if you look at what the to do group has done with some of their guides, they, you know, they. They're all in the repo and they've got, you know, that's where all the development happened, but then they have like a guides section on the website that has all of the, all of the guides in a place where you can easily find them and you don't have to dig through our repository. So I would say that. Markdown is easiest for a lot of us just code contribution wise, but there's nothing stopping us from, and we have resources on the CNCF level to help us create websites via Netlify that can be attached to the repo. So. Yeah, I was like bashing Markdown. I was just saying. Random files in a listing on GitHub is more what I was talking about. Yeah, for sure. Yeah. So. Oh, I had one more thing about when we're having documents. That aren't published already. I would suggest me, but we also put something in the document itself saying that it's not. Published and done yet. It's still draft. Just having it in a folder on our GitHub repo. This is the folder path is draft. I think it's pretty subtle for some people and they may find it and then think it's real. And not know. Our convention that that wallets in a folder called draft, like it's pretty easy to overlook a URL like that. They be. Useful on our part to put a. One line header at the top of these files and say, this is a draft. This is a whatever it's pending. It's not. It's not really yet. It's not published. It's not. It's not. The. Of course, I guarantee that that ends up with a circumstance where when we move it to wherever it. Gets published to a site. That one of our constant tasks will be, oh wait, we need to remove the draft header. The doc directory did to say draft docs. And something like that. That way it's kind of in one place. And then all the docs we put underneath it. I don't know. Yeah. I don't know. I don't know. I don't know. I don't know. I think it's suggested like in review and draft, but like if it's in the, if it's in the directory link, it's a lot more likely to get missed versus inside of the document. Right. Yeah, you're just relying on people to know our own internal things. Like we all know that it's a draft and it doesn't mean anything and hasn't been adopted. But to someone who stumbled upon it. They don't really know how official it is. Like I'm just trying to convey like, I see this stuff all the time when I'm trying to watch what's happening in the TOC repo and understanding how official things are and where it's going and like, when is it going to happen? And just having something written down in like, full sentences somewhere in the doc is super helpful. So I think what might be cool is that as we publish things into this new fangled place that it's going to live, that we start removing them from the repo as well. Right. And we can maybe tabulate a, like these are lists of decisions that we've made. Right. And this is where the final decision guidance lives. Right. That way there's no duplication of content. And like, yeah, we have to, we'll have to strip a draft header once, but like, I think we can live with that. Yeah. Well, I don't think it needs to be anything more than italicized text at the top of the document that says this document is currently under review. Yeah. So, okay. So I guess my question is, do we want to propose basically a new site for this or do we want to propose that this lives somewhere under cncf.io? Both. I think the, I think cncf, I think with a new Netlify site, it should be fairly easy to, if cncf.io is already Netlified, which it probably is, to stick a link into a different repo reference. Right. So that content can live in one repo, but it can, the site can link out to it. So I think we do some of that across Kubernetes already as well. Yeah. I think it can just be its own Netlify site, but then a different self domain or something like that. Right. Yeah. Should we bike shed over names? We don't have any content yet. Yeah. The, I was trying to come up with some really tortured version of cncf contribute that would maybe involve a numeral somewhere, but the seven, seven, seven, seven, seven. So, yeah, I mean, the other thing I'm thinking about, and maybe Amy can weigh in here is that there might be some painful restrictions on putting anything under cncf.io slash. Sub domain is going to be a lot easier. That'll take like zero time. Getting something up on cncf.io proper is going to be challenging. So what about just proposing that we use contribute.cncf.io? Yeah. We can do like a redirect towards like whatever we want for that. It can go towards Netlify. It can do like something like that. Ihor, is there anything in here that I would, that I am not aware of that would cause this to be a problem? No, not sure. Again, as you mentioned, it's way easier to set up the dedicated sub domain for something at cncf.io and to have it redirected, or to use the existing contribute.cncf.io sub domain, but it will be even difficult and I'm not sure, completely I'm not sure if there is a strong purpose to do something under cncf.io slash something. Okay. I'm good with the sub domain. The cncf.io already just points to the repo, so we can figure out how to be able to, like wherever else you want this to be. This is me here is to try to set up the GitHub pages, which are pointing to the contribute repo. And in this case, this can also solve both things. Steven mentioned it's easier for folks to contribute. If you are contributing something, people have experience with Git, so it's easier to contribute content. We are Git, we are GitHub as a code. And if this repo is set up as the GitHub pages, it will appear there automatically. So that's probably the easiest way to handle this. Okay. At some point I want to bike shed because I'm not sure that contribute maybe is representative of what we, what the content is. And that also already points to that other contribute repo and not to the contributor strategy, say, group. Yeah. So like my question would be like the, what's the, is there an eventual intention for this? I see that like right now it's kind of a listing of the, just the projects, right? Do we, what I'm imagining is the, the CNCF version of the community repo, right? The streets of the Kubernetes community repo. Carolyn is saying, Yeah, you're free to update. So submit a PR space or open the issues in the contributor repo. If you want to see some different content there, or if you want to submit a direct PR, specific proposals. So please do it. Welcome to do it. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Cool. Wait. So are we going to use contribute that CNCF.io? Are we not? It sounds like initially we're not, but maybe there is a point at which the content converges. So where would we put it if not there? I mean, if you're going to bike, should you have to actually make a proposal? I'm thinking like some of it is, it's guidelines, some of it is advisory, like I worry about choosing a name that is, like, I think the names should be descriptive enough that we know what we're getting out of it, walking into it, right? If someone ends up in our repo, I think it is valuable for us to put something of a note that the content herein is advisory and not officially ratified by some CNCF body, yada, yada, yada for things that we have, you know, things that we have discussed on the TSE level go here. I don't know what to call here yet. We can cross-link, we can explicitly mention the contributory strategy or within the contributory of the repo readme, so, like, just to mention that there is some extra advisory content available at the contributory strategy repo that you can, you can also be interested in. If you don't want to put everything into the same place tonight. Alternatively, we could rename our repo to something and let our repo content kind of shift around the directories and let our repo content be, you know, if you want to see drafts of the things that we're working on, go here. If you want to see things that have been officially approved by the TOC, go here. So, so I'm still stuck on the where is that second go here? The go here, if it was to just be our repo, the go here would just be a sub-director in the repo. No, we've already established that putting stuff in a repo is bad. Well, this repo are specifically our repo. No, no, no, we've already established that final content should live on some sort of an indexable website and not just in a GitHub repo. But what we're also talking about is creating a Netlify site so that that content is indexable. So that Netlify site content would live in a repo. So we're still talking about repos. We're just talking about a different presentation mechanism. Right. Right. But I'm asking what is the Netlify site? Because the suggestion was contributed at cnsf.io. You said I don't like that, but you didn't have a counter proposal. The only reason I don't like it is because it currently points to a list of all of the projects, right? So if we are going to decide that the published content should live in the Contribute repo, then totally fine. But are we sure that Contribute is the is the name that we want it to be? I don't know. The more unsure I am about that, because to me, you think about the Contribute.md files to see on GitHub, that's about how to contribute to a project. And that's kind of what this Contribute repo already has. So are you interested in contributing to one of the cnsf hosted projects? Here's a big list of projects you can contribute to. And what we're talking about more is, I don't know, sort of... I have a project. What do I do? Yeah. Yeah. We can easily mention that as well. So if you work through the Contribute repo, in a bottom, you'll notice that we are not on the mentioning cnsf projects there, but also some different ways of how can you contribute to cnsf ecosystem. So the original intention of this repo was to just to have the single point of reference and how can you be useful in the community. You can start with contributing to projects. You can also contribute to at the TLC level, like to be the TLC contributor. You can contribute to the community, to the ecosystem, like run in the made-ups, run in the community groups, be it an ambassador, and so on. So the original goal of developing this repo is just to have all the useful links and how to get started with this in a simple place. It's not only about projects, it's about all the useful links. And we can definitely restructure that if you have different suggestions of better plan on how to restructure it. Yeah. So I think that a lot of the content is going to be geared towards maintainers or people looking for maintainership. We had talked about maintainers.cncf.io before. Right now that redirects to just the Google Sheet. And I think that a link to the Google Sheet could just as easily live in this new repo. Yeah, because a lot of our guides are going to be more about how to set up governance, how to measure whether you're successful or not. It's not really how to contribute to things. It's really how to set up your project for success from a contribution standpoint, which I feel is different. Getting back to what Josh said, I'm not proposing it. I can't think of anything better. This is my problem. I feel it contributes not right, but I'm struggling to find something better. So let's do maintainers unless people have objections. I'm going to caution against that because maintainers.cncf.io was baked into some other stuff as a redirect to that Google Sheet. Sorry. How badly baked? Enough. Definitely baked. Right, something else. Yeah. That's a really good one. Well, so part of the reason that we end up hearing a lot about it is that we're really maintainers focused. Do you want to try to be able to look at how to be able to build community? Thinking about project.cncf.io? Maintainers is already claimed. Sorry. Let's find something else. I mean, but previously we had discussed that like, is maintainers even super useful having this displayed as a Google Sheet, right? Ideally, as a maintainer, as I'm onboarding a new project for thecncf, hopefully the process, I'd imagine the process eventually getting to simpler points where you're putting, you know, you're essentially putting stuff into a YAML file. Love YAML, right? And running some script and that, you know, and that's generating a, you know, that's generating a new list of maintainers or updated list of maintainers. Think the, you know, running make generate on the Kubernetes community repo, right? When you update the six that YAML, right? This sheet is not super useful and it will continue to get long. Other reasons why the sheet needs to be under maintainers. Let's, let's move on. Yeah. Okay. The, or more importantly, do we really want this to potentially get hung up on thecncf slash LF website team doing a bunch of cleanup? No. But since back to, back to your point, someone suggest something better. Yeah. Yeah, I mean, the problem is that some of the obvious ones, which would be like project management are awkward. Yeah. So I think we should go to our respective corners and strategize about it. And let's maybe move on because we've got like other updates. We can bike shed maybe in the next meeting. Okay. Take this on Slack, et cetera. Yeah. The later games. Just, just to close the discussion with contributor sorry for traction judge. So if you, if you have any suggestions on that on the currently existing report was the person who originally was building it is from mostly from scratch. So I'm happy to collaborate with you if you have any specific items for what can we commend her. So just let me know. Sounds good. Yeah. The. Okay. So. Working group updates. I see that somebody's typing stuff in for contributor growth. So do you want to say that out loud? No, no, first not. Um, I've submitted a template to our project template. If people could take a look at it. Um, again, the goal for these is we. Stop doing get, I'm sorry, Google docs and we just start doing PRs for everything. And, um, if people want to do more changes on top of them, we'll encourage polar class instead of. I'm mostly asking one person to do the edits for them. Um, and then, uh, Paris is working on. Yeah, Paris is here. She's working on community management documents. Um, like how to contribute recruit contributors. Um, and I'm working on. Taking the good first issue guy that I wrote for Kubernetes. And. Refreshing it and making it not specific to Kubernetes workflows. Uh, so we can put it up at the CNCF level. This is good. So Paris has. Dropped in a bunch of stuff. About maintainer circle. Um, Should I speak a ghost for her? Yes. Yeah. If you actually understand what. That first item is about. Because I don't quite. So actually Amy might have more context than I would. I can speak to some of this. So I rise up out of the deep again. So, um, here's the thing. Paris wants to be able to actually do a survey about. Um, you know, being able to get. People to register for the maintainer circle piece in here. I have looked at the calendars and there is a lot going on in here. So like adding in another meeting is probably not going to be as relevant. My suggestion was. Taking one of the normal contributor strategy. Meetings and. Putting maintainer circle in here. And correct me. Was. Was this actually the plan in the first place? This was the plan. Yes. Um, so not. Not under the guise of maintainer circle specifically, but an opportunity for maintainers to. Come by and ask us questions if they had it, which I guess is the same as maintainer circle, right? So, um, so yeah, we should, we should do that. And the thing is she wanted to be able to have registration. In order for it to work for China, we need to be able to do it through a survey monkey. That is the question in here. Okay. I say maybe we just start doing it. As, you know, as one of our meetings, if we, because we can slow roll a survey and say, like, if this time does not work for you, then maybe we can discuss another one, but I think we should at least try it in our meetings first before. Their goal here is to be able to do like breakout for like 10 people breakout groups based on the amount of. Frankly, people that we get in these meetings, I don't know that breakout meetings are going to be as compelled. I read exactly like, yeah, I can turn it on for these meetings. That's fine. But, you know, I don't know if it's meaningful. That's all. Yeah. I think we, I think we just want to start doing it to, to be honest. Yeah. Um, I will, I will put remarks in the doc so that my comments are more clear. Yeah. I mean, one thing I'll say for this particular meeting time slot is not terrifically friendly to Europe. Don is up late here and it's well, not super late, but it's still dinner time and, and it's definitely not friendly to Asia. So yeah, we'd want to have some around the clock, you know, things, different time slots. Yeah. So, you know, what could happen is a U. U. S. East, a Mia time slot and a U. S. West, a pack time slot, and we can probably find some balance there. I think that's, I think that at least starting in this time slot, we'll get, you know, allow us to key in on some things that we might want to tweak if we expand to multiple meetings. But I would agree with the whole, like Thursday is the funniest, like overly stacked meeting day for me. And I'm sure everyone's schedules are kind of crazy. So like less meetings are better. But yeah, we do want to accommodate, but we should only try to accommodate if the need is actually there. So I'm going to actually have to drop off this call. Cause an emergency just came up for me. All right. I hope everything's okay, man. Yep. Yep. Go for it. All right. So next up. So yeah, it says Paris is going to look at chatting with Sarah Novotny on some values and principles topics, as well as Tim Hawken on review or maintainership. There was one more topic up for discussion that we had initially raised, which was the, which was talking about naming protocol for various projects. I think this was posed as potentially our first topic for maintainer circle. So I will put that on the notes too. Do other people have thoughts? Cool. Cool. Cool. So if you do have, if you do have thoughts on potential topics, maybe we'll spin up a separate doc or something in the repo where people can request topics for maintainer circle and we can do something like that. Oh, I had a topic. Yeah. Um, it's not a fun topic though, but I hear this is actually more than any of these other things that we're talking about currently. A lot of stuff we talk about. Adds to the time commitment to maintainers. I'm not sure if you can hear this, but I was going to let me talk to, especially this year has been saying that they are over. Subscribe. Essentially. And, um, they're looking for ways to keep the project going. Um, and just kind of deal right now. Um, without. Hurting the project. Right. They're dealing with the backlog. They're trying to not lose people, but at the same time. They're trying to keep features going or deal with security issues that are coming up and just all the various things. And it's like, we can't. Maintain the level of like. Fostering new contributors and doing all the various things we need to do that our. Group actually talks about as being really important good stuff to do at the same time. Cause, uh, There's a lot going on and there's a lot being asked of maintainers right now. So how do you go into like. Like, Yeah. I guess. And take care of your project and not trash a project while you're taking care of things. I guess. That's what I'm hearing people talk about. No, I, I love it. And I feel it too. Um, you know, I feel like every, every interrupt that we get, like sometimes you've got your schedule in line. Like it's perfect. You're like, I know exactly what I'm going to do. Like I'm going to be doing my entire thing out of the way. Um, and yeah. And it's usually never just one. Um, so, and you know, when this happens across multiple projects and different venues and foundations, it's, it's, yeah, it's super stressful. Um, so I, yeah. Let's, let's talk. Let's talk about it. Yeah. Yeah. Cause I'd love to like support. Support people with this. Cause this is like. This is really. This is pretty hard to figure out. I mean, like, doings well, I had to, like, set down my project for a couple of months and that really sucked and it hurt the project and I don't know how to have done that better. I have put in a word that I think describes this, and I think it's being able to build our projects for more resiliency. Yeah, yeah. So I think being able to, like, start from that as a base to be able to say, what would it be like if we were considering resiliency as we were kind of looking at schedules and roadmaps and kind of like how, how could I actually make this easier for everyone, including me, because I love this baby little project and I wanted to succeed. But I also understand that my availability is really inconsistent right now. Given that, what do we do next? Yeah, I love that consistent availability. Yes. I think, yeah, I think one of the trickiest parts of this is, is, it becomes another interrupt, right, it becomes something that you have to like sit down and consider, at least for SIG release and maybe this is actually a discussion for the time that we discussed this right. But, you know, for SIG release, we recently brought on two new technical leads and a program manager, right, and I think, you know, it's the first time that we've done, or people have done a program manager like embedded in a SIG. So there are growing pains and there's like an additional, there's an additional overhead for like interrupts bringing people up to speed so that they can help you shift, shift the workload right. And it's like, it's like, yes, I know I need to do this thing or I know we as maintainers need to do this thing but right now it's another meeting or it's another set of meetings before we get to some reasonable outcome, right. Totally. I think a lot of that is also looking at like what are the priorities for the project like what could fall off and no one will like no various will fall. And what things can we push off towards, hey, perhaps in spring, we could. And I guess I'm using more of like the program manager, like, expectation of, if we didn't do this, what would happen. Yeah, no, it's my it's actually one of my new favorite questions like, is this important right now. Do we need to myself that every day. And, you know, I, you know, this is like internal gripes from the past like I think of, you know, I think of the potential things that we could have done in SIG PM and Kubernetes right and you know just hearing project project. Right. And having an idea of like what we were actually going to be able to deliver that comes from being able to aggregate the ideas of multiple maintainers right and have them deliver those things at on a certain timeline right so certainly you know for a large project like like Kubernetes. I'm finding that there has been more activity by having a local program manager or local PXM E type to help you with some of this stuff because I think that maintainers in general. If you show up and you do the work, you get the power. And that's, you know, that's how it happens kind of often. But you're not necessarily always the best positioned person to do that thing. Right. Maybe you're an engineer who is like, fairly organized like cool you're kind of like our PM person now you're like whoa hold on. Like, I'm not sure I signed up for that. And, you know, so there's there's a lot going on with with maintainers in general where they're wearing maybe five hats that could be, you know, delegated out, but also delegating out takes time. So yes, I think this is an excellent topic to talk about. Yay, I want to be in this meeting so bad. Alright, so we do. I mean like let's, let's hype it up. You know, it's, and we have to figure out times right and when we're officially going to kick these things off. So, that was Paris's question of when. Yeah, because we is, I think last we talked about what kickoff looks like. Well, let's just, there was, there was a wants to do something for, for keep gone and have that be like a kickoff event. But I think we should, I think we had talked about just getting started in September and look we blinked September is gone. We've got a couple different options here. You could track towards being able to take like the October 8 meeting for this particular group and saying man this is something we really want to do. You could promote it at the Tuesday, October 6 Toc meeting, and that kind of leads from there. And that that means that you don't have to have a lot of momentum in order to be able to make this work. But you can look at the 22nd of October, and that does like both of these things do get you something before cube con. I am just not sure about like the bandwidth that this group has. Yeah, I would lean towards something later. I would lean towards the 22nd meeting for myself, at least I will have limited ability to facilitate all of this are some of these things with like all of my attention because I'm also, that will be the point at which like cube con prep is already getting pretty going. So we're working on program review stuff right now. And it will only get deeper as as October goes on for me so assessment because I think we do not take the amount of time that keep con and the amount of energy that keep con even though it is virtual is still taking from from folks. Yeah. I don't have a good answer here. And, you know, maybe it's we wait, maybe it's we wait we get you know we get the conversations going on mailing lists. We could be doing more to hype up the fact that we have a mailing list I think a lot of the discussions that could happen on the contributor strategy mailing list are currently still happening on the TOC list right so I think the TOC list becomes this kind of like garbage bucket for anything to potentially There are votes in there. No you are you are accurate in that we do want to be able to have the signal of this reach people in a way that is meaningful. Without, frankly, making another email for people to be able to deal with and that's the balance there. Yeah, yeah. Yeah, I am not combining this into cube con because the. I've been on the soapbox for four months but the idea of combining everything around whatever when this physically going to be in a place is not the same as trying to combine everything around virtual conference where we're sitting on video it's not it doesn't work. I actually checked our notes we decided last time not to do it cube con so. Yeah, good. However, there is a. I am going to use my chair hat for a second and poke into the content management schedule for cube con, because I believe we do have a session. So, strategically. Okay, okay, so that's. Okay, it's just a project paperwork one it looks like Carolyn, you don and Josh are on that. Okay, right. So, maybe nothing to do there I'm happy to. I would love to start something. I don't know what that something exactly looks like and I, but I do think it's fine to start something small and see at least get feedback. I don't have to worry about continuing to wait post cube con like we're going to blink and cube con will be upon us as as usual, but it is in November so there's a bit of time that we could be doing stuff with we wanted to. There's always a cube con you're either getting ready for recovering from it so at some point we just have to do it. Yeah, yeah. We're going to do the same way. We spent a time that works for this program and we launch it. Yeah, when it makes sense for the program and not not necessarily worry about keep on. So, so Amy the the next to see meeting post October 6 would be the 20th. So maybe spoken for as far as like to see meetings thing. Yeah, there's something in my mind about how like someone someone has claimed that one. Also, I don't know if a to see like I would, I would highlight the fact that you want to be able to do this in your sick updates for October the sixth, which is like this is me plugging you all to get your slides in the end. So just being able to like actually like highlighting that this is something that you want to do, but not being sure about when exactly would be a good time for it might actually get some good input from to see. Okay. Alright, so, yeah, we'll plan to plug on the October 6 meeting. We tried to do something not for the eighth but the 22nd, at least so we can have one more meeting here where we have all the chairs and attendance, potentially to I don't want to make this decision, you know, for everyone will note. The only thing that I've heard you guys really get fired up about is talking about over subscribed maintainers that is the one that is like, like that lit everybody up. And that seems like a really easy conversation to have. Yeah, they're like, it's in me. So because of that I want to be able to like, I want, I want to be able to have you scope this in a way that is valuable for you and valuable for the people that are going to be here as well. So if you say hey look we do the over subscribed maintainers as a conversation for the 22nd, you might get a lot of people showing up. Cool. You will. Yeah. Josh has returned. Josh, while you were going to be made decisions. Oh good. Yay. For any of them, because you weren't here. So good call. No, the recap, the conversation was really looking at the maintainer circle kind of planning on tracking towards the 22nd for that and the piece that is really kind of risen up as a possible topic is talking about over subscribed maintainers burnout and how do you take care of your project when you have inconsistent availability. Have I mischaracterized any of that anyone. Gorgeous. So the follow up is if you can put that into your slides for the TOC deck again October 6 dates and calendar are closer than they may appear. That would be lovely, because it'll get people excited and they know when to be able to come and have this conversation. So, all right, so I think we're happy here. And we should talk a little bit about governance before we leave. It's not not any momentous we're still churning through our content checklist. If we don't have anybody on the call who might be looking for something to do so I won't mention the unassigned items that we have So, I mean we're basically starting with all of the advisory documentation and then moving on to requirements and templates. The. So nobody's really working on the requirements or templates yet. Awesome. Do we have so we have six minutes left. I think we have six minutes off we've got six minutes. Is there any topic that someone would like to raise before we go. Oh, I submitted the proposal for our succession to at kubicon November. I haven't heard. Assume it's going to get accepted. One of the things that I'll have to follow up with the CNCF folks on is what I proposed is highly interactive. And I if we're using intrado as a platform, which is what I've been given to believe that we are highly interactive is not supported by intrado. And so we'll need to discuss how we would actually carry out the proposed event. This has come up and for other talks. So if you want to start in a thread with you. I'm going to call myself Nancy, a few others. If you have Constance's email, I can shoot it to you. Yeah. The. Okay. The. Yeah, because just the thing is because, you know, the way it's proposed, which is a project paperwork session, right, you know, let us help you with your requirements and project organization and stuff. What we need to cover is going to be very dependent on who shows up. And, you know, and this is the sort of session where if we have maintainers from six projects show up. That's a good showing. But we're not going to know advance whether these are mature projects looking at graduation or whether they are, you know, new projects looking to join the sandbox and what we want to talk about is going to be very different depending on who it is that shows up. And this is, yeah, this moves towards like, is it possible to do a recorded session style situation I would say, I would say, do this try to do this ahead of time because this is, again, this is coming up for for other talks. Right. Precieve the question get people to submit the kind of paperwork that they want to cover. Right. And then you have a basis for building the session, as opposed to getting caught off guard with anyone potentially popping in right the the problem is that we can't do that on what are likely going to be video submission timelines. So realistically, people are not going to know whether or not they're planning to attend the session, a month out from the conference. Fair. Yeah, there is there's a bit of clairvoyance that's going to be required because the timelines are tight for everything. So, just a suggestion, I would say it's, because figuring out how to do the live thing is, I don't think is a solved problem right now. I, if I was thinking about the session I would think about, like, let's take, you know how much time do we have let's take a small problem and maybe a large problem or small project large project medium project to medium projects kind of kind of thing and talk about different accesses of, of, of contributor documentation or maintainer documentation. See, I was, I was thinking of doing things as creative as, you know, hey, let's have this five minute general information session. And then say, okay, everybody was here, meet us on the zoom channel. Interesting. Yeah, let's, this is, I think this is turning into chair talk versus contributor strategy talk so let's let's offline it. Yeah. Yeah, just so people know that that's what's going on. Yeah, yeah. So, yeah, it's just, you know, when I wrote the session I proposed it. I'm still geared to think about in person events. Or events that are actually part of conferences that I run. And thus have some control over the platform. So, yeah. Yeah, it's come up a lot and the way some of the, I mean, not, not this is easy. Another stuff I'm dealing with, you know, another event that's supposed to be highly interactive. And I just found out that the platform we're using has a limit of nine users live mice. And they were like, wait, you need more than nine. And I'm like, yeah. Yeah. We're trying to figure out a way around that a few more. Yeah. They don't need to be live at the same time, but they need to be able to turn them on. Yeah. So, yeah, we're struggling with technology. The, we have actually reached, we've actually reached the stage when we genuinely have technology problems instead of people problems. So, it's a rare thing. Most problems are people problems. We'll get through it. We'll get. Yeah. All right. So, okay. We're at time. Thank you everyone for hanging out and thank you for the thoughtful discourse. Thanks for taking over when I had to duck out. Of course, I catch you all later. See you everybody. Bye-bye. See you.