 So I guess the foundation believes in the whole idea of continuous stability, as in the benefit it brings to software development. And that's kind of, I guess I see it as a, if you don't believe in the mission, you shouldn't be a part of this. And then another part I think is, you know, you should have this, the obvious important mission for the foundation is we should have this ecosystem of open source projects. And then in order to sustain the growth of that, it should be a better new to a place that facilitates the collaboration and so on. And I think, you know, you already, many of you have already been a part of some sort of this open source organization in the past. So I think you have all the people understand like what this means in the practical terms on the ground. And then the last bit, I think, I don't know if we talked about this point explicitly in the past rounds of this conversation or not, but I think it's also important that for us, the practitioners be able to advocate the ideas of the continuous delivery. And then among the users so that they can swap notes, we can all convince her boss that the content server is important effort and the efforts that we're spending on is worth spending time on etc. So that advocacy of the practice, you know, not just the software, I think it's actually for me a very exciting part of the content series foundation. All right. So, and then, you know, so this work is being done with the Linux Foundation, I guess, again, I think many of you already know what the next foundation do in this space. So they've been pretty successful in building a lot of some foundations creating, you know, neutral playground between different vendors. So, you know, that I really I don't think needs any, well, further introductions unless you want to specifically talk about it. And I think there's a growing rise of continuous delivery, or in fact, I guess on the backdrop of the growing importance of software in the space. So I think the time is right for this effort. And then there's, you know, like a lots of CICD tools in this space. Many of them open source but like need not really like right now collaborating or working together. So that's part of the things we mentioned in the past. So yeah, so I think, and then this kind of aligned well with what we've been working on in the Jenkins project, which is to find a good stable home, right? Like a move away from this halfway house between this external perception of the cloud is on project to certain people versus us, they cannot having the more community driven projects. So I think that what's going on in the broad industry, I think it aligned though is what we are looking for. So some of the details that they didn't cover, I think in the documents in the email that I sent. So for us, there's like, you know, content series foundation, we have members, you know, members and they are generally, I think a certain to be a companies that comes in a different tiers. And they, you know, they grant access to certain level of various, I guess, quote unquote privileges and then exchange they pay in the money. And so that forms the budget that allows us to kind of plan how to spend those. So we don't have to run around like trying to secure the next place where the infra budget did come from now that the Microsoft arrangement is going to expire at some point, etc. And then so the content series foundation has some governance bodies, like the group of people. So these three, I think one, the three of those are particularly worth talking about it also the first one is the governing board and it's So like I provided, ultimately, I think it provides the oversight to the budget and the money that these companies are paying into. So, you know, so that's an overall like a big picture of stuff. And then there's this outreach committee, which does this events and other advocacy of the content series space. And then the technical group, which is the technical oversight committee, which is around a collaborative like a coordination of the projects. So those are, I think, the key bodies. And then you currently think of we are talking to, you know, I guess the three projects at the moment that's the base like a high level of commitment, I guess. So the one is like a Jenkins and Jenkins X, I guess. Well, it's two. And then there's a Google backed pipeline, CRD, K-native, you know, kind of products. So that's the another one that's, I think we have a high confidence on. And then we are talking to starting to talk to, you know, like title or timeline, that's read. Part of this is like, you know, we need to start, there's a bit of a chicken and egg program here in that like we need to build some shape of it before we can approach more people and then unless we approach more people, we don't know which project can go in. And so on. So some of these like conversations are happening. I think it really started happening last week, I think. So it's just a year to be out in the process, but you hope to gain more projects as we go. And so the one thing I think is worth clearly pulling out is, you know, what this means is in terms of the changes, it means like, I think what it means is like, we've been moving some of the foundations from SPI to CDS. So today, the SPI has roles like, you know, holding assets, you know, dealing with money, et cetera. So that's going to switch to the Conger theory foundation. And then the SPI, you know, we gave some heads up to the SPI about this. So they are aware that this conversation is happening. And then I think the other important part to clarify is like the role of the members, those are, you know, primary companies versus contributors, which, you know, who you are. So, you know, contributors under the scheme of CDS, just like today may or may not be from members, like it's kind of independent from that regard. And then the decision making structures in this project, you know, these, it's still largely remains intact. You know, the Jeff Siegs, all the processes we've built up so far, or like an implicit way of us doing things, like, you know, changing that the bar of entry into commitorship, et cetera, CLA, we are not expecting any change in there. And then so just because the point that I wanted to reassure is just because like we have all this member company now it doesn't mean like they automatically get to drive the direction of the project or anything like that. So that's important part of, you know, the making sure that this open source for this kind of function that it is. And then as contributors, the, we get the electronic seats into the sum of the aforementioned governance bodies as a kind of voice of the committers or the voice of the contributors. So that's additional, like a visibility and like a leverage we, you know, the people in the community get toward this foundation. And the members, like what they, like where they come in is one, so they pay in the annual fees and that forms about it. And, you know, it talks already about that. And then as a part of like a paying in the money, they get to provide some level of oversight about how those money are used. So that's the governance, governance board GB part. And then generally, right, being able to sort of raise awareness and advocacy of continuous saviouries are seen to seem beneficial to vendors. So you can imagine like companies like these could see this angle as a part of the, you know, the part of the reason it's excited about being able to part of this endeavor. And then from Andrew's perspective, you know, a lot of companies do use these multiple tools together. So being able to kind of have them talking to each other. And then they end user have some like a forum to voice their thoughts. That's also generally seen as beneficial for the end user companies. So that's another motivation for companies to show up as members. And then there's other like recruiting other interests that generally encourages people to join. And then the another, I think, for me, the benefit that's worth coding at is when the big company joins this foundation, like it opens up more, it creates more air cover. It opens up the umbrella for people, engineers in those organizations to spend more time in airports under the umbrella. I say it makes it easier for managers to see that this airport is aligned with the other thing these companies are doing. So that, I think it's going to play some positive influence on those. And then since, you know, the week is here, it's I can reiterate that the, I think, things we can do in China gets a little easier. And I know that's something exciting to you as well. So anyway, that's kind of quick, quick overview of what's like what I think largely captured in the email thread. So let's open up the floor here. What's any, any thoughts, questions, opinions, so it looks like we have a crease. So that's great. Hi, this is Markey. I have a question. How will this affect the individual contributors of plugins? Right, so I don't think it's good. So I'm not currently expecting any changes. So they, the one thing, yeah, so the, almost the way I think of it is like, so we have existing structures in this project, like the core plugins or developers and they're like a rain and all that. It's just kind of mostly take it as these and then flag that into the structures into the CDF where the part that gets connected is what the CDF calls that the technical steering committee and then from the Jenkins speaks that's the Jenkins board and the office service. So I don't really think that impacts anything in the plugin space. But you have some specific, like, maybe you want to talk more specific if that's the case, I'm happy to. More I was just wondering if there would be any change to the, the technical direction of a plugin for set per se if I have a plugin that I work on or a series of plugins. If the governing body will now be steering the direction of that plugin or will it just sort of become a much like how the Kubernetes community is built. It just becomes a SIG and you sort of work within that SIG. No, it's not. So this won't be like, there'll be somebody else this calling the shop in terms of what should be done in plugins. So it is not like that. So it's very much my expectation is, you know, let's say you maintain. I actually don't know what plugin you maintain. Let's say Uli maintains a series of plugins in this like a static analysis space, right. So and he basically drive the roadmap he decides what features to do and what bugs to work on, and that will be the same. But I hope the CDF will be able to provide is like more venues in which like we can get the input from and thoughts from more people and then if that influences you're thinking that's great. But if not, that's so, you know, that's so beat as well. So, yeah, I really don't expect that if you're considering like somebody else is going to tell you what needs to happen and it's not going to be like that. No, that perfect. Thank you very much. That answers my question. Good. Anything else, Rick, I know you, you must be like this must be a good awful hour for you. So thank you very much for staying up this late. But anything you want to add any thoughts. I know you time being on that meeting this day, but yeah, we can hear you. I say, do we have a timeline. Okay. Yeah, so yes and no so we are marking we are working toward the mid March. And then so that's the that's all that's all we are working toward but ultimately it kind of depends on like how much interest we can gather so by the module of that it's going to be a mid March. So the next foundation has events called the open source leadership summit agreed. And it's in my backyard so practically so if that's the, you know, so that'll be a perfect place for us to talk about this in front of the most, you know, companies that's participating into the next Foundation so that'll be a great place to kind of encourage more, more folks to join. There's some. Yeah, so that's the, that's the timeline. So back into the Jenkins project. The one thing that I'm trying to look for it's me so far to the extent that we had a conversation in the database that so very overwhelming support. But given the magnitude of this, I kind of want to like a record this consensus as a decision. Okay, so we collectively decided you know we consulted the community they supported this and we collectively decided that this is a move we want to make and here's the like a decision law or something like that. So, I want to make that happen. I think sometime in February ideally. That's maybe another key milestone. They have any concerns about those dates or like other things that you want you'd like to see more done or if not, any, anybody else in any terms, what else could be what else we could describe that might be helpful. Hey, cascade. I'm just going to make a suggestion that we can maybe introduce Chris and check. And I know Mark you mentioned like the Kubernetes sake so maybe we could get Chris to Yeah, kind of how this relates to sort of seeing a few people are familiar with. Yeah, I read of me. Yeah, so please Chris. Sure. Hey, everyone, my name is Chris Anizic. I have kind of the fun job of both founding and running the CNCF organization, which is the home of Kubernetes, you know, Prometheus, Envoy and other kind of planning your project. So when we were starting up, you know, CDF, you know, it was kind of inspired by kind of a lot of the, you know, practices and lessons we learned at CNCF. So, you know, one thing to note is, generally, every Linux Foundation initiative, we separate both kind of business governance and technical governance from each other, right. So there's no like, you know, kind of pay to play type, you know, action going on, it's more of members are paying to sustain the overall efforts through like, you know, events paying for security audits and so on. So, usually the way it works, you know, like in CNCF is each project kind of independently kind of runs on its own. So you'll see the same pattern here where both, you know, Jenkins, Jenkins X, K-native, you know, build pipeline will all have their own kind of independent technical governance, right. You know, in the Kubernetes case, it's a little bit more complex since it's a larger project. So like, they completely independently run, but they have their own SIGs that kind of subdivide work that kind of, you know, run amongst them. But in CNCF, the TOC or the kind of the main technical board has no direct, you know, they can't tell the projects what to do. They can't tell like Kubernetes, you need to like ship this feature that they could do like overall like, hey, you should maybe have like a security audit or something, but they can actually influence like roadmap or anything like that. They could have things around improving, you know, what makes an open source project, but they can't tell the project necessarily what to do, if that makes sense. Yeah, I'm all ears if people have any, you know, questions or anything else to kind of ask, ask me about this. I would like to state that I think this is a really awesome opportunity for the Jenkins project and I'm very excited. Great. Thanks. Sorry. Hey, it's Andrew. I just wanted to clarify a little bit or try to get clarified a little bit further on the plugins. Well, my understanding is that while some subset of plugins may end up getting managed by the the TSC like plugins that are effectively core that the overwhelming majority of plugins that are developed by individuals or you know, companies doing integrations with other services, etc., are not going to be at all controlled by the TSC. They'll have access to the infrastructure and get a repo, etc., like they do now. But there's no, there's really no change in terms of their governance and management. Is that correct? Yeah, I think it's the, I mean, right, basically, it's also gonna lax this indeed. I mean, just like today, you know, the Jenkins core developers don't really dictate what's going on in the plugins. There are some collaborations, like suggestions, etc., but that's really what I think primary what's gonna like what we keep doing in this new world. There's like also no conversations about whether like, you know, some of that should shift as you know, Andrew, as you said, like, you know, there is some interest in thought about, well, maybe you need to take some more critical plugins more seriously, etc. So those things we talked about, and I think it still makes sense, but it's, it's also no conversation from the CDN. Thanks. I have one other question. With regards to folding the Jenkins into the CDF, will we start working under their infrastructure? Mainly what I more mean, like we'll have a Slack channel, things sort of the way they structure a lot of their, like the CNCF structures are sandbox projects. I think that's more of a question for Chris. Yeah, I mean, it will depend on how the TOC kind of defines project structure. So what I mean here is, I'll give you an example. When CNCF was first founded, there was a bit of a bootstripping period where the TOC had to be formed and they kind of came up with the overall process of sandbox incubation and graduation. I see a similar pattern playing out here once that initial TOC is bootstrapped. At least from my perspective, I don't have the intimate knowledge of how the Jenkins community is fully, you know, structured, so it'll have to defer to like KK or someone else. Yeah. So my, I think the short term, I think everyone is interested, like I try not to rock the boat too much. So the, you know, for example, today Jenkins projects in Prateem kind of takes care of things that it can't, and then I expect that to continue the same. Whereas on that front, I think the key change would be the projects budget, Jenkins projects budget, it's going to basically get subsumed in the CDS budget, so we'd be able to kind of make sure that they think, well, basically be able to pay off the cost being fried, et cetera. And then in a long, but in a long run, I think, well, if, I guess, then things could evolve, like, you know, this, this, this infra work has a scale benefit, right. So, you know, the, if there are some things that the next foundation has already been doing, and then it makes sense that so that we don't need to do separate things in early infra teams and I think it makes sense to avoid that. So I think those conversations will hopefully unfold in the context of the infra team in the coming days. But that's more like, like a longer term thing in my mind, like it's not going to be a thing that needs to happen before we decide to join or not. And then they, Chris mentioned about this, the sandboxing and so on. So, you know, the, looking at some other foundations and the next foundations build, like in this, they do create this money labels around projects to indicate their general status. So I think it does apply to say the Jenkins project, Jenkins X and the, you know, the pipeline CRD that we mentioned, but I believe the way I think we are not trying to map every individual plugin into its own project in the eyes of the, you know, CD foundation so for the plugin developers perspective doesn't, I don't think the moniker is going to make much of a difference. If anything, I think it's more for the overall Jenkins project and Jenkins X project to meet certain bar of the governance, like, you know, that's the, that's the work and in some sense, like we've been doing that work all along. So it just creates a bit more explicit bar and criteria. The march toward. Yeah, I'd just like to just add to, to that specifically on whether conversations happen, whether that's slack or not. I think it will continue to be dictated by where the community is talking so Jenkins, you know, that will be IRC and we're seeing a lot more in Gitter these days. And Jenkins X they have conversations in the Kubernetes slack. So that's not something that will get dictated that's, you know, up to the community where they want to have their conversations and expect in the short term that will that won't change. Personally, I don't mind you actually using this opportunity to get off some IRC. Just like two cents. Yeah, good times. Yeah, every every communication medium has its has its problems. But yeah, it's Tracy said it. My question is, do we have the next step or actions and how I can help or other contributors can do for the CDF. No, right, because, right, I think you're you're interested in, like, you know, part of these CDF foundation is like doing some work in that space. So yeah, I think it's good to let me you have, I think now you're talking to Chris. I think that's the great fourth step. So there's that side of the conversations and then there's this other side of like what we did Jenkins projects should do as a next step. I guess that that's kind of like maybe it's a good way to turn the table around a little and what what should be, let's say the leadership the community needs to be doing. I mean, again, like I know the only key milestone for me is basically the end state which is to build to record some like to do some ceremony or formalty to record this consensus and decision. But I want to make sure that it comes across as a natural step, not something forced upon people. So the they're like in this Q&A is a part of that the email thread was part of that but if you feel like, you know, like try to picture other people in your shoes and if you feel like they need more, more information, more venue, more something before people feel comfortable, like us blessings decisions and I'd love to know those. So if not, I think the one thing I want to do at some point increase that I almost thought about writing to you just shortly before this call is like at some point I do want to be able to share that charter document. Yeah, absolutely. I think we have another week or so to get kind of final feedback and then I'll be in it's kind of finalized. Yeah, so I think that I think that will help for people to kind of wrap their heads around. No problem. I mean, it's it's it'll kind of be boring like other when you look at the CNCF one as an example. It's not super exciting but kind of quantifies the structure values, etc. How things work. Chris, maybe I can ask one question. So we've got this growing community in China. So maybe can you speak to how the Linux Foundation would be able to help Jenkins expand in China and do more there? Yeah, sure. I mean, we actually have a legal entity all set up there. So, you know, I don't know if you've ever gone through the experience of getting business done in China, but there's this complicated like ICP license that you have to do in order to register like a WeChat handle for Jenkins and manage it properly. We could do events. You know, one option for the Jenkins community and kind of the city of community in general is we have open source summit China or KubeCon China. You're more than happy to do like a co-located event there if you want to do kind of grow the community there. But we have all the legal things in place to do events, social media type handles, registrations, websites, etc. So, if anything I can help, please let me know. Awesome, we'll do. You know, I think one thing I'll be kind of blunt with folks is like there's always a bit of kind of like a bootstrapping period where you're just kind of getting the thing, you know, up and running and operational. So, you know, just please expect that it takes a while to kind of expect us to get it fully operational. Well, I guess if nothing else, I guess it's on the 30 minutes more so we could call it a wrap or Yeah, I just wanted to thank KK and Tracy and Chris and everybody else who's been involved in getting this ball rolling and all the work that you guys have been doing so thank you very much for your for getting this all in process. And then, yeah, Tyler, I think this is a he's he's also like a key part of getting this. Yeah, definitely. Cool. All right, and we'll keep talking about this. So thanks for thanks for being a part of this, especially Rick, I know again, like in your time in your times on this is a crazy hour. So, I appreciate that. I'll talk to you in I'll talk to you in some other place and see you soon. Thanks everyone. Thank you. Thank you. Thank you everybody.