 Greetings, folks. We'll get started five after meeting notes are in the zoom chat and add your name. Any agenda items. Welcome, we'll get started at five after welcome if you have a topic and feel free to add it to the agenda. Please add your name to the attendee list. We'll get started in about one minute. Welcome. If this is your first time. This is the CNF working group. And meet every week. We meet weekly on Mondays at 1600 UTC or 8am civic. If you have a topic you'd like to discuss you can add it to the meeting notes in the agenda area. And please add your name to the attendee list. You can verbalize if you're having problems us accessing the Google doc I posted that into the zoom chat. Does anyone have anything specific they'd like to go over. I've added some of the pull requests that are open that we could take a look at is my audio coming through. No, I hear you. Oh, thanks. I haven't heard anyone else. There we go. So there's nothing else on here. I'll just move on jump right in the pull request. Some of these are already open. So, I think we might be able to close them out. The first one was around the governance for the voting. And it looks like we've just really quickly think everything may have been addressed here. There's a lot of items that were updated changes. So elections. And this is related to the nominations that are open right now. One year term. Most of it. The changes were around the voting and names. I'm trying to make sure that there was consistent organization company, and it matched other PRs that were in progress. I think that's it. I'm not going to go through the whole thing. Right now. But I think this is the only one open. Ian, are you here. Yes, I am. Yeah. All right. Are you good with what Dylan said here, as far as kind of leaving it open, I guess, to self policing, there is another comment and a totally different PR or a different PR but related about community being able to come in and vote on something that's in a disagreement. But this is the last conversation that's open on this one. Yeah, I mean, fine. It's not particularly a big concern. I don't think. Not today. All right. Well, the rest is approved. So I'm going to go ahead and reach that. I'm going to swap these to match voting. Oh, I did. I did out of our, let's say max representation. All right. What was the answer on does red hat and IBM count as one company. That was inside. I saw it somewhere else. I would hope the answer is trying to see. And I'm not finding the response from bill. But there's a, oh, here it is. So there's already a section that we've in, in the, in the, in this PR that it addresses if there's a problem with it. So the company membership and subsidiaries. Noninvolved members will decide. So I'm not, I'm not sure that's a very good, good answer to be quite honest with you. Okay. As far as I know, IBM and red hat are separately members of CNCF. Correct. And while red hat may be a subsidiary of IBM. We are managed as a separate company. So for noninvolved members to decide that just because red hat is owned by IBM doesn't seem like a very proper. You know, we pay CNCF membership separately, et cetera. If we were the same company, why would we need two different CNCF memberships. So I think it would be represent, let's thank representation within this group. So this group. And we're saying, ideally we have a large number of people, a large number of companies and organizations that are, that are all represented. So if, if we said from the technical or legal standpoint, maybe there is an association and all the other members and in the CNF working group felt like there was unfair representation. I think that's where this goes in. Right now we're not saying it's a problem for. So red hat and IBM could have membership and both could have tech leads. And that's dominated by both. And there was only representation from those. That's the only time this would come into play. And it's also something where everyone could go, well, we're happy with how things are being led. Right, but from a charter perspective, that's actually not how that reads your description is fine. It just says in the event of a question of company membership. So therefore any time somebody could raise an issue of company membership and this up as an issue doesn't have to be, you know, the scenario you're describing based on how you're, how it's how you just read it or how it reads. Well, I think the point is that this is part of the CNCF charter. It's nothing specific to the, the work group. And cars put something in chat that kind of touches this directly. That's just for the TOC. Yeah, sorry, that's only for TOC agreed. I was going to say that I was speaking on mute. But I just wanted to point out that there is language in there that you could use if you wanted to, because it uses the term group of related companies. But I'll give you, I'll give you another, I'll give you another example for example, from an operator perspective. If Telefonica Spain and Telefonica Brazil had represented representation in the group, they are separate companies that happen to have common ownership, but they operate as separate operating entities. Would that apply to them? Or, you know, Deutsche Telecom and T-Mobile. Or, you know, I mean I can go on and on on the list, right? I think the spirit of this though is, is primarily to prevent things like, like it's easy to create a C-corp that is a wholly owned subsidiary. And if you wanted to, to basically try to overwhelm a board or similar, you could easily establish a wide number of these things and then say, look, every single one of them is a separate entity. I need, I need to be able to put a person in it for each one because I paid the memberships on each. On the flip side, you also have things like to give one another good example on the other end of the spectrum was the EMC and VMware, two separate companies, one wholly owned by the other. And, but operated and managed, it's two completely separate companies. So I think there's a very wide diversity. Exactly. So I think this one is, we need to be a little bit careful with this one because we could have one or one under the other end of the spectrum quite easily where one, where one of them is acting in good faith. Like I think the, the examples you gave would be operating in good faith, but simultaneously, if there was a thing where you had, where the votes significantly mattered across the industry, it's easy for an organization to set up and, and subvert some of, some of these controls basically by creating a whole bunch of subsidiaries as well. So I think the language has been in place to, to help act as a trigger to prevent that kind of, that kind of thing. So it could be, it could be based upon my, my recommendation is then perhaps the wording remain, but it'd be done with, but we, we enforce it based upon the, the spirit of what it is as opposed to the, the actual, the actual letter. And I know that's not the nicest way to approach it, but I, but I think it's something that, like it's something we can't necessarily ignore, but at the same time it's something that we, we do want to allow players in good faith to, to not be harmed by, by such a thing. And I don't know a good way to, to manage that particular expectation with, with just, with a style of wording. Real quick too, can we kind of discuss what this would impact? Cause from a chair position, if there's only three chairs and one is from the community, one is from a service provider, one is from industry, then you can't stack it because you're only going to be able to like represent, you can't have someone from red hat and IBM simultaneously maintain the vendor chair slot, right? So it probably more gets into when the community as a whole is voting in how that's shaking out. So then the question is, is, um, what type of proliferation is allowed within like the community voting? Well, to be clear, the chairs are not from service providers and from industry. They're defined by what you do, not where you come from. So if you're a service provider who writes your own CNFs, you have the option of putting your name up for two chairs. And since we all use Kubernetes, then you have the option for putting your name up for all three. The question is probably more about the consequences of what you're talking about. If red hat and IBM were considered to be one company, then they would only get what I think we said, like 30% of tech leads, didn't we? Or something like that. It's, you know, not as consequential as it sounds for them to be considered one entity. Based on that, I guess I didn't quite understood, understand what I was reading as far as like representation for chairs because if I just say I'm a CNF vendor now and try to stack things and I've got Kubernetes like, okay, that's weird. So then I do think it's, there needs to be a hard requirement that like one company is only allowed to own one chair. And then I hear where Shane's coming from, but I would worry that like, you know, top level executives could come down and try to steer things. And even if you're run as a separate company, you could still have pressure, financial pressure, executive pressure, et cetera, coming from on high to try to force an agenda into this group. I mean, let's, I think we're being unrealistic about the impact of this group if you're talking about, you know, to that degree, right? I mean, what, I mean, it is what it is. If the group wants to do it that way, I just think it unfairly impacts people who have, you know, because IBM bought Red Hat. Now Red Hat is no longer a first class citizen. Yeah, I don't think I have a clean answer for this, Shane. Like I said, my worry is, is, you know, Red Hat wants to push TOSCA or IBM wants to push TOSCA. Other groups don't. And, you know, IBM says everybody on IBM side, everybody on the Red Hat side pushed TOSCA. I'm not saying I am for or against TOSCA by the way. So please don't come at me with pitchforks. I'm just using it as examples like we're trying to like say like this is going to become something that we're going to try to proliferate across the industry as a best practice. I mean, I think at least on my side, one of our big fears is that, you know, a single vendor would come in because they have the capital and try to dominate. I've seen it in other open source groups where like, you know, a vendor specific model is chosen as the quote unquote open model just because they have the staffing and the resources to flood a group and make it happen. And you're probably right that like this is getting a little bit overzealous at this point and whatnot. But I don't know. I have seen it happen a bunch in LF networking. So it does concern me a little. Yeah, I wish IBM and Red Hat were that coordinated to be quite honest with you. I'll just remind you that the meeting is recorded. Well, I'll say that publicly. I'm okay with that. Yeah, it's totally fine to say that publicly. We really are red hat has its own interests. And they, they can conflict. Maybe red hat and IBM aren't the best example of this. Actually, I think we were focusing on that particular duo, but that is a duo that I don't think will be problematic in that respect. I think we're more thinking about the examples, the chain set of telco subsidiaries and. Yeah. Yeah. I mean, taking it away from red hat and, and, and, and IBM, I can tell you from, you know, working in the telco space, for example, I mean, the telephonic example, I think is actually perfect because while they share a corporate structure, they operate independently and have historically been very vocal about operating independently and having different opinions. In fact have fought against each other in standards bodies. And not personally conflicted. Example. Okay, so one thing to step back is this isn't something that we came up with for the CNF working group just out of thin air. If you want to be involved in the Kubernetes community, or in many CNCF communities, you're going to see this same representation. So right now we're trying to one of the things that we're trying to do was align ourselves with what the other groups are going are already doing. So why don't you see that? Because the language here is different than what's being proposed. And. What are you looking at like the. I mean, look at look at our language. It's in the PR and look at this language and they're not the same. They're slightly different. Okay, let me see the, it's the difference on the companies. Yeah. Percentage of companies makes representations, but what we want is like subsidiaries. That's the problem. And there's no language here about subsidiaries. In the event of question of company membership. So this is right out of that. Well, no. It's evaluating the independence of the subsidiary, not whether or not the subsidiary should have a vote. Right. It's very different actually. So this is, if there's a need to, to evaluate, and this is sort of what somebody else was mentioning, right? Is that what we need to evaluate is the independence. Of the subsidiary, not the organization gets to the, the group gets to decide that that doesn't get, that there's a conflict and doesn't get a vote. It's, is the, you know. So I think it's a merger of this. This is this. Kubernetes staring and another Kubernetes and the TOC docs. And one of the, I guess one of the main thing is going to be the CNCF TOC as. We, we need to have things aligned for the TOC to. It all has to go under that umbrella. Well, the TOC has very specific requirements to be members of the TOC. Right. It's very different than a working group. As is a steering committee is very different than a working group. So the question would be, what does this look language look like for other CNCF working groups? Maybe one observation here. Because we are talking about representation and potential influence over something. And since the working group is neither the steering body nor decision-making body. It produces actually the results, the best practices out of which each one has to be proven in practice and elaborated by the real value. Some kind of agenda goes through that easily because there will be debates and discussions. So we do not have a voting on, at least we are not here discussing the voting on what best practice is a good or not. And this is the main influence and I may outcome of the group that might have an impact in a broader community. So if somebody is a chair or lead, I honestly have a difficulty to track what would be that even if all of that is kind of rigged, at the end somebody rigs the system, what would be the influence of it? And I think maybe we are taking too much of focus on how the process of getting to the tech leads and then chairs is going because they will at the end, the best practices will work, will be adopted if they are really best and will not be adopted if they are not. Nobody will follow something just because it's somebody's agenda. I have the same premise, although I may come to a different conclusion, which is this particular group will very likely become a feeder into other groups. And so things like the OVP verification program, which I believe was merged into Anoket for credentialing and other similar types of things that eventually may become standards will very likely pull from groups like this. And so this is a very different structure from, let's say, CNCF SIG network or CNCF SIG storage where they may discuss things and try to push things forward, but I don't think those are going into things that can necessarily become standards where, and one of the reasons why it's important is because you have to look at how the structure it is with telecom and service providers where there are multiple companies that literally have a requirement that says you cannot deploy something unless there's some standard that you're adhering to that's industry-wide. And my concern would be that if in the short term, it doesn't matter in the long term, that if this becomes a feeder into the standards that this will be seen as a target for trying to gain undue influence along those particular standards. But even if they pull from us, even if Aniket pulls from us, it's going to be re-debated using that decision framework that they have. So it's not like they're going to pull from us and just adopt it without additional debate. I agree, but it's also in terms of defending. And I think we need a case-by-case basis on something like this. I'm much more comfortable with IBM and Red Hat than I would be if you had some company that made subsidiaries that were designed specifically to influence a group. And so I think that there needs to be a way to differentiate both of them. The steering committee, if you read the language in the steering committee, it's slightly different than ours. What they say is that the organization or the rest of the group will debate the independence or discuss the independence of the subsidiary, right? So I mean, you have to look at our language versus what's in the steering committee language. There's a slight difference in how it's worded. I want to add some of my own two cents here. So I agree with book basically, you know, we're not a standard's body here. So if we don't have a good reputation and good legitimacy, then people will just not adopt us. You know, we're all spending a lot of man hours here on this group and people will just leave if the group is seen as somehow dominated by a specific company and not open enough. So this is an important discussion because there is a lot of stake here. This is the reputation that we're trying to give to this group and to make it appear as legitimate as possible. So, you know, in the end, we can also not vote. People can vote against something that seems to be a takeover of a specific company or of a specific agenda. Yeah, that's why I mentioned like short term, I don't think it matters long term. I think it could matter a lot is because once it's developed that reputation and then it's easy to try to push these type of things forward. I do think that having the, and that's even on the community side, like you could have a company that literally says, you know what, I'm going to bring in 100 people here so they can all vote on this particular area and get our people in and then push things forward from, push our agenda from that moment on forward. And then we'll do the same thing with the thing above that as well within the standards and then we'll get our products into the standards themselves at the expense of others. And so, I think there are some controls that are present in some of the standards body above now because these things have happened in the past. And so there have been things put in place to help defend against them. And so, I don't think it's going to, I think it's not going to be important in the short term, but it is something that we should be mindful of moving forward if this particular working group gains the type of influence that it wants to have in the long run. Can I play devil's advocate for a second, too, and just post a counter argument? One thing I don't want us to like lose sight of is participation is super important. And if we kind of isolate certain companies because of like mergers and this and that, participation potentially drops. Outside of the rare extreme case, too, where like a company spends up multiple subsidiaries to try to like swing a vote, typically there's not going to be like, you know, five companies under one umbrella that we would have to worry about where they have that big of an impact. It's probably going to be something like a Dell and VMware, a Red Hat and an IBM. I mean, is that one vote? Because this now major corporate entity has two. My big fear is, and this is something that service providers on my side, this is what we're guilty of or notorious for doing, is if there isn't a cap on a single company's vote, we'll send 40, 50 people to an organization until we get what we want. We'll just keep throwing bodies at it because we're huge. Jeff, to your point, soft bank owns Sprint. Does that mean of soft bank? I put that, I use that example in the chat. I don't know if you saw it. And like I said, soft bank is weird, right? Because soft bank doesn't typically get in to, I mean, they're one of the few examples where they have the capital to actually like make an army of subsidiaries. I mean, soft bank owns tons and tons and tons of stuff. They also though don't typically, they're usually like interested in equity, right? Like owning a stake in a company, getting a return. It's way more like investment banking than it is. I'm going to merge tech companies and try to lead them. So I mean, I think, Shane, you mentioned that we should have something specific to subsidiaries to make sure that people aren't trying to like cheat the system. But I mean, I would ask this group, you know, it evokes comment about like, you know, how severe is this? Is if a company, you know, two companies merge and now there's a potential that two votes would swing in one company's favor. Does that have the impact of say something like, you know, a charter or an AT&T coming with, you know, 200 developers from inside our CTO office, you know, in every single one of us casting a vote for, you know, what we think is best for charter or AT&T. I want to go back to what Tal said. I think there's a almost a self-destructive or self-regulating factor. If 40 people from charter will come in and influence this group, I guess we will all step away from this group and take our business elsewhere or our knowledge elsewhere. So I think there is reason for concern, but I think at this time we prefer to encourage participation. And if down the road we get the situation, or one company throws in dozens of people, I think at that time this group will just lose its legitimacy. So that would be the end of the group. So you shouldn't worry about it too much. Yeah, I would agree with that actually because at the end the valuable outcome is in the concrete recommendations, practices, or models that we would propose. And if there are 40 people from charter coming in, each one of them will then need to say something and say something differently, not just to repeat the things. It's not because of so many people have joined that everybody will be overwhelmed. That's why I'm missing a bit of point why that matters at this stage for this type of working group setup, even long-term, honestly speaking. I'll add even more to that. I think if this group is going to be succeed and have some legitimacy, it will happen by consensus. That is, if we ever get to a point where we're really fighting over something and there are two sides to it, unless we find a way to compromise, I mean this will reflect the technical problems in the community, right? So in the end this is a place where we're all coming together from different perspectives, exactly in order to be able to work together. So it's almost a circular argument here. This group will succeed only in so far as we don't really fight too much or find a way really to find solutions to arguments, right? We want solutions. That's why we're here. So right now, do we have a real, do we have a problem right now where we have representation that's going to go over one third or is this more theoretically we could have a problem in the future? I haven't seen it yet in the nominations or anything else because one of the, I think the biggest point that I've heard was you put forward on best practices. This does not have to do with best practices. Tech leads and chairs do not get to pick what a best practice is or what's adopted by the group. So this is only about voting in the tech leads and chairs. That's all this representation portion is. And then how many from a particular company can be in there? So then in fact, Taylor, the real concern would be in the voting on best practices, not even here. Yeah. This doesn't have to do with that. So why do we need any of this at all? I mean, wouldn't the idea be that some tech leads are voted in? The real issue is in how the voting takes place, not in who the tech leads or chairs are. So instead of putting a limitation on who the tech leads or chairs are, we have to figure out how we're going to handle 40 people from one organization being involved in that organization having more power to vote than others, not who the people are and who the roles are. And other places in CNCF are handled by the fact that there's only one vote per CNCF membership. Here we're saying that anybody who's involved gets a vote. And that in and of itself creates a different problem. So I don't think we have a problem with limiting co-chairs from one company organization to one per company or tech leads to one third, because if people think there's a conflict of interest, they'll handle that in the voting process. But how do we prevent one company from having more votes than another by just simply overwhelming the workgroup? So if Cisco wants to come in and come up with a best practice for how XYZ problem is solved, none of this solves that. And that's actually a bigger problem. There is some language around that that was already, I guess, starting in the voting PR, but we don't have all of that in place yet. So it will be a similar thing with regard to representation so that you're, if we're saying best practice, then we're going to have to have similar roles on representation from a group. But we don't have to try to address that right now. Well, we do. We do. We're voting for tech leads and voting for pairs. And I'm personally way less comfortable with having, let's say if you took the extreme end of it, 100% of tech leads being from the same company. I'm way more uncomfortable with that than I would be with most of the people who were voting for one company to determine who those tech leads were. I think part of this though is that I really like the wording that they have in Kubernetes. Like they, from the tech lead side, it's that there's a measure there to try to work out the independence of the organizations. And I think that's really the key behind it because this is something that you cannot resolve just with verbiage. There's a spirit of language matters. Where is, where is, is there any documentation on that project? Yeah, it was, it was on the thing that was, it was on this, the, the scene. I think it was. Yeah. I'm confused in this. I'm confused why you'd be less concerned with the people voting for a tech lead than what company the tech lead is from. The reason why is that when, when you have people voting, both of them are concerns, they absolutely are, but when, when you have, if you're voting for a particular lead, there's also, there's, there's two problems that appear. So the first one is that if you have them all in the same company structure, then you have a single chain of command that says, this is how we're going to vote. So as opposed to you have to convince multiple companies, like you still have to try to move towards the same direction. The tech leads aren't making decisions. They're, but they do influence significantly though, people will look up to the tech leads for, for that. So I guess I would tend to disagree with that, right? The voting is done by the group. So why would someone vote for a tech lead if they didn't care, if they didn't think about that they didn't like their approach. Exactly. So what does it matter what company for their from if the majority. I do have an influence on the pull request. I mean, we're still working on this. They got moved into discussion versus, I don't, I don't know if you'll have seen this, but. I guess that's my point. I think we need to resolve some of these other issues before you can put limitations in because they're, they're cascading, right? They're not, this is, we're, we're dealing with these issues in a vacuum, but they, in fact, we don't even, we're, we're saying what the, we're putting in place policies and what tech leads to be from one company, but we don't even have a job description for the tech leads yet. Right. Because we don't know exactly what they're going to, what impact they're going to have. Yeah, we, we have not fully defined what tech leads can do or will do the one area where there's been some discussion is around how do we decide on updates for important things. And probably the two most important are best practices, I'd say, is going to be the most important and then charter updates. So if we want to make changes to the charter, like we're doing right now, then how many approvals do we need to move forward? Part of this is just trying to get pull requests to not sit there forever. But if you look at, but if you look at even at these approvals, right? So for our best practice, even if both tech leads were from the same company, you would still need three other community members. So the issue isn't the tech leads. What if the three community members are from the same company as one of the tech leads? Now you've got four people from. You still don't have representation. Right. Now the, so we, what we don't have in here, and this is again a discussion, not a pull request. We need to add that other Burbage around for these. So how, how much, how do we get a pull request in? Well, it's probably the same thing. We don't want to pull request. I'm sorry, a best practice. We do not want a best practice to be adopted fully and say, this is a best practice at the scene of working group wants to put out in the world and say we all approve it until there's more than one third representation outside of one company. And I would say that that, I mean, we're doing bad if, if we can't get more than one of these groups that we say is problematic. IBM Red Hat. If we only have IBM Red Hat behind one best practice and the rest of the community is against it. But because of the setup, IBM and Red Hat gets to vote it in. That would be a problem. The same as anyone else. Any other group the same. What I observe here is, and probably this adds to the, to the problem of this discussion is that there is a kind of silent equalization between best practice and the standard. And there is a lot of echoes I hear from the standardization by the veterans who did a lot of battles and their relevant concerns. But in this case, I think if we, if we are producing best practices and then assume that there are standards, this will probably not work. So there might be for the same thing, more best practices that will get merged. So even if somebody wants to dominate something with, with whatever, there might be alternative thing that will also be a good practice or best practice. I think it's probably better to live the whole thing for a while and then adapt. See how it works. Then to make it perfect in the, in the beginning. And I think the most important influence here is who holds the keys of, of Github repo. You know, this is the, the, the person who can control the doors to what we are producing. But again, it doesn't even matter who holds the key. Once this group loses, it's legitimacy because there's too much dominance from man company. We're done. We're out of here, but there is no reason for existence of the group. I mean, at the end, that's correct. I fully subscribed to that. At the end, we want to probably live the spirit of, of CNCF and support and then accelerate the user and user driven development. So we need to see who would be the users of the best practices and then what do they have to say on, on what we do. Because by this group saying something, it will not mean that the end users will adopt immediately. So we will be measured here by the adoption and by, by influencing in a positive terms, the community and the broader community to start adopting those practices, to start putting them in the RFPs. So yes, I want that because it makes sense for me and so on. If it goes in the other direction, as you said that the working group will not produce anything useful and then it will not be adopted. I think there is self-regulating mechanism that we need to count on to believe in. I think the problem would come if we got a good reputation and it was subverted for what it's worth. And that's more the issue, right? You're absolutely right. I think it's adoption if this was a lopsided group and more to the point, even if it was a lopsided group, if it came up with best good recommendations, it might still see adoption. But bringing this back to the core of the question, I think what I don't understand from what Shane's saying is the concept and I don't want to go through it because we've got 10 minutes less and this is the only thing we've discussed so far today. But if we could do it in the group, we could do it for the rest of the week. What Shane is worried about in terms of the consequences of IBM plus Red Hat being seen as a single group. Because we had two ways of looking at this in the original discussion and debate and documents. One was one group, one vote, which we pretty much ruled out as a possibility. The other was one group, no more than one third of the representation, which I don't think anyone is reasonably expecting anyone to achieve. So that really would end up ruling out pathological cases. My concern is with the coach. You've got one person from any one company organization. If you vote that IBM and Red Hat are one company or one organization, I can tell you that IBM, what's an IBM's best interest is not necessarily in Red Hat's best interest. So therefore if IBM gets, you know, votes in a coach as a co-chair, nobody from Red Hat could also have a position. Right. And is that the worst thing in the world? From Red Hat's perspective, yes. Right. What about from the community's perspective? That's up to the community. And I would say it's not in the best interest of the community either. But I can't speak for the whole community. And I can tell you, even if you read this language. If IBM and Red Hat somehow ended up with more than one third. And I can tell you, Red Hat's not going to resign because IBM's on, you know, they're not going to resign because they're going to resign. And I think that's the best part. So I guess we need to have that representation. And IBM's not likely to resign because Red Hat now, neither organization holds any positions. So, well, that's, I think, not quite what the next part is. If we had made to vote to have, I guess you're saying resigns. So I don't know. We'd have to have some kind of special election. If possible, the entire organization representation will be removed. Right. There's two parts to that. One is the, are you the same organization? And does it matter where we could say that a member could raise a point of concern that two entities are the same organization based on the reality that there is some cross ownership. And then the community decides whether they want to act upon that or not. So that means that you've got two levels, right? Firstly, there has to be demonstrable relationship. And secondly, there isn't an immediate action just because the relationship exists, which means that IBM and Red Hat could indeed hold two of the three chair positions. If that's what's the most appropriate thing in the community agrees with that, which gets you your get out clause for, it's not just automatically going to happen. The other part is, if we have multiple representation and the concern is raised after the membership is established, then I believe I've seen in some document that's been waived past us today that they come to agree or alternatively one is removed by basically random chance, random choice if it comes down to it, which means that no, you don't lose both of your reps, but you do lose one if the community believes that you're over represented and only if the community believes you're over represented. We could set it up as well. What is the definition of special election in that scenario? Like if it's literally, let's say that three was the limit, but he had five reps due to a merger. And so maybe the special election could literally be among these five people and exclusively these five people, who would the community like to keep involved? Granted, that doesn't solve your problem entirely with what if one side of it ended up being more than the other. I think that's a better answer though, right? So firstly, Shane, if we did those two things, right? Firstly, someone has to raise it as a concern, and then the community gets to decide what the action is. And secondly, that if we are over represented and we need to fix it, then there's a special election. Would you be happy with that? And then everybody else, would we all be happy with that? Would we accept that as part of our charter? More accurately, does anyone have any objections to that wording? Because that will get us, you know, speak now or forever, hold your peace. And any injustice to be clear, I'd be fine with the, it's not automatic, right? The second piece, the special election I'm not as concerned with, but just bringing that in the event of a question to be more definitive where it says, you know, in the second paragraph in the question, in the event of a question to be more definitive that it has to be, somebody has to raise it as a question. Yeah. To me it would solve the issue. Somebody, one person, perhaps, or two people withstanding have to raise it as a question when it is then debated and we decide whether or not as a majority decision to take an action on it. I'm good with that. Thank you. Taylor, how do you feel about writing that language in? I don't see a point in changing the language on the second set. I'm in trying to define what a question is. I think in the event that a member in good standing raises a question. Raises an objection or whatever. An objection, right? Yeah, I'm just saying I don't think that we need to write all that in for this particular part. The other part that you're saying and sounded like your potential, I couldn't quite tell, but it seemed like you were saying to update something in this section or with the wording. Let me work with you offline and provide wording for what I've just said. I think we could do both of those things. I don't think we end up with a charter that's overly more complex or difficult to understand than the one we have right now. I don't think we end up with the worst result than we've got. We're just basically putting stages in place up front rather than having to decide it later on when it's going to be a bit more awkward. Yeah, and I like that it keeps the humans in loop here because that's really key. We cannot determine with verbiage the legal structure of the companies is not well-defined enough to determine is the independent. So you really need somebody to look into it and try to work it out. So defining the trigger to that. And then if it turns out that the two are not independent enough from each other, then there's a path to not remove everyone from that group. But instead to say, look, you still participate, but at the appropriate level so that they're not punished for the merger in that respect. So I think that's a clean path. And I think it addresses Shane's concerns enough that we may be able to proceed and certainly covers my concerns well enough too. I'm mainly concerned with the spirit as you're saying, and Frederick, and then I have a tendency to lean more towards protection of anything getting exploited by overrepresentation. And I would rather have exceptions when required versus trying to go back and stop something if it looks bad. But I'm happy to work with you, Ann, off-line and see if we can get some language that finds a compromise for that. And, you know, we can also change this document in the future. I like to think that everything we do here is a living document. We might be bogged on this too much. I think we all just want to make sure that we're starting off on the right foot here. And everybody feels confident. I feel confident by this discussion itself. It shows that everybody is thinking very deeply about the legitimacy of this group moving forward. And we want it to be influential. I mean, we're spending a lot of effort on this group. So this in fact, this in itself is a reason for optimism. And, you know, if we do get stuck in the future on some hypothetical takeover by one company or the other, I think this wording will be the least of our problems. And I think we're going to have to work it out between us to see how we can keep the group going. I mean, sometimes groups split into two or change of scope or something like that. So in the end, whatever we write here in the paragraph, I don't think it's going to be that important. And yeah, just Taylor, just your point. I tended to tend to agree with you. But when you work for a company like Red Hat, who's just subsidiary of somebody like IBM, it's not IBM and Red Hat. My concern is IBM goes out and buys somebody else. And then Red Hat loses its voice, right? That's my biggest concern. Don't just blame IBM, Shane. You took Coral West from us. I'm just kidding. Fair enough. But I think you understand what I'm saying. I would. So Shane, I guess I what the way I'd lean into this is we're all working in an overwhelming number of groups that are coming in and they're all trying to participate and contribute. And they go, we're all owned by IBM, but we all work independently. I'd love to deal with that problem. We go, let's go update the charter because everyone in the community says all of these groups are helping so much. I would rather have that problem. Where Red Hat goes, look, there's too many other groups that we can't be on and we've been contributing. And we go update it versus we're going along focusing on other things and we don't recognize that someone that had a bad intention versus Red Hat trying to contribute someone else, they came in and we didn't have the protection. So that was my one side on bias. I don't disagree with you. So I think what Ian described won't change the spirit of the intention and we'll just make it more explicit that the group gets to decide. Sounds good. I'll work with Ian on that. I think the big thing we should be striving for is finding ways to increase participation while also protecting the reputation. I think we keep talking about nobody will use this if our reputation is bad. But the people who tend to show up on these calls are invested in this. And I think the other fear is we don't want to think a bunch of time and effort into this only to have the reputation trashed in six months. And we all feel like we didn't get a return on investment for this time that we're spending. So I mean, this whole thing about open source. We're at time, y'all. We're at time. Please go check out the use case template so that we can get this closed out and open this one. And there's some things being split out from this, but most of it's been resolved. So please give your feedback here so we can close this one out. And Ian, I think if you had a different deployment use case, please link so that people can read that. And then maybe I can continue with the discussion. I haven't shared it yet. So I'll start a discussion for that. I don't think a full request is quite appropriate right now, but yes, I'll do that. Okay. Sounds good. Thanks everyone. See you online and otherwise next week. Cheers. Cheers.