 All right, welcome everybody in September 14th, then you are at the hyper ledger technical oversight committee call. There are a few people on the call that I haven't seen before so just a reminder, we do have the antitrust policy notice that is being displayed on the screen. There are a number of people here from different organizations and so we need to make sure that we're adhering to the different antitrust and competition laws across the world. And then the second thing that we have to remember about the meeting is that we do have a code of conduct. So be respectful of other people on the call and their opinions and ideas. And then for announcements today, we have the dev weekly developer newsletter. It goes out each Friday. If you do have anything that you would like to include in that newsletter, please do leave a comment for consideration. On the wiki page that is linked in the agenda. Any other announcements that anybody has for today. All right, so we do have two quarterly reports. We have the cello report. It's been out there about a week or so. I think we're mostly proving that I haven't seen any comments come through. I think we do still have a few more people who need to review before we can push that or until the two weeks is up so we'll give that a bit more time. And then the second report came in yesterday. The firefly report came in. I did have a number of questions on it. I think mostly driven by the first comment about wanting to move to graduate of project status I don't know that I would typically ask these questions in a project report but I did think it was important for us to be aware and as we prepare for that request. To ensure that we know exactly what's happening with that particular project. Nothing, nothing on the necessarily the report itself I don't think just some clarifications and questions that will help us as we start to have that discussion. Any questions on the firefly report. Not a lot of people have had a chance to look at it yet but any other comments or questions on the firefly report. Okay. If there's not, then we will move on. So we do have two reports that are due next week Thursday, the basic and the caliper report. So we'll look to see those coming in probably after our next call next week, but do keep an eye out as those might appear in the review. So, for discussion items today, we do have. Yeah, hey, Jim. Hey Sarah Tracy just very quickly since we're still on the reports. People who have seen the firefly reports may have seen our intention to apply for graduation so just want to mention that to give folks a heads up. The report is being the proposal is being written and should be circulating very soon. Great. Thanks, Jim. I did mention that because I think most of my comments are driven by that. As we are finishing that. Yeah, no, I think that's great. Jim, and we'll look forward to seeing that. And then as we're speaking about I guess graduated projects and requests I did see cacti also created an issue yesterday on the repo to talk about their desire to also graduate. So Ramon, I see your hand does up. Yeah, Peter's on the call, but yeah, Peter, you had a meeting meeting yesterday and Peter said he was going to ask for a consideration of. The next meeting. I just wanted to ask you, do you need anything? Should I send something to the TLC numbers before that meeting or can we just do a quick presentation during the call? We could do both. I mean, obviously, if people have time to review your material before the call and provide any thoughts or feedback, that's great. But we could also do the presentation directly in the call and let people ask questions and comment on that there. Okay, so sending the slides is okay or do you need a door for a wiki? So I don't think we actually I actually looked at the project lifecycle yesterday. It typically hasn't been any sort of wiki page or anything like that that people have used in the past for that. I think it's just been kind of a request and then a conversation during the TLC meeting. So I think slides are fine to present and kind of answer those questions about why you think you meet the incubation exit criteria. I think that that will work out fine. Cool. I'll share the slides before the meeting. Okay. And Jim, what were you guys doing? Were you putting together a wiki page or how are you going to do that? Because I don't know that we actually have a process around this. Yeah. At the moment, it's just in a drafting gist. I think we were planning to create a PR. So I think probably creating an issue, which would add it to the decision log. Yeah, that makes sense. Right. I think the decision log is a good place to capture these things. And then issue instead of PRs. Yeah, there might be. Sounds good. Yeah, I just realized we don't have a place to capture that. So, okay, we'll create an issue. Sounds great. All right. Any other questions, comments on this portion of the agenda of the project reports and kind of this graduation aspect? Yeah. Okay. It's good to see these two projects looking to move to graduate it. And so it'll be great to have these discussions coming up in the upcoming to see me. All right. So for discussion today, we have the first item is an update on the security policy PR. So as far as I know, there was some conversation about this last week. And if I recall correctly from listening to the recording, it was that people would like to have the policy updated before we actually vote on it. Have we made any progress on that? So I did work on it this morning. I'm part way through completing it and should be able to complete it. Certainly by next week, my apologies for taking so long on this. It's not a big deal. I just just haven't had a chance to spend a couple of hours or on it, but I don't think it'll be very difficult and I will have it prepared for next week. Okay. No worries, Stephen. I mean, obviously things are busy and Yeah, I feel bad. I should, I should have had I volunteer to do it is it's really not very hard. So I should get it done. All the hard work was done by the people that put together the document. I'm just really doing some mechanical updates to it. So I feel bad about not getting it. But anyway, next week. All right. Sounds great. Stephen. Any other questions or comments on the security policy? Okay. So the next item on our agenda is a question for the TRC. So as Rai has reminded me election season is coming up soon. And as we were, or as Rai was going through the process of trying to put together the scripts and gather the right people. I have a question about this particular statement that is in the charter, which says all maintainers are similar technical role in the case of supportive projects that have different technical roles than TLC projects of any technical project who have been active in the past year. So this is related to who gets to vote is basically this statement. And so there's two ways that we could read this statement. One is that it would refer only to current maintainers who have been active in the past year. The second way is it would refer to maintainers regardless of the current status who have been active in the past year, meaning that if a maintainer has retired sometime in the past year but was active at some point during the year. So just people who are currently maintainers and not retired maintainers. So, I guess the question to the TLC is, when we read this statement, do we read it as one or do we read it as two. I read it as one. Okay. Peter. Same for me. All right, Jim. It feels like two for me because what's important is the people doing the vote knowing what's going on. So regardless of their status, if they've been active in the past year, they should be able to vote. Okay. It sounds more like one than two to me. So I think if you, in a past maintainer, it would be strange to have you, I guess, keep office in the TLC. All right. Thanks for my part. Hey, Tracy, I think you're either a maintainer or you're not a maintainer, right? If we wanted to include ex-maintenors, I think we would have included ex-maintenors, right? Okay. So you're one. Again. Okay. Marcus. Well, I also read it as two, but I also think that one is more desirable. Okay. Anybody else? So far we've got four and a half maybe for one and one and a half maybe for two. Anybody strongly, strongly feel that it should be number two. I think one is very clear. It's easy to enforce. Okay. Thanks, Jim. Any other thoughts on this, Marcus? Yeah, one question. I mean, in the past we were not restricted to maintainers, right? So every contributor was able to vote. And then I think with last year that has changed that only maintainers can vote. That's correct. Well, I think, I mean, they were losing maybe some people. I mean, this does not personal observation. I don't know what was the idea behind changing this to maintainers only. Do you still remember? I'm thinking heart might because he raised his hand very quickly. Yeah, I can answer that Marcus, at least. So the idea was that, well, there were really a couple of things. One was we had a lot of discussion over what defined a contributor and how to define a contributor. And it turned out that the definition turned out to be very broad. And people thought that, you know, if you like sent an email or or edited a wiki, you know, maybe that wasn't as important. If you voted as someone who was an actual maintainer. The other reason was that the election is just much, much, much easier to run. If it's maintainers because we have, you know, maintainer lists for all the projects so we can just pull down the maintainer lists and get the eligibility from there. Whereas in the past, it was a massive effort and pain to track down everyone who contributed. So I guess that's the short answer. Did that sort of make sense. Yeah, absolutely. Yeah, I mean, for simplicity, this totally makes sense. I'm just, I mean, I mean, I just know one person who was very active as a contributing code, but then was not able to to vote last year because she was not a maintainer for any of the projects but I mean, was still very active. I'm just having this particular instance in my mind. But I also do not intend to, I mean, change this rule again, because I mean what you said absolutely makes sense on me as well. Yeah, I mean, I guess my comment to that would be to encourage your friend to seek maintainer status. Absolutely. Okay, thanks. So I just want to show this, this is the list that I maintain all the maintainers and where they are active, what repose that they are maintainers for. This generates a CSV file. That is 245 people that are maintainers. Anywhere within hyper ledger or hyper ledger lens, I think, you don't know that it's not my head to have to check. And then once a day, we go through here. This shows the actions of anyone and all in hyper ledger. And if we go here, this shows activity by maintainer for repo for the last to see why. So we can go in here and look at you know what has telegram Sam done the last calendar or the last year, and see that what what is activities were on that specific repo. So I have all this. It makes it pretty easy to generate this, who has done what where type activity. Why I'm always impressed by your spy scripts. I wish there's a privacy preserving way to do that as well. Well, the, so the thing is, GHE runs off of the public GitHub event log. So I'm not using any, this data is on the public activity feed from GitHub. I'm not using any special sauce to get this data. Yeah, I understand. If you have the superpowers to put something together like this and then this gives you good, good insights. I mean, which is good. All right, great. So I believe we have agreed to number one. Right. Just said you were the one who brought it up. And so I'm sure that's the expected or the hoped for results. Okay. Thank you for the guns. Thanks for bringing it up, Ryan. Thanks for. Thanks for keeping on top of the fact that we're supposed to do elections because like it would have completely slipped my mind if we would have got to December and I would have been like, Oh, hey, aren't we supposed to be like these people. I know right as we're working on putting together the schedule and whatnot and I'm sure we'll be bringing that to a future TOC meeting so that everybody can review the schedule and approve that because I believe we have to approve that before we can actually make it happen. All credit for this goes to Daniela for driving it. So this is something that I knew was going to happen this year, obviously, but Daniela has been poking David and I in the back saying, Get ready. So it happened earlier than I thought. Great. Well, I appreciate what you, you folks do for us and keeping us on track and making sure that we're paying attention to things that we should be paying attention to. So, all right, last item on the agenda then unless anybody else has anything they would like to discuss before we get to the task force. Let me start with that. Is there anything else we should talk about before we get to the task force discussion. So I think the last thing I'm here is just the badging life cycle. I know some folks have been meeting to talk about badging life cycle. I'm pretty sure we have another meeting tomorrow on this but it happened to come up on the agenda or the cycle for the different task force today. So we can have a conversation about where we're at and what's been going on. So Rama, maybe I'll hand it off to you at this point. Thanks. Okay, so I'll just give an update on this. So this is still a task force who's working through the process. This is a initial set of notes that were drafted that covered all of the history behind this task force, its objectives and open questions. So we can still see that. I don't think it's changed anything here. You just see a couple of references to YouTube videos. Under this page you can also see there have been three task force meetings so far. Actually the first meeting was for a group meeting. The TOC meeting on August 10th was converted into a task force meeting. So we had a full group discussion that day and the subsequent two meetings involved only the numbers of the task force. So if you go to each of the pages you'll find recording links. I have the notes. I just have to put them in. I just haven't done so yet but I will very soon for all of these. But for each of the meetings you will find the recordings if you go to the pages. So at a high level on the first meeting there was a discussion inspired by Bobby around how to track various criteria related to badging. And Bobby's idea was that we have a token-based criteria or a credit-based criteria. A token-based criteria is equivalent where a project accumulates a certain number of tokens or credits and then it gets a particular batch based on how many credits that particular batch requires. And that way you can also accumulate more badges and depending on how many badges and what kind of badges you've accumulated you can move to a different stage in the project lifecycle as shown here. So that was one thing that, that was one major topic of the first meeting. Also associated with that was how do we report or how do we track these tokens or credits for each project? So there was a discussion around a dashboard, probably one dashboard for all the last projects. Maybe or maybe one dashboard for each project including each lab and each full project. I think we sort of tentatively agreed that each full project should have its own health dashboard. We didn't exactly reach conclusion on the lab projects but I'll come to this whole discussion of tracking in a second. The other thing we discussed was whether or not to incorporate the labs within this lifecycle as the Linux Foundation Networking lifecycle done. And there we sort of came to a conclusion that based on feedback from, I think, Tracy, Arun, I know that it would be better to keep the labs separate because any within hyper leisure what we think of as a lab is substantially different from what we think a project should be. So a lab can be something very half-baked in terms of its code but as long as it's proposing a good idea and has potential we allow it to be a lab. But project requires much stronger set of qualifications even to get to the integration stage. So I think that's something we're going to stick with unless anybody has any objections to that. And of course, we feel free to raise this question again in later meetings or in the past four meetings or the thoughts that go to you. On the question of going back to the question of tracking credits and reporting them in dashboards periodically allowing manual inspection as well as some sort of automated filtering criteria that allows a project to acquire a badge. I think Bobby's suggestion was that he used the blockchain or smart contract system to try this and that seems to make sense from an industrial perspective. In the first subsequent task force meeting what we then discussed was that this is a great idea for a project but it is something we should probably defer to later stage because the building the entire structure for this project requires a lot of thought and a lot of work and in the task force meeting we decided that this would probably be best left to maybe next year. Maybe we propose this as a hybridization mentorship project next year. We of course before that we popularize the idea to talk about what this actually involves and maybe we'll get them committed volunteers to work on this next year. Our immediate goal is to focus on making the clearly outlining the criteria outlining the project lifecycle transition criteria state transition criteria, both going forward in life as well as reversion of a particular project is not meeting its duty. So I just want to pause there a minute and ask for feedback or if anybody has an objection. So question is the other decision is we move the infrastructure part of this the whole idea about tracking credits to a later date. Right now, at least this year we just focus on clearly drafting the set of badges and the forward and reverse criteria for each stage in this diagram based on the badges that a project has committed. So that's going to be our goal for the staff. So moving on to what we are doing right now. The past couple of weeks we've been discussing exactly and actually been into this in the most recent task force meeting. So what we're trying to do right now is draw a first thing that want to do is draw a list of minimum list of badges or let's say a complete list of badges that any project should be firing for later we will that the column here. So there are a bunch of things you want to list for these badges, the name, what are the criteria, how we're going to monitor particular project to see whether or not it qualifies for a given badge, how frequently we do the monitoring. And what is the penalties or compliance with respect to that particular badge. And most importantly, how does a particular badge factor into a particular to any state transition. So, like, this is not complete yet something to work on. So, in the last meeting we went through maybe half of this table, as you can see, and we made some notes around what whether or not that particular badge is useful and how we check for check for the particular criteria to have been met by the project maintenance. And make some notes around that. So, thanks to Tracy and Arun for being active in that the task force meetings. Thanks for all your input your suggestions and feedback, which is all listed here. So, nobody has, does anybody have anything to say right now or I can just go over the list of badges, the criteria that you want to discuss before. And yeah, once I run through the list, we will of course go back to the next task force meeting and continue with discussion. Any comments, questions on the phone. Just trying to look at. Okay. Okay. So, the list of badges here, if you look at column one, they're drawn from the main page. Yeah. So, there were lists of badges that were described in earlier, that the product of an earlier TSE meeting. You can see, as you can see, this was last updated in 2021. And there's a list of badges here with particular criteria that were listed. So, yeah, those are listed here. We go from legal up to the CIA. I have those there. And in addition, we've added a few extra badges for consideration, which seem to not necessarily be covered by what's already already in the olden days. So, going over these values. So, legal is basically it refers to people back to the criteria here. The project being compliant with all legal requirements. Primarily, it's that the code is covered under the Apache to license and see if it's compatible dependencies. The main thing they have to check here is whether it figure out is whether this can be tracked or made it way. So, maybe, right. From this, if you know of any actions that scan an attack code base for licensing declaration. I know it's easy to scan the repository for license file, but perhaps that's some code that's not completely covered. So, maybe there's a right now we check it manually, but other than that, we can build some kind of GitHub action that the mandate that every project uses and which reports whether or not the entire code is covered by licensing declaration. And I think that would this would allow for evaluation to be ready. I don't know one off the top of my head. We do have either quarterly or twice a year. LF does do scanning. But I will have to look into to see if there are any actions to watch licenses. One difficulty here would be the penalty for non compliance. Would either be re licensing the mitigation would be re license. Remove the code. Or the, it would have to be something more drastic than move the deprecated. And I don't know what that would be off top of my head. So, so right, I guess that means that what you're trying to say is that if people are non compliant with the legal requirements that we have for hyper ledger. And they're not doing anything to fix them then the the result in the action would potentially be even removing the code from the hyper ledger repositories. Did I understand correctly when you said kind of drastic. I would have to consult with our lawyers. I think the easiest mitigation would be to make the repo private interim. And then we would have to figure out if that would be removing the code or some other. I don't know heart has his hand up part. Yeah, I'm just going to agree with right we can't mess around this. So, we would have to ask the lawyers about this. And they are. I mean, this. This is like. Zero or priority 0.5 for why the Linux foundation exists. Yeah. Having a hand, you know, having a good handle on licensing. We haven't really had any projects where licensing was an issue where when stuff was brought up when Scott sent me an email saying, hey, by the way. We were able to get that remediated fairly trivially. But that might not always be the case. This is also something that legal will help us typically without a very fast time scale. For the purpose of this task force, then we just have document that. The, I guess, yeah, maybe. If we that can find out more in heart of, right. The penalty for non compliance will be basically just. As you say. Not just to deprecate it, but make it private repo until. I mean, I think you can put like determined by LF legal staff or something there. Because it would highly, I mean, there could be like very major things and there could be very minor things, right. Yeah. But yeah, I don't think deprecation solves anything. So take that out. I guess, I guess a question. Sorry. Anyway, I guess the question becomes, right, if we have a project that is. That's using using our current terms right graduated. And they're not dealing with the, the legal ramifications. You know, maybe it's just one repo out of many. Like we can move that repo to private, but what should happen to the actual project itself at that point? You know, if they're not following best practices, then. You know, and maybe, maybe this becomes a non question if for some reason we just start to capture the badges and not states. But if we do continue to have a project lifecycle state, then. You know, I do think that something should be done to a project that says, hey, this is not really a graduated product because they're not acting under the best practices anymore. Tracy. Yeah. Sorry to jump in. No, go ahead. I thought I was the only one with my right hand raised. Go ahead, Rama. No, no, I thought Tracy was right, but you can go. I think this, this would be a big judgment call, I think, because there are so many different ways that a project could be in non compliance. And some of them might be that like somebody just made a small mistake, right. They might. Someone might make a legal mistake, despite following like best, you know, best software practices, right. So I would think that the TSC would have to judge this on a case by case basis. Yeah, I guess I agree with that. I think that, you know, I'm thinking about something, I guess more critical but yeah, you're right that we need to think about the minor to the critical and what actions will be taken based on the different, you know, different ways in which somebody is non compliant. Yeah, a third party dependency changing licensing or something could be an issue, right? We've seen this. And that's like, you know, as long as you respond quickly, right, you know, you probably shouldn't be punished at all for that, right. Yeah, what, what is, what is quickly. If it's a major, major dependency of your project quickly, maybe longer than you would expect it to be or want it to be. But yet, you know, you've at least recognized that and maybe called it out as well. I don't know, right. I feel like there's some certain things that, you know, could potentially delay somebody from being able to respond in a quick manner. I agree, but I will also say that if you've been using a dependency that's a major part of your project, and then they change the license, then you should be able to keep your version of dependency pinned to the last version that has the license that you want. So I would, in that scenario, in that hypothetical, I would expect the project to pin it to the version with the license that's acceptable. And then if it takes a long time to migrate away, then they can do that while they have it pinned to the license. That's correct. Okay. Is there anything, I don't know, hard, right, maybe you can find out and shed more light on this? In the meantime, I guess we will, the decision we'll have to make is simply like, what is the penalty for non-compliance? And it looks like we can't have a one-size-fits-all penalty, right? So we'll just have to evaluate in case by case basis. Jim? Yeah, this makes me wonder. These badges are applying to the releases or applying to the current latest code in Maine, because there can be a huge difference in the hypothetical case that Peter just mentioned, which can be real, right? In some of the very popular open source projects like Mongo is moving to a more commercial stance and moving back from open source. Something like this may actually happen in the future. Are we applying these to, are we making a difference between, okay, so all the existing releases are still compliant and there's a status of the badge applied to those, but the latest in master is out of compliance and there is a different badge for that. That's something to consider. Good question. I think, does it, I thought it applied to the latest staff of the Maine, but the others can agree. Stephen? In the case that was just raised, the, if they, if a project were to pin on an open source one, then they are in compliance with this. So really that case is kind of, doesn't cause a problem. So we should assume the situation where they're out of compliance, they've stuck with the Mongo, you know, hypothetical Mongo moving to a private source and are still using it. And then that would be the case that goes to the LF legal staff. If they come up with a mitigation, just like you talked about where they remain legal then or remain open source, then it's not an issue. Yeah. So, and I think, you know, Jim, a little bit to your point, I think if we look at how we're going to monitor this or the frequency of which we're going to monitor this, right, this one particularly says continuous. You know, if it's continuous, then it should be what the badge is currently, not what the badge was when release one data was put out or something like that, right. And so I think for each of these sorts of badges, we need to look at what is the frequency of which we're going to run these things. You know, and if it's a quarterly badge, then, you know, maybe remote these as Q1 2023 badge or something like that, right. But if it's a continuous bag, I think it's a yes, no sort of answer for whenever the person who is interested in the badging of these looks at them. At least that's my take on this. Tracy, I think in the previous meeting, we tend to be the law, at least there were no objections to evaluating badges on a quarterly basis. In this particular case, do you think it'd be useful to have a badge associated with the latest snapshot and badges tacked to particular reasons, right. I think that that would just be adding noise. I think it's reasonable to have badges, you know, tied to a release, as opposed to a snapshot. And I will find out. I did have a conversation. A little while ago with one of our member companies, where they were confused about just graduated status. Apply to only one, like fabric inner inner graduation back at whatever release 1.1. Is that the only release that fabric did under that graduate status is that the only one that applies to so there is some communication clarity that we need to provide around this and I don't think adding any more noise would be helpful. Yeah, I agree. Right. I mean, I think, you know, people want to know what the current status is more than anything. Right. As as they are reviewing the different projects and deciding which one to use. What is it was it currently look like. Maybe there's some trends or historical data that they might be interested in. And I think we should decide what those things are. But, you know, if you look at the graduated status, as you said, right, it's a it's a wanted done. You did it or you didn't do it. But the question I have more, you know, yeah, okay, I got a degree, but am I continuously learning. Am I growing. Am I improving. That's that's what really matters. And I think that's what should matter for our projects as well is whether or not there's continuous improvement that the health of the community is maintaining or improving. Right. You know, I think the challenges that we have right now is we don't have a way to see that on a regular basis. I think the quarterly reports were told what we're told, whether or not it's accurate or not is a judgment called by us as to, you know, based on information that we've leaned from conversations or work in the community or whatever the case may be. It's really hard to know unless you're in there day to day, or being able to track certain things day to day, whether or not a project really is doing well still, or did they graduate. And they're, you know, they're, they've gone downhill since that graduation, right, like that was the end of the glory days and nothing else is happening in their project at this point, right. So, I think that's the, that's the challenge of why this particular task force keeps coming up is because we haven't really solved the real problem, which is determining what the current and true status of the project is. Yeah, hi everybody. That like the great point is the continually monitoring this stuff. And so, when we were thinking of the tokens in the dashboard, if you think of all of the different badge types, like a slice of a pizza pie, and that when you've completed it like got the whole pie colored in and then you get that badge. Or the tokens that require you to fill that in, you get the tokens to move on to that next phase. And as far as continually monitoring, it could be tied into that new thing that we're doing with the TOC where we take that a project for that one big report every year and run that have the maintainers run the check through the dashboard that we're going to create in the next year. So, again, I think this is the, maybe necessarily. I mean this applies to the whole project is done task force, not just to the legal credit. We do want to know precisely how well the project is doing and we need to have a good way to both to track it accurately and to visualize this in a way that is intuitive to people. So, yeah, point taken. Okay. Maybe we'll review this issue tomorrow's and next batching task force. Okay. Moving on to the next one, maybe we'll be able to cover one or two more in the time you're there. This is the diversity badge and diversity means the basic amount of decentralization and community involvement in a particular project. We go back to the criteria district here. So, project must have an active and diverse set of contributing members representing various constituency, and project is not highly dependent on a single contributor. And the number here is important, but there are at least three legally independent committers, and there's no single company entity that aspires to be successful project. So, I think both these things are important. As the scheme of speaking mentioned in the last task force meeting, the incubation criteria also requires three or more legally independent, three or more organizations participating in the maintenance formally. So, they should be in the maintenance or MD file. And also, the loser criteria we have to monitor is that there's no single company or entity that is dominating the project. So, like if you have, you could have, say, eight contributors, and two of them are in two, one in company one, another one company two and say six of them in company three. That might mean that company three has not a power in deciding what's going on the project. So, that is also something to watch out for, and it should presumably not meet the definition criteria unless the maintenance can show that all there's not too much of a queue in the contributions made by any single organization. So I think that's kind of what we decided. How we check this. Okay, this is all written in the notes here as well. The question is how to check this. Not sure if there is really a programmatic way to find out how diverse contributions are to a given project. The one easy thing we can do is we add organization field to the maintenance, the file, and then we have a, we can have action trials, but again, it's pretty easy thing to look at and evaluate, take a few seconds. Other than that, if somebody is going to take the responsibility of evaluating this particular batch, then they can look at the commit activity and as well as the help dashboard, the links to which I think we submitted a report and report. Those can be checked to see how diverse the contribution will be. And so yeah, at this point it looks like this is going to be a manual check that reviewers that is one or more of what you see will have to do. That makes sense. Okay, I see no objection. What should the parent, okay, Trace. Sorry. Right. Is there anything that we can do with the GHE potentially to to see this, I guess GHE doesn't really have a word in it. Is that correct? That's correct, but we can, we can, we can get that right. So if we went into GHE and updated the. There's nothing blocking us from adding data to the containers.csv, right? We could add a company affiliation by we, I mean, me. So the answer is yes, sort of. We're not there yet though. Yeah. Yeah, I think company affiliation is always the tough part to get with this, right. Because company affiliation changes over time and, you know, being able to track the contributions to a particular timeframe for a particular company, you know, is the challenge. I guess if we're looking only at current, then it is a matter of what is your current affiliation, right, get independent or with a company. And, and then, you know, based on that we can do some sort of percentage here, right. So, X percent comes from company X, Y percent comes from, I think you guys get it right. But the different sorts of percentages based on the different companies that are maintainers or individual affiliation. I think that's what we would like to put out. Thank you. So we are seeing the end of the hour. So we will take it, we continue this the next, that's when we have this review. And tomorrow, we have the next edition of the task list meeting, same time of this meeting. So yep, please join the call to contribute to give any feedback. Thank you. All right, we from. Well, you want to point out that it. Now, when you talk about percent contribution, we get, we, that's a whole other kind of the corn, right? Like, are we talking about PR comments? Are we talking about lines of code? Right. So that's an even harder thing to measure. But no, I think what I was trying to say was not contribution, but percent. This number of maintainers come from company X versus this number of maintainers come from company Y. Not how, how much of the contributions come from company X versus company Y. Because this one is particularly focused on maintainers that I was trying to communicate that poorly. So hopefully that maybe clarifies a bit. Okay. No, I was actually thinking about contributions and both what points that you and I raised. I'm not sure that how to make the contribution. Is it percentage of the commits or projects life cycle? And that's the one thing I can think of, but I don't know if that's something we want to use to issue value issue this particular time. Okay, well, I guess with that we will close out today's meeting. Thank you for the updates and for the discussion everyone. We will obviously see everyone again next week with a couple of different topics that I've heard from today. One being an update on the security PR, the second being the move to graduate it from cocktail. And then I don't remember which thing is up next, but I feel like Peter, it may be you for the automated pipeline. So I did include that in the agenda. I just can't remember what it was. So we will take a look at those things next week. So thanks everybody for participating and joining.