 Alright, okay. Hello, everyone. I apologize. I cannot see you all very well because the lights are absolutely blinding. So, I'm going to do my best. This is the tag meeting. There are individuals here that are not part of the to see and not part of the tag. That's fine. We welcome you. If you find the content of this interesting and fascinating. Excellent. We're happy to have you. Hopefully you'll be contributing to our tags in no time if you're not already. If you find this. Yes. Oh, technical advisory group. Apologies. If you find this topic boring, you are welcome to depart if you would like or listen or just enjoy our pleasant company. We're all wonderful friendly people. But we're happy to have you so. Real quick. So, in the past, the to see has had these to see tag meetings at cube cons. I think we've had 2 of them previously maybe 3 and we spent a lot of time talking about the problems that exist within the tag contributor. So, we've had a lot of time talking about the ecosystem from a perspective of making sure that we have new tag members coming in challenges between tags that they may be experiencing. And I wanted to do something different based off of feedback that we've gotten. We wanted to be more decisive and more outcome oriented with this meeting. What I did was thank you Lynn and Nikita and Karina and several others that I spent the time and energy front loading a lot of the work and pulling content together that way we can try to get through these things and move forward with the next generation of what tags are. So, we're going to do a quick review of the survey results that were run. We're going to have a brief comment from Rianne who spent a lot of time going through all of the technical advisory group charters to compare and contrast the differences between them. And then there was a request at the last TOC tag meeting in March, which is still this month around, sorry, around what the expectations of the TOC are for tags. And the TOC had spent some time talking about this at our off site so we did come up with several expectations that will go over. And then we have some decisions and some groups that need to be formed as a result of this, both off of the survey results as well as off of some of the TOC decisions. Because ultimately what I don't want to have happen is I don't want the TOC to dictate outright what each of our tags should be doing. You all are the experts and the domain extensions of the technical oversight committee and we need to be doing a better job of leveraging you as such and therefore it's important that your voices are heard and your equal shepherds in your own future. So, let's get started. So real quick about the survey results. We put out a call to action to provide us with insights and some information around your experiences either a tag chair or a tag lead or contributed within that group. We know that it was a short turn around time so that's probably the largest contributing factor for the low amount of responses, but I do want to provide a reminder to everybody that your involvement and providing these feedback to these discussions and not only just making us aware of the problems, but coming up with recommendations and solutions that might work or are based in potentially some other groups work like Kubernetes we've seen a lot of input from the Kubernetes community that has been impacting to see processes and we need that feedback we need your active participation and I know that this is yet another thing that you all are doing, and we really appreciate it but if we want to fix and make changes to improve the tags and the tag experience. We definitely need that feedback and that active participation which will be important for the working groups that we'll talk about later today. There was a lot of feedback also that the purposes of the tags is not exactly clear it's different depending on which tag you're in and what the current leadership team of that tag is. In some cases we have tags that are very vibrant and robust they have a mountain of work that they can come through and not enough people to do it. In other cases the tags are a little bit, they need a little bit more direction setting they need better clarity from their TOZ liaisons on what it is that they should be working on within the scope of their charter. So we're hopefully going to fix that today. There was a clear need that there are opportunities to work across tags but we don't have the leaders to step forward and facilitate a lot of that work it's coming out of the existing leadership of the tags, which is becoming increased, increasingly as we have more and more demands on our time and less and less opportunities to actually provide that level of impact. So there's opportunities for improvement there. There is a noticeable call out that there lacks a leadership ladder within the technical advisory groups and more specifically within the technical leadership portion of CNCF outside of projects themselves. I know tag contributor strategy has had several discussions on adopting a contributor ladder for their specific tag. And I think that is exemplary and something that we should all start looking to do, including the TOC of identifying what is that path to leadership look like within cloud native. There was several comments around misalignment and misincentives for projects and this is something we've talked about in the past. Cloud native projects don't see an incentive and going to talk to a technical advisory group. That's kind of the basis of what that is. And because of that missed incentive and that misalignment. They're not seeing projects that come to the tags come back after they've had that presentation and they've gotten some form of feedback. They're not contributing that institutional knowledge that they've developed through that participation, as well as within their own project back to the tag to help improve that experience for the next project behind them. So we have some work that needs to happen there. And the chair and leadership expectations of being within a technical advisory group are not explicit they're not very clear and in some cases as a result of that they're not being filled appropriately. We have contributors that show up and they might ask questions they don't get responses and they'll disappear, or we'll have individuals that will attend a tag meeting but they're missing the leadership to facilitate that meeting or there is an agenda set. So people show up they don't see a lot of activity and they'll disappear and they don't come back so we have a lot of holes within the existing process that we need to start figuring out how we can close those gaps to be able to move forward. Are there any questions about the survey results that I have talked about so far. We got a mic. I can, I can wander around. Okay. Yes. Josh hold on. I'm coming. I'm coming. Speaking of low numbers of results. I don't remember seeing the survey when was it sent out. It was sent out. Two weeks ago, we posted it on the tag chairs channel and slack and to see channel. And then, and the mailing list so we tried to hit all of the communication mediums that we usually talk to you all but I know that it was a lot of traffic in the past two weeks so it was probably missed. I mean, there are recommendations for better communication mediums with tag leadership. Let us know. I believe I also just heard that not everyone knows about the tag chairs channel over in in slack as well. And that, and that is an excellent step that we can take. So, like, well this is very uplifting. Yes. So there is a public tag chairs mantle channel in CNCF slack. I would like if you're not already in it, please join it if you're not a tag chair also please join it because that's one mechanism that the to uses to communicate and mass to the tags. It's easier if we have one to see member that's facilitating some project or activity that needs to happen, instead of having every liaison reach out individually to the to the tags but that's something that we can potentially codify within the to see but a set expectations better. And again it's a public like, please come in and come hang out and be useful. Yes, yes. I am by no means a member of any tag or to see but in a different open source project and also within our, my company. We have a slack box that automatically invites people based on a membership in other systems. So if you're a GitHub member somewhere or a mailing list member somewhere. It'll pull you in into the other channels where you might belong. That could probably help here as well. Yeah, we can look at that. Yeah. So, like, I'll put in the notes. It's okay. Thank you. So I wanted to mention, as we're thinking through all of this that this isn't just a problem with the tags, it's problem with projects, because people show up to a project and are, you know, advocating for the one feature that they want and then they disappear. And same with the tags, they'll come. A project will come and present or, you know, talk through something and then they disappear. So just overall ecosystem as. Yep. Talking through it. Thank you. That's a good call out. There's actually a lot of parallels to some of the stuff that we're going to talk about here from the survey results and like recommended actions the next steps that we see with projects too. So I'm hoping that if we can figure it out for us or get closer to figuring it out, maybe there's some opportunities to replicate that within the projects themselves. So think about that in the back of your head as we're talking about these things. Okay. Rianne, I'm going to have you talk a little bit about the review of the tag charters. If you don't mind. Thank you. Alright, can you hear me? Good. For those that don't know me, I'm Rianne Kleinons. I'm the program manager for CNCF specifically for tags. In a previous lifetime, I've been a systems auditor. And the easiest thing is to find fault with other people's work. So the point here is not to find fault with other people who work. So what I did is I went through all the tag charters and read me over the last few months. I compared what's in there. And does it make sense. Actually, we're going to have in the next session next door, we're going to have a talk about making people welcome in your project. And at the moment, if you've many of the tags and I'm going to point to nobody. If you go to the read me, it's a historical document of when the tag was created. It was in sync. Some of us out of sync. Some have the leadership in the charter in the tag, read me and some other place and not one of those documents actually matching up. So you've got lots of leaders listed and lots of places that's changed over time. So the purpose of the review was to see how can we help to make it easier and make it clearer for everybody. So what we came up with is a matrix documents so I cannot share all of these on the tag chair group that you can have a look and you can comment. So we had a matrix of what is in all the different documents and we came up with kind of a recipe. I'm not done with the what exactly it should look like, but the recipe for your charter and a recipe for what should you read become have in it. So your charter should only have things that never change. This is the things that we're going to do and not going to do. This is what we stand for the read me is this is what we do in general. Look at our charter. This is the meeting the leadership of the type of projects he supports are basically like a proper read me that is properly maintained and then we're going to remove duplicate information. We did not settled on exactly where it lives charters is most likely going to be deleted in your local directory and goes to the to see director because they actually have to approve it leadership. We're still deciding where but hyperlinking as much as possible. Some projects that name the or some tags name the projects and they have five or six listed from three years ago and they have like 20 now. So also landscape is actually now developed that you can hyperlink to specific tags so you can actually say here is our projects hyperlink landscape you actually go to the landscaping only see your projects on the landscape so making things. It's going to be a little bit of work in the beginning to just clean it up, but afterwards you're going to have to change your leadership in one place never change your your projects and basically everything should be streamlined and easily maintainable according to a template. Any questions. Thank you. So we're going to be introducing more consistency across the charters and we're going to improving the experience of newcomers to the tags by introducing more consistency within the read me is on setting expectations because that's the first place that they'll go to is probably the tag repo and they'll read through. Kind of what the tag is what it's doing when it's meeting or the people that they can talk to that are key figures within that. So that's the first portion of the advisory group. So hopefully this will help things, but it's by no means done we still have a lot of work before us. So at the last to see tag public meeting there was a request from Alex and several others thank you for having the to see actually come up with some decisions on what we expect tags to do and we've spent a lot of time both looking through the recommendations for charter alignment as well as our own experiences either contributing to a tag leading a tag or partnering with the existing tag leaders as to see liaisons on what it is that the tags are doing. And we've kind of come up with a few areas so I'm going to go through them one by one. This is traditionally what the TOC thinks about when we send projects to tags to do a presentation except what we have found and what we've heard is that it's more of the tag the project doing a presentation to the tag instead of a dialogue and exchange and providing feedback to the project specific to that domain area. We do know that there are some tags that are actively doing this they are participants in that presentation. They're asking questions. Wondering like why did you make this design decision over this one that's against a best practice for instance we know that those occur but it's not consistent across all of them. So one of the things that we would like to do is to formalize domain technical reviews by the technical advisory groups, so that the tag can fully explore the project in the context of cloud native as well as the domain that they're covering. It's to evaluate the technical merits of the project itself the design parent principles associated with it, and its inheritance is to best practices that have either been set forth by that tag or by the TOC, or just by industry proper. Part of this means we need to define what an expectation of performing a domain technical review actually looks like from a tag, and it's going to be slightly different for every tag depending on the domain area that they have. So we've already identified a few items that fall underneath of this to get started so when we talk about forming a working group around this concept to introduce consistency. We have some material to get started so thank you Nikita for putting that together I really appreciate your assistance in that. The next one is criteria and criteria related to reviews. I understand that we did not do a good job providing an update to everybody that we have changed the incubating and graduation criteria and when I say change I mean we clarified a lot of things that were undocumented expectations of projects. We also incorporated significant feedback and recommendations from the moving levels task force. So if you haven't been to the TOC repo to see what those changes are. I highly encourage you to do it the repo looks slightly different things have been moved around, and we've gotten rid of a lot of old content. So criteria reviews are intended to cover the domain specific criteria for moving levels. If you look at the current or the, the new incubating and graduation level criteria there's sections now, one of them covers governance for instance. The intent of these criteria reviews is to cover that particular area of the criteria and that review can augment the material and the content that the project is expected to provide the TOC with the next step is criteria criteria related reviews. These are not things that are explicitly defined as criteria for moving levels for projects. These are things that are related. They're around the edges of it. Security reviews are not a requirement of a project to graduate. However, a security audit is, but a security review like a joint review from tax security or a self evaluation. Those are things that can exist. Can assist in augmenting the content for the due diligence document. This is intended both to ensure that projects have better. Better feedback loops to tags, but also to ensure that tags are a part of the due diligence process.