 Oh, right. We are just at the top of the hour, so we'll give it a few more minutes for folks to come on in. This one may be a pretty late meeting because it's kind of a special edition. But Alexis, thank you for dropping on in. Josh, you're here too. Excellent. Hiya. Hello. Hello. Excellent. Hello, you made it as well. I wasn't sure if people were going to make it because this is the time where Zoom has started gating meetings. I think I caught everything. Yeah, I think on the link, I thought I was going to have to press some sevens or something, but it just let me in. So the links have been set up that the passwords are embedded in there, so folks should be able to get in. But, you know, it's, we'll see what happens this week as far as like who gets in and all of that so. Hello, Alexis. Hello, Liz. How are you? Good, I guess. Thank you. Feels like coming home. If at any point you feel like, you know, you want to take over. Thank you, but no. How are we doing? I know there's less left superglue on the steering wheel. There we go. God, I haven't seen you in person like seeing what you look like Alexis for a long time. Got more beard the last I saw you. It gets saved every three weeks. Okay. This is not officially a beard. Okay. Justin Cormack ping me said he'd be a little bit late, but I think we can go ahead and get started as far as. Looks like we have a good showing of people welcome everyone. All right. Made it normal things. Okay. Okay. So I think today. It's all about graduation requirements, maintaining diversity and Alexis's. Kind of suggestions around steering committee and. You know how we might be able to help projects. And enable projects to run in a, you know, a way that is good for the entire community. While also, you know, Well, that's good for the entire community in broader ways than we currently require. So we currently have the multiple organization requirement on maintainers. We, I think we have all acknowledged that the definition of word maintainer is a bit unclear. There are other vested interests. Involved in projects, other ways that we can, and doesn't all just have to be about co commits. Alexis, do you want to talk us through your proposal and why you hold on. Let me just, I've got a stripe of some of my face, which is going to turn me into stone. Thanks everybody for being so patient on this. Let's see if I can try to summarize what we've got to in the many, many, many discussions that we've had on GitHub on email on Twitter and probably some other places that I can't remember right now. I think that the key objective for me stems right back to when we formed the CNCF and wanted it to be a place where all sorts of different participants in the industry could come together and benefit from the things that a foundation offer, including a firm legal basis for sharing intellectual property and marketing umbrella and potentially other things as well. And I was certainly very keen to see what I thought of as high velocity projects be in the CNCF and I'm delighted that we have some really good high velocity projects like on boy from lift originally and Prometheus from cloud, which came in, but also I think that some of the sources of innovation in our industry are from from ISVs. And I've been in many ISVs myself small independent software vendors and I've also worked in larger companies that have partnered with them and acquired them and so on. And I do feel that they have a special set of challenges which we need to understand better. And we do have companies and teams associated with CNCF, some of whom are VC backed, some of whom are not, who I think need to be heard and listened to and supported, so that we have big and small vendors, as well as big and large and small end users in the CNCF as a four legged table. And I think that if we stop supporting ISVs we might find the table wobbles over and this becomes a three legged table that's half on the floor. So, going to the detail and that's why for me what I would really like to hear today is the views and real challenges that have been run into by independent software vendors with getting more maintainers, retaining maintainers and keeping up the mix of maintainers. And I just want to say first that I know that the maintainer diversity language has been in there for a while but I do think we should reserve the word diversity for other social and political purposes and focus this maintainer issue on some other language that expresses a mix of companies or some other concept that expresses. We did discuss this on GitHub already. And so, for me the question is what are the downsides of single vendor open source or open source projects where there is a lot of initiative coming from a single vendor. And I've seen various different versions of this over the years. And I've seen it to be very successful under foundations I mean for example, we talked about the example of Kafka on the Apache Software Foundation ASF where most of the committers and maintainers are people associated with conflict but not all. That seems to be one where the community feels it's maintaining a decent balance. I think that's a pretty pretty good situation. But there are other ones as well and not all projects are as big or mature as Kafka so how do we help smaller projects get there and I believe it's very very important that whatever we are doing we are helping projects. If we're helping projects get to where they need to be in the long run then end users will have the confidence to trust us and our recommendations and thoughts around projects, architectures and the whole cloud native tool chain. And if we don't have that trust then they might as well use something else. So what are the two issues that came up again and again when we talked about this before what were the downsides of having a concentration of coding maintainers associate with one or a small handful of companies. Really it came back to two things. One of them was this issue of the sort of, I think what was the project that was acquired by Apple and then separated I can't remember what it was called the database project. Thank you very much there's the foundation DB problem where you know a project a has employees associated with it from a single company that gets acquired goes into large co which for whatever reason it may not be malicious then just basically evaporates all the work on the project. And somehow there isn't a mechanism for rescuing that situation. And I think that I'm not convinced the situation is truly mitigated by having multiple vendors I think having lots of vendors helps in the case of something like kubernetes. That's a big enough project to sustain acquisitions and all kinds of changes but there are other projects that are smaller and medium sized where you know even if you had two vendors it would rock it quite a bit to have something like that happen. So I believe that that's worth discussing and I think the LF is can play a role here in helping projects to migrate. And I think the LF should provide an underwriting guarantee that in some sense this can never happen to a project it will always continue to exist in some form. And then the other thing is this issue that I described in great depth in the document that I sent around about the so called steering committee proposal, which is this feature hold back open core thing. And for me, I think this is the number one thing that really upsets me about commercial open source and some of the more recent debates around licensing models. I think that there is a I just don't like projects where the project is crippled or held back in some way deliberately due to a servicing someone's commercial strategy I just think that if you're going to play the foundation game. You don't have to be willing to have a fully featured product and sell ancillary things like you know in the case of scenario. Nats is fully featured they have a separate product in form of a SAS that's an example. And I think this comes up again and again. There's also reality that needs to be recognized. Not in a small group of engineers it's very very hard to add all the features everybody wants. So you know you do need to prioritize things. We've also seen other projects like Prometheus, for example, have problems with feature hold back not for commercial reasons, but simply because from time in the past. There's been a tiny group of maintainers and far too much work to do. So they just haven't been able to keep up so it's often not malicious situation. But I think that it's really important that end users have a voice in this process. And we see a well governed project as one that listens to its end users and doesn't hold back features that really ought to be in the open source project. I mean for me that is the number one goal of graduation other than long term stability. And I believe that individual companies or teams or groups, you know, other weird structures that we haven't thought of perhaps should be able to convince the CNCF they've taken this seriously. And so one model that I thought could do that would be the so called steering committee. Now, I don't think the steering committee is the only model for doing this and I would like to briefly note some alternatives. First of all, one alternative certainly is for every project to be like Kubernetes to have a large number of vendors and to have a really nice, quite complicated governance model with with SIGs and steering committees and charters and elections. That's great if you've got a big enough project. You can have the other model where you don't actually have a steering committee you continue to have a repo level or org level management committee of maintainers, but you change the notion of a maintainer. There's not only coding people but can include end users people who do documentation, people who organize events and anyone else that I haven't thought of, who is involved in the project and one thing that I really admire in the world of Kubernetes is the way that they have stated that type of person non coders in their structures and I see people being elected right now, standing for election to the Kubernetes steering committee who won't necessarily be coding on Kubernetes but are heavily involved in some way in the project that's great. So that's another model. And then there's another model that I proposed which is the so called steering committee, which is simply a recognition that end users and coders and documenters and other people with a stake in the project could form a oversight committee, which acts at the organizational level, which I mean, let's take Prometheus as an example there's a Prometheus org, and it has multiple repos and the maintainer is associated with the repo. So this is an org level structure. It meets periodically. And it acts as an intermediary between things that are concerns of maintainers and repos, and the CNCF TOC itself. So it can listen to, for example, complaints about people being unfairly treated like, why is my contribution not being accepted. So is it because I work at IBM. Is it because of some social discrimination, or is it because of a technical reason and that would be a complaint that could be heard at that level. And then of course there is the extreme exception of if things are still not being sorted out properly, they can go up to the TOC. The steering committee isn't acting in lieu of the TOC. It's there to provide good transparent project governance at the org level, involving end users, involving documentation people and other members of the community, in what I hope is a very healthy way. So my intention there was to open up the org level governance more so that people who were non coders could get involved. And this I believe I hope would help some of the folks like buoyant. Storage OS, Upbound and others who are behind some very exciting projects like, you know, Linkerd and others. So, and I also want to stress that I don't believe that, for me, Weaveworks is anything to do with this. We are completely committed to the, what I would call the previous CNCF model, with all of our projects we happily work with refinal apps on Cortex, and other people on Flux and will continue to do that. So we're not looking for anything like this, but we do want to see, I do want to see healthy projects like Linkerd get help in this regard and that's as well. So I hope I've covered the aim of the steering committee, which is to solve the problem of an open fair roadmap involving end users, and also perhaps help us to focus on the other problem of the foundation DB issue. And thereby, give us a different approach to governance than simply mandating multiple vendors be involved at some scale. Does that answer your request for an intro, Liz? I think it does. Okay, so I wonder if the next set of people. I'm thinking the working group who looked at governance, governance working group, I think you're called. Yeah, Josh, are you a good person to speak for. Yeah. In less dims is not on this, is he. He took the lead in this particular issue. Dimz is on. Oh yeah, Josh. Do you want to summarize, and we wrote this up and send it to the DC, but do you want to summarize where you found problems with this particular proposal, not the general concept of steering committees but the particular steering committee proposal being made. So, I think Alexis, I just most of the things that I was going to comment on. It's hard to do that right now. So, one thing that I was thinking about was, like, how do we set up like a progression where the project might start the way, you know, Alexis laid out, for example, right. How do we, over a period of time, maybe they start getting attracted, attracting more contributors from different companies, how do we get them to progress. It's almost like in a contributor ladder in Kubernetes is for getting contributors to go where we want them to go. So this would be like a ladder for how do we get projects to go from like, you know, to a better stage than or aspire to something more, you know, so that that is the kind of thing that I was looking for. And, you know, because I don't want people to say okay I'm going to pick this I'm going to stick to it and I'm not I'm going to stay with it like so they should be a life cycle for things progressing forward. In terms of what the people in the project can aspire to and the people looking at it from outside can aspire to as well. Does that help Alexis Josh. Yeah, the other thing we discussed is, there's a huge difference between a steering committee that exists because these people are actually leaders of the project. And a steering committee that's been imposed by the CNCF where members of the steering committee are not necessarily otherwise involved in the project. And we felt that the second kind of steering committee would be completely ineffective in resolving any issues around multiple organizations ability to participate in the project. And, you know, so what we actually drafted and have not submitted against the CNCF is to have a more general sort of conception of project leadership. Regardless of where that leadership resides, you know, sometimes it's just the group of maintainers on the core module sometimes it's technical to see sometimes it's a steering committee. And that's where it's important to have multi organizational representation of some kind. The, because I certainly agree with Alexis that you know the term maintainer within the CNCF concept is extremely loosely defined. And, and even if I look at a couple of our projects getting down to trying to tell the projects to reword how they define their own contributors which is really not where we want to be the. So, when we raise some objections to Alexis's actual full proposal it had to do with, there was some conception in there of having a steering committee that would actually be assigned by the TOC, instead of coming from within the project. And importantly that that steering committee wouldn't necessarily actually be project leadership. Because down there because when you say that you just said this again, that if there was a conflict between the steering committee and the people with merge rights on the project that the steering committee still wouldn't be able to do anything about it they would have to take it to the TOC. Whereas if you look at other projects like we just went through this long process of revising the steering committee for Knative, and the steering committee actually has the rights to tell people to do things. Instead of just being there and serve an advisory capacity. Although I think there is some benefit in having a group of people who are in some way more closely involved with the project, who can serve as some kind of intermediary or sounding board between the people who have a concern and taking something to the TOC. I mean, ideally, things get raised. But the TOC is ultimately there to try and smooth over and help resolve issues that might come up like that. But we're not involved in every project day today and a steering could be more knowledgeable about the actual operation of that project. I don't think that the steering committee would be welcomed at all by the maintainers if it was imposed from above. The steering committee was a group of random folks who, you know, it's like it's the classic kind of architect astronaut problem. And I also, and I also believe that the NTS existence, which happily we managed to fend off. There was an early desire for sponsors who paid for membership to form essentially groups of people who wrote product requirements documents which would then be sort of imposed on the projects and, you know, I had to sort of fight against this because it was sort of going to break the wheel of the poor people working on the projects have this sort of thing going on. And I think it's important to consider for those things just to service naturally through the community, which in fact they do in most of the projects. So, I believe the steering committee, if it includes and users and people who do other non coding activities should it should arise naturally and organically from the community itself. Who are around the project and I pointed Kubernetes as a large scale example of such a thing. So quite how this has been achieved it's to the credit of those involved, but certainly there are all sorts of interesting people who don't all right Kubernetes core code, who seem to be welcome included, and have surfaced through the system in a good way so let's try and capture some of that thinking. If we come up with a steering committee idea for smaller projects. To jump in here on this I think there's an important element to you brought up that happened in Kubernetes right. You saw people who chopped wood carried water did work. It's not an advisory group or people who have opinions on what a project should be that got involved in the steering committee model, or even got involved in things like say docs or other things that aren't working on core code. It's people who ended up chopping wood and carrying water, and being involved in the day to day. They didn't show up for meetings that didn't show up with ideas of what other people should do. They showed up and they did things and they earned respect that way. And I think that in any steering committee model needs to be there, or the people who are contributing code the people who are around them aren't going to have that same level of respect. They're going to want to listen to them. And it's going to create a, well, not a great community. And then I think the other thing to think about here is lots of people have opinions on what a project should be. And it's also important to say, no, that's not what this project is. That's a great place for this other project, or that's a great place to create a new project to solve that problem. And as somebody who's worked to maintain things, as a Kubernetes sig chair and on helm and with different things, what I've learned is lots of people have opinions on what you should do. And if you go down all of those things, it's going to be the death of a million paper cuts because you're getting outside of your core thing. And so whoever's on that steering committee also needs to be of, here's what this project is here for. And kind of hears its boundaries. And if somebody wants to go in a direction that's different from those boundaries. It's a great place to encourage something new or encourage the use of something else that's complimentary, rather than try to grow to be all of the things. And I think some of the most successful projects we have have done that and you know in Kubernetes lots of times they say, we're not adding new controllers to core, but you can extend core to create your own because that's not us. We're ending our boundary here, but we're giving you a plans to a place to go further. And I think a steering committee needs to have the knowledge and we're worth all to do that as well in any model. I think Jim says his hands up so polite. So I'm going to point to you next. So I don't want to talk about Kubernetes, but I do want to talk about turning the view from the solution to the problem. And the problem is what can end users of a project expect from the project, right? How can we surface the information on how the governance works or how do we give them out at one glance that, look, this is a project that works this way, right? So one of the ideas that we had been throwing around in the governance subgroup was, do you want to talk about it, Josh? The tags? So badges, yeah. We're still not, we still haven't finished that proposal though, which I need to ping you about. So, yeah. The short version of it is, like, so the TOC can apply badges to projects and the badges can give some information about how the project works or what state it is in. We can include all the stuff that we already have, like incubating levels and whatnot, right? But then we can also have additional badges based on different criteria and within each, like, groups of badges, there'll be, like, a progression that I was talking about before, right? So we kind of, like, give guidance to the project saying, okay, go from, you may be starting with this set of badges, but then this is what you need to aspire to and you can earn the badges as you go along, right? And then this is, so when the TOC does annual reviews or whenever it talks to the different projects, then the TOC can say, oh, now looks like we can call them, like, whatever, multi-vendor or whatever, right? So, and they go from a single-vendor to multi-vendor. So the end users of the project, when they come to a project and they look at it, they'll say, oh, okay, I know what to expect from this project. This is the set of things. So that was the kind of idea that we were chewing on, but we haven't finished it yet. So I would like to support that idea, but I think it's an overlay to all of this. So I believe that, funnily enough, I discussed a very similar concept with Abby when she was running Cloud Foundry. The end users would love to know for specific features how many vendors they can get support from. And we could have a whole completely different hierarchy for graduated projects of commercial badging, you know, bronze, silver and gold, reflecting that your bronze project means you can only buy things from one vendor. Silver means you can buy from more than one vendor and gold, you know, there's lots of vendors or something like that would be pretty cool because then you're sort of making it into a business thing. And end users can then express their preferences in business ways. I think for graduation. This should be about governance and making sure that the project is well looked after has good mechanism with complaints and error handling and such like in a way that the TOC can provide a blessing for and support to without creating a administrative burden for itself. And in terms of how it how do you get people going. There is one example of this out there which is the up bound. I think we just got a thing for their cross cloud project I think which is quite formalized worth having a look at the prior arts but you know there might be others out there that we can take as a starting point I believe Colin wants to say something. Yeah, thanks Alexis and by the way thanks for all the work on the steering committee doc that was those really good stuff. And we're kind of dancing around this but and Alexis you started talking about this. What does the CNCF wish to convey with graduated status to the users. I think it's about being stable here to stay. And people can make. If you're if you're a big it shop. You can basically put your money behind these projects. That's what it really comes down to I think I know that there are other people in the world and we should think about them too. But ultimately I think the people who are really paying close to this attention to this are folks making big risky bets on the technology. And they should make sure they understand that the technology is is relatively likely to continue to exist. And it's being looked after by the CNCF and the TOC to keep it on an even keel to keep it moving forward. Now that doesn't mean that there is impossible for a project to run a ground but I think it should be a lot harder by the time it gets to graduation. I think we've used quite a lot of language around risk. You know, in cube con discussions presentations for example at graduation the risk sufficiently low that it's fine for basically mass adoption. Yeah, the, I'd like to talk about another aspect about risk just because this is something that has cropped up. And for me recently in projects outside of the CNCF, which has to do with vendor risk as well. So, I work at a vendor that often decides to participate in open source projects that were started by other companies, and to incorporate those into our stack. We incorporate a project into our stack one of the things that we want to know is that the, you know, other folks involved in the project are not going to change that project in a way that breaks our stack. And the best way for us to ensure that is to ensure that we have some kind of voice in how the project is run. And I think this really needs to be a critical part of how the CNCF looks at the multi organizational requirement, as in, if a project gets to graduated, and at that point, it is still run entirely by one organization has the ability to break compatibility with other projects and with other products. Through an internal process, right, they make a corporate strategy decision, and it breaks everybody else's stuff, then that's kind of a major problem. And I'm not talking about, you know, other vendors getting to say how the project is run I'm talking about other vendors who want to put people on the project to make sure that it maintains compatibility with their products, and are prevented from doing so. And we would like to think no one would do that, but I can tell you from other outside CNCF projects I wouldn't name this happens. Can I add something here. So, I think if we peel this back to the fundamental problems that Alexis laid out. I think one is ensuring that end user voices are heard on the project even once the project is graduated and two is ensuring that a given project is not at the whim of a single company in terms of longevity, in terms of kind of what the project is implementing and that kind of reflects itself in that making sure that they're building something that end users want. And I think both of those problems are very legitimate and ones that the TOC should look to resolve. I think the problem I see with the steering committee solution is that it's an imperfect solution for both of those problems. If we talk about maintainer or we're calling it multi organizational, I guess diversity. The problem with a steering committee approach is that, you know, what we're trying to address is, you have a project that is effectively, you know all the maintainers are from a single company. And that is problematic so to address that we're saying let's, let's put in a steering committee. And the steering committee could be made up of folks that are from other organization potentially end users and not completely unrelated to the project. And the question comes down to how do you maintain kind of the relationship between the maintainers and this committee. In general, I think what we've tried to do with Kubernetes is maintain a strict wall between the folks who make technical decisions and the steering committee. We've said that the steering committee does not influence technical decisions and the only way that you get to make technical decisions or become a technical leader is through contributions and I think the way Matt described it was lots of chopping wood and carrying water. And so that's something I think we would like to maintain. But we're kind of, it's, it's a, we're in a tough spot right we want this multi organizational kind of cooperation and maintainership. But at the same time, we have very good projects that don't have this so we're kind of struggling to find a governance model that would allow us to have have both effectively. And so I don't know a steering committee could work I'm not sure it's a perfect way to be able to address that issue and then going back to the second issue of listening to end users and ensuring that that feedback is incorporated back into the project roadmap. You know, a steering committee is made up of a fixed set of folks. It may be that today you have users A, B and C, but in the future you may have D, E and F. Right. Right, right. Otherwise they will die. And ideally, you know, if we have things like surveys or, or I think the idea of an evolving or dynamic group of end users who come together periodically would be very interesting. So I think what I'm getting at in this long winded way is that I completely agree with the problem set I think what I'm concerned about is dictating a very kind of narrow solution from the TOC. Instead what I'd like to see is, sorry, I just wanted to complete my thought. What I'd like to see is the TOC would instead of dictating a solution would instead dictate just the problem statement in saying that hey, as a project that is going to be a solution, you must provide two things. One is a longevity plan, which means if the one company behind this project ends up disappearing, how do you ensure longevity? And so then it falls in the project to figure out, well, how that's possible. And the same thing with user feedback, it's give us a plan for how you plan to incorporate user feedback. And the TOC enforcing that if we become kind of a hey, you tell us what works for you. And the TOC can determine whether that works or not. I really like. I think that's a great formulation of one of my concerns through the process of discussing this with everybody has been to focus on outcomes not not not on the means for getting things. I'm just indicating that the TOC must be convinced of the longevity and fairness of the roadmap would be great. And then individual projects can solve that in different ways. We're not trying to mandate a steering committee. It's one potential solution to the roadmap problem and possibly might help with the other problem too. But it's not by any means the only solution and it may not be to everybody's liking. So that was the thought. But I really like your formulation. Thank you. I think Alex has his hand up Alex. Yeah, I just I just wanted to sort of summarize something small. So if I take this back down to sort of the core, I guess what we're looking to do is to have graduated projects that are dependable long lasting etc. You know, as as as Alexis said their projects that after due diligence and after that stamp of approval from the TOC that companies can depend on that companies can put into production right it's it's it's that definition. Yes, what we're trying to say is that in order for those projects to be dependable and long lasting, they have to have user input and they have to have that roadmap and they have to have, you know, a dependable future. Probably multiple ways of ensuring that happening and having and we probably I guess the CNCF should be flexible. Having multiple containers could be one way of doing it having a steering committee could be another way of doing it. But, you know, as sad said, there might be there might be other ways of doing that as well. And yet, I can't help thinking that we should still have some high level guidance of, you know, what is a good idea and what isn't a good idea or what's worked and what hasn't worked because I kind of feel that otherwise we're going to end up in circular loops every time we do a due diligence on one of these projects and it becomes a very subjective decision. So, you know, a steering committee could be a good idea and it could be a way of ensuring longevity multiple maintainers could be. Of course, you can always argue that either of those things could not necessarily ensure the longevity or the or the roadmap or, you know, because some there are definitely projects with multiple maintainers that have had those sort of issues to So we probably should have maybe a handful or one or two or three methods that the TLC probably says, look, these are things that we can recommend. But yes, ultimately, it's up to the project to prove it, but I kind of feel if we don't have any guidelines at all, and just focus on the outcome that then we end up with a very, very subjective decision process. But I suggest we do three things. One, kind of document and agree to the outcomes we want first. Right. Let's just start there rather than the model of how you do it. And then the second part is for each of those outcomes document hopefully two or more patterns that can be used to solve for that outcome so people can see there's different ways of doing it. And then after all of that take to maybe a few different projects that do their governance slightly different and point people to these as examples that they could use as starting points, if they wanted to understand how this work as a whole. And then you get your outcomes you get a general set of patterns people can look to and hopefully understanding of why these patterns work and take them from successful projects. And then because one of the things that I've been asked by several sandbox projects lately is, I need to go do a governance where can I start. And of course you tell them go look at this project or that project, but they also want to understand why and what patterns. And so by pointing them at some projects that have solved for it. And then you also give them a good starting point. I think if you have those three things, it would help us get past these hurdle, without recommending just one way to do things. Having a couple. Yes. I'm just reading a couple of comments on the chat. So we're having a boss, I guess it crossed my mind that we were talking about one of the problems being user feedback or input onto roadmap. And you can see arguments both ways for whether a single vendor maintained project should also be influenced by other vendors. I think Josh is kind of nailed it when he said it's not feedback there as contributions that we would expect a well governed project to accept contributions from other vendors, even if those vendors are competitors to the single vendor who is the main maintainer of that project. I guess that's one thing that a steering committee model can allow you know if you have multiple maintainers that also, you know, you want to prevent the veto from a single vendor. And just one of the simple ways to do that is whoever your top body of maintainers are. Don't let one company in a graduated company, have a majority of those maintainers. Right, because then you're you're you're forced to have at least three different organizations with maintainers, and they have to coalesce in order to do that. So if there is a pattern, you could say, you know, no one vendor has so control of the project. A pattern is your top governing body. No one company can employ a majority of those maintainers at the top level. Right. And then you could point to a couple of projects helm and Kubernetes that already do this and they do it in slightly different ways. Right. And so there you've kind of got your stepping stone but it starts with that criteria. And I think that's why we've up until this point had that definition of multiple maintainers and not wanting to see a single maintainer having control over the project. I guess what we're now saying is code committers are not the only body that can be a another level of body. And we're saying they don't make technical decisions, but they are a body to whom people can bring complaints if they believe. I guess that's actually part of the. That's not the problem statement right so we, I think Sal meant a very good point about saying here are the two problems we need your governance model to solve longevity and let's say input to the roadmap. So Liz, I think one out one one artifact that could be created by a steering committee is a roadmap. I'm not sure this is the right thing. Okay, brain storming live here. But, you know, a steering committee could produce a three month roadmap every three months that could be a recommendation. And that reflects that it's taking input from end users on high level direction of the project. I think that would go a very long way to dealing with this issue. I mean I would love it if everybody can be like Kubernetes but they may need to go through several stages to get there. And this is an interim stage, just a thought. Josh, do you have your hand up. Yeah, so to do things here, one is, you know, in a comment for a sort of sods thing about outcomes and that sort of thing. One of the things we could look at, and I'm going to speak here for contributor strategy is asking projects to specifically have a plan for recruiting and advancing contributors. I mean, at least from my perspective when I'm evaluating a project, even if the project currently all of their senior maintainers work for one organization. If they actually have a published contributor ladder that demonstrates, you know, a clear way for any contributor regardless of who they work for to advance to senior maintainers status. Then that's a very different situation from a project where all the senior maintainers work for one organization and they don't have that the such thing number one. The other thing I want to remind people of and I address this in the TOC mailing list is well it's important that whatever structures we have are capable of taking complaints. We can't rely on complaints as a way of determining whether something is wrong. Again, speaking for somebody who works for a publicly traded company. I can't simply as a contributor bring a complaint about a project run by another company. That has to like go through my executive management. And so unless the problem is really disastrously serious I'm not going to do it. And I think a lot of other contributors from the CNC ecosystem are in the same situation. So, I mean we do need to deal with complaints but that's not a way to know whether or not something is wrong. And I like what you said that with the whole contributor ladder thing. What's been said there because it's not just that somebody who approaches the project knows how to get up to go up the ladder to become a maintainer. That means those people who maintain it have had to think about how do they bring in new people and how does that process work for lots of maintainers who just want to go sling code work on things that may be great at getting feedback. That whole world of mentoring bringing in other people is foreign to them and I think for a lot of the folks are going to do that. They're actually going to struggle with this and giving them. And people who can help them figure this out and understand it and maybe mentor them when they start going from other projects who already know how to do this would be really useful and kind of a benefit of the CNC F, because right now a lot of project struggle to bring in new people, but yet they don't know how. And coming up with that plan and how and thinking it through is useful for everybody involved, not just people who want to become maintainers. That's been a big challenge that I've seen with smaller companies like you know boy and mentioned this that you know somebody comes along contributes for a year. And then for some reason they disappear. So you need a sort of critical mass of other people in order for this to work. I'm trying to see a Paris wants to speak out loud. The, I mean that's pretty much why we started sake contributor strategy, because we saw that a lot of projects needed help with these things. Ignore my ignore my work from head head. Yeah, so yeah this is the exact stuff that we're talking about in contributor strategy and like I think ultimately what you're saying is like we're dancing around this notion of community management and maintainers doing community management. And I really think that there needs to be a community management strategy at the time of graduation and that's sort of hand in hand with what I think sad was saying as well with like some kind of strategy on how you're going to get to where you need to go. And especially with how are you going to take care of your people, because there's multiple ways to do that as we see with multiple projects there's things that deal with contributors working groups that deal with outreach. Full time community managers part time community managers, but in my research that hopefully I can present at some point when life isn't weird. My research is suggesting that the open source projects that have that kind of a strategy are longer lasting projects and projects that are more transparent and projects that are also aligned with urban governance. So, I think that's one of the crux of the issues at hand is we have maintainers. We have maintainers burning out and working on 800 million things and not necessarily thinking about the long term strategy and the long term is community management. Colin, or someone else representing one of the those. Let's, let's say, I don't mean this pejoratively at all but let's say a single vendor project. How do you feel about this idea of contributed matters and community management strategy. Yeah, I'll share our experience, and then maybe that can inform from the discussion. We have about 90 repos in under nats. And there's there's only two that were really, you know, not to use inflammatory language flag this problematic by the TOC, and they were our server repos. So, if you look at maintainer mixes of whole across nets were actually pretty good in these two repositories of server repositories. And that's, that's because we we know the code we have efficacy in solving problems and responding quickly to to bugs. They're very complex. So it's not a weekend project. It's not something somebody can, you know, even come in in a week and learn it takes a dedicated resource. It's a weekend in the egg problem right, we're solving these problems quickly we're moving very quickly the projects moving quickly, but we're doing everything right. So our end users don't see the value in adding a resource to the at least to the servers, they do with clients all the time we get contributions all the time on the client side connectors bridges that sort of stuff. And this is where I think a steering committee would really help us out, because the servers, you know, and one one other comment I'd like to make is, in order to get to be a successful product project, you need to have, you know, solve the market problem, and then listen to your users to continue to evolve and solve that problem. I don't want to argue any any project that's that's has a velocity and gain meaning maintaining and gaining adoption and users and in particular, if their production worthy if they're being used in production, they're doing the right thing and I don't think you should really change much in their process of listening to user requirements. I went off on a little tangent there, you know, back to getting maintainers. We have tried to get maintainers for the servers, and we we have some we have a couple external maintainers. But, you know, again, this is this is an area where we're doing things. We're doing things very good. So people, other end users don't see the need to add maintainers to these particular repositories of our product project. A lot there did I answer your question. Yes I was wondering how you feel about the idea of. If we were to make requiring a contributor strategy to be part of the graduation requirements. The contributor strategy is, you're talking about like the maintainer ladder, how the project and move forward. I don't see a problem with that. Where, where I would be concerned is what happens if, you know, let's say we get somebody that that meets the bar to barely be a, a maintainer to work on the server, right. And then they don't really do much because everything's working. So will that be an issue for graduation. I think what we're saying is if we are changing the requirements so that other governance models, such as steering committee so long as there is some kind of multi organization. Well, actually, so long as it solves the problems that we're identifying which seem to be longevity and community input on the roadmap. You don't have to have walked everybody through the contributor ladder, we're saying you have to have a contributor strategy that means if somebody really wants to get involved in your project, they can see a path to doing that. And that you would accept them if they met that if they follow that path, regardless of what vendor they came from. Absolutely, absolutely. And we're behind the steering committee model we think that would work great for our particular project. So Colin, just do you have you ever had any maintenance who have left Synodia. We have. Have they stayed on as maintainers or does that disqualify them from being maintainer. Oh no, this data. Yeah, so because that's actually I mean historically that's been a good way of. The diversity has increased is for people to move somewhere else and retain their main ownership. Yeah, that's a. Oh God, sorry Colin that I'm sorry Colin and so part of the other thing with the Nats project in synodia is we have had folks that do have a vested interest in Nats they have they know that they've learned that they come to us. And then we hire them. And so now there is no secondary company. Now they're all back to the ISV. So does that mean that we're not allowed to hire people that have this great vested interest in Nats and can work on that. And we have had, you know, people leave and then come back. So it's all a bit muddled when it comes to the experience and intelligence that takes to maintain the Nats servers. Right. I was keen on the model that this hiring thing is just you can't prevent that it's very hard. If you stop people doing that. Yeah, I mean you don't want to stop people doing that that's kind of not the point. What I'm saying is that if people naturally leave that ISV, they don't sort of drop their maintenance ship they can choose to continue being a maintainer even if they move to a different organization. I would consider that to be a healthy thing. Yeah. Yeah, definitely. I mean it's, it's, it's a, you know, it means that people can go somewhere else and contribute with it, perhaps a slightly different perspective or something and things like that. I mean it's, it's definitely been a way in which maintenance diversity has increased in other projects. All right, we're very much getting up to time here. I think this has been really useful. I think the key things that came out that I've noted and I'm sure we'll have more debate on this but there are two problems that I've identified. I think we should absolutely say we require projects to if they have a governance model that addresses longevity and community input to the roadmap, then, you know, any governance model that the TOC believes meets those would solve those problems should be acceptable. I think we're also, I mean, obviously I'm just summarizing we haven't had a vote here but it looks like there's a lot of support for requiring some kind of contributor ladder strategy as a graduation requirement. I think that the steering committee model, I don't think anybody right now is suggesting we should mandate it, but that perhaps a steering committee model could meet those requirements. Did I miss anything particularly critical? Awesome. We are one minute over. Thank you very much particularly Alexis for all the work that you've been putting into thinking about this and presenting it. Thank you to the governance working group folks for all your work on this as well. Thank you. Great. Thanks everyone. Thanks everyone. Bye. Thank you bye.