 All right. Welcome everybody. It is June 15th. We're halfway through June. This is the hyperledger technical oversight committee call. As you are probably all aware, I think I've seen you along the call before. But two things that we have to abide by the first is the antitrust policy. That is being displayed on the screen. The second is our code of conduct, which is linked in the agenda. So for announcements today, we have the standard. Dev weekly developer newsletter that goes out each Friday. If you have something that you want to include in that newsletter, please leave a comment on the link at the. That is linked in our agenda. The second announcement that we have is that David has made some substantial updates to the presentation. I think that's a good point. For why contributing to the hyperledger community will help meet your goals. So please do take a look at that and review. Those changes and see if there's anything else that you would like to have. I think, you know, David has also volunteered to come back and, you know, talk about that again to the TOC. So if we are looking to. We can do that. So if you do want to do that, please do let me know. And we can make sure to get that on a future agenda. Other announcements that anybody has. I would like to make. Okay. So this particular. Agenda is not the latest, but that's okay. I don't think it's the latest report. Because I think everybody has seen the, the sauteed report came in, but we do have the firefly and the sauteed report that has come in. The firefly report. I don't think has all of the approvals yet. So please, if you haven't had a chance to look at the firefly report, please do that. Okay. Thank you. Thank you. Today. Okay. Not seeing any hands. So we did get the sauteed report. Right. Submit that. I believe right. You took the. The draft that they had put together and submitted that. Is that correct? That's correct. The Google doc was already in. Markdown. So I basically just copy pasted it. Okay. So I mean, I posted some comments about this. I have some questions about the, you know, the claims being made and, you know, it seems to report a lot of activity and stuff. I don't really see it when I look at the insights. And in particular, I posted a comment just a bit earlier. If you go through the list of maintainers. Some of them haven't had. They haven't had an interaction. Get up. Get up. Entirely not, not even talk about so tooth in particular. So I'm like, how can they be maintainer of so tooth? If they don't even interact with get up in over a year. So I did. Go through and. Post a bunch of PRs to adjust the maintainers files a while ago. I got a lot of pushback from the sawtooth team. And so I abandoned those PRs. So that's why they're still there. Okay. And, you know, the report claims that there are people like Cargill involved. I don't see any trace of this. Maybe it's something and another. I haven't seen. I mean, you know, I'm not, I'm willing to give the benefit of the doubt here. But you know, it's a bit puzzling. Yeah. I think the other. Challenge that we have. With the report at the moment is that there is no. Sawtooth person who has submitted this report. And so they're not going to see the. Comments that are coming in. So I think we're going to have to figure out how to get the sawtooth team to take a look at these comments. Because it's going to be very hard for us to merge this with the outstanding. Comments given our. Our process that we have for doing. The, the merger of this poll request. So I think that's a, yeah, thanks for adding these folks. I think that's going to be something that we really need to have. These folks coming back and providing. Answers to the questions that people have posed. So it's, it's not just your questions. I've seen other questions coming in as well. So I think we can actually merge this particular report. Yeah. You're showing my comment there. I just fundamentally didn't understand several of the things that we're talking about here. So I, you know, I agree. I mean, Tracy, the. You know, the whole point of having those reports, right, is to make sure that projects still have a pulse and everything is going reasonably well. If you know, so thank you right for bringing up what they had. But I think that alone is not sufficient. If we just go along with this, then we are failing on the whole idea of, you know, making sure this project is still fully functioning. Yeah. And I don't know, I, you know, I did copy obviously the TOC and the messages that I sent to the contributors last week when I was trying to get this report submitted. I have not responded to the latest message about this being a bureaucratic process because I'm afraid that I'm going to make this more contentious than it needs to be. Because I have tried to explain in my past. But I don't know why these things are important. At the moment I'm, I'm leaning towards the fact that, you know, this is our first clue. It feels like it's our first clue. We see, we saw it with borough. We saw it with Ursa when projects did not. Provide their quarterly reports that something is going wrong. Right. That the project is not as healthy as it needs to be. And so that's where I'm leaning on responding, but yet I'm a little hesitant to do so just because I feel like this has become somewhat contentious and I don't want to make it worse than it already is. And so we'd appreciate any kind of, you know, help guidance as to how we, how we go about getting this, the sorts of answers that we need to get and to, you know, make sure that the project is really moving in a direction that, that we think it is or that they think it is. And that if it's not, that we can get some, some sort of, you know, earlier sort of response than what we did for some of the past projects where we waited, you know, six months to a year before we finally took some action on it. So anyway, and that's where I met with this and would appreciate any sort of thoughts or guidance around the best way to approach this. All right. Well, thanks for the background. I mean, you know, I think the record shows I'm pretty lenient on those things. I'm not the one to say, oh yeah, let's just kick them out. But at the same time, I don't think we're asking very much. And they have to play their part. So. All right. So hopefully. Right by you adding that we'll start to get some responses. I will try to. Gently. Push again to get those responses in the subject's contributors channel. And we'll see where this goes. Any other comments or questions on such youth before we move on. Peter. Peter, we can't hear you even though you've come on units. Peter, we cannot hear you. Right here. Yeah, if you want to, if you want to put that in the chat, we can definitely read it there. And if you do get your microphone working, that that'll be fine to come back on as well. So I think just a reminder that the cello report is also due. I think that the last time we sent a reminder was on the fifth. So it's been over a week. Arun, I don't know if you have sent a further reminder or that if the job that you have has created an issue for cello. No tracing and follow up. Okay. Sounds good. Thanks Arun. So for upcoming reports for next week, we do have basu and caliper that are due. So we'll take a look and see. If those show up Thursday next Thursday. Okay. So for discussion items today, we have a couple of different discussion items in the task force. The first is the project annual review. So I did put together a poor request. It isn't draft. But appreciate any sort of feedback that people have on this. I don't think we're going to be ready to devote on this today because I think there is going to be some commentary, but I did want to get something out there for people to respond to. So I think. Yeah. The very first thing here is around the timing of the reports and how they relate to the quarterly reports. So that's kind of the, the first question that we have in place. I think the, the suggestion by Arun and. Steven is that. One of the quarterly reports should be replaced with the annual review report. So that would be my only concern and the reason why I suggested that they should be done. I don't think it'll be challenging for the project, but it definitely would be. A challenge for the, the TOC because. The TOC is going to have to do some work. To really dig in deep to these annual. Reviews to make sure that they are reporting correctly. The information. And to really help understand the status of the project. And to really make sure that they should be done on some anniversary of either being. Moving to incubation or to graduate it status. But that's, that's kind of, I think what, what we're, what we've got there. So let's stop here and just see about the timings and whether or not they should replace the quarterly reports. Other folks have any. Thoughts or comments on this. Rama. Yeah. As I mentioned the comment here, I, I think I may have missed where you mentioned the single. Like, like single because something, but that's kind of what I was suggesting here. Maybe we could have like a week at some point of the year where all the reviews could be bunched together. I mean, if you think about. People that happen and the organization we work for, it's like they don't, it's not an staggered man. I think it's just more efficient to do them all in one particular cycle at one particular time. I think I'll reduce the load on, on us and also if you are reviewing all the projects at around the same time that allows us to relate the projects to each other, see how they depend on each other or the complement each other and so on. So maybe that, that might be more efficient. Yeah, Rama. So I think right now I don't, I don't remember the exact number of projects that we have, but let's say it's somewhere in the range of 15. If we're doing 15 annual reviews at the same time, we've got 11 TOC members, that means at least four people are going to have to be doing two of the deep dives at the same time, the, the way that we have them. And then all of us will have to be, you know, obviously responding to comments, asking our questions about these annual reports. I do think that it'll be a very, you know, I think it'll take a lot more time than we would expect, you know, during a week or two week process of trying to, to go through all of these. So, yeah, I mean, that's, that's my biggest concern is just the amount of time and effort it will take if we put them all at one time. That's true. I agree with that. I think though, if it is like much together, doesn't that be one week? Maybe it's like two weeks. I would say 15 projects, maybe two to three weeks. Then it just gives people a bit more focus because otherwise you have reviews coming up like almost every month, right? Every month, couple of months and people have to take some time to work on that. Other thoughts on timing? I remember this is, this is everybody on the TSC's responsibility. So I would hope everybody has a thought on what they would like to do as far as spending time on these. Bobby. I like the idea of having them present to us at least once a year. And with that, it would have to be toggled through the TSC. I think it would be a good idea. You can't have all the, you know, 15 or 14 projects reporting all at the same time. And I don't know how you'd pick that on the calendar, but I think that that. Not just having to fill out of a form, but actually having to present to the TOC and show up and discuss the project would make it. More relevant to what's going on and give us a better insight as to what's happening with the project. David. I agree with Bobby. I would also say that I would have a much easier time digesting the deep dive reports if they came like once a month, rather than all at once. And I think I'd spend more time on each one rather than just trying to knock them out if they came all at once. I'm not sure if others are in the same sort of position, but in the Aries might fit together or Aries and other projects might fit together and be combined. So maybe we can think about. That to reduce the sheer number. So that might make it a little easier. I don't know if other projects have that similar relationship. So Stephen. It would still be two separate annual reports, but then at the same time. Sorry. Yes. So the actual presentation, I totally agree with the idea of, you know, having it a bell, whether in the community that people are, that are focused on and they show up to the meeting or, or are invited to the meeting at least and, and that specific maintainers are involved in the meeting. But I just think that could be combined for some of the project, like some of the projects can have their meetings combined. Okay. Where the clarification. Anyone else in favor of. Putting them. All at the same time. Jim thumbs up is yes, you think all at the same time. I have to admit to be a bit torn about that one. When you're against. What's at the X. You guys are using these thumbs up and X's and I'm not sure what they mean. I think I agree that having all the reports come at once, maybe too much tedious work for everyone. But then we need a strategy of how we distribute. It could be like in the quarter one, we designate four projects and quarter to the next set of four projects. Or. It also allows the TLC designase designated members to go in and do the same thing. I think that's a great detail and come back with it. Okay. So I, I feel like most people are leaning towards the, let's separate them. And we've got maybe. One and a half to two and a half people who might be in favor of doing them all at once. So let's, let's at this point, maybe move forward with the. I don't know if that works and see if we need to adjust or change that as, as we move forward. All right. So then next comment is. Right. If you wouldn't mind moving us forward in the. All right. Yeah. Yeah. Sorry, Tracy, but before we move on. Yeah. Don't do all at once. Okay. So I'm going to talk about how long it will take to go through all the reports basically. Isn't that like within a quarter or so we see them all anyway. Or is it over the year? I don't know. So I haven't looked at the actual when things have gone to incubation or when they. Have graduated. That was the original sort of thought I had is that it'd be on some anniversary. So I don't know. I don't know. I don't know. I don't know. Specifically the anniversary of going to incubation would allow us to. You know, that after a year kind of see where they're at, see if they're ready to move to a graduated status. See if they're meeting their charter, that sort of thing. Right. And then a year after they moved to graduate, it would be, you know, a look at kind of. The process of making progress towards the releases that they're doing. Making progress towards their roadmap or things like that. So my thought was to somewhat distribute them over the year or no. But I don't actually know if by looking at when things have gone incubated or graduated, if that would be a true statement or not true statement. So I. Obviously what is trying to distribute as much as we can over the year, but yeah, I don't, I don't know how that works out for sure. All right. I understand. I mean, I was thinking maybe there's a middle ground there, which is to try to get them fairly close fairly quickly all after another, but not all at the same time either. Gotcha. Gotcha. I don't know. I don't know. Are you thinking. But I'm just afraid of the workload. If we really ask them all at the same time. I think that's the problem, right? So maybe there's a middle ground where we kind of try to have them all come in. One after the other in a fairly short period of time, but not quite the same time. Anyway. Yeah, no, that's, that's interesting. Yeah. I mean, is there anything you distributed over one quarter? Are you thinking distributed over two quarters? What kind of distribution are you thinking then? Yeah. Something like a quarter. Something like a quarter that made, you know, something like this probably. Because I think Ramas point is good that, you know, we, we, if we have them all fresh in our mind, it helps see maybe if there's some, you know. Yeah. Yeah. So from that point of view, if you stretch that over six months, probably it does not go, it doesn't work. Then you might as well forget that, but. If it's over a quarter probably still have enough brain cells to remember that. Okay. Yeah. Yeah. I understand. So maybe, maybe we replace one of the quarters. Yeah. I mean, I think it's just Q one or Q two, whatever that happens to be with the annual report. Instead of trying to distribute. Over Q one, Q two, Q three and Q four. Yeah. Something like that. All right. Thanks. I'll be worth thinking about. Yeah, definitely. Definitely weren't thinking about Steven. Yeah. So I just thinking through some logistics of what it could be. So yeah. Yeah. So with one quarter. We're saying that a TOC member would be. Would engage with the, with the. Project. It could be that, you know, the teams use one of their regular reports. To talk about it. The TOC member participates in that they prepare the quarterly report that has some additional information to collect. And then. At that, they also get scheduled to appear in. A TOC meeting. And maybe we have up to two. Two of them per TOC making during that quarter. Does that flow seem right so that they, the, you know, there's some publicity across hyper ledger that, oh, this is the annual report quarter. So there can be some publicity about that. But. Each of the teams is, is, or each of the projects is encouraged to dedicate one of their meetings, at least a segment of one of their meetings to cover this. What gets said and the TOC member attends it to hear the interactions of, of the team. Of the project team. How's that for a logistics of it? I don't know if that makes sense on the fly, but. Yeah, I think it makes sense. Yeah, I think it makes some sense. Steven. Assuming that the other projects have. A meeting at least. Once. Yeah. If they're not having a meeting every month. This is true. This is true. But yeah, I think that makes some sense in my head as well, Steven, what you did say. I'll add a comment to your. To that PR. Okay, sounds good. So I, I think then that will definitely be a change that we can make to the, the PR to reflect kind of a different sort of schedule that we put together. And, you know, maybe we'll actually think about what that actually looks like as far as the true process so that we can add a little bit more detail and. A little bit more information into the PR so that we were understanding what we're all agreeing to. Before we actually agree to it. Any other comments on that before we move on to the next comment here. Peter. I just wanted to test my microphone. Yes, it works great. Okay. Sorry, I missed part of this conversation because I had to reboot, but. Okay. No worries, Peter. So we're just, we were talking about timing and whether or not makes sense to do it within a single quarter instead of distributed across the year. Is where we've ended up. So that's something that we'll take back to the PR and get added into the PR. All right, so this next question, yes, archiving does mean end of life from a, I will update that PR to reflect that. To really make sure that it fits in. Steven, yes, I will laugh at your comment. That was a good one. I did write it in a weird way. And so I think some of this did end up getting repeated. So I will make sure to. Remove that repeat. All right, let's see what we've got here. Okay. I wait against the site goal. The project should be asked to set the annual goal for when they applied to enter a hyperledger foundation. So Arun, I think. You know, I said this in response to something that Arnaud said earlier, but my thought was that when, when you do go to incubation, there is that proposal and there's some information in there about kind of what the, you know, you know, you know, there's some goals that kind of are being set there. You know, but we can definitely be more specific about what it is that we're asking for in the incubation proposal. To make sure that people understand that this is something that they will be evaluated against as we. You know, go through the annual review cycle. And then we'll look at the other pull request that we will take a look at as we continue this meeting. So next on the agenda. Another stage next stage. So I think I'm going to leave this as another stage because I know that we're going to be looking at the project lifecycle and we'll see how that all works out as to whether or not. We do think that it's going to be different in some way or form. But for now, I think we'll leave this as another stage. A room. Comments on that. I understand. So I think with the approach that the projects could move back and forth depending on number of votes. That makes sense. Yeah. Okay. Let's see. Okay. So this is about. I think we scroll up just a little bit, right? This is about. I'm not mistaken. Yeah, this. This comment about the at least two thirds of the TOC members agreed to continue the project at its current stage, or if we don't agree to continue. So this is a change. If you think about it, because I think right now all of our decisions are at least. The majority of people have agreed to move it to the next stage, whatever that stage is, whether it's incubated, graduated. Um, dormant. End of life deprecated, whatever that stage is, right? So I think this is a really good thing for us to discuss. And so Rama, I'm going to hand it off to you to, to talk through your comments and see what your thoughts are. Sure. I was just making a simple point. I mean, your first line, line 60 says at least two thirds of the TOC members agreed to continue the project at the current stage. I think if the, in the review, if the maintenance have made a pitch to move to the next stage, like going from incubation to graduated, then that should be the first thing that the TOC should be debating. And if they, if that is not on the table, then they should decide what you say. Gotcha. So I always say that if the TOC thinks that they should move, like from incubated to graduated, there's actually a process right to move to graduate it. That we should follow and that we shouldn't change that process from what it is today. So I think we're in agreement if I'm, if I'm understanding what you're saying. Sure. But other thoughts on this two thirds, because that is a change to, to what we currently do today. So I want to, want to make sure that people are in agreement with that statement. Or if we should just move it back to the simple majority. So yeah, Tracy, I guess. My question here would be what happens if the TOC members can't agree to do anything? Because if we can't sort of agree to continue, if we don't have the votes for that, but we don't have the votes to change what happens. It was mostly just a wording thing. You mean there's a, there's another else in there that I didn't take care of was what you're saying. Yeah, I don't know the answer. We will discuss with you what might be the next stage, right? Well, you know, then you have to vote on, you have to get two thirds to be the next stage, right? Or what the stage might be. Well, that's, that's actually an interesting one to heart, because I'm not changing the way in which we decide to move to deprecate it or dormant. So that would still just be a 50% or a simple majority. What if three fifths of the people want to continue the current project and two fifths want to move it to end of life deprecate it, right? Then we're sort of stuck in a limbo, right? Yes, yes. And then there's, since it requires two thirds to continue, the project is sort of in an undefined state, right? Yeah. So I think whatever, you know, whatever we want is fine as long as it's consistent and we, we don't end up with a project. That we don't know what the state is in, right? Because here, if a project is not voted, doesn't have enough votes to continue, but doesn't have enough votes to be deprecated, what state is it in? Yeah, yeah, no, that makes sense. So sorry to be pedantic. No, no, it's, it's good to be pedantic heart. And I appreciate the call out here because, you know, I could see that happening to us. And we'd be like, yeah, what do we do now? Okay. So that's making me think that we need to just change that back to the simple majority vote that we have. Because I believe if we do that, then we wouldn't ever run into a problem where, although I think there still is a second LCF, right? Which is deciding what the next state is. So I'll think about this heart and trying to come up with a wording that will resolve the concern that you brought up. So you could have one, you could have some fraction vote to not continue the project at its current stage. And that would solve the logical issue, I think. Because then if there's no consensus, the project just sort of stays. Okay. All right. Next item here, then. That could be a good way of handling that drama. I don't the guy necessarily want to define who has to do the annual review, because we don't define who has to do the quarterly review. But I do think that your comment about who knowing who to contact is probably a good sort of thing to think through. Okay. Okay. Okay. Okay. So. Would Rama, if we change this to be something about. And informing the TOC who that person would be, would that resolve the concern that you have? Yeah. Okay. Okay. All right. Is there another comment that we have? Okay. This is an interesting one, and I'd love to discuss whether or not we think one person should be responsible for this. Thoughts on the responsible member. Peter. Peter, your microphone stopped working again. Can you hear me now? Yes. Okay. So I think we could do the current number of projects. We could do multiple TSE members per project. But then I would also put some formula in there to make sure that if the number of projects triples, then we come up with something else. So that the load on the TSE members don't get too much. But with the current number of projects, I think it is doable easily to have more than one member. All right. Peter. Rama. Just keep in mind that the TSE members who are on that project can contribute the same project. So we have to allocate this property. Okay. So that's another discussion that we should have. There is currently no sort of exception process for somebody who happens to be a TSE member who. Okay. I'll give a specific example. I have fabrics report came up in Dave's name was the next one on the list of people to do the review because I was, we had the round robin sort of thing. Would we be okay with Dave being the one who provides information or would we say we should skip Dave and move on to the next person. Peter. I think to me it's to be okay because at the end of the day, there's no additional benefit. I would say David, we just have more context than compared to if I was doing it. So I don't. I don't think there's a conflict of interest necessarily, but also I'm very open to. Not thinking that way because I'm also a TSE member who is also a maintainer of a project. So I'm not going to try and manipulate those rules in that way. Thanks, Peter. Thanks. Just to clarify, there is no conflict of interest aspect to what I'm going to say. It's more about looking into report more objectively than trying to be like trying to miss out certain aspects that otherwise could have not been missed out. So I'm in favor of having somebody outside the project, having a review of how it's happening. That also helps us understand how the project report has been, if the project report is effective enough for somebody who is not involved in the project to understand what's happening in the project. Now the other aspect, which we can also consider is like, if we were to just go with the round robin without having to worry about who the person is. The favorable point to that debate is like, we just propose that we'll have multiple TSE members, not just one person. So then we can look into having a mix of people from within the project and outside the project. So those are my comments on both far and against. All right. Thanks. Rama. I don't go to the point that I wanted to. All right. Park. Hey, so I would ideally like to see someone who is not affiliated with the project. Do these kinds of reviews. You know, even today we've seen a quarterly report. Where perhaps a project exaggerated their community contributions a little bit. And, you know, there's no reason that that couldn't necessarily happen with these, these more in depth reports. But more importantly, you know, I think it's an opportunity for, you know, TSE members to, to see and learn about other projects. If you're going to spend the time doing one of these, why not, you know, learning about another project, you know, see what's going on. And, you know, maybe you learned something, maybe they learned something, you know, I think it's just a good learning opportunity. All right. Thanks. So I've seen super in favor of having somebody who's not affiliated with project through the. Be the TSE member responsible for. Working through the project annual review. I can make that update to reflect that as well. All right. Any other comments that we have on this particular PR. Okay. Yeah, I'll fix some typos. All right. That looks like it. All right. So I think, you know, I've got some really great information from folks. I appreciate the feedback in the comments. I will make sure to update this. And so look for a. Non-draftful request to come in to see if there's. Resolve the concerns that we've brought up here. So I know we're looking at time. I'm thinking we're probably not going to get to the task force today. We might have to push that off next week, but we'll see where we, we get and decide that. But let's take a look at the encourage projects to set annual. The annual goals. PR that. Arun has drafted as well. So I, this is added to the project incubation, entry considerations around full setting. So this is. This is kind of in regards to. The. Making sure that during the annual review process that people can. I comment on how they've been meeting there. And or their goals that have been set. So any thoughts. That people have on this particular PR as they're reading it. Makes sense to me. I agree with it. And. I just wanted to add maybe we could. Maybe we could be more specific and say you could have a roadmap. MD in your project. And describe your plans for the year. There. All right. Thanks, Peter. Any other thoughts. On this particular. All right. So, Arun, maybe you can make a suggestion. And also. I don't know what the. Proposal form looks like, but we might want to make sure as Peter. Mention that we do update if there's like any questions that might exist for. For project incubation entry. Yeah. Right. So I don't know about the roadmap. MD file in the repositories, but. I can come up with the structure of how. Project teams can set their codes. Like an example or maybe guidelines on what that looks like. By next year. Okay. Sounds good. And speaking of templates, Stephen, I did see a comment from you somewhere about having a template for the annual reviews. I don't know where that. Comment was, but I will also take a look and see about creating a potential template for people to complete for the annual reviews. Sounds good. All right. So that I think the, the last item on our agenda is just this task force. Badging. Life cycle. Rama. I don't know if 10 minutes is enough time. For us to have this discussion. Or if we should wait till the next go around. So let me know what you think about. Coming for this. Things up to you and the team. I'm fine starting if you want, or what I can say. I am sorry. I just, I finished meeting some notes earlier today. If you can go to the. The wiki. Let me look at where we have all of the task force. Brainstorming going on. So I created. And added something to the, to the wiki page. Let me send you the link. I think it's under a community task forces. Yeah. So. Bobby created this page. It's kind of a skeleton page. So I just made some notes here. So it's carried that. It's kind of a skeleton page. So I just made some notes here. So it's carried that. I haven't actually discussed it with anybody. I looked at your. Description of the task force. Then thanks. It was really comprehensive. I read through the different. Links that you had there. So I think. I think I would really benefit from having some discussions of people. And I hope that. What I had here would. Start the discussions and then you could. Get around to. Converging our decisions and making some recommendations. So. This page. What I have here. I just. The beginning I captured the goals that. You stated in the task force. And the goal is actually quite. Quite simple. How do we. Accurately and comprehensively represent the state of a. Life cycle. So that we can make accurate assessment about a project's health. And also make. The right decisions about. How it should proceed like which includes both. Graduating to a higher stage or. Maybe getting demoted to a to a lower stage and so on. So. And. There are two broad approaches that you articulated. I'm not sure if the. The two are necessarily. Completely independent, but. Broadly speaking one approach is we just take the existing. Project life cycle diagram and. We see what it is lacking. In order to make these. Assessments and. We try and. And the other approach is that there is the view some kind of a. Badging system, whereby. We make a. We create a list of badges each representing some kind of. Some sort of attributes or. Some kind of. Quality control. Measure that each project will aspire to. And once it meets that. The criteria, then the. It will be awarded a badge. And when the project is sufficient number of badges, it can be. We can move it from one stage rather. I believe that was the thinking. So I actually would like to. Get some. From some of the veterans here on the TOC. There was a long discussion. I see that happened in 2020 and 21. Well. You were discussing. Badging. And. I have some links to that. Here. So again, it's copied from your. From the issue. And there were a list of badges that were recommended. And also a process whereby. Each project would. Acquire those badges. And that process was. Roughly speaking. Each. Maintenance of a project would self-verify the project. That project. As possessing a given badge. And that could trigger a discussion. With the project maintainers and. Folks in the high policy community. Other contributors and. If somebody had a. Dispute over that, then they could bring it up before the TOC. Which would rule on whether or not. I should stay or should be removed. And a batch could either be. Something that comes up for. Periodic renewal, like. Let's say the project is undergoing an annual review. It could be. Part of the review process could be does a project. Live up to the. The badges that kind of possesses. If not. Maybe. And there are some. Badges that. Project would. Just acquire once and. It would be deep to have met. Like, like the infrastructure badge, which. Just basically say that the project should have a. A proper repository and. And the really the basic stuff. So. Just wanted to ask, I mean. Because I see that the last. Than those pages updated word 21. And I saw. Messages from Tracy. And I know. I think it was Daniel who created the pages, but it's not on the TOC anymore. So what was the. What was the. Thinking there. Why did the discussion around by just stop. I just like would like to get. I think if I recall. The discussions. We couldn't necessarily come to any agreement. On exactly what the badges would be. How they'd be created. If they were objective enough. Versus whether they were subjective. You know, what it would take for somebody to actually. Do kind of the self. Reporting of that. And so I think, you know. As we look at things like the annual review process. You know, just do the badges start to play a bigger role in that. So I just to get the time we just didn't have a good. Mechanism for how we would move forward with doing badging. And, you know, there was no sort of. Strong agreement one way or the other. And so really the. The conversation was dropped. And so I think that's why. It's worthwhile to have the conversation. Again, and see if there's. You know, one, a different set of. Folks obviously that are part of the TOC now. That have different views or different ideas about ways that this might work for our projects. So I don't know that I have any really great answer as to why we didn't move forward other than we just didn't have any strong. Movement to do so. Oh, thanks for that. That makes sense. I think I have a. I get my tentative conclusions, which, you know, I don't know to put them as recommendations, but I would like to read them as discussion points for now. That. Badges and the continual. Evaluation. Evaluation. We'll put a fair amount of overhead on the. You see, so we have to be careful with that. If we do. Choose that option. On the. On the other hand. Projects. I mean, some things. That project would benefit from having a badge, like, for example, whether or not it meets adequate. It's not adequate. Test coverage. Maybe even bad about whether it's been up to date with its security vulnerability management. Whether and especially the document that Dave. Drafted on project best practices. I think we could probably extract some. Broad criteria that could be could label as badges and then. Could give to the project. So maybe we can discuss that. One other major thing I was thinking of. If you can just go up a little. To I. I went. If you can scroll up a little. I looked at the. Yeah. A little further above. Yeah. Yeah. The comparison of the hyperlegion. Foundation. Networking life cycle. So. You link to that. And I thought that was quite. Interesting. I was just doing comparison between the two. Life cycle. So I just. They'd not have this diagram at the right. I just made the diagram based on the table that they had. And. It looks likely simpler than. The high college diagram, but. But not really. I mean, it's just that I think. The hyperlegion diagram. There are some states are distinguished from others based on. Purely based on project activity and not just based on. The. Projects maturity. So I think that's the difference. Other than that. Lessons. We can get from the. From the ladder from the. LNF life cycle is that they have. Quite clearly articulated. Criteria. For. For all the reviews. Both in the forward direction and the reverse direction. So I think. Clearly. We should have. Something like. Something like that. Even if we choose not to have the. The budget. I think. The. Having a project life cycle. So. I think. I think. The. The. Having a project life cycle. He. I mean, we should have that. The. The original question, I think. Was framed in an either or way, but I don't think. That's necessarily how we should go about it. Like. We should not just say that a project should have. Badgers and not. Have. And we shouldn't be concerned about the life cycle. I think the life cycle should still be there because it tells us. At what stage. The project is in. But. Yeah. I mean, on top of that, if you can. Reason about. What kind of badges. If any of you want to give the project, then we can. We can have a discussion. That does my tentative thoughts. All right. So. This is really great information that you. And Bobby have put together here. I think. You know, we should definitely take a look at that. I agree that I don't think these things. Are either or type of situation. I think we can do both. Of these particular items. So I'm, I'm in favor of, you know, seeing what it would look like if we. Do. Modifier project life cycle as well as. Taking a look at the different badging that might be available. And I really like the idea of looking at the project best practices. The document that they've put together. And seeing if there's particular badges that we could come up with based on that particular document. Bobby. Yeah. Tracy, thank you for saying that because that's exactly where I was going with the documentation task force. One of the things that we're doing is trying to incorporate. You know, those. practices and move to the next cycle. So again, we're working with the labs to get that in there. And I don't think that it's again, I think best practices in badging work hand in hand. And that that that now that they've, that task force has come up with their recommendations, we're taking that in the documentation and user guide section. And, and running with that and trying to get that information available on the spots where people would be looking for it. So, you know, if you want to get one of those badges for your project what does that look like and what does that mean we're trying to fill in those gaps. All right, thanks for that Bobby. All right, so I see that we are at time. So, Rahma, I think this has been a really great start to this particular task force, and I would recommend folks take a look at the particular task force document to add any sort of thoughts or comments to that. I think for next week we are back to the security task force to close that one out. And then we'll also take a look and see where we are with the overview PR. It's really so I heard. So, so, so I presented the proposal to the working group yesterday on the open SSF, but I don't think so they'll be ready with the comments by next week. The meetings run like by weekly. So maybe it will be good if we have this after one more week. Okay, so I will see what the next task force is I'll put that in the TOC channel so that whoever is up for that can prepare. So we will then I guess talk again next week and I will again comment on the TOC channel about the next task force. All right, thanks everybody. Thank you. Bye.