 As people keep joining just to make sure it sounds working for everyone. Sound is working, Richie. Hello everyone. We will wait a few more moments for folks to arrive. We're trying a new format today. All right, Amy, do you think we got enough to get started? 21. Yeah, 21. We're going to get so like. Yeah. Awesome. All right, welcome everyone today is Tuesday, December 5th. You've made it to the meeting. So you're familiar with the logistics and the LF antitrust policy. Notice if you're not, please take a look at the slide deck that went out on the mailing list. We have several to see members present here today, but we are not making any voting decisions. We're trying a new format. So to see is going to talk a little bit about our current work and then we're going to go into discussion and then Q&A with our tag leadership. Right. Next slide. So quick update from the TOC. Now, hopefully we've resolved any confusion associated with annual reviews. By the way, tags. If you do have some confusions or questions on these, do speak up during the discussions person. The TOC is going to be picking up any annual reviews that are not tag labeled. That means if you go to the TOC project board and you click on annual reviews, anything that does not have a tag dash label associated with it, the TOC is going to be conducting the annual review for that. There are several that we have already done that are complete and have been merged. Any projects that are falling less than 50% of what we kind of expect from a sandbox project will be opening an issue directly on those project repositories with our roadmap and kind of a little bit more of expectations for bringing them back into a good state of health. Any annual reviews with a tag label on them, we're still looking to the tags to have those completed. There was a question on whether or not that can be extended due to contributor bandwidth availability in the impending holidays. So I believe we've made that available through January 1st. To give folks a little bit more time, but if you do have any questions on that, reach out in the TOC channel or chat up your TOC liaison for your tag. And then we also have three TOC members that are going to be providing direct feedback for project health review and automation. Amy, did we have who they are listed? I'm forgetting. We didn't, but it was Duffy and it was Aaron and it was Justin. There you go. So if tag leaders, if you have any feedback on project health review or automation, reach out to those individuals. I believe we've captured most of what's been discussed with the tags based on the November 16th meeting. So those will be included in there. But as with all things in software development, we start with a few small changes and then we iterate and improve and move forward. So we're not going to get it all done at once. Based off of our last discussion we had, we're still looking for feedback on a few different topic areas from the tags. What's missing in the ecosystem that we're not covering as well as what should the tags be focusing on, kind of a little bit more about the scope and the charter of the tags as well as how they're engaging with projects, how they're providing information out to adopters or guidance. So those discussions are over on the TOC repo. And then December 12th is a sandbox applications review meeting for the TOC. So tag members, if you have a moment, please take a look through the ones that are in the upcoming queue and provide any comments, feedback, insight based off of your knowledge experience and any presentations associated with that particular project that certainly helps the TOC in our decision making for acceptance. Any questions, comments, feedback, additions to the TOC update? All right. Let's move on to TOC and tag discussion. So during our KubeCon TOC tag meeting, there was a proposal to shift how we're doing our monthly tag updates to be more discussion oriented. So we threw together the slide deck I've already gone through with the pre-reads on all the tags. So you'll have comments on your slide. TOC members I know are also still providing comments on some of that. So please take a moment to respond to those questions. But in the interim, I wanted to kind of open this up to discussion for folks. What tag supports projects related to messaging and databases? We can certainly start there. Tag storage, how do you all feel? I created this. I was hoping the tag storage would say yes. Yeah. So hi. This is Xing, one of the tech storage here. So, yeah, I think this should be part of tag storage. We already have Provega in tech storage, which provides storage systems to support streams. They actually publish a blog comparing Provega with Kafka. So I think this, let's see what is this, the project name. Streams, yeah. So this should be operator to support Kafka. Yeah, should be part of tag storage. So anything has to do with data, right? So that's for streaming. That should be part of tag storage. Databases, where we also have, we have Vitas, supports the horizontally scale my SQL. We have been talking to Clowny to PG, which supports horizon operator for Postgres SQL databases running Kubernetes. So any projects that has to do with data, I think that should be part of the tag storage. There are also a few projects for key value paths that are already part of tech storage. Okay, that sounds like we need to make sure that we have those well documented for tag storage because I'm assuming the question came up because it's not immediately clear for a lot of community members. Yeah, yeah, I agree. So we probably should be doing that. Maybe update our read me section for our page. Okay, yeah, let's do, I will do that. Yeah, we do have to start with that. We have, we have those projects listed there, but it's just, we don't really have categories to describe what they are. It's not clear. Yeah, this was an open question that we had during the Kubecon meeting is the kind of the subdomains of each of the tags starting to document what those are, checking in with your liaisons, ensuring that they make sense and that they align. Josh, you had your hand raised. I'm curious what your thoughts are here. Yeah, one of the things that's about to come up for the tag storage for tag storage because of what's in the sandbox queue is needing to come up with some sort of working rules to define what is a cloud native database and what is not. Okay. Because there's a project in the sandbox queue that is a database that is certainly usable in a cloud native context, but it's also quite usable outside of a cloud native context. Okay. And, and tag storage is going to need to start, you know, decide, you know, because need to decide when, when is it that we say no to a new database that wants to be a part in the CNCF because it's not cloud native. Okay. Okay. So that's something we should work on. Yeah. Okay. So yeah, I will pin you flying as well just to talk about this and talk to other tech leads. Alex. Hi. Sorry. I was late joining the discussion on the concept of what's included as part of the work that's going into the landscape version two, we should probably also make sure that those projects are appropriately tagged that way too. And it kind of gives people a bit of guidance. I do have a bit of a similar comments around things like databases when it comes to cloud native, but Josh mentioned right. We, there are, there's obviously, you know, things like and things like that, which are built for cloud native and designed specifically for cloud native. But I think we should also consider sort of things like cloud native operators and things like that. And that was something that's not, that's something that's not often clear and often has been debated as to whether operators count as a project. And in many cases, the operators actually make something that's not cloud native cloud native. So maybe they should be considered as a project, but it's a bit of a gray line. Yeah, but that's something that we've talked about in the past. Katie, I see your comment and slack. That was something that we had talked about in the TOC tag offsite was defining the scope, the domains, tools that fall underneath of each of the tag categories. So it's still work that needs to be done probably moving forward through the net through into the new year. Justin Cormack, I know you had your hand up. Yeah, sorry, I was just writing in the name, but I mean, I think, yeah, I think we do consider the cloud native projects and appropriate and then SCAPE, but it's just we're not sure if they're sustainable as standalone projects as a, you know, kind of standalone thing. But I think from this point of view, the scope of the tag, they're very much in SCAPE and, you know, they're an important part of how people use things. It's just a moral question of viability as a project, as a standalone project that's been the issue rather than in SCAPE or out of SCAPE-ness. Other comments on this? Like the conversation has shifted a little bit into operators specifically. Matt? I'm not sure if now is the right time to talk about it, but as we're talking about how the landscape is divided into tags and subcategories and subcategories and whatnot, I've been doing some work with the landscape data and a lot of the reports that one might generate directly from it are somewhat potentially misleading depending on how the reports are generated. For example, open telemetry is represented in the metadata. We've recently recognized by a single project, the Java agent, Kubernetes is represented by just the Kubernetes repo, not all of the Kubernetes repos. So I've done some work to pull in data for each project for the entire org so that we can understand activity data and community activity. That's inclusive of not just the repo that's reported in the CNCF, but, you know, all the home parts and ancillary repos that are contained in the organization. So highlighting that from an initial look at just the observability sector, but I'm doing this for the other sectors because it's just a for loop with the same reports. You know, I think there might be a mismatch so anything that's aggregating stars for a project or number of commits, you know, it may or may not depending on if it's coming from DevStats or coming from ad hoc reports that use the landscape data directly as published without sort of adding an address. You know, we should shore that up to inform our discussions moving forward. That's the only thing I want to raise. And I'll have an update in a week or two. There's some work happening in my stuff in the landscape, Brad Freepo and in some notebooks, but those are my initial findings from the weekend. Okay. Thank you. I want to kind of circle back to tag scoping and subdomains. From tag leadership based off of what your current capacity is and your availability. Is this something that you all feel you can do before February? Having an initial draft of that scope and subdomain area for each of the tags. I think I saw head nods. I see. Yeah. Okay. Alex. It's not unreasonable in my opinion. Okay. That will certainly help lead into discussions. Yes, exactly for February 6th. Thank you. Matt. As a quick follow on, did we ever like formally settle or I assume it's still an open issue around whether we, we want to as, as I think keep the number of tags from growing. Too much so that we don't, you know, further divide resourcing, but have some way to. To indicate one projects or working groups or, or extremes or what, what have you are relevant to multiple tags. Is the, the new landscape to Jason. The right place to do that, which is sort of a super set of the older first version landscape data that we should be using some PRs to that repo, or as do we want to like work things out in other places and then move things more formally to get hub. Once there's consensus. I'm of the opinion we work things out outside of GitHub. And then once we have consensus, we codify it there. But I'm open to other opinions and feedback on it. Ideally, I'd like, like we have not set a cap on the amount of tags. I think it's always been where there's momentum and interest and alignment. That makes the most sense for having a tag there. That's how most of the tags initially got started. But we're seeing a lot more requests come in, which is why we've been pushing and staffing. Yes. Thank you, Josh, making sure that there are people available to serve in leadership positions to carry on that work. I think the other challenge that comes in is when we have some of these requests, we've been pushing them back into the working groups to try to make sure that they have the appropriate resources available for them to get started as a tag, to get started as a working group to get familiar with the reporting process, with the leadership, with doing deliverables, reporting, roadmap planning, those kinds of things. So what we've been pushing for in the TOC and any TOC member, please chime in and add additional color clarification and correction is to have a lot of these initiatives start as working groups sponsored by one or more tags. That dual sponsorship by a tag is something that's new and we're trying it out. We don't know if it works. I'm hoping it does. But from there, go ahead, Matt. No, I'm sorry. I'm sorry. I said, we'll see what we have multiple instance of that that I'm excited to see. Yeah, exactly the same. But the next question is once those working groups have been executing and are working successfully through deliverables engaging with projects, things of that nature, what are the next steps to promote them to a tag if that's the route that we want to go or in some cases it may be that the activity dies off because it's only a limited time kind of sense of urgency on providing any kind of information guidance instruction to projects or adopters. How how is this currently working for you all that have multiple working groups. I know tag app delivery has a very large scope. They seem to have a new working group almost every couple of months for yet another thing that's showing up, which just shows the growing need in that ecosystem. So, Josh, I'll I'll hand it over to you for your question. There's definitely room. I mean, even looking at like the platforms paper where we listed out capability types, which I think actually spreads across all of the the tags. So it wouldn't be fair to say all of the capabilities in a platform should go into app deliverance. Literally our whole organization here. But we do have we did form the platforms group a couple years ago and the artifacts group about six months ago. Artifacts has been. It's been interesting to watch it grow. And it's it's getting to critical mass. This last one. So this has been a top. I just wanted to raise it so people are aware that the discussion is happening to Josh Berkes point. You know, it hasn't gone further mainly because of resource constraints in tag app delivery. And so I just wanted to surface it to the top. We talked about maybe opening an issue in the talk repo, but we haven't. So here's just me putting it up here. There was a group that came and presented to you all a few months ago about API enhancement proposals, essentially API standards and common patterns that folks could adopt. And they came back to us and we recommended they consider forming a working group and bringing in related projects that, you know, try to put some structure around APIs and, you know, establish some standards and synergies. They did propose that. That's number 448, which I linked here. But it's, it's kind of died in committee at this point, because we really, we weren't confident that we could support them within tag app delivery. Maybe we can. I'm not saying we absolutely can't. It's just where the conversation has been so far. I brought it up particularly now because API curio or API curio, however you want to read that just submitted themselves to sandbox. That's also why I asked about messaging because API curio is also a little bit associated with Kafka and stream Z because people store their Kafka schemas in there. Yeah, but I just wanted to, to bring this up. I don't know that I'm actually asking for anything, but just, just to let you know that there's been that conversation. Okay. Okay. Josh Burkus, I know you had your hand raised. Yeah. I mean, one sort of open question for the TOC here is, what happens with projects that don't fall current within any current tax code, right? Because like this is an example and actually the API thing is a good example because there isn't a clear working group for it in the app delivery because or networking, which would be the other place you could stick APIs because there aren't people to run that working group, but it is kind of a distinct area of functionality. And actually the, there's a couple of projects currently in the sandbox queue that are basically API management. Clearly within the domain of cloud native, but sort of what happens to those projects? Does the TOC pick up anything we don't have a tag for? Do we try to shoehorn them in somewhere where the tag's not really prepared to cover them? How do we handle those? In the past, from my experience, it's the shoehorning problem is we try to identify a primary tag that that project can align most closely with knowing full well that there is definitely overlap with others. But that's how we've done it previously. Other TOC members who have been on the talk for a long period of time. Have you seen this play out? Or is this a new challenge that we have to face? Justin? Yeah, I think, I mean, we, sometimes we try to allocate them to things, even if it's not a perfect match. Tag app delivery and things like that, like as a kind of fallback. But I think that, yeah, I think we sort of usually kind of either, because we haven't actually, a lot of the time we ended up without an official list of which projects were attached to which thing. I think we lost some of them, you know, and kind of forgot. And now we're trying to make them more formally attached again. We're having to do the work that we have, oh yeah, they don't fit again. So I think we need to, we need to come up with a list of ones we don't think fit and have a discussion about it and understand where they fit better. And look at what, where we put them in the landscape and where we've, where they might go and where, and maybe talk to the projects about where they feel they go and see if we need some new tags to go with them as well or, or maybe we've kind of attached them to working groups, but as a new model or something. That's also an option. It still runs into the staffing issue of making sure that there's leadership to be able to facilitate that engagement and discussion. But I recall us talking in the past about having projects select which tag they're home underneath of. How do the tags feel about this? You all are the one that are experiencing either the joys or the pains of that kind of alignment. Alex? I think if we're, I think a tag needs to be accountable for purposes of, you know, reviews and graduation processes and all of that kind of stuff. But I also think that we could have sort of a primary tag and maybe like secondary tags allocated where there isn't, where there is some overlap. Like for example, I think when Harbor went through graduation, we had a similar sort of thing where, you know, there was either runtime or app delivery or was owning it, but storage got involved because there were, there was a lot of replicated storage components to it. So I think, I think that kind of works too where we can kind of have some shared responsibility, but ultimately one tag should own it. Okay. So we've observed and discussed the problem space a lot. We have some recommendations, solutions. Is there anyone that's interested in actually putting together a proposal so that we can make progress on this? Are we talking about the proposal on how we allocate projects to tanks? Yep. I can give it a go and work with somebody else if other people are interested. I was saying I'm happy to contribute, but my plate's full to drive to drive it, you know, as a race C.A. However, some of the data that I've been working up for both the observability ecosystem as well as the whole CNC up, I think, as I said, could inform that and I'm happy to prep that and contribute. Yeah. I'd like to help from, you know, from the perspective of what goes into a platform. I'm kind of curious how how our landscape will kind of map to that. So yeah, I'd like to help out. All right. So Alex, I am seeing Ricardo, Matt, Josh Gavante, Leo in chat. Karina, Max, I see your comments on focusing on the surrounding topics, but not necessarily a specific domain. Maybe it would make sense to have a caretaker tag with corresponding working group for each domain. That's also an option I would recommend working with Alex to include some flavor or optionality of that within the proposal to move forward with. Sounds good. Do we want to try and set a date for this? Yeah. I think we can start with the January 6th piece out there. I was also going to suggest starting a discussion over in the TOC repo because that way we can track it and basically put this back on like the agenda for, yeah, that meeting on the 6th of February. I know it seems both very far away and very short. Yep. That'll also allow you to direct any of your community members of the tags over to that discussion if they have an opinion or also would like to do that. Good suggestion, Amy. Thank you. Alex, given that you're now the lead for this, do you have an ideal date in mind as February 6th? Good. Or is that a little too soon? It's a good date as any targets. All right. So folks that are interested in this discussion on alignment of projects with tags, primary, secondary check out the TOC discussions part of our repo. Alex is going to be initiating a conversation there and for those that are interested, do please chime in on that discussion topic there. Excellent. Other topics, concerns, questions, consideration, feedback. Anything else we want to talk about today? Tags and TOC members. We'll start with the tag chairs first. How do you think this went? Asynchronous updates, TOC comments, and then an actual discussion. I think it's great that we're having these discussions as opposed to not having them before. So this is a big step in the right direction. All right. Josh, go on to the mat. I saw you both come off mute. I just was going to say I was happy to be able to bubble these up and have the discussion. So thank you. It's a welcome change. Josh Berkus. I think we're going to stick to the asynchronous. We should use a format other than slideshow. Okay. What would you recommend? Either document or get a discussion. Amy, how do you feel about either a doc or a discussion on that? I was actually thinking something even worse. Email back into the TOC list talking about what you all are doing. That works too. I want to be able to have the widest amount of surface area for people to see what you're doing and how to get involved. We haven't yet gotten to the point where the discussions are taking off over on GitHub. I don't want it to go into a document and die. We can change things up as far as there's not a ton that's really visual about the slide deck. It's usually mostly text. Yeah. I guess the only thing I worry about email is it's harder to change it. For instance, when I update the tech network slides, I can tag my co-chairs if they comment and I don't know if they will have time to comment. At least I offer them an opportunity and window to comment. I guess we just don't have time in the last minute. That is a good thought. That leads me back over to being able to do a discussion and we can do a discussion and then kick off with here's your updates for we're not going to do one for January because at this point it's January 2nd. No one's back in yet. We're going to have a discussion for the February 6th conversation. Here's the tag updates and if we do that we should also drop the slides. I think the consensus is around dropping the slides. It's a matter of how do we want to send the information out. I will add here that I've learned and I've probably mentioned this a few times with folks that maintainers don't always check out what's going on in the mailing list. If we're trying to make maintainers more aware of the work that the tags are doing maybe sending messaging out on the mailing list for those updates would get more eyes on that work and potentially drive more interest of projects back into the tags for closer collaboration especially around things like APIs and their frameworks. What do folks feel about that? Then we can leave the TOC repo for the future. I like that. I'm thinking for the tag updates we can send out emails but for any issues associated with any tags I think either TOC an issue I think is also good we have issues to track those and then people can give different inputs and that's also tracked that's my that's my thought. Any issues that come up with the tags where you need your liaisons if it's pressing obviously reach out to them Slack, DM, email but other than that an issue on the TOC repo should be enough as long as you're tagging your liaisons so that we can see it. Katie you had a question can we have the updates in the form of a newsletter once a month? I was actually going to go in a different direction with that. Here's our agenda for tomorrow email that goes out just respond to that email with your updates when you are ready and if you don't come by and get your updates I will come find you that seems like a really low key way to be able to here's the updates here's what's going on and there's one place to be able to make a home for it. Thoughts and opinions? What kind of format is it the same format as the slides or you have to be determined? I mean it's an email what do you want to put in an email? Anything? I still have a place for people to collaborate on that before responding because there are multiple chairs so if I'm sending out email then I maybe won't get chance for other chairs to chime in so if we have like maybe a github star with a github issue or maybe put that on the github discussion somewhere and then reply with that link I just thought there should be like a draft in place for multiple beauty collaborate before that thing to be shared with the community. Yeah I think that's a good point I think you know you can coordinate between these the tech chairs maybe that can be through a slide or google doc or whatever people can give comments right and after you sort it out finalize that and then you can send out an email to either audience even in the email you can attach the slides So Katie and then Richie So the only reason I came up with the newsletter term is because I think it's very important for us to have consistency in updates so for example these are the things we've completed these are the things we're looking at like very similar to the slides because the more consistent we're going to share this information between the tags the easier it is to digest for other people and to understand where exactly to look at so I think this is where I think perhaps we need to decide on a format as well and kind of make it as consistent as possible in terms of the areas we would like to cover and to see updates from the tags So for the kubernetes weekly like last week in kubernetes development maybe we should I mean maybe let's not do it every week but maybe we should have a monthly if somebody just brings everything together similar I'm afraid to say that because am I volunteering for that so it's a great idea I think I don't I'm sorry no no no let's do this because like again we're changing a lot of things we've already just changed like the slide format use the slide format like respond back into the email with like how we've actually got like this this like kind of running together keep keep like the normal slide format of what we currently have then respond to the email when you're ready like each tag collaborates with themselves like the like Karina's suggestion about like each tag works through like the process in here work through the slide and then when you're ready go ahead and send it out and if by this meeting we're like this time of the meeting if I don't see your updates we might have questions here about like hey where are your updates what happened can we help that seems like a lightweight way to be able to move us forward into February not necessarily like it's not going to be always like this but let's just try it yeah so we're not necessarily changing the content of the updates we're just changing the mechanism in which they're being shared that way smaller tweaks iterating changes over time and then if that works and we like it and we're getting good feedback then we can look at adjusting the content to make it more seamless easy approachable for anybody on the mailing list does that work look at us being all agile I know alright somebody want to take a shot at doing that from today's deck I'll share it on tag chairs if I do okay anything else so it sounds like this went well let me recap what Ricardo's put in chat place each of the tags will figure out a place to collaborate amongst the tag leadership to consolidate content for those updates and then the updates once they're finalized amongst the tag chair they'll send out those updates on the TOC mailing list once Amy kicks off the here's what's coming tomorrow email sound about right? do you expect us to send it before the meeting of what's the timeline? yeah I do I expect like it's the same kind of thing where like the slides need to be done before we get into the meeting and then like yeah I do expect them to be able to be here before the meeting because then we can talk about like oh so I saw the thing like you know like and it leads on to like another conversation that's why yeah that's good for me to know because like I said you know my co-chair doesn't always respond so at least I know I'm just going to time it before the meeting while I send in case they respond totally fine oh you know what I mean yeah Matt yeah but I think Richie had his hand up before me and I don't know if it's still up or if I'm lagging did you? nah it's fine what I wanted to say is basically we said like have a doc for all the tag leaderships amongst the tags themselves and once they consider it final just send it and if it's not final just send a follow up and done like to be super processed heavier on this yep that's right I agree I wanted to respond briefly to your initial question about how this is gone today in my view briefly I really really enjoy having the unstructured time to both hear other people talk and how they form the things that are interesting to them and important and we also have a forum for things that don't quite belong without having to have a system for absolutely everything as an example of sort of a non-standard interesting thing that I wanted to surface here to be to get a 2 for 1 last week in the tag observability we had a community member come out and say hey I think accessibility is important and I'm an expert in that so here's some things that we should all know about accessibility as we're building as many observability analysis tools have complex UIs you know if the hypothesis is that if we can ensure that things in the CNCF that are in that sector at least are able to describe in what ways they are or might someday be accessible to people with various needs you know right now we don't really measure that but we have other tags that are already looking at guidelines for all projects right and so we can we can connect you know this person tagging through strategy to get advice on that so like that there's not really clear issue type I could make I could shoe hard one in but I really like having this sort of just all hands even if it's a cadence touch point where the things that don't belong in the odd ducks which are oftentimes it might be the more interesting things anyway can get some time yeah excellent feedback thank you and also good segue over to tag contributor strategies new work on the deaf of hard at hearing working group and improving accessibility for cloud native projects to definitely make that connection fabulous yeah the person and the person that came out and the videos posted I you can see it's a presentation but I think it's important and it might be the start of something like a working group this is coming out of what they saw a coupon and what a lot of people are talking about that effort so awesome awesome alright anything else I have a question I really have a question so I was looking at the discussion in the TOC in GitHub earlier today I think some there was an interesting question about how the tag can potentially work with the tab to get more user feedback for the particular area the tag are interested in so I'm curious how to pursue that as you all know I'm very new to tag as well so I'm interested to kind of revise the chat of our tag and as part of that I think getting the use of feedback will be critical as well right so I can answer some of that they just kicked off yesterday give them a hot minute like I think this is probably going to be a conversation for Q1 because my knowledge like their very first meeting was yesterday but if you have things that you are directly interested in like really specific things that you need feedback from that would be a great thing to be able to kind of share with us and we can kind of start working out how that gets over to the end user tab Ricardo Dave and Katie I believe you all are our tab reps come on in I'm not a rep but we did I'm in the tab but in first meeting yesterday so as Amy said the effort will really start Q1 but any feedback feel free to send directly to one of us or there is also a Slack channel for the end user tab that you can post there so I think for right now I would recommend folks posting in the end user tab Slack channel that way all of the tab could potentially see it I think it's better and then that way at least gets it on the tab radar to understand like these are active requests from tags to the tab to provide feedback in that mechanism and hopefully they can have something put together before the end of Q1 I think the tab Slack channel if you post it there Ricardo it will help people can join also the tab meetings I think the tab chairs at least can join there to discuss I think that's a great question to link the how we can link the tab with the tags right when it's an user feedback of 10 points and the other is the tags that could provide solutions to solve them or could solicit any projects to coordinate and to solve those 10 points so I think it would be good I think the tab is open for people to join the meeting is it open I thought it's only for end user but I could be wrong I can check in a bit I'm in the car now so I can post I can drop in the Slack channel it's hashtag TAB is the channel where that's at I don't have the details on the meetings but it's definitely worth question in that channel to just verify from the source thanks anything else Matt sorry does anybody know I had a couple of things in addition that I was just reminded of out of the discussion around the potential for should this be a working group or how might accessibility in general not just for vision impaired mobility impairment grossing there's a variety of types of accessibility the discussion came up what makes a good working group and I know we have formalized criteria but one interesting thing I thought that came out of that was the notion that as tags are worth these three demographics sort of come together and at points overlap their intention is to pitch the working group as something that can produce artifacts or outcomes that speak with the same information and audiences in audience specific ways so if you're a consumer looking to shop for cloud native stuff in the sense you have to use in your organization you might want to know what should I look for when assessing accessibility since I sell to government or education large enterprises things like that that have requirements around this if I'm a project maintainer what do I need to know so I could jumpstart things the right way and not have to reinvent how to do what is an easy forward but fairly elaborate set of things to get certified or to at least understand where your gaps are and set yourself up for success and then from similarly for the third group so I was curious if anybody else had criteria for what can be a working group what other things like that might make sense to have as either aspirational or optional guidance to those that want to draft and create new working groups or other ways to make it as broadly applicable to the targeted audiences or tags what do you think any question I don't think anyone was expecting that question I wasn't expecting to ask you I'll put it as food for thought and I'll see you guys on Slack but stuff to think about for the holidays I think accessibility like like Catherine have launched is an opportunity for the sense you have to differentiate itself because commercial software is oftentimes way further behind and unable to address things because we're building these so fast we can build them right the right way yeah Josh Govant you came off mute I was just noting that the parallel what you said earlier Emily that we want tags to take responsibility for those working groups early on and then delegate them help them get started bootstrap them it sounds like something that's worth collecting some of those successes with working groups and placing that in the tag resources area since I know that we likely to have more working groups in the future underneath of tags and it would be beneficial for the next group to understand what expectations are how to get started bootstrapping a lot of that staffing expectations associated with those leadership positions so if you do have some of that information I know Catherine Paganini you've had a lot of success with working groups within tag contributor strategy I know your insights would be valuable there I know that there's a few other tags that have great working groups as well let's move the discussion over onto the TOC discussions in our repo Matt if you would post it yes I can I can capture that I'm doing a bunch of updates like three or four to the discussions board following between re-event Kubecon and life thank you awesome if anyone is interested we can collaborate on the initial docs Catherine said that she is happy to assist excellent alright so I think this was good we got a lot of good feedback we got some changes and some recommendations not too terrible next meeting like I said is the TOC sandbox reviews so tags if you have a chance please take a look at them provide a comment around the project in the context of the CNCF whether or not you would recommend it if there's more work that needs to be done something along those lines it just helps the TOC make those decisions also annual reviews are extended through January 1st I believe yep so if you have any questions on annual reviews reach out to your TOC liaisons and I think that's about it so don't talk to you all before the end of the year have a lovely end of year and enjoy your holidays please take some vacations and time off including from open source and CNCF slack I think we all kind of deserve a break this year we've gotten a lot done but there's a lot more to come in 2024 thanks so much everyone enjoy the rest of your day thank you bye bye