 You've got eight out of nine. Cool, Alexis, go for it, Yura. I'll meet myself. Thank you, Chris. No worries, go for it. So let's move on to the first slide, please. Next one, the next one, right. So who's not here today? Just Sam Lambert. Who's not here today? Just Sam Lambert. Okay, thank you. So agenda for today, for me, the main topic will again be to work through the categories as we can. If we have time, which I hope we do, we'll have a quick kind of graduation review for Caudia S and Caudia D. So let's crack on. Next slide, please. Amazing news, ReQubeCon. See you all there next week. Next slide. Start booking 2019. Next slide. This is important. The governing board now has 45 candidates for T to C positions. Do you wanna talk through the process a bit, Chris? Yeah, go to the next slide, Taylor. Yeah, so we have 45 candidates for the governing board selected seats and five candidates for the end user seats. We're currently in the, what is known as a qualification period where governing board and voting folks are able to reach out to the candidates to ask them any questions or essentially do anything they want to kind of vet the set of candidates after this two week qualification period closes. There is a vote to see if these candidates are qualified nominees. Once that happens, that final list is when it will be voted upon by the respective voting folks, whether they're governing board or end user seats, and then we'll close the election and post the new TOC seats by January 29th. If you have any questions, let me know. I had one, Chris. I was just curious, the condescent voting system we use doesn't work terribly well for large numbers of choices like that. I mean, limited to seven. Do we have any thoughts or plans around that? It's literally kind of baked in the charter for us to use condorsed IRV. So it is just ranking 45 people, which it is a little bit painful, but the first time we did this, I think we had a good 20 or 30 set of folks last I recall. So it does work, it just takes more time on the person ranking folks. I've forgotten who actually votes. Governing board for the governing board selected seats and then the end user board votes on the end user seats. Right. Yeah. The other thing, Quinton, you don't actually have to rank all 45. You could basically just pick your, let's say six for the governing board and then just leave the rest ranked last, essentially. But it's up to you in terms of how you want to vote and do it. Oh, no, I just thought the algorithm itself did not work for large numbers according to what I read, but if it works fine, that's fine. Yep. I haven't had issues in the past. Because any other questions, feel free to reach out. Otherwise, we'll chat categories. We'll move on to the next slide. Okay, so we're in the categories. Great. So sorry, can you go back please? I beg your pardon. So thank you very much for the feedback on categories and SIGS. There's been a bit of discussions since in the last two weeks or so from people on the document, which is the right place at the moment to discuss it. I particularly want to thank the folks around the SAFE Proto-Working Group who've been helping out by proposing SAFE as a kind of concrete example model for what a SIG should do. I think it would be useful to actually just look at that right now if we can go to the categories page. In fact, maybe even Taylor, you could, I don't know if it will work to jump across to the, let's just look at it on our own screen. So just click on the document, press it's both of the link in the, in Slack. I have it here, I can share it if that makes it easier. Yeah, why don't you do that? I mean, I'm just slightly worried that it's just gonna exceed the screen. But yeah, we can't share two things at once. So we'll have to, here we go. So let's wait. Thank you. All right, so if you could go down please to the end of the document, there's a section about the security stuff from the SAFE people. Okay, so this is the example and this is designed to show what a SIG could look like as a mechanism for us to debate the details. So here you can see a mission statement which is quite general. Essentially asserts that there's more work to be done in open source security, especially the cloud native. And then has a kind of vision down there in the other bottom of what Quintin is showing you. Can you scroll down a bit please Quintin? And then is that, he may not be able to speak because he's in Barcelona. Justin are you on the call today? Justin Cormac, okay, maybe he's not. So you can see here is the need for new projects. So one of the things that they wanted to do was to make certain new projects and you can see responsibilities. And if you go down just a tiny bit more Quintin you can see deliverables. So opening it up to the floor, who thinks this is a plausible set of deliverables for AC that are presented to the TOC, which is the voting body meeting on these calls and in GitHub? Yeah, it looks good to me. The one thing I see missing from deliverables there, and I just read them for the first time now is basically the health and welfare of all the security related projects in the CNCF. Is that sort of implied there? Right, I'm actually, okay, I'm just gonna make a note of that now. Is anyone miniting this conversation? I think we didn't get enough minutes last time. Okay, I'm gonna add that to the... I can take minutes if no one else can. If you wouldn't mind. I'm also gonna edit the main document. So I'm gonna put project health checks liaison with CNCF staff, because I think Chris and Co are doing some health checking. And I'll put it at the bottom as well, okay. Sorry, I can't edit the notes. Will I stop projecting this document? Okay, never mind. Let's come back to that. And help with health check of projects in the category. Okay. Right, Brian Brown, do you have a pronounce or stuff a little bit cautious on the notion of a safe working group? Do you think this is a better, tighter set of deliverables that would bring you over the line? Or do you think we need to say more or less, maybe? I hadn't caught up with the recent changes in the documents. So I'm still reading through the mission statement and such deliverables. I think it's really important to have deliverables that users will understand and that are broadly applicable to both users and to the projects. I don't, just reading the deliverables alone, it's not clear that they do. So I'm reading through the rest of the background. Brian, I see you made a comment there about the serverless work white paper being too long. Just some other feedback there. So I was involved in the storage white paper and we didn't target a particular size. We targeted a goal of explaining a particular area and it turned out to be about the same size as the serverless one. I personally found the serverless one very useful. And I think if it had been significantly shorter, it would have been significantly less useful. And the same was my experience for this storage one. I can certainly see a value in having a summary of those papers for people who don't want to read a 30 page document. Is that the essence of your comment there that we should have a summary of the document as well? I think it's, that's one issue and it was specifically with that document. I haven't read the storage working group white paper. I did review and comment on the serverless working group white paper. I think it could easily have been multiple separate documents that were more focused and more targeted. It was really, really broad which I agree has value to some people. I haven't really seen that much discussion of it from people outside the set of people who are already deeply involved with CNCF. So I don't know what kind of impact it had more broadly. But that's one of the issues. I am practically speaking, I think we need to understand who the audiences are for the things we produce and what kind of impact we expect them to have. So one of the audiences that we could state more clearly is it's implied in all the stuff around education. And I think that we don't yet have a good joined up story for educational material coming out of the CNCF which I think is a mission fail. I think that having a more focused attention on each category through the SIGS could help with that and maybe provide a focus for CNCF staff to provide resources to help to solve specific issues. Yes, so that would be one audience. And then I think another audience is the TOC which is ex-hypothesis bottleneck and bandwidth constrained. And that's part of the thing being solved by this. I think what other audiences are there? Do you think maybe the community at large? I don't know. Well, I think another example that has been brought up by many people is the landscape diagram, the full huge landscape diagram in terms of who the audiences and what impact we expected have. I think we just need to be a lot more deliberate about the artifacts that we produce and who is supposed to make use of them and how and what effect do we want it to have. And I think the cloud native landscape is big and it is complex. And if we can help users understand the impact and help them understand what the pieces are and how they fit together and how we'll improve things for them but also what the risks are and how they can mitigate those risks. We're gonna need to be able to distill it down into something simpler. And working groups don't need to solve this entire problem independently or by themselves but I think my other concerns with working groups are more one concern is that they need to provide value and we need to understand what that value is but also we need to just make sure that we organizationally understand how to run them in an effective way. Right. So that comes under execution, you know. If we don't have a mechanism for articulating work and then finding out how to get it done we're not gonna do anything. So. So, you know, one thing that I can't help but notice with these is that the deliverables for example in the safe working group or safe SIG that we have are a mix of it's like they're a mix of high level research, thought leadership, you know, landscape building, you know, definitional stuff and then there's just some like very nuts and bolts for core on product project security help with health checks. And I sort of wonder if those two things belong in the same group. Like I actually think it's very easy for us to say let's create a working group whose job is really like reporting on project security like helping with the actual nuts and bolts work of making sure that the projects that we have in the CNCF are secure and they have the resources they need to, you know the handle vulnerabilities and timely manners and da-da-da-da, mixing that with the thought leadership pieces. I wonder whether that's where we're where we keep getting tripped up in these working groups and SIGs. Is anyone else concerned about that? Or is that. So this is Matt Frenner real quick, you know to jump in to take this from kind of the Kubernetes perspective, what we've done over there is we'll have like an organizational unit and then it'll have, well, sub projects. And I think in the document Quitten might have brought this up. And so in a sub project, you might have, you know an area, which is what a SIG owns and then a sub project is a concrete thing. So maybe one sub project is going and producing certain reports around target audiences. Another sub project is about educating project maintainers on security and helping them audit it and get to where they're going. And you might have different sub projects because then if you need to know, okay, I'm going to this kind of thing who owns that, what area do I go? Who do I talk to? You know, you've got one thing, but that one thing may have more than one area of responsibility. And Kubernetes organizes those into sub projects. Not every SIG has them, but many of them do. Guys, otherwise how do you organize and find things? Yeah, I think I do share your concerns, Camille. And I think that the model that Matt suggested is a reasonable way of dealing with it. The alternative is to have, you know, two separate sets of organizations, the execution branch and the, you know, governance branch if you like. And, but then if they get disconnected they don't work very well either. So having them fundamentally connected is a good idea I think. And the sub project model does that. In Kubernetes SIG apps, we actually discuss this at length because we have a bunch of high level things where we've done with helping facilitate the community and get people thinking about app development topics in general, and at the same time dealing things like the workloads API in Kubernetes. And we talked about separating those and what it would mean fundamentally. And we, one of the things that hit us is we want the practitioners talking with the people who've got the problems and are trying to solve it so everybody can see where everyone else is coming from. And it's kind of like that thing of if you separate theory from execution, where do those paths go? Can the theory and can the teaching really solve the problems if they're disconnected from the execution? And for us, we chose we didn't wanna go that route because we thought it would lead to problems. Are the practitioners part of that SIG? Is that an assumption you can make then? Or is there additional process that has to happen to bring those opinions into the fold? We try and have everybody be part of the SIG. We do have sub-meetings and breakouts and things like that around specific topics if those are needed, but we make sure everybody's involved and invited and up to speed. Well, and I'm part of the Kubernetes storage SIG and I know that I think it's just kind of everyone in there and I wouldn't say we have a huge amount of customer input always. We try to consider that as an angle, but I don't know how to get all equal voices, which I think is what you're proposing and information to everyone, so. I don't think there is a way to get everyone, but I think if we go back to the audiences, if we understand and well-defined our audiences, then we can get more information. In fact, over on Helm, one of the things we did was we said, who are our audiences? And then we stack ranked them and then we had information on them because we wanted to say, where does an application developer come differently from a tooling developer, come differently from a package distributor? Because we understand, we wanted to have roles and then some details around profiles around those roles that we could talk to them because we just say developers and end users, really who are those and what are their needs? I mean, I don't even know if we have that documented or even a base documentation to get going from a UX perspective, so we can start building off of that. But without those details, we're all guessing and going in different directions on it and maybe not having much detail, right? And this is Dan Shaw here, one of the chairs I'm safe. Yeah, I would echo the fact that we, definitely needed to bring together a lot of people to build up the critical mass of expertise around security, having multiple groups out there. I'd love there to be, multiple groups of dense activity around security. In this particular realm, I struggle to see that emerging as several thriving groups. It's a lot of work we put in over the past year, bringing together all of those perspectives. So safe actually, I think brings up a really interesting point when we talk about space and bringing it up. Because if I go look at the safe working group objective, it says secure access for everyone, safe. Working group will explore secure access, policy control and safety for operators, administrators, developers and end users across the cloud need of ecosystem. But if I look at security, right? What about signing your releases and then distributing them and having your signature be done differently? That's a security practice, right? But does that fit into safe? And in the safe document here, I see safe, but then I see security as a general thing. And I get that there's a bunch of things outside of that small objective of safe. And so I can't, is it just meant to be a subset of security or security in general, right? So I was in visiting that at least initially, there would be one group, which was both security and safe. And we can evolve that later. I just think the role of this right now is just to provide a very concrete example of some people want to do. And so we can actually ask questions like the one Camille posed about the commingling of different granularities of work and responsibility, for instance. So let's not worry about that last question too much right now. I think one of the questions is, can we even come up with a model that's able to execute useful work? And I think the other question is, what is the dividing line between what the TOC does as a voting group and what happens in the SIG? Those for me are the two really key questions. Enabling people to get real things done so we don't just waste time and making sure that we have the right delegation and accountability. Yeah, and Alexis, one way to phrase this may be the questions that we on the TOC want the SIGs to either answer or to flesh out. So the questions that I have are in this space. And I think the worked example is great and we just need to not fall into the trap of only looking at the worked example, right? We're trying to use the work example to motivate the more abstract ideas. But the questions that I have are, what are the established practices in this space that everyone agrees are kind of the lowest column denominator, and there may not be any. I mean, for some of these spaces, there may be the approaches are so radically different. If there aren't any, what are the kind of common approaches? What are the emerging things? What are the things that people are experimenting with? And there I would expect there to be a couple of different approaches and a couple of different ideas. I think when we establish the landscape, it needs to not be as certainly not as a set of icons on an unreadable I chart. But I think we want to establish the landscape with a narrative that established that there are probably different, there are different parallel paths or different ideas that people are experimenting with. There are things that are more emerging. There are things that are more established. And I think that we might want to phrase those as questions that we want the SIG to ruminate on. And I can try to be more specific here on the dock. As opposed to, I think we want to, when we establish the landscape, we, I think we want to prevent the SIG from becoming a true governing body. I think this is where the storage working group ran into trouble. Those who are in the storage working group can correct me if you disagree. But I think where they felt like they've got to adjudicate a single path. And we don't actually want a single path. We want to know what the paths are that are out there. Does that make sense? I agree entirely and I don't know if everyone's aware of it, but we kind of reformulated the storage working group specifically around that idea. That was the crux of the matter. And I think the white paper that came out of the second phase of that seems to have been well-received, very well-received. Because it's precisely that. Precisely what, sorry, Brinton? It's precisely not dictating a one true way of doing storage. It's an exploration of historical storage models where the strengths and weaknesses are in the context of cloud native, more established cloud native storage models, their pros and cons and emerging storage models for cloud native and where things might go. And try and provide a transparent unbiased view of that space such that we can educate users as to where the potential solutions to their problems are. What we haven't done yet and which we would like to do in the next phase is actually get case studies of failed and succeeded major projects so that people can learn from others who've gone before them as to what things work well and what things didn't work well. And I'm sure the same principles, similar principles might apply in other areas, like security, serverless, et cetera. Okay, so we can put, I'm just putting down notes there and then further up in the education section or the end user section, publish list of use cases and published examples of failures to avoid. Okay, okay. So we're just conscious of time. Does anyone else have a major thing they wanna say right now about this document? I think we made it move this forward a tiny bit today. I really like to think about how we can take the next steps in refining what we have here and turning it into something a bit more compactly written and expressed that we can start to really start to kind of tear the vote on or maybe a tear apart and so on. Does anyone want to volunteer to help me to really tidy up this document? I can help if you need my help. Is that? But I wouldn't wanna get in the way of anybody else. It's Quinton. Oh yeah. I'd be happy to step back if anyone else has the inclination. Just because... It's gonna be a post-CubeCon during Christmas holidays project for whoever volunteers to help me. And Alexis, I'm happy to help you distil the questions that I think we would like to ask the SIGs to answer. So I'm happy to take a swing at that. Okay, so Quinton and Vernon Cantrell, anyone else from the non-voting TOC, what are community interested? Erin, I'll help. Erin. Hi. Hi there. This is Matt Farina, I'll help too. Okay, that's awesome. So Matt, Erin, Quinton, Cantrell, I'm gonna write that down. And are any of you not at CubeCon next week? I'll be there. Alexis, I'll be there, but I leave on Wednesday morning. Okay. So I'll email you about maybe meeting up or something. Cool. Right, so Chris and Taylor, please can you take us to the next topic which I believe to be the core DNS graduation discussion and Quinton, would you like to go to the screen? Great. Taylor, would you mind projecting again? Thank you. Okay, Chris, what's the process here? Let's, is Francois or anyone from Cordianus here to present? Okay, perfect. Cool. Go ahead. Yeah, thank you. Good morning, everyone. So my name is Francois Tur and I am one of the maintainers of the Cordianus project. So Cordianus, I guess it's the time of the annual review just to recall that we did the first applying as inception project in March 2017 and then almost one year later, it was the first annual review where we applied for incubation in February 2018. So now is annual review, but on same time application for a graduated project. Cordianus, I just remind a little, it's a projection grade DNS server in goal language. The main point is it is a return in plugins and actually plugins that make it very easy for any user to adapt for whatever you want either by reusing existing plugins either by writing your own. So what we did during these years, I mean, since March 2017, we have a bunch of plugins available and we tried last year already to start, we started to develop plugins for Kubernetes, which that means several plugins. The one, the main one that say, okay, we handle Kubernetes as an authority server, DNS server, but there are also some about federation or Kubernetes that allow several to handle several cluster. What we did this year, so here is the year is, the main point of this year is adoption of Cordianus. So here I show 25 public position users, I guess there is much more. 25 is because we did a survey thanks to CNCF to know who is using Cordianus. And then some people replied, yes, I'm okay to show up in your adopter list. What we did this year is, okay, follow-up is more unsure that Cordianus is reliable, is perform as expected and has a right tune age. So it's more maturity of Cordianus on one side and the other side is integrate Cordianus as a component of Kubernetes. That was already in the plan when we presented for incubation begin of this year. So now it is done. So I'm happy to copy pass this morning the tweet that happened yesterday evening that show the release of Kubernetes 113 that was released yesterday and that say Cordianus is a default DNS plugin. It was, it is the major, one of the major achievement of this year for Cordianus. However, now that we have this maturity and we have all these stability on Cordianus, we are pushing for a new plugins that will come, they are under review right now that will come in coming months. Can we go to next slide? Thank you, Chris. So Cordianus community, I don't know how to show, I know that each project I try to show here, I took the numbers we showed up at begin of this year and where we are right now after one, a little less than one year. So the contributor, for example, went from 40 to 112. The more amazing thing for me is the Docker pool, the 10 million Docker pools from our Docker Cordianus which does not include the Kubernetes pool for Cordianus because in that case, we host the image of Cordianus in the gcr.io. So it's only for the Cordianus repository. What I wanted to show here is maybe on the, this graphic on the bottom is what happened for the adoption by the developers of Cordianus. So you see these two lines. So one is the stars, but the second one, that grew up the same way and you can see the increase from inception incubation radiation is the fork of the project. So that means you have now 450 folks of Cordianus, means people that try to understand, try to maybe make a little change or just to browse and understand what happened inside. And that's a huge achievement also. So that's the numbers, I don't know. And next one, thank you. So that is the application for graduation. We show here that we fit on each of the criteria that CNCF defined. So there is a PR open, there are stats. You can follow the stats for the project that is stats that are monitored by CNCF. As we have 16 maintainers, Cordianus is more independent developer oriented than company. So we have company involved, but most of the maintainers are independent or prefer to be considered as independent than part of a company. We have last, I think last, like last year, 12 release. So that means quite often high rate of release. The rate of peer merges a little lower or little, I just say steady. It did not go up because we focused more on the reliability on the performance than to add and add and add features. So one thing, so globally this peer has been approved by Jean-Natan Boulle that is our sponsor for CUC, the sponsor of Cordianus. I don't know. I guess now the process is for everyone that has to vote to maybe go into that peer. I think that's all what I had to say for the presentation. Let me know if you have a question. I have one. Yes. Yeah, I was just curious. So from what I remember, Cordianus originated out of CoreOS, is that right? No. CoreOS, no. Then I retract my question. No, it's not the same kind of name, but it's not linked to that company, no. Okay, but it is an LCD backed DNS server. There is one of the plug-in is HECD, yes. Okay, my apologies. You can use that HECD as the backing but it also can back by other things. So when we use it with Kubernetes, it does not, it's not backed by HECD. It's directly talking to the Kubernetes API server. Okay, thank you. Just telling me, they had some kind of a change. Any other questions from the TSE or the community? Are there major uses of Cordianus outside of Kubernetes or is it mainly Kubernetes? There are some, that's why on the first slide, there are two kind of usage, yes, out of Kubernetes and inside Kubernetes. It is sure that, let's say, some Cloud and for blocks admiral are using as DNS service. Sometimes they're also using Kubernetes around but they're not using on the, they're not using Cordianus as the standard usage in Kubernetes. However, I mean, the size of Kubernetes make that, I guess that a big proportion of the position user would be within Kubernetes. And we can see, I think there is an ongoing CNCF survey that show that all version, within all version of Kubernetes, now that 45% of the responder to that server say that they are using Cordianus as the DNS server for Kubernetes. Does it reply your question? Yes, thank you. Of the 16 maintainers, how many are active in the project still? Well, they are all active, but on the 16, maybe you can have a set of five, six that are much more active, but they are all maintainers. There is a, okay, we talk a lot of how, how for this graduation criteria, we had to write down our governance. And so that was a kind of process where we had a lot of talk. The ex for the governance, we wanted to be open for maintainers. So that's why we have an important number of maintainers. The one that are more active, I think are the six or seven first one in the list. If you look at the six or seven first contributor in Cordianus. Okay, thank you. Okay, let's move on to the next presentation. Cool. Thank you very much. Thank you, Francois. In terms of order, if the original TOC sponsor, someone else from the TOC wants to propose this for a graduation vote, they could do that. So feel free to reach out to me if you intend to do that. I think that was me, right? On Cordianus, it was Jonathan Boll, I believe. I was Boll, okay. So he's online, do you want to ask him now quickly? Yeah, I'm happy to sponsor it. Does that mean we need one other person as well? No, we just need one person to say do a vote and then we'll vote whether it graduates and he needs two thirds, super majority to graduate. So if you're okay with that, Jonathan, I'm happy to kick off a vote formally. Okay, cool, thanks. Thank you. Okay, fluency people. We had Eduardo. Hello, everyone. Hello, hello, go for it. Hello, can you hear me? Okay, thank you. Well, my name is Eduardo Silva. I'm part of a fluency team since a lot of years and the goal of this graduation presentation is try to demonstrate our website status of the project since we joined it incubation on November, 2016, two years ago. So nowadays, fluency is like real production grade login solution and it's been used mostly by major cloud providers and major distribution companies, the distributed communities or also standalone solutions that are not containerized by like Google, Microsoft and Red Hat. In terms of growth, we have seen a huge growth in the last years and for example, in the last 10 months, we have seen around 35 million docker pools from our official registry. And since then, this has been growing a lot in not just how many people this use in fluency with Kubernetes and standalone services, but also from a community and developer perspective. Next slide, please. Okay, in the last year, so the first year after inception at KubeCon, like it was one year ago in US, we released it through in D1.0. And since then, we had done like 62 releases and the last release that we have available is 13.1. That was available since like seven days ago. And also we have seen some kind of awareness and knowledge on our GitHub repository where currently we have like 7,000 GitHub stars. Next slide, please. One important thing to understand about Fluency itself that it behaves a bit different than in the way that works with other projects with the developers and ecosystem. Fluency itself is like a really small code base, but most of the major features and extensions that are available are based on plugins. And plugins can be created by anyone or any company. When we joined it on incubation, like two years ago, we had like 600 plugins. And nowadays we have more than 800 plugins which has been updated in the last year. So we are quite amazed because you will understand that we as maintainers, maybe we focus in the Fluency core base and also on no more than 20 plugins. So you can see that our many companies contributing back in their own way. And since Fluency of course is like a base on a Ruby ecosystem, that these plugins are published in the Ruby gems registry and everybody can get them and take advantage of that. In addition to the plugin as an ecosystem, we also provide like language SDKs. So for example, if you're writing your application, Go, Node.js or any kind of language, you can ship your logs directly from your own code to Fluency. So Fluency can also behave not just like a log forwarder, but also as an aggregator. And we have seen most of this model where people ship logs from application to Fluency is mostly outside of the Kubernetes world. And we've got a lot of traction with that people writing application in Java. It's using that in Python and Go. Next slide, please. And in the last time we did, so since we joined in the incubation phase, we've focused a lot on how to be a better citizen with the enterprise or major solution that are around for different areas. As you know, as a login solution, you need to connect the dots between different input source of data and ship that data to a central place or a different cloud provider. And there's a lot of complexity between that because you need to deal with data formatting, parsing, buffering, doing to provide a reliable way to accomplish that. And I will say that in the last time we have focused a lot on Kubernetes, a good integration with Kafka. We maintain also official plugins for Splunk, elastic search integration for Node.js application, which is a custom thing. And also we did a better integration with Prometheus. So in general, we have tried to make an increase for the whole adoption and work better with the community in terms of create for the more extensions for it. And also we focus a lot on how to integrate better with the enterprise. And we're quite happy that whole fluidity has been growing in the last time. And I think that, so the whole thing is pretty happy and our goals for the next year is start working in the next version will be two that old. So that will start since in January. So in representation from the Fluentd team, I would like to ask for the TLC to start the voting process. And if you have any questions now, please just let me know. Thank you. Yeah, I had one that's Quinton here around your 800 plugins. On the one hand, it sounds very impressive. On the other hand, it maybe makes me wonder how specific these are rather than being more general. I was curious, what is that landscape of 800 plugins look like as far as I understand, there are producer plugins and consumer plugins. Is that true? Yeah, actually we have more categories. One of them is like we call it input. When you say consumer, we have filter plugins. We have parser plugins, buffer plugins and output plugins. So all about what you need because sometimes you have the right plugins to consume the data but you need to write your specific filter to parse, sorry, specific filter to apply some kind of threshold or I don't know, obfuscate some data that is coming in from your source. And also people try to create their own parser because the data doesn't have a proper structure and they need to structure that data in a special way. So the best way is the insert of Extend Fluent D for that in the code base, we provide a flexible ecosystem with plugins so people can create their own solution and the way to do it is using like the RubyJM ecosystem. What the code can be Ruby or C and then people can pull those plugins easily because also in the Fluent D distribution, we provide our old tooling to get those right plugins for the right version that Fluent D is running. Okay, thank you, that answers the question well. Thanks. Any other questions? Okay. Who was the original sponsor of this one, Chris? It was Brian, Brian Grant. Oh yes, that's right. Yeah, I mean, I'd encourage everyone to also look at the stats of these projects as we look at the graduation reviews from the Project Health dashboard I posted earlier. What would you, could you just get a couple of snapshots for the two projects and just attach them to a post that would be too powerful? Yep, yep. The DevStats is really good, Chris, good job. It is still quite, it's quite a kind of information encyclopedia that I think not everyone will immediately understand how to use. Yep. Okay. I'll see, go ahead. No, no, you go ahead. Yeah, no, no, I sent out a note on the mailing list if there's feedback on the Project Health dashboard that's kind of in beta, but there's a lot of information there right now. Yeah, so it'd be good to see how you would see this dashboard being used to assess progress for something like Fluent D. Cool, okay. Please can we go on to the next slide, please, Tanner? I think we could probably take this over the line. Yep, pretty much. Yep. Got up six minutes left, so if there's any questions. A few reminders, there is a Meet the TOC public session. I think it's on Tuesday afternoon. Is that right, Chris? Yeah. And I believe that there is also an opportunity for anybody to book a meeting with individual members of the TOC if they make themselves available, which the CNCF will handle. Chris, how do you plan to publicize that to people? We need you to sign up first in terms of availability for TOC members and the link that I sent to you and then it will be posted on the schedule and people could just show up. Okay, any other things? Chris, is there a demand for that? It strikes me as peculiar, honestly. Lots of people want to talk to TOC members to potentially bring in new projects or get feedback on stuff. So yeah, there is a bit of a demand. Okay, but is that what it's about? Because I really do, I mean, I don't know that have booking time for us to be individually lobbied by projects is a good use of anyone's time. Well, I think people are gonna find you one way or another, but there is demand for it. So it's up to you whether you wanna sign up for it or not. Fair enough. Okay, thanks. People just wanna meet you, Brian and hug you. Almost disgusts me. Okay, anyone got any other questions about kind of meetings, gatherings, parties? Next Monday, there's a GBE face-to-face. Really anything to do with KubeCon there that any of us should take away the action before KubeCon that's burning for itself? So there was some confusion, I guess, about whether the TOC was invited to meet with the GBE. Sounds like we are not in general. Would that be for the Monday afternoon GBE meeting or for some kind of social event? For either one. Okay, I think it would be a good thing for the GBE to mingle with the TOC once in a while. And maybe Chris, you could see if you can pull some strings there. Yeah, yeah, generally not for the board meeting, but for social events, we could be a little bit more flexible. Let me check to see what we could do. And there was last year, and there seems to be a change that there will not be this year is what I just heard. We can have a kids' table for the TOC. We can all wear our special class for the mining teams. Yep. Okay. Cool. Thank you, everybody. So was there ever an event organized for the end user group or jointly between the end user group and the TOC? I suspect Cheryl would know the answers to that. And then if she's on the call. Yeah, I'll follow up. I'll follow up with Cheryl. I believe she's at DockerCon right now, so she's probably not online. But I'll follow up. Yeah, thanks. Good luck. See you next week. Bye-bye. Cool, take care. Great, thanks, everyone. See you next week. Thanks, bye. Bye.