 Hello. I can't hear you. Should be able to do that. Awesome. Hi there. I see you're outside despite the weather. Well, despite the weather, it depends where you are, right? Yeah. I'm currently in South Carolina, normally based in DC. Okay. Where are you? Oregon. So definitely not taking a call outside. I'd be wanting extra layers if I was. Yeah. So I have to ask any relation. Oh, to the. Yeah, violinist. Not ready. Well, it's my husband's name too. So I cannot. Yeah, but. His sister believes like she did some research and there may be and my husband thinks it's just wishful thinking. I comment of the name and everybody has relatives. So. Yeah. I've got one of those friends who's like. Two hundred and seventy eighth in line for the British throne. Which means he gets nothing. But you can claim you're related to, you know, blood, blood, like. Yeah. Blood running into in your veins. Yeah. Yeah. Okay. So. It sounds like it's going to be a rather small round, right? Yeah, we were supposed to have a different. Agenda. And so I didn't set anything up because I was expecting this other agenda. So. I guess we will just briefly go over status stuff to the extent that we can. Given that. Yeah. So I think what we can do since we have. So forward looking, our intent was to have kind of like either a separate maintainer circle meeting or. Yeah. That. That so basically alternating the. Every, every two weeks, a standard. SIG contributor strategy meeting and then the alternating two weeks would be. The maintainer circle meetings. So since you're here. We'll pretend this is a maintainer circle meeting, which it was planned to be. And talk a little bit about container D maybe. Not linker D. Excuse me. I was going to say. I was going to say, this is, you know, So I'm just pinks also, Charles who wanted to be here. So somehow like the. Is not triggering notifications. So I've heard that happening recently. Yeah. So I pinged him and I hope he can join, but. Yeah. So. Yeah, I mean, like I was really excited. So I joined boy and recently. A month. A month and a half ago. And for me, it's the first time working for a company that is also maintainer of source of open source project. And one of the things that we're trying to do. And I was like, oh my God, this sounds like this is some, I think this is like a really good thing for us. Because one of the challenges we have is. Well, we are a small company. We're a startup. And so we're putting, and we put a lot of work and effort into LinkedIn. But we also have to start. Working on stuff that we can monetize, right. So somehow we need to also. So what we want to do now is kind of help help and Charles is joining. Hey, Charles. And yeah, and Charles is a field engineer with buoyant. Yeah. Yeah, just, yeah. And before I said, like I, I'm, I'm, I'm ahead of marketing. So I'm on the marketing side and Charles is a field engineer. So he really helps people on the technical side. Right. And so one of the things that we wanted to do is like, okay, how can we engage the community more? Because it's a lot of the work has been done by people like Charles and some other people who are like really like writing content, like, you know, being on Slack shopping out and we want to incentivize the community to be more engaged because we're always, I mean, it's all about community and open source, but people focus a lot on contributing code. But we want to say like it's more about that, you know, it's also about, about helping each other out or like sharing their information. And we created like a program. We call it to tell people, hey, if you have a story, we're going to assist you if you, you know, if you, your writing skills aren't that great. You're not confident if you haven't submitted a talk yet. And so I was wondering, so yeah, we're trying to think around those lines. And I was wondering if that is any, because I'm sure you discussed lots of different things. But if that is kind of the stuff that we can discuss here too, it's like how to engage them more. And it's like, because that's been always like the big challenge for us. Absolutely. So what was the name of the project? Linkerd community. Oh, the Linkerd community anchor. Anchor. Cool. Yeah, we just launched it and the CNCF is going to post a blog post on Monday, I think that we wrote out, but. Okay, cool. Yeah. And if you have, if you have anything that you're interested in forwarding over to the list, we have a mailing list as well. Give me a second. It's, yeah, it's higher up in the dock. list.cncf.io slash gcncf. SIG community. Contributor strategy. Very easy to remember. But yeah, I think that you're, you're touching on something pretty, pretty important around, you know, a lot of the things that we do, you know, I think that Josh and I are both in the Kubernetes community as well as Josh has had some time in the Postgres community as well. By some time, I mean, lots of time. Lots of time. So the, one of the big things that we have turned focus to community wide is, is kind of like recognizing and enabling non-code contributors, right? I'm also a dex maintainer, which is CNCF sandbox. And one of the, one of the things that we run into is we have a lot of folks that are, are maintainers in the classic sense of writing code, maintaining, maintaining the project overall, and maybe a little less of the softer program management, skills, content management. And that's, that's something that we're looking to fill the gap with. I think that Kubernetes has, I think Kubernetes has the mass to do a lot of these things, but considerations around, you know, like when I think of dex, we're, we're spinning up a website or we've spun up a website and it's like, okay, who maintains this now? Right? Like, do we have the skills within the maintainers to do that? Do, you know, thinking about information architecture. How do we get people to the places that they need to go quickly and easily, right? And, you know, in terms of sustainability, like, I want to, everything that I do, I want to build more maintainers. Like how do I do that? Right? And also thinking from the, the field engineering perspective, because I'm former field engineer and solutions architect, I don't want to do that day to day. Right? Like the, your primary driver is essentially building products and solutions for customers, right? And pushing that feedback into product roadmaps, right? Or project roadmaps. So how do we do that effectively? Right? So I'm just saying lots of words. Stop me, please. But actually more, it's, I actually wanted to back up and say, because Lingerty's been around for a while, right? Y'all are kind of the first service mesh. So what is your current community situation? Yeah, I can answer that. And so Josh, it's good to see you again. Howdy. Even it's always, always a pleasure to be on a call with you. So the current situation is we, we were, we're at the point where we have to be really engaged with folks from the, like the maintainer perspective. And where we're, which is fine. That's what we want to do. We want to be the shepherds and the stewards to make sure that we have a healthy, healthy community. And what we're looking to do with the anchor program that Catherine mentioned is to get, you know, basically ambassadors or captains or whatever the analogous term is to have folks who are, who love Lingerty want to use it and who are so excited about it, that they want to share their experiences with it. And that's our approach to growing. That's our current primary approach to growing the community. Should this not give us the result. So we want, we'll go back to the drawing board and see if we can figure out another plan, but this seems to be the tried and true approach. And so. Yeah, we just, I forget how we discovered this. It's the SIG contrib growth group, but this is certainly something that we could use right now. We're using Slack and GitHub as our primary interfaces with folks. We have a discourse, but it just doesn't get a ton of traffic. It's mostly for Lingerty one stuff. And there's not a ton of Lingerty two content on there. So things that we're thinking about our. As how do we get content? And we've got a good plan there where internally we're having each of the. The maintainers or contributors. Generate one blog post or one tutorial once a month. So that'll keep us if, if nothing else changes, that'll keep us going. We'll have one piece of new content for the next like 18 months. But our goal is to grow that and to encourage folks again, who love Lingerty, like we don't want people, we don't want to. We don't want to make or ask people to do something that they're uncomfortable with. We really want people who are excited to share what they're doing with open source technology, how they're integrating it with other pieces of open source technology and gluing these things together. And these are a lot of the conversations that I have with folks on Slack, like DMs, and they're saying, Oh man, we just integrated Prometheus and Lingerty with Cortex and it's driving all of our metrics and it's super, you know, they're super excited about it. And so that's where we pick up on those cues and try and encourage them to get involved as well. So taking that abstracting that away from. For taking the Lingerty part out of that. What we're looking for is just common patterns or even shared. Shared thought around continuing to grow, continuing to encourage folks. Now I've said a lot of words. Does that all make sense? Yeah, so I mean, I guess, so one of my questions there is, I mean, Lingerty obviously has a user base, both for Lingerty one and for Lingerty two. How connected do you feel like you are with that user base in terms of, of them showing up on Slack or filing GitHub issues or other methods that you have two way communication with them? It's, I would like to be more connected and I feel like over the last three months we've lost a little bit of connection. And this is just based off of anecdotal things that I see like fewer conversations in Slack, fewer PRs, fewer issues that are filed externally. And I can dig up those numbers and the trend actually looks like we're right, but so we're kind of in this, a strong course correction mindset to, to get people engaged and get back. So I feel like we're in touch with a lot of, like we know what people want out of Lingerty, where I think there's a disconnect is our roadmap and what people are looking for. And so that's, that's a converse. That's the first time I've ever said that at all. It's the first time I've ever had that thought. So it probably is something I need to think about more before we go down that rabbit hole, but the few, we have a few folks that are just really engaged and then people that come in. I think over the last few months they weren't getting the right amount of attention. They would join the Slack channel, ask a question. And maybe it took too long or maybe they never got an answer or, and so they kind of just bounced out. So that course correction work that we're doing now is, and it's, I don't even consider it work. It's like, oh, I see somebody's new in the Slack. Let me just go say hi, right? When they've joined, it's that kind of thing. Just to build that welcoming and like encourage folks to write, ask questions, because I am also the kind of person who's hesitant. Oh, like I will scour the internet for quite an answer to my question before I am like, before I'll go and join a Slack and ask the question publicly. And that's just my own like hangups. I want to, the other side of that is I understand it. And I want to encourage people out of that. I mean, I think that, you know, I think that part of that is like, it's a good pattern. And maybe I'm saying it's a good pattern because it's something that I do as well. But it also starts to poke holes and kind of like your information flow. If I can't get the answer quickly, then that points to an opportunity for optimization. Right. I think that I'm not saying that Slack or discourse should be a last resort. Just that people should be able to self enable. So I think that's a good point. Essentially. So you mentioned roadmap and I was going to mention roadmap to you as well. Having a clear vision of what's next in the project is huge for a lot of people. I'm seeing that you have 131 issues open. On, on just linker D linker D. I'm sure there are. Tons of other repositories to consider. Right. Yeah, that's linker D one. So linker D two. Okay. All right. And that one is 209, 209 open. So like if you can. Yeah. So if, you know, finding a way to kind of aggregate some of that stuff, get a better idea of, of who's doing what when is helpful for users. It sounds like just like, I know this, I know this problem too. And it's, and it's a, you know, it's a triage problem. It's a, it's a maintain your ship problem as well. Right. So do you have enough? Right. And, you know, so I look at, I look at the maintainers that empty as well as like adopters. Right. Adopters are potential maintainers. That was actually a question I was going to have, which is a service mesh doesn't exist independently. Right. So are there other organizations working on. Stack pieces that integrate with Lincard D. Not so much stack pieces that integrate with Lincard D. They are integrating Lincard D with, like I said, that, that Prometheus Cortex is a good example or. Integrating Lincard D into a CI CD system like Fargo. We're seeing that kind of stuff. And yeah, the, the maintainers and adopters, that's, that's where William. Our CEO has been that's kind of the path that he goes down as soon as he gets really excited when we add somebody to adopters. And then he goes and like pokes at them to see if we can get them to do more than just add themselves to adopters. And that's, we've had some success with that in the past. It often involves bribes of hats and T shirts, but it works. Yeah. Bribery is, that's great. Because I'm thinking of this because one of the things that we've strategy with projects that originated with a smaller company as, you know, an internal main product of that company, right? And that gets very, very hard for those projects to get core contributors from outside the company early on. And so one of the things that we've seen that has worked better is you recruit contributors around the sort of fringe for the project, you know, integrations, plugins, UI stuff, that sort of thing. And as people build up experience and a commitment, they eventually get into submitting stuff to the core project itself. But it's very hard for people to start there as their first contribution. Yeah, yeah, that makes sense. I think that we see that too. And then and then overall, like from the, you know, the CNCF level, that is, you know, something that people look at deeply for, for graduation considerations, right? Is it, is it company diversity? Like, is there company diversity? Right. So just staring at the maintainers, at least for LinkerD2, I see only one email address that is not buoyant right now. So. Yeah, that's pretty honestly pretty standard for a lot of these startup projects. Yeah, yeah, for sure. Because it's very, it's very different compared to the big company projects where the project is one of 800 different things that that company has. The so, but you know, we're looking at some of these things, some of the other projects that are in your same situation and where they've managed to get traction is to bring people in through all of the sort of satellite stuff that makes the project work, the, as a way of people building up experience and commitment to the project, because ultimately, you're most likely to get people contributing to the core, etc. When they have a, you know, when LinkerD is important to them at work. Yeah. And end users tend to be really good primarily for non-code contributions and for maintaining bits of stuff like integrations. And it tends to be the case that you're looking for ISVs and similar, you know, people who might have LinkerD as part of a stack for more substantial contributions closer to the core. Um, just because of the time commitment involved. Um, the, so, but I mean, it sounds like part of it, you know, begin with, which already addressing this anchor program is, is kind of connecting with your users, right? Because you have your pyramid and the users is the broadest part of it. And then contributors is, is almost, is always a subset of users. If in users, you include things like integrators and tool builders, etc., which I do. The, the other thing that I'll actually ask is contributor path, right? Like say, you know, imagine I work for Actuate. And we've decided that we're going to offer something built on LinkerD for a customer. And there's stuff that we need that's currently broken or a to-do item in LinkerD. How clear is the path, right? Assuming that I, as a potential contributor, have the time to put in the work, how clear is the path, right? Assuming that I, as a potential contributor, have the time to put in the work, how clear is the path for getting that contribution in? Like, like how difficult is it for me to figure out how I would contribute that thing, whether or not even can contribute that thing? Because one of the big obstacles that we have with the smaller company projects is this perception that the perception that if you don't work for company X, you can't contribute to the core actually exceeds the reality. You know, I was working with Kong folks on this. And they like would desperately love more third party contributions to the core, but people don't even think they can do it before they, you know, attempt it. Yeah, that's a good question. Good. But I think we could make it easier. And I think you could say that about any contribution path, right? Like, we could make it easier. So, and I've had thoughts around this recently just about, like, a tutorial for setting up your development environment for Lincardy. Certainly, there are enough moving pieces that it's not it's non trivial to set up a development environment. So we could, that's something Catherine and I can can work through even that if we, if you don't mind, we'll bounce ideas off you of how we what the what the path currently looks like and then how to smooth that out. And then, of course, the takeaway from that would be we would put that into this SIG, like this is where we started as a community with Lincardy for our path. And then this is how we changed our contribution path based off of meetings for for this this SIG. And then put that into like a CNCF blog post. So I could see that being a really effective exercise. And I think it would help a lot of we're certainly not the only people who have this struggle. Yeah, I think we we for sure crave user experience reports, essentially. And from the from the project perspective, this is the kind of this is the kind of work that one people want to see that you're actively doing. So be vocal about it, be vocal about like we have recognized that that there are ways to improve the, you know, the way that we bring people into the project, but also like the field engineering experience that you have is is is really massive here, right? Being able to write being able to write user stories, right? And feed that into the product roadmap and make that roadmap visible is huge to contributors to. If I don't know what you're doing, I'm I'm a lot I'm a lot less likely to touch your project. OK. Taking notes here. Yeah, that's awesome. That's really, really helpful. How do you do proposals today? Proposals in terms of feature requests. Oh, feature requests. It comes they all come in through GitHub. Though it's in that's kind of the manual part where it's up to us to pick up on them. You should we'll get some that just come in straight into Slack through issues and we have a template for a feature request for a GitHub issue. But we also have people the second most popular way is people will come into Slack and they say, hey, does Lincardie do this or it would be really cool if Lincardie does this. And so going back to what we're just talking about about that contributor process, our current process is to say, hey, we'd love some help with that. Would you either file an issue or if you want to do if you have time for PR, that would be great as well. That's our current process. And that's the one that I need to think through that Catherine and I can think through that I think that we could make improvements on. I have a question. I mean, because you've been talking a little bit more about the technical part, like, have you do you know of any company that is organization that is like our size and has managed to do this successfully? Because it's like, of course, like you have like the big projects with the big companies behind them and they had the chance to put a lot of marketing dollars in promotion and you have like all these excitement and then you have these people like talking about it and so on. But for us, of course, we don't have that option. And yeah, what I'm kind of trying to search now is like, OK, who is doing it right? Like, who has figured it out and maybe no one has. But it's like, that's why we're trying to do this anchor program and so on. But it's like, like, who else has been able to engage and get people excited? What what has been getting people to speak about it publicly? What are I mean? Yeah, like, do you know of any company? So that would be hugely valuable. Hi, Don, by the way. Hello there. The I mean, so maybe Amy. Oh, hey, Don, maybe Amy or Don can think of somebody else. The ones that I think of that have been really successful were the ones where they managed to get other companies involved in core development in a substantial way, which part of it just depends on sort of what your technology is and where it is in the marketplace. And that's not really, you know, necessarily a great example. I'm trying to think of. Yeah, I think you're right there, Josh. We sorry to cut you off. We we identified that as we identified that as being like the thing that would move the needle the most in the fastest for us is if we could find a company, an external organization, like an end user that was available to dedicate their engineers to building contributing. Yeah. So I would say that, you know, one, if you are doing something for KubeCon and have not recorded your talk yet, include that as a call to action. Two, you have the, you know, you have the the TFC list, the CIG contributor strategy lists at your disposal to kind of to help market some of this as well and the end user community, right? So CNCF has an end user community exactly to raise these kinds of topics. So so there are a few avenues to go down in terms of building this out. I think I think that, you know, one of the best strategies is to help people drink the Kool-Aid, I guess, and then turn to turn them again, turn those adopters into maintainers because like they're, you know, they're already invested in making this thing successful, be it for their business or be it for the wider community. And and those are going to be your strongest advocates for sure. Yeah, I was looking at who else we might have because we're looking at, you know, among the projects that were originally sponsored by smaller companies that we have on the graduated level. I mean, Vitesse obviously comes to mind. Vitesse has had some great stories lately. Yeah. And, you know, and they had real challenges getting other people involved in like major contribution stuff because because big, you know, like they exist in the intersection of cloud native and databases and databases have historically, you know, pretty much with the exception of the PostgreSQL ecosystem been a story of single company projects. And the and part of it was, I mean, again, but again, for them, part of it was honestly getting some other vendors involved, but getting a lot of end users involved actually from the look of things. Yeah. The because because they got Google involved, Google and Microsoft involved, which helped. But they also picked up on a bunch of end users and integrators because they've got PUREX in there and Slack and Pinterest who are making contributions to the project. So I would also take a look at the general general fitness wise. I would take a look at the the CNCF graduation criteria and think about some of the gaps that you have in the project currently. Right. So, you know, we had already mentioned it, but the, you know, the single single company maintainership is is is one of the ones to think about and having a website looks great. I feel like I can move around and find what I need on it already from the, you know, the few minutes of searching around that I've done on this call. But I would yeah, I would say I would say definitely look at the graduation criteria and I know that Josh, you, Dawn and some some folks have written up documentation around governance, so stuff to take a look at too. Let me. Yeah, I don't in the repo. You know, I feel like governance, governance actually kicks in at a different level, which is I think a different level because because where governance becomes important for growing your contributor community is after you have that initial engagement, right? So yeah, I say that to say they they are incubating right now, right? And it's just something that should be really on your roadmap, right? Yeah. The so the I mean, actually, I haven't looked at what they have for. I have no idea how the project is governed the. So dropping some links in Slack. No, we have a file here, which is while you're required to. So yeah, I mean, my basic self-selecting maintainer group. Yeah, my biggest piece of advice when it comes to like recruiting the outside maintainers and you guys might have talked about this before I got on the call, but it really in a lot of cases boils down to like one on one hardcore recruiting of people and and being really proactive about it with individual people. And once you get a couple of individual people that are outside of your company, then it gets easier to start to scale that and put some mentoring programs in place and kind of build up the contributor ladder, which is what the contributor growth team working group looks at. But it's it's honestly, it's a lot of hard work and it's a lot of convincing individual people that they really want to contribute. And that's it's hard. But if you approach it from that, that direction, that's the best experience I've had. No, that's yeah, it's and we are I'm glad that we're having these conversations and I certainly don't want to hijack the entire entire SIG meeting for for linker. Or it's fine. We didn't you are our agenda. Honestly, the only stuff we had on the agenda was check in about KubeCon prep. So it's really not they're really there. You know, this was actually I think every other meeting we're supposed to leave at least half an hour open for projects to come by and ask questions. So so you are here. You did the thing. Yeah, I will use my very good agenda too. Well done. Yeah. Yeah. Well, thank you all. Yeah, that's Don, you're right. I think boy, it was it was certainly much easier went in person when we could like KubeCon is the best example when I would run into folks run into users who are curious about linker D and then fast forward a year and they have a KubeCon talks about how they're using linker D in production. That's like that's a really good feeling for us. But you're right. It's been a long, long road. It's been long hard work. And so to your point about it being difficult, these the virtual interactions I've found have made it much more difficult. And this is probably my perception. I feel like when I'm DMing somebody on Slack, I'm one of about 18 to 23 other conversations that they have going on at any given moment. And and my main the main thing about that is I really feel bad about bothering people. So anything that I can do to offload their cognitive workload would be great. At the same time, I want to get them involved. I want to get them excited. So that is just a big ramble about I agree with you that it's difficult. And there are hurdles to overcome in that regard. We all feel your pain, right? So we've all we've all been in this situation before at various times and various projects. So yeah, so we're here for you. We feel your pain. We're happy to help in any way we can. I think in some sense, like we're, you know, for every, you know, for every Kubernetes sub project or something that we may spin up, it's it's a very similar situation where we have to do the recruiting, we have to do the one on one time with people, we have to think about the way that we want to market the sub project. So like, you could you could see them as as as many projects and in and of themselves. I think, you know, very sensitive to the very sensitive to the Slack overload. It's actually currently happening. What what is maybe a good task to do is think about the questions that you get on Slack, right? The questions that you ask and the questions that you receive on Slack and say, did someone did someone come to me explicitly because I'm the only one who can answer this question? Or because there aren't docs that explain that, you know, explain that process well enough, right? And those are some quick opportunities for contribution there too, right? The, you know, if you've if you've onboarded, you know, one of my favorite things to do when like onboarding a new new team member is like, hey, you're now responsible for the onboarding docs, right? Like, you know, so so pen and paper, you know, anything that you notice that caused friction in your onboarding process, like, that's now part of the onboarding process, like you should write that in. So, you know, putting putting the power in contributors hands to do that work is huge too. Yeah, you can also sort of pull people in and sneak them in and, you know, in little ways too, like there's a, you know, a pull request and it has some, I don't know, some intricate something or rather that, you know, someone else has some experience with and encouraging people, hey, can you take a review on this? Because I know you know more about, I don't know, postgres or whatever that I do. And so you kind of like wrote people in in little ways by just proactively pulling in them into things like answering questions on mailing lists, little reviews on pull requests, answering some hard question and slack. And once people start to see other people answering those questions without knowing that you pinged that person and proactively ask them, that shows people that it's not, it's not just your company that is responsible for answering questions and reviewing all the pull requests. Because if that's what people see, that's the expectation you set. And the more you can do to change it in small ways, that helps kind of make it easier to make it better in the long term. There are also, you know, more minimal permissions that you can provide to people. I think there's like a triage option on GitHub. So if you have repos that are like you have a few repos that could use triage, right, as the short version. So if you have people who have been commonly committing code or, you know, non-code contributions, pull them in for triage as well, right, or you can set up boards, you don't have, these don't have to be repo pin boards, but you can set up GitHub project boards, right, and assign permissions outside of the repo permissions, right. So that way you kind of get around the, the, the problem that you often run into where you have a repo scoped project board. And the only way for someone to actually maintain it is to give them a host of permissions on that repo, right. So having an org level one or having several org level ones allow you to bring people in as kind of PXM types, right, and, and work on that. Yep, that's, that makes sense too. It's great. I have another quick question to Steven. You meant that, you said that, oh, if you have something, just send it to the mailing list. But the mailer list is like everyone who is in this, like what do you mean, like for instance with the anchor program, you said, oh, just send an email. So, so I think too, so we have, so the SIG itself has a mailing list. The TOC list sends to get a lot more traffic than we do. And then there's also the end user group. The end user group, we would have to, Amy probably knows more about how we could activate that for you. So I'll shut up now. Yes, but Cheryl is the one who is, is running that. I'm just saying Amy. That is legitimately the answer. No, okay. The answer is, Cheryl is the person to talk to for being able to work with the end user community. That is it. Awesome, thanks. Cheryl is my hero. Cheryl's awesome. Yeah. And Cheryl like has the perspective of like working on, you know, working on these projects as well. So has some of that end user feel too. So it's open source way is very useful as well. It's, I, I follow that repository. I haven't visited it in a while, but that's something. I dropped the link to the guide about from users to contributors because it has some, it has some good tips in there that might be helpful. Yeah, I should have shared this with Catherine. That's a great, a great resource for lots of stuff. Oh, let me get these links into the meeting notes. Oh, yes, sorry. I should have put them in the meeting notes instead of the chat. I was, I was dumping in chat too, so. So easy. And then you end the chat and you're like, oh, rid of my links. Oh, no. That's what Zoom does. Oh, I feel like Zoom's part of the part, part of the family these days, right? It is. It really is. Spend more time with Zoom than real people. Good. That's good marketing. Well, I think that gives Catherine and I a ton to process and talk about for sure. So I would definitely. One of the things I would say is after you reach out to people, like when you have some kind of a line of communication going on there, based on something you said, consider having an open road map session. Where you like invite these ambassadors and anybody that they invite in that sort of thing to have a discussion about roadmap. And it can be a frank discussion where you can say, hey, here's a bunch of things that people are already working on. Here's a bunch of things that people would like to have. But nobody from buoyant is working on, you know. So if you want them, someone else has to step up. And here are the things that we have to decide. Are these things ever going to be part of linker D? Right? Because you have to, every project has to decide what their scope is. And that's that's a process. You don't have to decide what your scope is just once. You have to decide what your scope is. Multiple times because the environment you're operating in changes and the technology changes. And you know that both has two things. One is it gives people a chance to participate in something, a chance to feel part of the project and like they're being listened to, etc. And it gives you valuable information about what people are looking for. I mean, particularly environment where you're competing against other open source service mesh projects, projects, right? And a big part of in a competitive open source situation, a big part of how you drive adoption is implementing the feature that the other ones don't have. And then it turns out that people want. I think the hardest thing that we have to deal with outside of like all of the many, many things in the Kubernetes project is the at some point kind of like all of the responsibilities start funneling into the de facto roles for SIGs, right? So so the chairs and technical leads, which means they're doing, you know, they're doing the technical leadership stuff. They're doing the the cherry stuff. They're running meetings. They're triage. They're building out boards. They're they're reviewing enhancements for features. So, you know, all of that. And you still have to decide what does and doesn't go in, right? We don't have a very good way of doing that right now. And I think it's easy to I think it's easy to say yes. And and not realize that you don't because you've got all of the this, you know, these these other tasks occupying the mental space to be able to say like we don't actually have bandwidth for this, right? And and being I think, you know, being able to be honest, really honest about that stuff like one, the roadmap helps because you can just look at it and go like this is just not not in the cards for 120 or whatever release, right? But two, like giving that opportunity by having the roadmap and saying like this is, you know, this is in the freezer, the backlog or whatever, like you can feel free to pick it up, but no one will be there to maybe to maybe carry it along. So, if you're comfortable, you know, if you're comfortable engaging in that way, if this is a feature that is important to you, then feel free to carry it. But being able to say no as a maintainer is so important. Yeah, I think I like the open roadmap session idea and I think there isn't a difficulty in saying no oftentimes. So, but I definitely take your point. It is, it's like kind of towing the line of making sure that we are addressing community requests and meeting project goals. Thanks so much for dedicating the full. Yeah, thank you, thank you for coming. Yeah, of course. We've got two in the books now. Container D popped by first and we're gonna get all the Ds in here. And by the way, I actually want to reassure you it's even not just the small companies. I will tell you that some of the projects that originated at big companies are also facing this particular challenge. For Google, they're having this issue with the GRPC project. For us at Red Hat, we're having this issue with Cryo, where we're really trying to diversify our contributor base and grow it. Diversify it by growing it. So it's actually, it's honestly, it's a challenge for everybody, right? Some projects kind of manage to be in the right place in the right time to attract other companies that put a lot of time into open source. And they get to advance quickly. And then the rest of us are like, we have to make this happen ourselves. And that's a lot harder. Now, scheduling note here. The next proposed maintainer circle would fall on November 19th. And I am assuming that all of you would rather be at KubeCon. Yeah, the nod means cancel that meeting. Yeah, well, so, I mean, I think it looks like our next scheduled would be the 5th, no? For the maintainer circle. Okay, wait. The part where we would leave space open for folks to be able to come by and tell us stories. Although, I don't know. Actually, wait, you know what, although actually, if we can get enough of us together, having one of those during KubeCon wouldn't be a bad idea, particularly if we could make it after our session. Because we're doing, by the way, we're doing an actual session in the program on project paperwork, on all of fulfilling all of the requirements the CNCF expects in terms of paperwork, etc. So, having one concurrent with KubeCon that was after that. That's a later in the day session though, right? Wednesday or Thursday? Yeah, I don't know. I haven't even looked at the schedule. It's midday on Thursday, so it's like 9 p.m. my time. Yeah, that's, so I didn't mean immediately after that. I meant after that on the calendar. Yeah, yeah. Not before it, because I would want to plug it during the Q&A. Fair, fair. So, maybe we do a fast follow and the next contributor strategy meeting becomes a maintainer circle meeting as well. We just flip the calendar. That would be the one on the third. The third. Yeah. December 3rd. Yeah. I think that gives us, you know, the hope for this week, and I think all of us respectively got dragged into things. Running KubeCon, being one of them for me, is doing a maintainer circle on resiliency, right? So, talking about maintainer sustainability and burnout. And it would be cool to keep doing something like that, but it would also be cool to get some tasks that fall out of the project paperwork session. So, maybe we do that one first. I don't know. I don't know yet. There's the inclusive naming one that we want to do as well. And I think we're running out of days in the year to do these with. So, chairs, I say chairs. Josh, you, Paris, and I should get together and figure out the schedule for the next few. Yeah. By the way, are we planning on launching an inclusive naming thing for CNCF? LF level. LF level, okay. Yeah, more details soon. Working on that with Priyanka, Celeste, and a few other people. And Josh, you did upload our presentation, right? You aren't waiting for me to do that. I'm not waiting for you to do that. Okay, perfect. Yeah, your scheduling options right now are kind of tracking towards like November 5th or December 3rd for being able to do like, you know, other meetings to take over. So. Yeah, I would say that maybe we shoot for, you know, maybe we shoot for immediately after KubeCon and let the, let the November 5th meeting just kind of be a wrap up as we go into KubeCon. I am putting said notes over on the documents that we don't not forget. Thank you. Thank you. Sure. Like this. Huge. And. Hard to miss. That sure. No, do anything you can, but that sort of thing. All right. So I feel like we're good. Are we good? There's stuff we want to chat about before we go. No, other than just to tell the Charles and Catherine, you know, you know where the Slack channel is now. You can follow up on this. Keep us appraised of the schedule for the anchor program. Yeah. And we can definitely pump it how we can, you know, big, big community hugs and wrapping around you. Yeah. Let us know how we can help. Yeah. Yeah. Well, I think on Monday, as I said, is going. We're going to have like a CNCF blog post. So I'm going to put all the information in the Slack channel and I would appreciate any little bit of endorsement and like or like push out or anything is highly appreciated. Okay. Well, let us know when it's posted so we can echo it. We'll do. Thank you so much. This was so great. Really, really thank you. I mean, we are so excited. We found this. And we're like, why do you love this? Tell your friends. I'm trying to cleverly draft my tweet as we speak. I'm extremely online. Oh, I know. To be fair, this is kind of a newer SIG that has kind of risen up and it's slowly getting going. So you're not really, no one has missed out on anything. You came at the right time. Okay. Awesome. Well, nice to meet everyone. And thank you so, so much. And we'll see each other soon, I guess. Yeah. Thanks for coming. Take it easy. Good luck. See you online. Bye. Bye. Take care.