 All right. Welcome everybody to March. It's March 2nd. The hyperledger technical oversight committee call. As most of us are aware, I think we've been on this call before, but for those of you who are new, we have two things that we must divide by the first is the antitrust policy notice that is currently being displayed on the screen. And the second is our code of conduct, which is linked in the agenda. For announcements today, we have two announcements that we've heard in the past few meetings. The first one is the hyperledger definitely developer newsletter goes out each Friday. If you have something that you would like to include in that newsletter, please leave a comment for consideration on the wiki page that is linked in the agenda. The second one is the hyperledger mentorship program has started. There is a call for project proposals and that call goes until March 15 so just under two weeks that you have to submit your project proposals if you are interested in being a mentor. I did take a look at that there are five out there that look really interesting so looking forward to seeing more show up. Any other announcements that anybody has or would like to make. Okay, there's no other announcements. Then we did have the quarterly reports here. So Lane did come in by the time I had created the agenda. We have also since received Ursa and cello. That have come in the bevel one is still out there. I think there's a couple of people who have yet to review that one. Please do take a look. I didn't see any questions except for the one that I have on Ursa, which is that the Ursa report for q one actually comes out and is supposed to be doing like two weeks. And I think this happened the last go around to is we had the quarterly report for Ursa come in, like, just before the Q4 one was due and so we, we had some bit of confusion there and so I'm wondering if we should make the separate report the Q1 report and just assume that the Q4 report doesn't happen or in some ways what should we do here. So Stephen I see you have your hand up on a separate topic so I don't really have an opinion. I mean I think it would be it makes sense that that it be the whatever it is 2023 Q1 report, I would say but hand up for a different reason after. Okay. All right. Thanks, Stephen. We'll get to you in a moment. Does anybody else have any thoughts on the Ursa report and what we should do about Q1 versus Q4 or no. So I agree with you I think might as well skip it the only problem is they shouldn't become a habit that the groups can just keep on completely agree on. All right. So, yeah, Peter. There was a comment, though, that they had changed some of their committers. Yeah, I did see that too right. So wondering if maybe we could get them to add the Q1 information to it. Unfortunately I didn't see an answer from the submitter and what they were planning to do for Q1 so maybe we'll take that back to the discussion thread and see if we can get some sort of closure on that. Peter. I would leave some sort of trace of it that it was skipped. And then other than that, I would just skip it too. So that that should maybe hopefully deter the habits forming where the projects just skip it because it's actually pretty easy to skip it and there's no any sort of consequence. Of course, I was just writing down how this has been skipped is not really a severe consequence but I also guess you don't really want to see your consequence or at least not a person. Okay, makes sense Peter. So we will take that then back to the submitter of the report and see if we can maybe maybe get the Q1 report to come out since it does have some differences like Ryan mentioned and see if we can see what we can do there. Yeah, I think Arno and Peter you're both correct we don't want people skipping their quarterly reports those are useful and they do tell us that things are happening or not happening it's the case maybe. Alright, so Steven, your topic. Yes. I missed this in in when I started to prepare quarterly reports but what is the timeframe that you're supposed to use for a quarterly report. Like the for the first is for releases and for the LFX insights. I've always done it that is the calendar quarter previous to when I'm reporting so I would do like when I did one this February I think it was I did from September to December as the time range that I was only talking about things that happened during that quarter. I noticed in the reports today that I was looking through it, the period was November, end of November to end of February so they're because, you know, basically they're putting it into February they go right up to the point of release so is there a guidance on this. Just like to be consistent with what others are doing and what what we're supposed to be doing. Yeah, I don't think I don't think we really have any guidance that we've given to projects. And consistency is key right consistency when within those reports for the project. So for you if you're always reporting the quarter, right the calendar quarter, then you will always cover all of the information and you won't skip anything right, say from the beginning of January to when you report it. You will have reported that, obviously in the Q2 report right so you're reporting on Q1 during the Q2 report. There are others who basically do from the last time they submit it right so that they're consistent in as far as not missing any time between when they submit it the previous report and when they're submitting this report. I don't like like I said I don't know that it matters as long as we're not missing any sort of information that exists there. Arno has his hand ups maybe has a different thought there. No, I just wanted this question has been raised before and I always tell people you can choose either one of those. You know, ways that you just talked about that Tracy, I think the problem with fixing saying this is the actual quarter is that because projects don't always all report at the same time. If you end up, you know, being towards the end of the quarter reporting on the quarter before is already quite far away. I remember doing this for fabric at some point and it feels like well I should report on the last, you know, three months rather than the actual quarter before. And so, for that reason, I felt like, you know, the last three months, whatever that is for you at the time you do report. I think works better. And as Tracy says, if you just keep doing this anyway, then you're consistently doing the same thing. You won't have gaps and that's what matters. Thanks Arno. Right. I have a terrible idea that I'll make as a suggestion. And that's just that we go. We all use fiscal years right and everyone reports in the same day. So all the reports will be due on the first day of the quarter. That would give clarity. And if you're a manager of multiple projects, you would just have to get into insights one time a quarter and get all your reports done. But I don't file these reports. So there might be people that have other ideas. I see a couple of thumbs up. So I see the floor to heart. The biggest issue at that rise, not the people filing the reports, but the people reading the reports. I don't think we would get very good quality reviews if we had all the projects reporting on the same day. Either people would have to do a ton of work or they would just mail it in. No comment. Yeah, Alexander. Yes. Just as a suggestion. It might not be that. There could be middle ground between detaching from the fiscal year entirely and between reviewing everything on the same day. What we could do is we could just do a randomized assignment and projects report on certain days after the fiscal year begins, but it's a fixed date. And it's assigned externally. What could be done is that they have to be reported on the same day. And as I pointed out, the people reviewing them are given a regular schedule to review the, the basically reports reviewed but not all at the same time but in sequence and that sequence is determined. Allocate a certain amount of time, how much it takes today. Double that and we have a good estimate. Yeah, so I think your first option is what we're doing today, right, where everybody has given a certain time in Q1 to report, right, their Q1 reports, whatever that is that the project calendar that exists. And then your second option, the, I guess the concern that I have, and I'm not sure if it's a big concern, but if we get everybody to report say on January 2. So they can recover from the new year. Then we have, you know, this sort of schedule that being shown on the screen here, where the TOC reviews on, you know, a weekly basis, somebody reports. And it might be that if there are questions or concerns, getting the, the submitter to respond to those questions or concerns. You know, say a month later, right. I think that's the biggest challenge that exists there but I, I don't know, this is, this is what we do today and I think that, you know, back to Steven's point, it's really just up to the project as to whether or not it makes sense to report for the previous quarter or for the 90 days since the last reported. I've built this calendar based on something that Tracy had done. And as this calendar has evolved over the years. I've tried to make sure that projects that share maintainers become more and more aligned like Aries, Andy, you know, grid and transact. I've kept fabric and salt to where they were since they were the first two projects to kind of get the ball rolling. So they're still kind of at the top. And to spread this out so over the quarters that these line up and they help us avoid. At the end of the year, it's easier since we have so many holidays to avoid having everything come do at once. I'm not married to any of this. If anyone has a better or fair way to do this. Let me know. Let us know. I'm totally game to change this up for 2024. I'm going to try for bringing up this. I think this helps people to kind of see that there is a consistent schedule for each of the projects. It's just not consistent across all projects. Like, meaning everybody reports on the same day. Other thoughts or comments about this. Even did we answer your question or cause more computer. Sorry to take this down radical. No, it's all good. So good. Thank you for the question. Alright, so if we then go back to the agenda. I guess the question that I have is, are there any other questions on the reports that we should talk about before we move on. Marcus. I wanted to say that I actually kind of like the idea of having this fixed schedule on my personal preference would be I mean not spreading it over three months, essentially. I mean, that of as part mentioned this will would introduce more work on the reviewers but on the other hand I mean reading or reviewing report which is already I mean this is also smells a little bit like old cheese. But anyway, so I would keep the system as we have, but I think it's also more important that the reports itself that they are consistent. So what I actually do not like by when I reviewed the reports we had so far is that some reviews basically report for the actual quarter. And some of some others were actually reporting on the beginning of the quarter until they until the actual report submission was done because I mean if that will happen for a project which submits in the end of the current quarter for the last quarter then this report will almost spend half a year I guess. Yes, this is just my comment. Yeah, thank you for that. Okay, now I'm going to having thought about it a bit more. I agree with Marcus I think and I find as a writer. It's kind of painful to have to figure out okay, let's ignore things like I had comments in my last one since Timo knows about our project. And I mentioned this release and this release and that was because it happened after December 31. I would say to deal with both of those things that a report, I think the distribution of when they're due is appropriate. I think we should make it that the report should cover the three month period before. And any reports that have been any projects that have been reporting differently should just fill the gap with an extra note in their next report. But from then on should be consistently reporting right up to the day that they submit. And basically that is just to make it easier to both write and read. So you know it's always this is the latest of what's happening up to the moment. That would be my suggestion. So, obviously, the ones that you've been submitting even hard that way. I guess we would have to find out if there are other ones that report similarly to you. So I guess we'll have to go through the list and see and then maybe let them know that that is what would be preferred. And then one other is maybe we make them do. I noticed, you know, do 2nd of March do 9th of March would it make more sense to have them do at least on a month basis so that they're there, but that actually never mind. I think that's gets complicated and comes back to the you have to review too many reports at once. All right scratch what Steven just said. All right. Any questions on the reports says they were submitted at this point though. All right. I'll take that as no. So, I guess, two things. First, I didn't have any specific to see topics to discuss only task force topics to discuss today. But does anybody have any other topics that they think is worthwhile to bring up to the TOC today and discuss. Thanks. So, I think I wanted to bring up the topic of project and suppose and I know Jim was working on it last year. And we had a lovely discussion on the GitHub issue itself. And I wish that we bring that again we bring it up again and Jim I'm not sure you have lived availability. But I think we have so many good points over there in the chat. And it's worthwhile for us to consider those points and bring them up. I'm just just FYI Jim is not on the call today. So, we won't be able to probably have conversations with Jim about that. I did associate your message about the task force discussion that you don't have a computer and to see if we can switch out which task force we talk about today. Before we do that though, any other topics that anybody would like to discuss on the TSE level. That's not task force related. All right. So that would be a no. So, I think we have two options here. One is that we can talk about security vulnerability disclosure without a room you having a laptop. The second option is last week Dave, they've been putting you on the spot. So if you're not ready to say you're not ready. But last week you had asked if we could continue the discussion this week of the task force that we were going through last week. So what preference do we have for task force discussion today. Would we like to try to talk about security vulnerability disclosures without a room and having access to his laptop. I personally would prefer while things are still somewhat fresh in mind that, you know, Dave carries on with the conversation we were having last week, but personal preference. I do see as well that I have been working on some vulnerability disclosure stuff that is sort of half baked and maybe it would be better to talk about that in a later week and let Dave take over this week. Dave, everybody's putting you on the spot. Are you ready? Really able. All right, I guess Dave can do that. Do you want to share your screen or do you want me to. Yeah, I'm just trying to pull it up here. I think I got it. Okay. If I recall, we got maybe halfway through the community section. I forget exactly where we left off. I think we got through public meetings. Next topics we're going to be meetups and workshops. So I didn't have much initial guidance here other than they're a good idea. But if anybody has thoughts on what a good practice would be for meetups and workshops, we can add that here. So I guess question David Boswell. Do we have any documentation or anything on the wiki that would help with people who are looking to put together workshops or meetups that we can point to. There is the meetup organizer guide. We don't have a workshop organizer guide that's probably a good idea to do it. I'm not exactly and I apologize about this, but I need to jump to help get a meetup going in about five minutes. We're live streaming something, a meetup from MWC in Barcelona. So I'm sorry, I'm going to miss some of this conversation. But yeah, I think meetup and workshops are a great idea and we do definitely want to support and encourage them. I think the ones we've done have demonstrated that they bring new users, new contributors into projects and the projects that do them seem to tie into the project health discussion. I think the projects that do actively do meetups and workshops tend to have indicators of health that we don't necessarily see in the projects that don't do those things. I'm fully supportive of this is a best practice and I again apologize I'm going to have to drop in four minutes for part of this discussion but there is the meetup organizer guide we don't have a workshop organizer guide is the short answer. Okay, we'll add the link to the meetup organizer guide. And we do sorry one more thing that just occurred to me we do have a bi-weekly meetup and workshop planning call maybe we can link to that as well that I can drop both of those links on discord. Yeah, I'd like to link David for the wiki page in the discord where all the meetup stuff is and the workshop stuff. Great, great, thanks. Okay. I guess I might be some more good ideas and run pull requests but I've spent the obvious. Oh, is there another comment here. Yeah, sorry. We're going to have to sign up to talk about meetups and workshops. Right, I think one challenge that I've seen people facing with that aspect is some of the maintenance have been reaching out or some of the people have been reaching out they don't know who to reach out to in order for them to organize the meetups. They don't speak or they're willing to give a workshop. They just need to find out people and I believe that has caused some delays or like they don't know who to talk to or who to reach out to. It would be worthwhile if we can have a mailing list where people can send an email saying that I'm interested in kind of this meetup to talk on this topic. And they can interact with an extra on the meetup optimizers, and they can respond back over there. There is a meetup organizer mailing list there's also meetup alias so people have questions. Those good the meetup alias goes to me and the meetup organizer mailing list goes to all the organizers. Let's add that information here. Bobby. I just want to say like I've worked with David running a meetup in my area. And there is a lot of resources out there. One of the things that, like a little history that has changed a little bit. Meetups before coven obviously were very geographically secluded. And then once coven happened, David opened it up so that if one group puts a meetup out there, it's broadcast to everyone. And now with the meetups were on the fence about going back in person because that seems to have so much more richness to the meetup and bring so much more so we're trying to figure out like a hybrid broadcasting them on YouTube but still encouraging people to meet up in person. And that's basically the meetups and I know with the workshops. The history of that was whoever wanted to do a workshop put it out there usually came out of something from the global forums. And I know now john carpenter and Jim Sullivan who have taken over the learning materials working group. They're really focused on doing hands on workshops and Jim has put a couple out there that are fabulous. So if anybody has any ideas for workshops like if your project isn't getting enough. So people coming in you might want to hook up with john carpenter and figure out a network meetup that will or network workshop that will get everyone involved and target the because they're attended fabulously these workshops people really want hands on short courses that can get them up and running on all the different projects of their flavor so just to catch up on those two items. Thanks Bobby. Anything else for meetups and workshops. Okay, so where I was going to pull requests I was just stating I had the obvious thing here about quick turnarounds are they are appreciated and encourage future contributions. I think of course, for new contributors especially it's good to be welcoming and positive but I covered that in the first bullet here. Peter. Yeah, and you can see what that is in insights. Sorry Peter. I just wanted to say to have not just a quick review turn around point but also get a point which we have written down some other document I'm just not sure exactly there but point being, if you put an extra sentence there maybe that says try to review the pull request in the order they come in instead of based on which one you like better. I think it was something like equal attention to pull requests. Okay, sounds good. Yeah, I think just on the on how to prioritize pull request probably made the if the pull request addressing one of the issues that's there in the the get up, then I think it's probably address it rather than just some random pull request somebody submitted. So, because it's solving a problem that I think the project maintenance want to be solved. What do you think, Peter. I mean, I think it kind of goes on said I think the maintainers use good judgment. If there's something that's really important and hot. I think maintainers usually will prioritize that but as a general rule of thumb it's good to have equal attention to PR so I think that's, I think that's fine. Yeah, I'm also guilty of having merged pull request out of order. And actually I did that just a couple days ago because we had to build broken, and it was important to get it back on track. So, I'm very on board with also adding some additional little clarification in there that says to get some of the best effort basis he's best judgment. Hey, yeah, so I've been someone who's really been encouraging this. And you know I don't think it has to be a hard and fast rule like right obviously if you have a critical, you know, a critical security review or something or you know that can get jumped to the front. Another is that sometimes there's perception that, you know, people review like their friends PRs before before PRs from community members they don't know. And, you know, the idea is that with some adjustments for priority of the PR there should be, you know, it should be FIFO generally right. You know, I'm actually really curious to hear what other people like like Peter, you know, had some just now had some good comments about this. You know, I'm curious to hear what other people think about might be, you know, good ways to practically implement this. So thanks. All right, so I've said equal attention to PR is review and order of arrival as a general rule of thumb so it's not a rule written in stone but something to strive for in terms of practical ways to implement this I can't think of any. I also, I don't propose that he implemented some sort of an instrument on this. Just to at least mention it because from what I can tell a lot of people might not necessarily think about it. It's just sort of an unconscious bias that just creeps at some times. I think including that in in the maintainers guidance, which I have started to work on by the way I think I took that on as a task last week so I've started to work on that and I think just putting that in there, knowing that in the other reports, part of the insights and part of the metrics we look at our, you know, processing times on PR is processing times on issues I think that is just not hard and fast guidance out shall do this but rather, you know, these are things that are important to the, you know, the, the health of a of a project in a repository and therefore, you know, as much as much as you should pay attention to that when you're a maintainer that's one of your responsibilities. I think that's the best we can do on that and I think we can include issues and in that as well. And the other thing I noted that is a big problem in our projects recently is the maintainers looking at them and thinking and what they need to do with it but not actually sending feedback to the community and particularly the contributor to say, Oh, by the way, I'm looking at this. If it is in in my mind, but we've got to do this and this before we can merge that. And I find that when I realize that's what's been happening, it's kind of frustrating. But again, guidance to the to maintainers to help them, you know, to get that communication going, the need for that communication. Yeah, I'll jump in here. I think over communication is a great, great approach. Like one of the things that I think good project, you know, really healthy projects do is that when like a review is going to be slow, you know, maintainers will will tag it and say like, Hey, you know, I saw your PR, I'm a little swamped right now, you know, I will get to this in approximately, you know, X time right. And that way, you know, people know that they're just not being outright ignored. They just, you know, they saw the, you know, if you're a maintainer you've told them that, you know, this is going to be slow. But, you know, you're not intentionally forgetting them. You're just super busy and you'll get to it when, you know, when you can and hopefully when you tell them. So I really think this is a good idea. Like, you know, if people are waiting on you, like, comment and tell them that you've seen it and you're going to address it you just can't right now this makes people feel so much better. Rather than just a black hole. Yeah, I think that's really good suggestions here. Anything else on pull requests. Alexander. Just an observation from our side. We often have very string coding guidelines. And we often found that we need to relax them for community contributors. Rasters of the very popular language and fewer people still capable of producing into the level that we require. So what we found is sometimes it's better to just give very, very gentle guidance and then fix up after it's merged. It's a good point. Try to think how to word that here. Be gentle on your contributors. Perhaps relax. Coding guidelines and fix up later. Okay, anything else on pull requests. Okay, let's go on to contributing docs. So I put several of what I thought were good references here of contributing docs that projects already had there in a smattering of different places between the wiki and GitHub and read the docs. So we might want to standardize on that. I guess that kind of goes to the whole doc work group, which we will talk about in the later session. But the other thing that struck me is a lot of the content in here was repeated across the projects. So one idea I thought is perhaps we take a look at this and we try to pull out some of the content that is similar across the projects and put that kind of in a central place so it doesn't have to be reinvented and read and re documented for each project they can just reference kind of the the basic guidance around contributing to hyper ledger projects. And then of course each project might have additional considerations they'd want to document on their own. But if anybody has a project that I think they think I've missed in terms of a good reference. You know, we can add it here as well. But I'll open it up for other thoughts. Okay, I'll just say I think having a consistent template. Things that should be included in the contributing guide is extremely worthwhile, which I think is to your note there. But, you know, obviously, each project might have slightly different requirements for contributing that they would want to put into place but I do think that, you know, these, if we have something that says, these are the things that you must include in your contributing guide. I think that becomes very useful. Hey, anything else. All right, if we take a step back, or is there any other guidance around community in general that we should be mentioning to maintainers and new maintainers. So on top or not, but within the contributing MD, if we have a template, I would suggest to be very sure and thorough of that template including some guides and tutorials or basic good stuff. Yes, that's what you do your struggle with 95% of the time on course that I believe. But I don't know if this is going to spiral out into complete different conversation that then becomes off the premise document so they don't have to talk about this. I just wanted to mention. I missed part of that Peter but I do have a comment later on when we get to documentation just talk about the project developer guide including coding guidelines build instructions test instructions is that kind of the area that you were targeting. Were you talking about a tutorial in terms of usage. No, it definitely would be project coding guidelines of closest to it I guess. Yeah, we can discuss it and that's cool. Okay, let's defer that to get to that discussion. Maybe we'll talk about that also in the doc work group doc task force. David in the community section do we have anything in there about making, making decisions publicly and communicating kind of those discussions online and mailing lists and that sort of thing. I think that there are times when organizations can hold meetings privately and make decisions. And then people in the community are like where did that come from. I don't know how we came to this conclusion that this was the right decision to make. So I guess that's one that I just going through in that first link in the YouTube presentation it's with and I am doing a presentation on kind of good practices. And so I was kind of going to do there and that was one that I didn't see included. How's that decision should be made in public or at least socialized in public. Yeah, I think that makes sense. And then also going through that same presentation under the pull request. One of the comments that we have here is like, do not waste the contributors time if you're not going to accept the PR say that you're not going to accept PR because it doesn't, you know, match up with the roadmap or that sort of thing. Like, don't don't leave people hanging that they think it's going to be included in the project but in the end there's no way it's going to be included because it goes completely off the direction of where the project's going. And then I think the other thing is like mentoring is the other piece of this. And it could be mentoring on for new contributors and then come in and submit a PR like helping them through that process is probably really important to. Sorry I missed the last one I was typing while I was typing the first one. What was the second one again. It had to do with mentoring. So mentoring new contributors on kind of what that process is like helping them through the process. And I think mentoring would even come outside of PR right like but I think just the mentor aspect in general is important. All good feedback here. Anything else. All right, let's see that might be good place to end because we have the security section next and doc sections next and I'd kind of like to have the next discussions and those task forces before we talk about what we put here this was kind of just going to be a summary of some of some things if they don't catch all if maintainer doesn't want everything else is going on in those other places at least the most important things I think we should mention here. But I guess, what do you all think should we at least start these sections. I will say I thought this secure developer guide was really good from open SSF. So they cover a whole lot of things. But it's not an overwhelming amount of things so I think this is a very good reference. We should point people to. And in fact, most of my bullets here in line with what's over there as well. But I tried to call out in a concise way some of the most what I thought were the most important things. So what do y'all think should we start this section or defer until after that we talked about the security tax task force next time. I was just going to say to try and start to discuss it and maybe we'll have productive and short conversation in time we have left but maybe in the first two minutes we arrive at the conclusion. Oh, okay now this is not going to be both. So I would say let's just start and see where it goes and feel like we should stop it and stop it. Okay, so maybe what I'll ask instead of just reading all these just take a minute to read through them and think at again this document was not meant to be all encompassing in terms of a comprehensive depth. And that's to highlight the most important things for new maintainers, especially so maybe read through the list. And then we'll get your feedback on do you do we think we've covered at least most important things here and then we could step through them if we want to. Thumbs up computer. Alexander. I'll give one more minute. Roma thumbs up. Stephen thumbs up. All right we have consensus on thumbs up. I know thumbs up. Marcus. I think people think this looks like a fairly decent section. Okay, so I'll ask first if I missed anything that's very important here. That might be already included in one of the link guides, but the first thing that came to my mind was to not use auto upgrade to always pin the dependency versions to the point so that the auto upgrades supply supply chain attacks don't work. And, you know, they overtake the dependencies project and they publish a new release that is actually malware, and then you auto upgrade on to that by accident. So that I think that goes along with this line so pin dependencies and keep up to date. Yeah. So what should what should we say about should we say be where. So, how do we summarize what you said. Well as a sub point you could say auto upgrade can lead to can and have in the past legacy malware being distributed in malicious new versions of previously secure software. Okay, anything else important you think I've missed here. I'm just wondering what it means to schedule a security audit for graduate project of major releases I mean I understand what it means but I mean how would I mean what kind of suggestion is that we should do that security audit I mean what do we recommend here. So this one was a little doubtful in my mind as well I thought we'd have a discussion around that so I know at one point at least we've talked about hyper ledger doing this for graduated project major releases I'm not sure if that's still valid guidance. So what do we know off the top of your head. Hey, that's actually a fantastic question. We have traditionally done security audits and sort of an ad hoc way. As you all probably know they are quite expensive. So we typically have to ask the board to adjust budget based on the number of security audits that we are doing. We have tried to do them for graduated projects around major releases. The plan has been to initially try to keep doing that. But obviously, any and all feedback is welcome. And just keep in mind that anything we come up with, we need to run by the board on this, because there's a lot of money involved and we may have to adjust the budget one way or another. Did that answer your question Marcus. Well kind of I mean, I mean this is super interesting. I mean I was wondering as to how much is a budget for such a review I mean I was never exposed to something like that. But I mean as a guidance I mean, I mean if the project maintenance I mean should they all agree okay let's, let's, let's go together and ask the board for for an audit or when do we. I guess somewhere the rules for for a section request already. There's no rules really what's typically happened is the main chainers have suggested that they would like an audit. And then we as staff have usually asked the board to do it and recommended it. It's, it's, I guess, right can probably tell you the exact budget details for the security audits better than I can. Some of it does depend on the, you know, the code and the scope of the audit, but we would like to have a sort of more deterministic audit process basically. So, yeah, we're also looking for we want to find other vendors to get RFQs from. I know that Bezu has been underwhelmed by the quality of the audits that they got back. So, help us out, if you know firm, we'd love to talk to him. Yeah, and I think the audits have run what 50 to $100,000 is that about right right. Yep. Yeah, so they're not cheap. I see, I see. But I mean, if, if a project got such an audit, I mean, do they do we then put a batch on the project side hey they passed the security audit by XYZ. We have a wiki detailing all the security audits that have been done actually. So, I mean, and there's not like, I mean, security audits are not usually pass fail right. They usually point out a bunch of stuff. You know, in a good security audit, if a project's been doing well there will usually be some relatively minor things they found. If a project has, has not been doing a good job with security then, then, you know, then there might be major issues. But you know it's not it's not really a pass fail thing right. It's just a more we did this and we fixed the recommendations. Right. Okay. And eventually like we open them all up. So we, we, you know, we publish them and say, you know, after all the fixes are done, like this is what happened. This is what people found. You know, some things. There can even be things that that aren't intentionally fixed right. We've had some cases where like, you know, there have been performance and security tradeoffs right where like security audit firms have complained that, you know, a particular interface gives people a lot of room to hang themselves. But it turns out that that interface is critical to some, you know, performance encode or something like that. So it's a process. I see. So what we would like to move to is we would like to, to schedule audits in some sort of more deterministic way, rather than the maintainers and the staff just sort of being like okay time for an audit right. In the past, it's been very, very ad hoc. I mean, I think something like, I don't know, once a year basis or whatever time frame is fine. I mean it would be good for the, let's say for the major projects, or for the graduated projects in general. Yeah, so our initial thinking on this was not too far off from that it was like sort of like at a major release and no more than once per some time period. Whether it's like a year or a year and a half or whatever. Yeah, I think on fabric I think we've had one for v1 and v2 and they were maybe three years apart so it seemed like pretty good cadence. Yeah, maybe we want faster than that but you know the some some cadence I mean these things take a while right. They take on the order of months. So if you do them too closely together then you're sort of always security auditing. But yeah, I think that's that's the general idea. Well but I also get that the first audit on the project I mean is definitely more work than follow up audit, if they leverage the magic of kids get histories. Well I mean I think it depends on what the project that's too large. Yeah, that's true. So I'm going to cut off this conversation because we are over time. Dave thank you so much for filling in today and working us through this. Arun will expect to do the security task force next week. So let me know if that's not going to be the case and we can schedule Bobby in if needed.