 I'll kick us off and then I'll hand it off to you. So welcome everybody. This is not the normal TOC called Technical Oversight Committee call for Hyperledger. This is the call that is focused on the task force. So specifically the Badging and Project Lifecycle Task Force. But two things that we have to be aware of. The first is the anti-trust policy that is currently displayed on the screen. So obviously there's competitors on the call. Make sure that we're not doing anything that will violate any of the anti-trust policy laws across the world. And then secondly, our Code of Conduct, which is linked there in our typical agendas, but not an agenda for today. So, but just basically be respectful to everybody on the call for their opinions or ideas and we'll get along just fine. So with that, I'm gonna hand it off to Ramo so that he can take us through the Badging and Project Lifecycle Task Force. So this is a working call. Ramo, off to you. Thanks, Tracy. Yeah, I just, and thanks for going over the policy. I just flashed one of the CACTIM-18 is an agenda page because I didn't have a new page for containing the policy notice. Let me get the tab. Okay, so I'll go over the wiki page that I created a while ago. And I think the last time we got to talking about this, which was the first time we discussed the Badging Lifecycle Task Force on a TLC call was, I think I got about five to 10 minutes and I just did a brief overview. So maybe we can go into this in a bit more detail and then like to drive discussion and get people's suggestions, recommendations. And then we can sort of add to this page and make the recommendations more concrete. So this is, so what we had earlier at least in Tracy's description was a bunch of links that were, that bunch of links for earlier discussions around this topic. So this is not strictly speaking an original Task Force action item, but this has been, this was discussed, I think two or three years ago. And so I looked at that discussion and some of the, and I summarized some of the discussion that took place at the time. So we need to take that into account. And also we need to look at the different project life cycles that we have as references. Of course, our Hyperledge Project Lifecycle and also the Linux Foundation Networking Project Lifecycle. So the goals can be summarized in this way. How do we accurately and comprehensively represent the stages of a Hyperledge Project Lifecycle in order to make accurate assessments about a project's health and make appropriate decisions on its future trajectory. So that's where we have to figure out what is the necessary and sufficient set of project stages as well as some kind of labels that indicate how a project is currently doing and where it is headed and how the TOC can govern the project in a manner that is fair to that particular project. So broadly, it looks like we can take two approaches. Either we augment the current project life cycle with a set of review labels each associated with a review criteria and rename or split or merge states as appropriate. So that the process and criteria for each state transition is clear and unambiguous. Or we can use a badging system whereby each project will be issued a badge that attests to a set of attributes or criteria that the project is deemed to have met. So each stage in the project can then be represented by a set of badges. So with badges, we don't get rid of a project life cycle. I think project life cycle, we have to have a project life cycle that indicates what the current stage of the project is and whether or not it's heading in the right direction. But with badges, we can have a state transition diagram where each state transition criteria will clearly state what badges are needed for a project to go from one stage to another. For example, if you want a project to go from incubation to graduated, which is I think the most important transition the project will be making, then we can identify a list of badges that the project will have to acquire while in its incubation stage before it can be considered for graduation. So is this clear enough to people think they need anything more for the staff force or any comments? Peter? I think this looks great as it is, no further comments. Okay, Bobby? Hi, thank you for acknowledging my hand. I think this is great. We're working on the task force for the documentation, task force on something similar to this just to have user guides. And we had Alfonso from the mentorship program talk about learning tokens. And I was curious as if maybe we can tokenize the badging system so that when you reach so much criteria you have like five tokens and then I'm not gonna say this correctly but you could burn that for the graduation token badge that gets on your project page. And then when you reach a certain point where you wanna go to graduated you've earned so many more tokens by meeting so much criteria that you get the graduated badge token and then that comes with a smart contract that needs to be updated. So it's like got a timer on it so that when your documentation or your project has many amendments to it you have a certain time period in which that badge expires for you to update. Like is that the kind of idea when you say badging that you're talking about or is it more of a static bed where you get it and then it's done? So this is something we should, we can discuss further. I think what you've just articulated can be a particular, can be a badging criteria. I think the discussion that happened within the Hyperiget TSC a couple of years ago involved something somewhat more static. This was a recap of that early discussion. What the TSC was thinking about at the time was that there would be a certain set of... If a project met a certain criteria then it could automatically self-certify itself for a particular badge. Example, legal refers to if the project has... If the project repository, the code in the project repository is all clearly licensed and there are no gaps, then I think the project can self-certify itself with a legal badge that is being legally compliant. If it is decentralized refers to whether or not the project has enough diversity of maintainers and so on. So testing refers to whether it's been... It has an adequate test coverage, whatever adequate may mean. And documentation, whether or not the documentation is comprehensive. Again, that discussion did not go into how the assessment for these will be made. If we go through the conversation there, people are talking about self-certification and some people had concerns about whether or not a project could be trusted to self-certify itself. But then if project cannot self-certify itself then it will be up to the TOC to constantly be reviewing or either issuing badges upon request by projects maintainers or if project demands a particular badge then the TOC will have to review it. But I think if your proposal or your suggestion, I think may streamline this if we can figure out exactly some sort of automated way by which a project can accumulate tokens. So I would like to understand that a bit more before we can figure out how that can be used to create these badges. So just to be clear, the notion of badging projects was not, I think, agreed upon during this particular this round of discussion and it was discussion happened, but then it was benched and then we have since been following the project life cycle. But yeah, so can you say more about how, Bobby? I mean, can you say more about how you think the token system can happen? I envision the hyperledger community actually engaging in tokenomics, so to speak so that every project as soon as it became a GitHub lab would I guess have its own project dashboard and have the dashboards set up so that when you are compliant with security issues you would put a check there and then the system, the dashboard would issue that I'm gonna call it an NFT token for security then you finish your testing. You check that off and then you get the token for testing and then when you have, I'm looking at the categories, one, two, three, four, five, six, seven, eight, nine, like say 10 categories in order to get into the labs that you have to have done. And once you check all those off on your dashboard it will automatically issue the badge to your Wiki page or homepage of your project on the website wherever that lives that you've got that badge and that would maybe initiate a call to the TOC that you're doing this or initiate the next steps to move into labs. And then once you're into labs the same dashboard would have a different checklist of things that you needed to accomplish and get tokens for before you would get kicked over to that conversation of moving into graduated. And if you had all your tokens and you went to the TOC and it got approved you would get that badge you'd be a graduated project and then I guess we're doing the yearly checkups at the beginning of the year but maybe there'd be something in that smart contract that said after a year you need to revisit your security, your legal, your releases, your testing and then you do that and then your dashboard gets that update badge or year two badge or whatever. So that as soon as you look into a Wiki page or a homepage for that project depending on what badge is there you know exactly where they are in the life cycle. That was kind of my idea. Thank you. Gracie, I think you've had your hand up for a while. Yeah. So I like the idea of having to look at the status on a regular basis, whatever that basis is whether it's a year or six months or whatever that timeframe is, right? I really like this idea of having to kind of recertify to ensure that you are at a particular stage in the life cycle. I think if we go with some sort of mechanism to issue badges it should probably be a verified credential but that's just my opinion because they are not transferable and then we could also revoke them or expire them to allow for kind of that recertification aspect of things. So I don't know if that's... I know why you're suggesting it Bobby I'm just not sure if it's more than we want for the perspective of this task force. Obviously there's gonna be some work that's involved there that's going to have to be some blockchain service that's running that we could be able to utilize and there's cost involved there obviously. And so I think we just need to think about the consequences of doing that. I think it's a great idea from the perspective of Hyperledger and blockchains in general and using the tools that we have written within the project or the foundation. But yeah, just let's consider everything that's gonna need to be done if we do go down that path of running a blockchain and having an issuing application and a wallet and all of those sorts of things that would be required from that perspective. Thanks Shrivi. Bobby, you have anything else on that? Before we move on. No, I think that's all. I'd love for you to join our Monday meetings just to see where we're at. It's on the public calendar nine o'clock Eastern time Mondays. Sure. Arun? Thanks Rama. And then this was a good discussion based on this discussion I have my mix of multiple statements or probably comments to be made. I really like the idea of having a dashboard which kind of shows us the progress of a project and how well the project has been doing over a period across multiple aspects that we identify that is required. I really like that idea. So if we want to achieve it via blockchain or just through some means of dashboarding, it's on us. Let's see if that's possible to do. Continuing on this discussion, I believe when we start looking into what should we label in those dashboards and what should we indicate in those dashboards? I guess it goes back to some of the metrics that we want to consider across projects. And this is the mixed set of opinions that I had, right? So going back to what are those metrics that we want to try? I guess it takes us back to the existing portal that we have through LFX to look into what additional dashboarding capabilities do we need using those metrics? I think all of this connects to the similar opinion of having a unified portal or an experience dashboard where we can see what's happening across a project and probably now we should start looking into how should we achieve it? Also as part of this task force, if possible. Okay. Thanks, so just to be clear, so we want one dashboard for all the projects so we do, we want one dashboard per project. No problem, do we want having those metrics details mentioned under the read me of each repository or if that's confusing for some of the projects because they have multiple repositories, then a dashboard where somebody can see those statuses. It could also be through our annual report cycle or maybe quarterly report cycle pages where they mention about these, where we mention about how the project did in that quarter. Right, I mean, I was, I wanted to bring up the question of, or rather link this process to the annual review process that we've already been discussing. Tracy. Sorry, I'm trying to get myself off you. So I remember, I think it was last time we kind of quickly touched on this particular task force. There was a website and I think it was for SNCF, but it could have been for something else that basically showed for all of the projects, kind of a one page website that had kind of red, green sort of responses. And I'll see if I can find that in our Discord chat from previously, but I think that, if we're talking about a dashboard, it does make sense to have a combined one so that everybody can see kind of the status of the Hyperledger Foundation projects. But I think it also does make sense to have the ability for people for projects to be able to display, you know, either on their GitHub, Readme or some place on the wiki or their project or somewhere, right? Maybe multiple places. A page that basically says, here's my badges, right, here's the project badges that we've achieved. Here's what we're working towards, right? Here's the things that are grayed out, if you will, because they haven't been achieved yet, but how do you think that being able to see both options is a good thing? So let me see if I can find that last one that we went through and put it out in the chat, the TOC chat. So thanks, that'll be great. So each project then could have a page called something like badges.md or lifecycle.md, would something like that work? Yeah, something, and it doesn't have to be like, it could be generated, right? So that we're not having the projects have to generate that, but something that could be easily displayed from the GitHub repo or from the wiki or something like that. So that if I wanted to find out what the status of CAFDAI was, I could go to the CAFDAI GitHub page and see like, oh, look at, this is the badges they've achieved already. There's still these other things that they need to achieve and just a place for somebody who is interested in a particular project versus interested in the entire foundation and the progress there. So every project, by the way, right now already displays badges for its feature testing, right? I mean, it has, you can call it a bunch of GitHub action results and you can see whether or not they are passing or failing. So can we tag these badges onto that or do you think that'll be too confusing? We need to have a separate. I think if we can make use of GitHub, functionality in any way, shape, perform and then we should definitely go ahead and do that. Okay, then having GitHub action for this, I think sounds good. Thanks, Bobby? My only, getting back to the question about how to organize these dashboards, I initially had thought it would just be as soon as someone applied for a lab because you're kind of giving them a resource by letting them set up a repository and then that would be the trigger but then you're right, you're gonna have like 64 or some odd dashboards. So another way to organize it would be by maintainer whoever sets up that repository would own that dashboard that everybody could see but it would be theirs to admin. And then the only other way would be once it's in gets out of labs into incubation, that's when it gets a dashboard but then you're like leaving those lab projects behind but the one that makes the most sense is I guess once it becomes a project tool or library in incubation it would get a dashboard. Thanks, yeah, that actually brings me to something I made note of here. I think if you compare our Hyperlegia Project Lifecycle to the Living Foundation Networking Project Lifecycle this one has, it seems to incorporate a lab project within its life cycle whereas ours does not at this point. I think our Hyperlegia, the proposal stage here refers to a project being proposed as a full project and not a lab project. Whereas if you look here there's a sandbox stage for a project and I think that kind of refers to is the equivalent of our lab project and because it's considered to be a project that is not quite ready for even be a full project because that would be the incubation stage but so therefore they call it as a sandbox project. A question for the TOC is do you think we should augment our life cycle diagram to include a sandbox and that would partly address Bobby's query. I mean, it doesn't address the question of like how many the dashboard blowups that you have but at least if you want to incorporate the Hyperlegia Labs project within, we want to capture Hyperlegia Labs project as a Hyperlegia project or as something that has a potential to be a Hyperlegia project. Then should we have another stage here and just have the lab project be at that, let's say a sandbox stage or a lab stage before it goes to incubation because right now labs just aren't covered in this. If I might, I think it would be interesting to formally extend the project life cycle for Hyperlegia to include something about the labs but that's not a fully formed thought, so. Thanks Frank. Peter, I think Peter you were the first so I can't see the harder but. So good. Yeah, I was just going to kind of reiterate what Ryan was saying which is that this might be a good idea but I have not been thinking about it in the context of the passion. I would say maybe that's another decision that we should consider separately, take our time to figure it out because depending on how we do that it might have an impact on the labs or maybe not. Yeah, it's highly dependent on what does that imply if we change the life cycles to include the labs then my big question there is what does that mean exactly apart from just it being documented on a chart does that trigger any other changes that now we have to push on the labs or not? Well, one thing it will do and I think I made a note of that somewhere is it will articulate clear criteria for review of a lab project to determine whether or not meets the criteria to be an incubated, a full project and incubation. So just have it because I believe that when a project is approved for a lab that is at least a tentative expectation that it will eventually try to make a pitch for a full project, right? Because we don't necessarily expect that last project should just be a lab project and then die, right? So that was my thought and I'm hoping others who have been longer on the TSC who have served longer on the TSC can answer this question. I can't see the order in which people raise their hands. I see Arun here, I think Tracy raised her hand earlier. Can you please speak in order? The order is as it goes on the hands raised. So it should be Tracy. Okay, thanks Tracy. Okay, so my thought about labs being part of the life cycle, my initial thought was yes. And then I started thinking about the process that we have for labs versus the process that we have for becoming incubated. Our two different proposal processes for labs versus incubation. The labs proposal is obviously much simpler from the perspective of it may be fresh new code that's being started. It hasn't been, there's nothing that's happened yet. The formation of an open source practices haven't happened in the community. This might be the first time that they're doing open source. So we tried to make labs extremely easy entry. So removing as many barriers as possible from the proposal and what needs to be done. So, I think it's okay if we do include labs in kind of the overall description of kind of the life cycle aspect and what's required to be in it. But I think there are two separate proposal processes that we should maintain because of that easy entry aspect that we've tried to create with labs. So just a question on this. So if the, once it's a lab project, I mean if the project has been approved as a lab and then it continues to mature and maybe gathers more maintainers, improves in quality, could we not then have it accumulate these tokens or badges which would then allow it to be automatically, not necessarily automatically but allow it to be easily reviewable in order to judge whether it can be moved to an equation stage rather than have it to have submit a fresh proposal which I imagine will largely be the same as the original proposal, right? I mean, the goal of the project's likely to be the same unless it's maybe merging with a different project like we did with cactus because what you just articulated for lab projects sounds very similar to what the LF networking page has articulated for a sandbox stage. So just wondering. Yeah, I would say that they're probably fairly similar as far as sandbox versus labs, this general same idea. I do think that I probably can't answer the question yet about whether or not there would be enough to allow it to easily be reviewed to move to incubation. I think we should definitely take a look at what is required for incubation. We obviously have those pieces of information. I think if we do a good job with this task force then the answer would be yes, Rama. But I do think that it's going to require us to be very specific and sometimes we're a little fuzzy about what it means for these different stages. And so if we can be more specific about what is required in order to reach a particular stage, then the answer is probably going to be yes. Makes sense. Thanks, Jethi. Who was next? Was it you, Alyne? I think that's me, Rama. Oh, no. Oh, yeah. So I think it's important to remember what how labs came about. And by the way, for the record there's no lab project that's not a concept that exists. We have projects and labs. And there is a reason for this, which is the point of speaking up now is I think we must not lose sight of the whole premise of the labs was projects involve management, resources, allocation. There's a cost associated with every projects. And we wanted to create a space with very low cost that we could allow anybody to pretty much try something out. And so once we start integrating labs into project lifecycle, I think we're starting to blurry that boundary. And I don't know where we draw the line anymore. I'm a bit worried about this, but I just want you to keep that in mind. I want to take another one. Thanks. Arun, did you still want to say something? No, I think please, I'm not covered. I wanted to bring up the same point that Arun not just brought up. Okay, thank you. Okay. I think the discussions covered a lot of the points that I mentioned here. So just a question about the end-of-life stage. So this diagram has, it doesn't say end-of-life, it says archived, which means that a project that's currently been archived can potentially be a candidate for a project again, if it requires maybe another set of committed maintenance later. I'm assuming that a Hyperledge project at its end-of-life can do the same, right? Do you want to explicitly call that out, like have an arrow from end-of-life back to proposal or do folks think that's not necessary? I'm not hearing anything, so I'm guessing it's not, I mean, if you haven't, okay, Peter, you have an opinion? I was just going to say that I'm thinking that I don't have any immediate opinion in. Okay. Sorry. Okay, no problem. I mean, if you have anything, then please make a comment on the page, Arun. Yeah, I don't think it's, I don't think necessarily any arrow should be ruled out, right? I'm fine with moving projects around in unorthodox ways, if it makes sense. Yeah, yeah, that makes sense. Okay, let's keep thinking about this and if you have any observations on the diagrams, especially compare these two. So just looking at this, this seems a cleaner diagram than this. Of course, it doesn't necessarily mean we have to have such a diagram, but if having a back arrow makes sense, if it accurately reflects what a project can go through in the longer term, then maybe we should consider it. So on badges, so just on the term badges, I mean, we of course can adopt whatever meaning we want, but just to be clear, the Linux Foundation Networking Group specifies a list of badges for people actually, for maintainers and not for the project. So you have to make a distinction. I think this particular task force, when you're talking about badges, we are referring to some sort of credential that is owned by the project, whereas in the LFN, they are talking about a credential issue to a given meeting. Okay, I think we've covered this part, the LFN Lifecycle Accommodates Lab that we consider the Hyperligel Lab to be the equivalent of sandbox. And let me see. Okay, I think the, yeah, I think there's a notion in the LFN Lifecycle of a reversal, of project reversal, going back from one station to another. And I think we, in this, we can kind of incorporate that here as well. Have to go back and look at the full list of review criteria. So sorry, it's been a while since I made note of this, but I think there are some ideas from there that we could incorporate here from the criteria for whether a project should be downgraded rather than upgraded. Like here, if you see, there's an arrow from graduate to incubation. Here, we don't have that. We, instead, we go from graduate to dormant and then from dormant to incubation. I suppose that kind of covers this, but the arrow here, but yeah, we should probably discuss that aspect as well. Whether that is, I mean, in the LFN Lifecycle, they have, for each cycles, they have a forward review criteria and reverse review criteria. That is, what is the criteria that the reviewers will use to judge whether or not a project is ready to move to the next stage. And also in a review, what criteria will the reviewers, that is the, what's called the TAC in LFN, they'll use to judge whether or not a project should be downgraded to its previous stage. So that's there. Okay. Let me just go through this tentative discussion points or recommendation points. Of course, we want to be refining these a lot more and based on, I'll go through the recording of this call and note all of the points that have been made today. Let me see what else I have here that we should be discussing now. Yeah, if we do, I think maybe just inquire about this once again. If you do use badges, is that certification a good idea? Okay. Arun, you had a question? Right, that was for the previous, I don't know, I don't have a comment on this line as well. I'll just go with this for now. So over here, the way I see that is, so when projects do a self declaration, they are declaring it in their reports and then the report needs to be reviewed and approved by the TOC, right? Or at least let's not call it approved but for now reviewed by the TOC and TOC will bring up further concerns and questions to the project team. And post that, we could go back to the project and tell them their self declaration may not be as intended if at all such case arises. And do we do this? Is this going to be aligned with the quarterly reports? Like we allow such certification to be made only during quarterly report or do we allow it at any point in time? I'm just concerned about the overhead if it is any point in time because could happen like every week, every other week, for example. The biggest concern that I see is in terms of the response and then of course every aspect is important but from a securities standpoint if there has been an issue raised to the project team and the project team has not been responsive to them. Per our recent discussions related to the security ways of working I think we discussed that will give time of up to 90 days for project teams to respond back. And that 90 days hopefully covers the quarters that we spoke about, right? So I'm okay to have it during the quarterly review cycles. And of course other points are also important related to contributors experience and the PR stuff, the time that is taken for a new contributors, PR to be merged the kind of advice the project team gives them but those things can wait for the quarterly reports. We don't necessarily need to ask project teams to keep updating their badges every time. Right, I think, yeah, you're right. They don't have to update their badges every time during quarterly report but I think my question was do they only get to update their badges during quarterly report or can they do it in between? My personal opinion, I'm sorry, see Peter raised the hand. Please go ahead, I can just chime in after. Okay, so my personal view I think we are okay to start off with a process that is to include this in the quarterly report and if we see a need to change it later we could accommodate those changes. That way we are not adding extra processes to the project team plus we are trying to bring in best practices at the same time. That's it. Thanks, it makes sense. Sorry, Peter, just before I hand off to you quick question to Arun. So you mentioned the security review, right? That review process we can adopt for every kind of badge, right? Not just for security. I mean, security itself could be a badge or the fact that a project is secure or we could have potentially multiple security levels as well, security compliance levels but the same process that of a project self-certifying itself as being at a particular security compliance level and therefore it's ready to get that badge and also that the TOC has been observing that the project is not being compliant and therefore it might revoke that badge after the 90-day period. I think the sort of process can potentially be applied to all any of the criteria, right? I agree, just to note related to the security we cannot certify a project as completely secure. However, we can certify a project that they have the best practices are following and they have been following the practice. We can certify on that aspect but not on the security aspect. Thanks, Arun. Peter? I was just going to say that for me personally it wouldn't be a big burden if we allowed people to just queue up a badge evaluation on the TOC agenda at any meeting where we have the bandwidth to actually discuss it but I don't know how much of a burden would this to be to others, for example, or managing the agenda like Tracy in the room but for me personally, if you are sitting here once a week and the project just decided that they should apply for a specific badge and they need our approval, then I would be happy to discuss it regardless of whether it's a regular TOC meeting or one with a quarterly report. Right, I'm just concerned about the level of scrutiny that would require. I think our weekly reviews of the quarterly reports, they are not particularly honest. I mean, but when it comes to badging, we may have to do a deeper inspection of the quarterly reports, right? So I think that would require a bit more work. Yeah, that's fair. So I guess this decision should lie with those who will have to do more work, which is not me. Thanks, Peter. Arun? Right, so Ramay regarding the extra work or deeper analysis into these reports. I know previously, when we were going through which practices to be adopted, we came across this word, TAC, in other groups, right, under the left. And I saw the word TAC that you also mentioned earlier. So can we have a TAC process adopted under Hyperledger as well? And I see multiple benefits of it. And of course, it's not, I mean, we can further discuss what that means and how the TAC gets selected and whatnot. But I see multiple benefits. One, we will bring in additional people who are outside the TOC as well to help assist in anything that is needed. And then probably it creates greater collaboration across projects, if at all we tell the projects that they can be their own TAC as well. So this allows project teams to get involved more with the TOC and pitch and probably come back with the report and whatnot. So just a thought. Sure, makes sense. I mean, I was just highlighting what I noted from the LFN wiki, which is that in the Laying Foundation Networking has both a TAC stand for Technical Advisory Council and a board. And each review is first connected by the TAC, which then makes a recommendation to the board. So yeah, the TAC would have to be a different body. Doesn't have to be mutually exclusive on the board, I think, but it probably has somebody who has different responsibilities on the board. Tracy? Yeah, so I'm not sure specifically about LFN, but TAC is typically another name for TOC or as we used to be the TSC, right? Basically the same thing that this group is currently doing, the Hyperledger TOC. So I know like in the open wallet foundation instead of a TOC or TSC, we have a TAC as the Technical Advisory Council basically serves the same role, right? Projects and guiding the technical community and that sort of thing. So we need to make sure that as we look at these names from other organizations, we understand exactly what these bodies do so that we're not like adding something that already exists within the Hyperledger Foundation just because it looks like it's a different name and now it's the same function. Makes sense. Thanks, Tracy. Okay, I think I've, yeah, I think we kind of covered everything I had noted here. I have, I just had some questions about logistics, but before that, anybody else have any other thoughts, any of the points they'd like to raise about this topic that occurs to you? Or you can always make comments on this page, but yeah, if you want to speak, go ahead. Okay, I guess not. Or maybe let me just take a quick look at the chat. What's this? Okay, so logistically, like the other task forces, I think have a regular meeting schedule to discuss these topics. I think it'd be good to have something similar for this task as well until we get to a stage where we can finalize the recommendations and then present it to the TOC. How do I go about scheduling those meetings? I think, Rai, would you do that? Or is it something I can do myself? Yeah, if Rai fell off the call or is not able to unmute, yeah, absolutely. We can help you with that. If you want to reach out to us on Discord or email, that's fine. Okay, thanks. So who, okay, who else? I think when I look at the task force, I think at this point, the only two people are listed here, that's me and Bobby. And Bobby, I will try to join the documentation group meetings as much as possible. That's great, thanks. For our meetings, for the meetings of this task force, who else would like to volunteer to review the material and make recommendations? Tracy? Yeah, I would like to be involved if possible. Okay, who else? Peter, Tracy, Arun. Okay, all right. Peter, Tracy and Arun, thank you so much. So I apologize. You were asking a question. I couldn't get to the meeting. What were you asking of me? Oh, I just wanted to figure out how to schedule like the regular group meetings for this task force, just like we have with other task forces. Okay, reach out to me on Discord. I'll show you how to do it. Sure, and I think once every two weeks, I think should be good for now, all right? Anybody have any thoughts on that? Otherwise, I think that's how, that's the frequency which I'll schedule it for now. Okay, once every two weeks. Thanks, right? I'll reach out to you on Discord. Yeah, nothing else. So I guess we can close today. Thanks, Rama. Thanks, Tracy. Thanks, everybody else. And, okay, sorry, before we break, Arun, what are you saying? Morning, morning. I just think to understand when would those meetings be scheduled. So the mornings are tight. So Monday's and Friday's work best for me. Morning US time rate. All right. Yeah, I think Monday, I think Monday, there are already a few meetings, right? I think there's a documentation meeting on Monday, the onboarding meeting as well. Maybe we should do this on Friday. I'll, okay, since you know, objections, let's go with Friday for now. If anybody has any objections, please let me know. And Rama, I was thinking we should set up a chat in Discord as well for the group. So I'll get a chat created for the channel, create it for the task force so that we can make sure if there's anything in between times that we want to discuss, we can do that. Thank you. All right, thanks, everyone. And yeah, look forward to continuing the discussion. All right, thank you.