 Test, test, test. Can you hear me? I can hear you. Yep. I can hear you. Hello. Hello. Good morning. Hi, this is Dan con Chris and check. And so we're going to. Are another three minutes as normal. And then I'll kick off the meeting. Okay. Let me go ahead and kick off the meeting. Okay. So folks should have the slides open for February 6. I just pasted them into the window and a terror. Could you please share your screen. So that folks can see the slides. If they. If they want to, I'm just going to make one request here at the beginning of our call, which is, well, first of all, just a reminder that everything CNCF related operates under a code of conduct. And so the organization here gets a little heated. I would request upfront that everybody just interact in a respectful and. I'll emphasize collegial way. And I will say that one of the advantages of CNCF is that we're only two years old. And so a lot of our structure and organization such was put together as a best guess. So I don't think that's a good idea. It's a good idea to work well, but absolutely none of it is set in stone. Everything about CNCF can be changed. Essentially with either six votes out of the nine of the TLC or for a smaller subset of things, a majority of the governing board. So with that, I will hand it over to Alexis. If you don't mind leading the meeting today. Hello, Dan. I certainly don't mind leading the meeting today. I just want to figure out why I've got a. This on my screen. Hold on a sec. Okay. Do you mind if we jump to the first slide, which actually has something non-generic on it? Right. Do we want to do a roll call? I think it's offline. So let's go to the project status theme. Okay. So yeah, welcome to the exception level project. Let's move to the next slide. And the test incubation next slide. Do you want to say a few words about this slide, Dan? I think we've talked about it a lot, but it's becoming custom rates and talk about it every time. Well, it is. And we do have this election coming up quite shortly. So Brian Grant and Solomon hikes need to decide if they want to essentially nominate themselves to run again. And then on March 17th, the TOC will meet privately and the other seven members will decide whether to reelect those two or to pick a new ones. And then once the nine member to see is reconstituted, those nine will select its chairperson and Alexis needs to decide if he wants to run again for it. So that's coming up in a month and a half. And then things are stable until the end of January of 2019 when the other six members are going to be selected by the governing board or reappointed and Sam Lambert will either be reappointed or replaced by the end user community. This is a Brian. I do plan to run again, but do we have an official nomination process or voting process? But we definitely don't. Brian, the TUC gets to choose how to do it. The governing board. There's a whole like very detailed process on, on that's written out in the charter, but CNCF staff is very happy to run an election for you. We would just do it be a sieve, which is how we do all of our elections and people use the rank endorse it voting. But I actually wasn't here for the previous time, maybe Alexis can say how you guys picked Alex, how you picked Brian and Solomon. Um, I actually, I'm being honest when I say, I can't quite remember. Sorry, Chris can remind us when he's, he's here from, from what I recall, there were, there were emails with bios sent and, you know, the elections. Uh, I did talk to the TUC one time and then there were elections. I didn't participate in that obviously, but, uh, there, there was at least, I think, like a roster of candidates or something. Um, I don't, I don't know if we need an excessive number of candidates for this election, but, uh, it'd probably be useful to decide for this and for future elections. Okay. Well, I think the key thing, Brian is, is I'm not sure that Solomon is going to, um, um, renominate himself to run again. And so if, if he doesn't, then, um, I presume the TUC would like folks to put their names forward, but just to be clear, I mean, uh, the TUC could also ask people to put their names forward. Is it this, sorry, this is Justin. Is it up to the TUC to decide who nominates people or can the community nominate people as well? T, uh, TUC really needs to create the process. Right. So let me have a offline conversation with the TUC and propose it. I mean, basically I would just propose that anybody can nominate themselves and the TUC can request people to nominate themselves. Um, just on the TUC mailing list or something like that. Yes, exactly. And then, yeah. And then when we, when we get there, we would do the condorsed voting, um, of everyone. And obviously it's only the, the seven members would do the, would, uh, be eligible to vote. Okay. Thanks. That's it. Yeah. Okay. So I think that was worthwhile. So I will take that as an action. Great. Okay. Just trying to get this thing open again. So what's the next slide done? Project status. So this is something we discussed last time at hand. Uh, those of you who pay closer attention to such things will have noticed that, uh, it continues to be a live issue for the community. And I thought it would be very helpful for us to spend some real time on this call discussing the matter at hand, which is that, um, in a nutshell, uh, several people and I'm not necessarily not one of them feel that, you know, inception is being seen as a stronger blessing on projects than perhaps the TUC had intended when we first came up with the category. Um, so much so that, you know, companies appear to be, uh, betting their future on becoming inception projects and the associated, um, reception from customers in the community and from, um, VCs and so forth is consistent with that, that people are getting money that, you know, they're being promoted as the choice for Kubernetes for purpose X and other things which were not really intended. And I think that we need to, um, essentially look very carefully at whether inception is a valid category. I think it probably is, but I think we need to make its lowest status much, much clearer than we got as far as saying last, last time. So, um, this is what I want to discuss today. And, uh, already, I think on the, um, public list Camille suggested, for example, that we adopt some of the methodology of Apache with their incubation status for these very young projects. Uh, I think also we need to, um, come up with some much clearer guidelines for the marketing team in terms of what the TUC feel is the status of an inception project. Um, so that, you know, it's not promoted. Uh, I think, you know, if there is a press release and, uh, some, and what goes into that press release, very important considerations, you know, we don't want people to think that somebody, can you please stop typing or go on mute. Whoever that is. Um, if there is a press release, you know, that should message the correct status of the project. And it should describe the project very carefully. Otherwise we have a danger of overhype and the subsequent uh, costs of that, which have already been felt by many people. Uh, and there's been actually quite a lot of upset, which is not great. So, um, I'm not quite sure exactly. Yeah, let's actually go to the next slide, please Dan. Let's go to them. This is, this is what we have on the website right now. It states that inception projects are at a lower tier, but that's the only thing we've done so far. If we go to the next slide, you know, as you can see here, this is, these are the topics for today. Um, so my first question for the TOC is, if we start graduating projects, um, do we still need inception? Because at that point incubation will be clearly demarcated from inception as a sort of starting point for certain types of projects. That already have reasonably significant numbers of users and, um, you know, get hub stars or whatever you care about following. Does anyone have any strong thoughts on this that we should listen to first? Well, this is Brian. Um, I think inception does, could potentially fill a valuable place, which for, for these early stage projects that do want a neutral, uh, home for collaboration amongst many companies. The incubation bar requires production usage. And as we've seen in some other cases, um, you know, projects at the very early stage, my, I may either choose another foundation or, you know, even worse, they may not actually get, uh, enough traction. I mean, if they are track getting a lot of, uh, participation, maybe that's a suggestion that a foundation is not essential for them, but, uh, you know, for areas that are important to, uh, cloud native, uh, cloud native operations, cloud native technologies, I think it would be a shame if we couldn't take on those projects, uh, just because they were early stage. I'm definitely inception or sandbox or whatever needs a lot of improvement. Uh, as I was looking around this morning, we don't even have a statement anywhere that I can find about why we do inception projects and looking at a number of the press releases around some of our recent new, uh, inception projects. Uh, the press hasn't picked up on the reason either mostly. Uh, there were a couple of exceptions like geek wire actually figured it out. Um, but, uh, we need to make that distinction much, much clearer, uh, and make maybe more drastic changes to the marketing so that they're not just put on the same level at cloud native con and whatever, uh, as all the other projects. Right. Sorry, Camille. Okay. So here's what I was going to say. I, I feel like there are like a number of conflicting forces at play. And, uh, obviously I was in the room when we decided to make inception and put linker D in it. Um, but right now it feels like one of the reasons that people want inception is it appears to be, and Brian or one of you who works for one of these companies can correct me if I'm wrong, that, you know, there are companies like maybe like a Google and Microsoft or IBM or whatever that don't feel comfortable having developers working on open source projects in a collaborative fashion that aren't in some kind of foundation. That, that, that is an impression that I've gotten. Um, the concern that I have. So, so if that is a legitimate thing that's happening, I would like for us to be able to, you know, enable those kind of cross collaborations because I think a lot of valuable work from those companies is coming, you know, is coming into the open source world. And obviously we want to continue to encourage that the concern I have a little bit though is that we have created a little bit of a beast where we, we don't, where, where we have kind of this, um, this arms race to get into CNCF as early as possible because otherwise you are kind of competing frankly with projects that are either being done by these big, you know, a thousand pound gorilla companies that are in CNCF partly because they actually need that foundation protection to collaborate at all. Um, and you know, and it sort of starts to seem like everything legit is coming out of us even at these like very, very, you know, uh, small stages. And it, it is, it does make me worried, right? It makes me worried. It makes me understand why people want to get in as early as possible. But I think a lot of the things that we've, you know, had up for vote to join inception are like sketches of an idea it feels like and maybe not quite like a real thing yet. Um, not, you know, I think Cordy and us and Lincordy and Rook frankly are all good projects and I voted for them. And you know, but, but I, this is my concern is that we've created an impossible situation for ourselves because we kind of need this to help, you know, to help a very, a very important group. Um, but by helping that group, we, we kind of bless that group at the same time and we make everyone else have to do that also. I agree with what you just said. And I think like, um, I mean, now that I work for a big company, it's different, but also like I saw the world from the like, you know, the big people are trying to crush us kind of way. And, uh, that is like a legitimate concern, I believe for startups and stuff. But I think that right now what's happening is it's being gamed, like people are like gaming the system so that they can get in and then get the like vettedness of the CNCF, you know? So I'm not, I'm not sure how we, I'm not sure how we have a, have a, have an area unless we are really very much like there is no, you know, there is no sponsorship. There is no advocacy. There is no press releases. This is a, you know, this is kind of a, a place where we want to let people safely collaborate and therefore we have this kind of sandbox inception place. But that's all you get from it. It's kind of this safe, you know, whatever trademark copyright, I don't know, you know, lawyer, lawyer safe area for companies to collaborate. And that's it. Like I'm not sure we can do much better. I'm not sure that if we, we continue to do more than that, we're going to get a good outcome from this. Yeah. I actually like the idea of turning the marketing of these projects down to zero. I think in addition to just providing a neutral home, we could potentially do some of the other things that we have talked about doing to help open source projects like provide example governance models and things like that for some of the projects that need them. But in terms of marketing, yeah, I would definitely be in favor of just dialing that back to zero to remove that as a motivation. Yeah, guys, if I could, if I could offer a comment. So this is Bob Wise with Amazon. Yeah, I think, so I think that would be a great thing to do. I mean, I had suggested on the email list, you know, a turn in the other direction, which is to make the bar for inception higher, but going with the theme of the moment at least. If the, I think part of the issue is that the TOC votes on it. And that is going to be an, and that's done in public. And that's going to be an endorsement that people take very seriously. And to the degree that the inception level is just like a safe harbor for anyone, any and all projects, the marketing probably will take care of itself because lots and lots and lots of projects will join, kind of like they do in Apache. Thanks. So I think what I just heard someone suggest is that it might be better to lower the bar than raise the bar and then pull it, make it a lot clearer that it is a sandbox. You don't get marketing, but you do get service desk help. Yeah, I agree with that. I think that what everything that has been discussed is, is great actually. And I think that's, that's probably the right thing to do. Quinton here, I have one other thought. So clearly the plan for inception projects is that they should graduate incubation and eventually graduation. And one of the, I guess underlying concerns is that we get projects getting into inception just so they can get their seed funding and then basically don't fulfill the ultimate goals of the CNCF. And so what we could think about doing, and I'm sure this might be contentious, but allow some amount of marketing. I mean, there is some achievement in getting into be an inception project, but then equally, if things get kicked out of inception after some reasonable period of time not having reached incubation, we could also make that public. That the inception projects are early, but on a trajectory towards graduation eventually. And as soon as we decide they're not on that trajectory, we remove them from inception. Right. Well, we definitely should remove. Hold on a sec. Just very quickly, just wanted to respond to, to Quinton. We do already have the concept of pruning projects, even from incubation, although that is more extreme. And I, it's been made, the point has been made that how do we already done so, perhaps some of the misunderstanding around the inception here would be less. But I do believe that we should, we should be more correct in that pruning projects, maybe do some more frequently and make it a lot clearer when that's happening. So I agree. So please continue. Oh, I think. I just think we're not very good at saying no. We're not, we're not very good at pushing things out. Like, and I don't think that's, that's, that's a bad thing about this group. I think it's just human nature. It's, it's hard to, you know, it's, it's hard to reject a thing that isn't completely abandoned. So I, I am not, I don't have a ton of faith that we would, that we would frankly, it would even be like the thing we want to spend most of our time on worrying about pruning projects out. Like I, I'm actually much more in favor of letting a lot more stuff in and saying, look, we're just going to let a lot more stuff in and we're going to make it much less of a voting process, much less of a public to do. You want to put some stuff in a sandbox and you know, whatever, then great, go for it. You know, we'll provide some, some of support, but perhaps not that much support. I actually think that's a better, that's a better path forward for us than, than pretending like we're going to do a thing, which I just think is unlikely for us to do based on everything I know about the way people act, which is that we would kick a lot of projects out. So would it be a CNCF sponsored sandbox? What would be the difference between that? And I just go get something on GitHub. I mean, I guess I just want to understand the boundary. My understanding is there are legal, there are legal things. And I don't know if Brian Grant or someone else can speak to that. My understanding is there are legal reasons that bigger companies would prefer to have it in a neutral third party. Yes. That is correct. And I can appreciate that fully. So I get that. I just wanted to know what, you know, we were going to lower the marketing, which I think is a great idea. You know, what, what will be the boundaries. So it's well defined for those new projects. They understand what they're getting into as well. Okay. Another thing I think we can do, and that we would need to do if we lowered the bar is actually do for projects that want to graduate to incubation. To do the full diligence cycle, as if it were a project from outside at that point, as opposed to doing it when it became an inception level project. That's a good idea. Can you type it into the chat box? So one, uh, this is John Bill Knight from court DNS. So as a, as a maintainer of an inception level project, I mean, one thing about broadening that there are, it's not just marketing that the CNCF provides. So like one of the things we, we use pretty extensively as we have access to the packet.io. Um, for that's where we run our CI and things like that. And that's all funded by the CNCF. Um, how would those sort of resources be shared? And maybe that's more a question for Dan, but if we were to expand inception to a large number of projects, it seems like that might be prohibitive. I don't know where the funding levels are. Hi. Good question. And, um, just by the way, it's actually packet is contributing those resources. So we're not, we're not paying for them. Um, so we're, we're very appreciative of that. And that program actually right now, which we call the community infrastructure lab is available to any open source project that goes and requested via, um, it's on our homepage under community, community infrastructure lab. And so, um, as of right now, um, there's plenty of server resources available for dozens of new projects to come in and use it. The idea has always been that we would prioritize the graduated and then the incubating and then projects and then, um, but, but as of right now, there's no scarcity. Uh, but the other piece I'll just add is I think what we're talking about or possibly talking about is explicit. It is saying that all CNCF services would be available to the sandbox layer, um, but not the marketing ones. And, um, we would really need to be more specific about that. I mean, I presume we would want to have a sandbox page on the webpage, which would not be on the homepage, um, where we would list those, those logos and, and describe the projects and such. And, um, then we would need to talk about whether we would be giving those, uh, companies the chance, uh, like Kubernetes SIGs right now can have a session at cube con, whether, uh, those sandbox projects can, all those pieces would need to, we would need to shake out. Right. Right. Okay. Thanks. Yeah. So for, we, uh, for those of who may not be aware, uh, we've had a thread related to this, uh, with respect to Kubernetes that we have a lot of projects cropping up that, um, would have are a potential use to Kubernetes and contributors want a neutral home for those projects, but it's kind of unmanageable to host them under the Kubernetes project itself because they have, uh, potentially different sets of contributors and, uh, different ways in which the project actually, uh, wants to operate and things like that. Uh, and that amount of heterogeneity is, uh, difficult to manage, especially on GitHub, um, which doesn't have great tools for managing, uh, lots of GitHub organizations and repositories. Um, so we've been discussing this idea of maybe if there were CNCF sandbox, that could be a place that such projects could, uh, kind of start and grow, uh, and experiment and innovate, uh, without requiring, uh, oversight directly from, uh, the Kubernetes, uh, steering committee and maintainers. Yeah. So I think that would be done by the same function here. We would just have a general CNCF sandbox, but we would also cover Kubernetes early stage. Yes. So, oh, sorry. One other question I would have for the TOC on this is, do you want to have, uh, uh, require the same six out of nine votes to get into, uh, the sandbox? I think we would have three sponsors or something like that. And then we wouldn't need to have a vote. Right. That's exactly what it, so you could do one spot. Yeah. Three sponsors, uh, would be a lower bar. Well, do I have any sponsors at all? I mean, it goes back to the TOC endorsement is really, really valuable in the market. Um, as, as long as the CNCF staff have done some basic diligence on, you know, is it a real project? Um, you know, I think that's, that's better, but it's still sort of falling into the same endorsement trap that we're trying to avoid. Well, if you want thousands of projects, but we can have them if you have no parcel. Well, I think part of the endorsement concern does come from, from things like CNCF press releases and interviews when the project is inducted, um, the, uh, putting, putting the projects on stage at cube con, you know, I think if we just cut that down and just say, look, um, they're not on CNCF.io. We have a GitHub page somewhere that links all the orgs for all the sandbox projects. Um, they have a lighter weight process and a lower bar for projects to get in. There's some amount of vetting to make sure it sort of fits with the right direction, but they have to, you know, if they want to become actual go into incubation, they have to go through the regular proposal and diligence process. Um, I think that seems worth, worth a try. Um, I don't know that's who, how else the vetting would work until, uh, the TSE contributor, uh, process, for example, is still very nascent and I don't know if we have enough, uh, participation or shared understanding yet of what we're doing there to fully delegate that to, um, people who haven't been identified. Uh, I would be really hesitant to, to, to say no, that everyone's allowed in. I mean, there's 77 million repos on GitHub and in reality, it does take staff time just, uh, to, to respond to service desk requests and just simple, small things. And so an alternative proposal to three sponsors on the TSE would be one sponsor on the TSE. And I, let me make even more specific proposal, which would be that if you want to be a sandbox project, you need to find one TSE contributor to, um, sponsor you and one TSE member. And the, uh, TSE contributor would be expected to actually provide some meaningful ongoing, uh, oversight and supervision and suggestions. Yeah. I think there's, there's a very important aspect here that we mustn't overlook, which is the branding side of it. And that kind of goes both ways. So whether we call these sandbox or inception projects, they're still in some way associated with CNCF. Um, and the CNCF has a brand to, to kind of uphold. And so we do, yeah, we, we absolutely need to have some bar. Otherwise that brand will, you know, time become worthless. Uh, which is, it is not at the moment. Um, yeah. How does Apache do it? I think, uh, Camille or someone sent out a link that was quite helpful. There's a lot of Apache inception projects. Sorry. I'm, I forgot I was muted. Um, I don't remember the details. Um, exactly, but it's all, you know, it's Apache. So it's all extremely transparent. And, uh, Uh, So it's saying that Apache requires a champion. And Louis is saying that Fedora requires a single sponsor. Yeah. So there you go. Yeah. That would seem like a decent pattern. Yeah. So, uh, on a, um, from an implementation point of view, if we're going to drop all marketing, um, I think it might be wise for us to first, uh, list exactly what we define as marketing. Um, because there could be some things in there which are just, just sort of essential to the functioning of making sure that people are aware of the activities we're doing with these projects that other people in the TOC may see as marketing. So, um, I don't have that list off the top of my head, but I think it would be wise to put it together and then have that discussed at some point rather than just saying as a blanket decision when I'm going to do any marketing. Okay. So I think I want to thank everybody for their contributions today. Um, Dan, would you mind finding somebody in your team to take the notes in the chat window and turn them into a Google doc or something on GitHub in the form of a proposal for a sandbox tier to replace in session? Uh, yeah, that sounds fine. So I will take responsibility for that proposal along with Chris when he gets off out of the air and, um, we'll definitely have, um, you know, some brackets or areas to discuss, but I think from here we can take it to a Google doc and the mailing list and check it again at our next meeting. Thank you. So there's another topic on this slide which we haven't covered. I want to cover today, which is the concept of more mature or stable or slower moving projects. Um, this came up in Austin during the TOC meeting. There was a discussion about projects like, um, etc, which are separate projects, which are used within Kubernetes and other larger projects. And I'm not, not necessarily evolving new features very quickly, nor are being treated as kind of projects, sorry, products on their own, um, trajectory to kind of long term standalone success. So can you go back from this slide? Thank you. Back to the, yeah, that's fine. Thank you. Project hearing thanks. And, um, you know, I think that, uh, this is a good idea that, um, we could label projects as being slower moving. Um, Camille, I think you were potentially willing to, I don't know, uh, act as a sponsor for this idea as well. Uh, there is, there is a sketch of how it might work below the fall in the slides. I think it's essentially just a label on a project, but I'm not sure if that's the right thing. What are people's thoughts on this? Yeah. I mean, I, I think that there are going to be projects. And I think at CDE was the, was the, uh, impetus for this discussion that are essential pieces of infrastructure for major cloud native systems that are just not maybe going to be, should not be expected to be feature churning machines. Um, that, you know, for whatever reason they are at a point of stability or they are just sensitive enough that they don't change that quickly. And, you know, they don't necessarily have a humongous group of, um, active contributors, but we want to provide them a stable home and support. And I think, you know, I don't think this should be in a totally common thing for us to have, but I would, you know, I would hate to orphan critical pieces of infrastructure because, you know, they don't meet, um, you know, they're, they're kind of atypical in their need for need to move slowly or, you know, they're kind of criticality in the stack. I'm not sure at CDE is the best example here because their, their development is actually relatively active, even though it's not necessarily adding tons of new features. Um, I forget why exactly we, we, we got to that. Obviously I wasn't looking at it when, uh, when we had the discussion, um, Brian and I were discussing it. Um, so maybe he remembers some more details that I feel like it was partially partially some of the concern was just the relative, uh, few. Committers there are on the project. Yeah. We have language in the, uh, uh, principles document about what kinds of projects we're looking for in terms of high velocity growing, et cetera. And, uh, at CDE didn't seem to match the. Spirit of. Of that, at least like in terms of. Adopt, user adoption, just, just as one example, I don't know that it needs to necessarily be a goal to get. Uh, zillions of more. Uh, direct users of. At CDE since it is a critical component to. Uh, to Kubernetes and to other. Uh, current sets of users and yeah, the, the small number of, uh, maintainers was a concern, although. Um, we are trying to address that of course, but. You know, it doesn't need to necessarily grow. It doesn't need to grow. It doesn't need to grow. That dozens or hundreds of contributors in the same way that. Uh, Kubernetes has tried to do, uh, you need high quality, uh, contributors who actually deeply understand. Distributed systems. Um, so it does feel like it's, it is kind of a different. Point in the spectrum in terms of, uh, how does it look like it's going to grow and it's a trajectory in terms of where it needs to go. Obviously we're open to revising any of the guidelines, but I, I'm not, it seems like this is already taken into account when the TLC, um, evaluates a project that, that at CDE being the exact example of something that nobody wants to have tons of features added to and presumably container D as well. So, um, I think that, um, I think that we should slow down dramatically and that new development would, would take place at other layers. Okay. So I'm actually going to suggest that we. Stop the discussion for today on this. Um, let people go away and think about it. Um, or renew another day. Dan, um, if you could ask Chris to make sure that that happens. Um, let's move on to the other topics for the day so we can wrap very quickly. Um, this is just a reminder on project health. We have some TLC contributors to help us do, uh, project health checks and other reviews. Uh, please email Chris and me if you want to be one of those people. This is important. I believe so far Mark has done and a couple of other people. Let's go to the next slide. So, um, Brian suggested that we update the cloud native definition, which everybody thought was a good idea. Uh, Brian, do you want to talk us through this and what you think we can do next? Yeah. Uh, so, so the reason, the motivation for, uh, starting this, what came out of, uh, discussions from the storage working group about what is. Cloud native storage and reading the proposed definitions. Uh, 90% of it sounded like what is cloud native. And they were trying to define that. And I went back to look at the definition in the charter and it seemed very Kubernetes specific. We talked about containers, dynamic scheduling and microservices, uh, which seemed particularly helpful for evaluating, uh, other projects, especially if we want to do things like lower the bar for, uh, inception, we're still going to need sort of a rubric for deciding what cloud native, you know, whether a project fits with the cloud native mission or not. Um, so, uh, I think that the diligence guidelines that we came up with didn't really, uh, cover this in depth either. So, uh, I have what's shown here are the points from the second draft. There, there's a third draft now. Um, but, uh, thanks to, uh, Justin, uh, Garrison for, uh, helping to propose, uh, most of these points, uh, come up with attributes for that would be engineered into a system in order for it to sort of qualify as cloud native. Coming out of the discussion, there are also, um, points about, well, maybe we still need some examples. Like we can use containers and microservices as examples of things that would be considered cloud native or other, uh, sorts of approaches like declarative APIs or, um, uh, other specific technologies would be useful to help clarify. It's hard to get, uh, really clear, uh, accurate precise definition that's also concise. So I think we're going to have to, uh, balance it a little bit with, uh, having a definition that is concise, but maybe not fully fully explained and then defer the explanation to, uh, to elsewhere. The charter actually has a short section at the top labeled the mission, uh, and then a longer section as sort of an appendix called schedule a where it discusses, um, cloud native different parts of a cloud native, uh, ecosystem and, uh, somewhat more detail. And that part also needs to be updated. I haven't started to work on that. But that is, would be another place where we can put some of these additional details or we could just remove that entirely and create an entirely new documents, which contains our up to date understanding of, um, what key, uh, technologies or, or functionality in that ecosystem would be and how they fit with cloud native. Um, so as far as where to go next with this, uh, there is a document, um, which I can paste into the chat, uh, just a second. And there is an email thread. So either comment on the document or reply in the email thread and we'll try to come to agreement on, uh, something concise and then maybe we can start working on the longer form, uh, with additional details. Uh, there, I might, it's my understanding that there are a number of charter updates potentially that we may want to make. So this would be sort of bundled with those and a revised version of the charter for vote by the GB at some point in the, hopefully not tremendously distant future. Hey Brian. Um, this is all, I'm very supportive of it. And we're ready to immediately change the CNCF marketing in terms of, you know, what's on the homepage and our slide decks and such, but all things being equal, uh, I would, I think encourage the TOC to make a recommendation to the GB to just eliminate appendix A. Uh, I mean the context here is that a very small group of people wrote that appendix in mid 2015 when they were trying to kick this off when cloud native didn't have a clear understanding and you know, things were just way, way bigger than they were today. And so I'm just not sure that we want to have a complicated bureaucratic process for amending that in the future. It seems like it might be easier to just eliminate it from the charter and then the TOC can have a document, which, you know, maybe try and update once a year or something where it lays out what, what you currently believe cloud native represents. Uh, I like that idea. Yeah, me too. So Dan, are there any other changes coming out of the operating principles that need to be updated in the charter just while we're on that topic? I mean, I could be wrong, but I actually wasn't aware of other meaningful changes to the charter going forward. Oh, well. Um, and so the election, uh, details were clarified that I still think that the language in the charter is fairly confusing. Um, I don't know if we want to bother updating that or also just remove that to a separate document or leave it as is. Um, I would, I would have to read the charter again to point out specific things that could be changed, but it is. I don't know. Maybe the documents of historical interest, but it's like as a whole, I find the documents somewhat confusing. So I do as well, Brian, and I want to make the claim that I did not write the charter and have no allegiance to it, but the election was a specific example where trying to pull all the information from the charter to, to create that election document was tedious and confusing, but I believe creating those specific dates in the schedule and everything is completely consistent with the charter and that by getting both the TOC and the governing board to sign off on it to agree that this was the path forward, it's not actually necessary to revise the charter. And so my, my fear is that undertaking that is just a meaningful effort and it's not going to produce useful results at the end of it. So, so maybe what we should look at doing is, um, putting useful content that we want people to understand places other than the charter and just make the charter less prominent. Exactly. We mentioned the charter in every single press release. So, and that's an easy, I mean, that we can just change that going forward. And so we already have the TOC principles document, which we went through this process on. So we can start highlighting that and then whatever we call this new doc of the cloud native definition or cloud native principles, something like that. Great. So that's a great strategy. We can take bits out of the charter, replace them with better stuff in chunks over time. And, uh, this will be the next piece. So in terms of next steps on this document, knowing that Brian often volunteers for things while being very busy, would it be possible for a TOC contributor, perhaps some like Justin, who's been down this path before to volunteer to own or co-own the delivery of a document? I would love to have Justin's help with his wanting to do it. I just really don't want this document to be designed by committee. That is my concern with this is that it is starting, it's starting down the path of designed by committee where, where it, you know, I will be opinionated on this one because I think, I think, you know, we were, we were inching down that path a little bit. And I understand that these things can be hard to pin down. And, you know, uh, making, making a precise point is, you know, it's sort of making a statement, putting ourselves out there. But I hope we can, I hope we can keep this to be something that is actionable as a, you know, when I put on my end user hat, um, I actually have found the original definition, maybe Kubernetes specific, incredibly, incredibly useful. And one of the best definitions of like an application layer, what cloud native kind of needs to look like. Um, and we aren't evaluating projects that are application layer projects always, right? We're evaluating a lot of infrastructure, which is why it doesn't always fit perfectly for us. But, um, I just, I do, I do hope we can, we can, you know, uh, not, not make everything good about software engineering, uh, credited to cloud native in our, in our definition. So I will, I will be, it will be involved, whether you want me or not, I suppose. This is the Justin, I'd love to be involved with obviously, you know, driving some of that definition. Um, I'm also very scared that it would be designed by committee. Uh, so I've been trying to, you know, at least have some, don't try to go into it and assume that we have no opinions, uh, but to know that, you know, the definition is going to be opinionated one way. And myself being a strictly an end user and not having any projects or, you know, actual like money on the line in any CNCF project. I think, uh, it helps me kind of take a step back and look at those things, but also coming to edit more of a, I help manage infrastructure more than manage applications. So I do have a little bias there as well. So, um, but yeah, I'd love to be involved. I mean, as far as design by committee, I'm happy to just iterate on it with a small group like Camila and Justin. Um, and certainly I'm not going to include anything in the definition that I don't actually agree captures the, uh, the essence and the intent of cloud native. Um, right. I think that's a plan. Um, so if anyone else has a really, really burning desire to be part of that small group, um, please say so to the small group, um, that's a little bit of a big off line, but we'll proceed with that. And Dan, could you ask Chris to table a recall of the group for say a month's time when they've had a chance to form an opinion? Certainly. And, um, Taylor, can you put your slides back up please? We just lost them on the screen share. And I will just say if we do get more volunteers, I would prefer someone who's actually willing to contribute text as opposed to just willing, willing to review and offer opinions about the text. That's a good point. I do think that to Camille's point about being actionable, um, it would be lovely to see something where in addition to a set of properties of cloud native as illites, there was a statement along the lines of typically these are achieved by, you know, containers, microservices or something like that. Because I think I will help write Brian. No, I wasn't referring. I'm just, I'm just letting you know, I will help write. But, and yes, I, we got a number of good suggestions and ideas from the mailing list, but, um, it's not going to converge unless we actually get people with those ideas actually, uh, working on the texts suggesting alternate texts. So, yeah. But your point is taken, Alexis. I agree with that. Right. I'm actually going to leave the call to get ready for a podcast. And, um, I think we've kind of run almost run out of time. So I'd like to just shove the rest of the agenda unless anyone has any reasons to not do that. Okay. Good. Thank you everybody for talking about Inception without having a fight. That was great. And, um, see you next time. See you next time. Thank you. Cheers.