 Alright, we'll get started. Hi everyone. Good morning. Good afternoon and good evening. We're going where you're joining us from. And welcome to 4th May 2023 TOC meeting. And before we get started, a reminder, we all have already known antitrust policy with the Linux Foundation meetings and says that we all come from different parts of the world, different companies and any information that we share gets shared in a public forums and we all respect each other and we follow code of conduct. We respect each other. So with that, we'll jump on to our announcements section. So quick reminder, the Hyperledger Dev emails, the DevLator emails, the weekly emails that are sent late Thursday or like early Friday to different, the large community base. This carries information of what's the latest happenings across Hyperledger projects. So if you have an important announcement from your project that you would like to discuss or that you would like to share across to a large community base, it could be worthwhile and these could carry information such as any plan that you have as part of your projects, the latest announcements from the releases, or if you want to bring attention to developers on something within your project, this is important. All you have to do is go there, click the link and write down your comments that will be added into the email. And last week, last week's TOC call, we did go through the security policy document that Hart had put up and quick reminder to all to read through this and add any comment that you may have so that we can start formalizing the proposal. And before we continue, does anybody have any other announcements? Assume the silence means no. So we will get started with this agenda and go through the quarterly reports and quick for the record keeping purpose just that I'm doing the, I'm running through the meeting agendas because Tracy is unable to join today. And this is my first time, so feel free to stop me or ask me any questions if I'm skipping through some parts and let's get started with today's agenda. And in today's agenda, first thing we do, let's quickly walk through the quarterly reports that were due for submission. These three reports came in this week. Some of them were submitted like three days ago and some of them a couple of days ago. I saw a few people have reviewed them already. I would first ask if there are any open questions that anybody wants to bring up in today's discussion that we should be concerned with or ask the project team. So with Hyperledge Indy, I see some questions related to the, oh, sorry, Dale, I didn't see your hand, is there? Yeah, I was just going to ask the question that you're probably looking at. I just added it a few minutes ago. It was about Ubuntu. So this is a thing that comes up across different projects. So I thought it might be good to spend a couple of minutes understanding the plans around Ubuntu and I can share what we're doing and fabric as well, if that helps. So if you have Stephen on the call. Yeah, that would be helpful. I'd love to hear. Basically, we have one, just one branch and or at least that's what we're trying to get to and one version of Ubuntu is what we're supporting. We could in theory support. Yeah, we don't want to have multiple branches. So the comment that was made about supporting 2204 is actually a really good one, because given the pipeline we have now we should be able to support it. Assuming there are not significant actual dependency updates. It would be relatively easy to test out and see whether we support it or not. So that's probably the way to go, but we just have a single branch and it has been stuck on 1604 because of the combined challenges of the dependencies that had to be addressed between 1604 and 2004 and the difficulty of the pipeline, the old pipeline we had. And so much of the work was spent on replacing the pipeline. The second sentence I have there at least what we found is if we build on 2004 it works on both 2004 and 2204. But if we build on 2204 then it doesn't work on 2004. Interesting. Okay. So we don't have to do anything special to support both but as long as we build on 2004 it seems to work on both 2004 and 2204 so I don't know if that's always true but that's what we found. That's super helpful because if that can be true, we can upgrade the nodes. The challenge we've got is the practical one of getting a whole bunch of organizations to upgrade their nodes, their OS of their node so if we can go to 2204 directly, that will reduce debt down the line. Thanks for that. That's really helpful. Thanks, Stephen. And one more comment on the indie project was about the help needed and identifying I think the answer to that Stephen can correct me is that you have a way to identify an active maintainers and then you want to realign some of those lists to the right set of repositories. Yeah. Yeah, the bigger challenge. It's just the, you know, and looking at that and doing the work I did yesterday of evaluating all the teams we have figure out, you know, what maintainers so basically what I did was extracted all of the members from all of the teams. Unicified them and then identify the organizations as best I could from them. And the challenge that I see in that the work is just we have too many teams too many organization and too many, too many repositories first of all but then then correspondingly too many teams and so we have to shrink that down so that the same team that manages a set of repositories shouldn't we don't need to have a separate ones per so and then there's also a bunch of cleanup there's clearly some repositories and or just teams that no longer need to exist. And so the plan I my plan was to sort of propose something and see what Rai thinks of it. I have a lot of good ideas of how to help out in cleaning that up, but I can come up with the, what changes we have to do work or at least the project can come up with what changes are suitable. Thanks. Are any comments or it's too early. Too early right now. Let's talk offline, or let's talk on discord. Yeah, areas is the same thing. So, yeah. And I don't see any major comments on areas are a non creds. I did her, I think David's commented reorganize the non creds report it was just cut and paste and move things around but yeah, it completely accurate that I had the quarterly detail in the long section so I've moved that. So again, a quick reminder. Please review the quarterly reports, and you could also leverage the details that are posted within the quarterly reports that should take you to the elect LFX portal, giving more details insights into how the project is performing. I saw some of the pretty detailed reports from all the projects this time. Thanks Stephen for for doing that. And those are pretty elaborate and and feels great to read those reports. Okay, any other anybody would like to bring up anything else on the quarterly reports and take silence us now. So moving on to the next section of today's agenda which is to go through past your reports. So, we have two projects which are passed their due dates and reporting. The first one is transact and the second one is sort of. So with respect to transact, there have been multiple discussions and reminders which were signed. There's also discord links which are pasted, which talks about waiting for any save from the maintainers and then eventually the final outcome of that is that project maintainers have agreed to move the project to dominant state. And that's in today's decision log will cover that as part of today's agenda. Any questions before we move to the sort of date, if not, then related to sort of it was due on 27th April. I was going through the discord chart and found out that there was a meeting on 26 April. And the discussion on that meeting was that sort of team is trying to relook into increasing contributor base as part of that effort. They have shared the responsibility of writing the quarterly report to new contributors. They will be submitting the Q2 report. And he's doing it for the first time and he reached out saying that he needs some more time. And given that this project is making effort and increasing the contributor base. I mean personally I feel it is okay to give them some more time, but any thoughts or comments from the TOC members. Yes, Peter. I agree. I think just the fact that at least they responded and they said they need more time for instead. We should give them more time. Thanks Peter. And on the discord link you will also see that James has put up a draft Google Doc and he did that just to make sure that he wanted internal project team to confirm the contents as he's doing it for the first time. So we may expect reports soon from them. And if not, we can always mind them again. Okay. Moving on to the next section, which is I think the next section is the next set of projects that are due for project quarterly reports. That is Iroha, which is due exactly a week from now. And we'll bring it up next week. No concerns there. And the discussion items for the for today. The first item is moving the transact project to dominant state. So they have been multiple discussions going through within the transact where the transact lab itself is more to sort of a project. However, the project code base was still there on the GitHub. And it was causing confusion for the first time users or for somebody who is new to hyper ledger to think that project is actually being maintained. However, there were no reports submitted. It was causing a lot of confusion. And the project team have responded. They have explained their plans of how to move forward with the transact project. And the latest outcome of those discussions is that moving project to the dominant state. Before we take the decision to move project to dominant state. Does anybody have any comments or thoughts that they would like to share on the project. Anybody from the hyper ledgers to have any comments. The one comment is about process. I think hyper ledger should make sure that from now on we don't ever move a project from active to end of life without going through dormant. I'm picking up the pieces of Ursa and the move we made last week. You know, Ryan made a good comment that Ursa should have been dormant a long time ago and that's fine, but we should never go directly to end of life without going to dormant so that we can allow anyone that needs to some time to address any issues. So I would suggest I don't know if that can be done but you know whether that needs to be done but certainly from a, at least from a corporate memory. perspective don't don't do that again. And if it can even be put into the project lifecycle. That it can't go. You know, from graduated to end of life directly remove that blue line would be a really good idea. Ursa was incubation not graduated point taken. Then remove that the red line purple line. I don't know it just I was no end of grief and if I'd known it was an option and my fault for not knowing the process. I would have at least suggested we move it to dormant before we do it to end of life. I will keep that in mind. I propose that you, this is a gv file. This is just text. Yeah, I propose I propose that you make your proposed changes here. Yeah, yeah, submit that for a vote. Okay, that's great. Thanks, right. Thanks right from me. Open the project lifecycle. Yes, so there was there were cases where it's wrong. Sorry, just about dormant do we call a project dormant or do we declare project dormant if it actually has been dormant that is there been no comments to it for a while. And is there a particular time period. Yes. So, as part of the previous discussions that we had to see can decide to move a project to dormant state based on the quarterly remotes that we receive. And, and to see can make a call. Okay, so right now we don't have a particular time period like if the that we know that we know commit for the past three months then we declare a document something like that. Remember discussions around the timelines. I don't think so we have formally put up in our proposal. Yeah, there's no official timeline in this governance document. It just says slowed down for a period of time. I think it should be easier and less pejorative for projects to move into dormant and into life. But I don't know that having a strict timeline here would would actually help that. Stephen. Yes, Steve. And the line that TOC decides to move the project to or from the dormant state upon request is interesting. For me, I, as a TOC member I probably would have been much more willing at someone raise the issue of Ursa to move it into the dormant state unilaterally versus waiting for the maintainers to do it. And have the maintainers say no, don't. So again, the upon request is interesting is that request from the maintainers or request from Joe citizen on the street. Leaving that open is actually useful so that somebody like right or or somebody else could have said hey I suggest we move Ursa to dormant and sorry to bring Ursa when we're really talking about transact but super useful. So anyway, thanks for highlighting that and how you get into the dormant state I think that's a good idea and I think that the TOC should take more advantage of it. I think it makes sense that we have a dormant state in between so that we are notifying to the people that even though you see these repositories and the hyperledger, it's highly likely that there has been no updates, and it has been taken into notice. And the community would like to move this into dormant state while we wait for more activity to happen. And going back to Rama's question. One of the point that I remember, like maybe we can go through the previous meeting recordings as well is related to a few projects being in a stable case or stable condition, which may not have more updates compared to other projects, or which may not see more activities compared to its previous orders. That was one of the reasons why the timeline part was intentionally not added. Now I think what you said earlier about quarterly update being like lack of a quarterly update being the sign of dormancy I think that makes sense. Even if a project as you say does not need any new code or any any new changes, as long as the maintainers are willing to put in updates that indicates that the project should still be active. Okay. Thank you. And I'm assuming Stephen you'll make a proposal related to moving to dormancy, which will be up for discussion. On my list to do. Okay. Any thoughts on others before we proceed next. Okay, I take the silence has no. I don't know if it is relevant, but it's very related topic to the same topic that we were discussed. We were discussing about the transact. And was it Stephen you raising the question on this call I remember asking questions where you asked that transact was moved to firefly. Was it. You suggested that something could have been done on the earth. Yeah, that was the topic we just talked about which is the, a bunch of things had to be moved out of Ursa and are urgently being moved out of Ursa, as we speak. And it sounded like transact was in a similar state, but I was more worried about the fallout from the Ursa decision last week versus the transact situation. Well, it's it's not like the code was deleted. And I will point out that, you know, transact did move to sawtooth live. And so that has already happened, like a year ago. And at your request I did move one of the Ursa Python to another area. Yeah, I'm not complaining about what was done right I'm just saying, had I realized the dormant was a possibility I would have taken it and that, and it was the, the, my lack of knowledge of, of a good way to handle something that is very active but not maintained in the place it is actively used. Anyway, I'm certainly not complaining about the follow on from what was done I'm just dissident, you know, sad that we didn't take advantage of the governance tools that we had in hand, and jumped ahead a step. And that opened left a lot of explaining to be done, which I've done over the last week, various people about why Ursa is in the state it is and what we're doing about it and so on it but I would have liked to have been able to do that explaining after the stuff had been moved. Not before. And that's that's the, the challenge that I'm lamenting. Nothing more than lamenting. Point taken Stephen. So we should start doing better job at doing quarterly reports and making sure we bring these concerns up ahead in time, so that project teams have considerable amount of time for for taking in action. So I'm hope it's all good now and will move on to the agenda item which is the decision item. So it's up for decision making if there are no other thoughts or comments. And if somebody would like to propose it or bring the matter before the TOC. We need a TOC member to bring moving transacted dormant up for a vote. Motion. We need someone to second that motion. Second. I will do a roll call vote in the matter before the TOC moving transacted dormant. How do you vote. Hi. Peter. Hi, Marcus. Hi, Jim. I vote yes. David. Hi, Bobby. Hi, Arun. Hi. The highest habit transact has been moved to dormant. Thank you. I'm sorry. When I get a vote. Oh, I seconded. Sorry, Stephen. Hi. Okay. It is again approved. Sorry. So I knew I hadn't. Yeah, I was using the zoom list. And you were unmuted. So you're up in the. Up the top of the list. So I missed you. I apologize. Thank you all. The decision has been made. Thanks for the roll call out. We'll move on to the next agenda item before we move on to the next agenda item. I just wanted to bring up a thing that that was discussed in in other meetings. So there was in general appreciation to the TOC work and the way the task force have been handled in the last quarter or so. The way, for instance, the security task force, the onboarding task force that have been happening and the way the team has been participating the way discussions have been going on. So there is general appreciation on on these things. So it's it's time for us to rejoice a bit and and see learn from what happened that made it go well, compared to the previous ways of working. So one of the thing that definitely was improved was a detailed scope task force discussions that we had, as opposed to having a pretty open. Ended conversations that we used to have previously. That's something that we can be all happy about. And the going moving on to the next quarter. I would like us to like focus on the next set of priorities that different project teams have. This is an excellent forum where you all can bring in different project perspectives and what's important from the projects standpoint, so that we can prioritize on those task courses. I know there is a task force which is about optimizing the pipelines and defining if if there if there's anything that we can improve through the task force that can be set as a guideline to all the projects. And I know this also plays important role, given that we had discussions about get a back shuns being limited to amount of time we can execute pipeline jobs over a month, or maybe in terms of storage as well that the artifacts that are produced. Right. And, and yeah of course we had discussions about optimizing the pipelines across the projects, wherever possible. And I know there was another discussion that was related to projects health status that Jim had proposed, and there was, there were really interesting conversations that went through. In fact, if you're new to to see and if you're new to just reading project reports, and would like to understand what's important for you to look for in those reports. I would infer and consider the issue discussion that has happened where Jim has proposed about project cell status that discussion itself is pretty overwhelming and easy to understand like what what are those parameters that we should look for in a project in order to understand that the importance of project or to know health of a project right. I mean of course we can bring those topics up for discussion and try to prioritize on which one to pick them up, which of them to be picked up. But from different projects perspective. I would like you to think through and bring those topics up for discussion into your submitting. I know it's short notice but if anybody have any suggestions on the burning matters that important things that we should start looking into. Would anybody like to bring those topics up. From my side right now the most important one is the CI performance. I know that for most projects that's been sort of fixed because we got upgraded to paid plan but for cactus or cacti sorry our need for CI is as in for CI time is much bigger so actually we just ended up going back to the free plan because it was costing a truck load of money every time to run the CI. So I don't know if this is universal to all the projects that probably isn't. It's probably something specific to cacti but regardless of that. That's one of my priorities still might not be to anybody else would like to bring up any other priority items. Well if no one else than I have spent another one which is automation in general. A lot of different things within that umbrella. That we've been already working on and there is there are great things out there already like the reports on the LFX portal. Great. But but I know a few things that. Right has been manually that are T stores in my opinion that so everyone down if if you have to do that manually. So I would also focus on just having more automation across the board in different areas where right now there's many others involved. Is this to identify some anomalies. Well first to identify what is reasonably easy to automate that we don't yet automate. That list might have zero things on it because it is possible that will be able to pick the low hanging fruit. But then just move up to the medium difficulty one and see which one what would be the easiest there. And then the bigger chunk of it is probably related to analytics about the projects. Like how do we measure measure project health in a sort of using formal methods. That are. Not subjective. They know when we judge the health of the project. How do we decide oh this project is healthy or not. Of course in the end it always has to be subjective but the more information you have for it the better. And I know that we had task forces for it for this in the past. I'm just sort of giving it a bump again. And then there's other things like. Meeting recordings which I know. Rye has been uploading manually. And I think that's also a trainer is time. And. There was something else but I cannot remember right now but I know that there are things like this. When it comes to meeting recordings. My plan is to. There is a tool that automatically moves stuff to YouTube. And I plan on getting that. Up and running the difficulty is. A lot of the stuff that happens shouldn't end up on YouTube. It's. I see here. So I don't know if this is actually going to do what I want. So for instance. All these meetings for zoom three. When this implementers working group call happens. And it's recorded to the cloud it should go but they are. Canceling the recording. Pretty frequently. Let me see here on zoom zero. What do you mean is what does it mean to cancel the recording. So people. When you join a meeting. The host codes are widely. Pass around. The identity working group meeting. For whatever reason doesn't want to use cloud recordings. So they just hit the stop recording button. The areas did com V2. Like this one and. Like this meeting. They started and then. They stopped it. Almost immediately. And, or this is actually after the main meeting. So someone else joined and recorded that meeting for a few seconds. That shouldn't end up on YouTube. Like these meetings for the did com. Aries did com V2. That shouldn't end up on YouTube. So it's going to be a matter of user education and. Figuring out how to tag the meetings. And honestly, it's just as much work to figure out if. The automatic thing should do the thing. Or I just download it and re upload it. So, you know, it's. Right now. It's only maybe a dozen meetings a week. But. You know, I'll figure that out. Don't worry so much about that in particular. The other thing with the. The GitHub CI, I'm not quite sure what you were asking about. So I wasn't, I did, I wasn't asking about it. I was just saying that to me, that's something that's important that I will work on it. And if, if others have. The same concern, but I don't think they have. But if they do, then. We can work together across projects. I thought you were saying there was something manual that I was doing. No, no, sorry. I was just doing a bad job of explaining myself. And I, I guess I can play at different points. Okay. No worries. Thanks. Thanks. Right. So we do have a proposal for task force on optimizing CI pipelines. And this is definitely. Given that it has been brought up again. We should prioritize on the task force. Okay. Thanks Peter for bringing additional topics that we should focus on. Any, anybody else, any other pressing issues that we should bring up. If not, so I am not sure do you want to share the screen with a list of all the open proposals that we have so that we can prioritize and we would also need. Team to volunteer to lead those task force. So for instance, let's say we pick up on the CI pipeline optimization. Would anybody like to. Preside over those, the task force. Lead the task force. I think that had, yeah, Marcus Dave and Timo. Signed up for it. Yes, Peter. I forgot to sign up for it, but I know. I would like to. And if no one else is willing to lead it, I'm also willing to do that. Awesome. Thanks Peter for signing up. And, and, and to all the members who may be new or. Like who have been previous to see in previous to see as well. This is great opportunity and you have seen how well the. Task forces do have been doing in the last quarter or so. And then I also mentioned about the appreciation part that came in. So, yeah, this is a great opportunity. To preside over and then bring in project perspectives. Okay, so that's something we will pick it up for the next quarter and then we'll go into the meeting agendas for discussion. Next meeting onwards. Thanks Peter. So, um, any other task force that you would like to pick up as a priority item for the next quarter. So we have options. There's one of that is a project help. The status that Timo was trying to put up last, last year. We can relook into that. The other task force based on today's discussion that I feel could be of importance is the. I think the closest one to this topic is like badging and life cycle would somebody like to volunteer and then. Start putting a page and then discuss about the task force. Badging and life cycle. So, Ramai, see you signed up. Would you like to do like to preside over this task force? I think I mean, it's a bit. This one may be a bit tough. But I mean, if you have some flexibility on sure. Right. So, yeah, I think you can pick it up and then. Okay. Bring up bring up topic for discussion. Everybody will jump in. Okay, sure. Awesome. So, um, I'm. So, okay, now formally and making that statement that we are going to pick up the badging life cycle task force as well as the task force on best practices for automated pipelines. These things will go into the engine item. So I just saw hard messaging saying that we should pick up the artifact signing security artifact signing task force as well. Once we wrap up on the vulnerability disclosure. That we are waiting for reviews on the Google Doc. Makes sense. Thanks for bringing that up. Awesome. Okay. I know we are 14 minutes left. And the next topic that we had on agenda was. The task force discussion. And Bobby, would you like to take over? Sure. Thank you very much. And I'm glad that there's going to be more tests. So, um, I'm not going to go into the responses because I do agree with you Arun that the way this is structured that things are really getting done. And there is a lot of attention. I had a lot of people in the meeting this week, which was nice to see new participants. So I'm encouraged that this is going well. Again, so. Um, Both the documentation task force and the onboarding task force are looking forward to getting a mentee, um, to really tie this stuff together. Um, the documentation task force. Uh, one of the things we've been working on was getting, um, the tasks and the, uh, Deliverables for the mentee together. So we worked on. Um, where we had certain categories of deliverables, which I think, um, unless anybody has any, um, additions, these are going to be the four we're going to go with. One is the GitHub documents that would be, um, the guidelines and templates for turn and the, um, supporting tooling that we offer as hyper, hyper ledger, uh, for maintainers, um, creating, or whoever is creating the documentation from the GitHub templates. Um, And then we also have other categories to, um, let people know how to use the products. Um, so in that, uh, we have a GitHub template, uh, set up where, uh, we're going to more on the task force than the mentee, um, create what should be in all of those and what, uh, templates you should choose from. Get that down. So that, uh, when the mentees come on, um, we also at the documentation task force went through the mentee programs. Um, and a lot of them had asked for documentation or have a documentation piece and, um, you know, I spoke with men and we want the documentation mentee to be able to support that. So that's why at the task force, we really want to get that done first, the templates and stuff so that we can see with the mentees, how that works moving forward to, you know, offer the stuff to the projects. Um, so the mentees, we do, we determined what projects needed documentation support. We're going to have our mentee reach out to, um, those projects and see how, um, any of these other categories, including the template for GitHub, um, can assist them. Um, the other thing that, um, the mentorship is going to do is we have to work closely with the other two task forces, uh, for their documentation support, uh, the first one being best practices. Um, if we're going to be badging to see, you know, when we move again, looking at that project life cycle that we had up on the screen before, you know, what are the criteria for moving from incubation to graduate and do you have these, this badge that this task force is going to create. Um, and in that badge comes a documentation piece, what is that documentation and how can the task force, you know, create templates and make that training easier for people to just get that done. Um, as well as the onboarding task force, um, they need documentation support, um, and training materials. So, you know, that we'll go into a little bit about that onboarding task force in a minute where those, uh, buckets of training materials need to be. Um, but those are the two task forces that the documentation mentee also is going to help support getting that, um, discussions going between the two. Um, and finally is the community. Um, there's going to be a big, um, change over in the website soon. Um, logos, all that kind of fun stuff is going to be, uh, revamped, updated, modernized. Um, and more, you know, for social media, getting all that stuff out there. Um, we want to be able to support the community and creating materials for, uh, not just inside the community, but outside the community. And we want them to reflect the new, uh, logos and new templates that will come out of the marketing department. Um, and how can we as, you know, the documentation task force, get that information where it needs to be. So that's another little, uh, ≫ And that's another one of the things that I, uh, wanted to make sure that we have that information and that we can get the target for. The, uh, mentees to worry about, um, Again, we're just, you know, looking at the candidates. We're waiting for that, uh, formalized list of people interested to come through so we can start the interview process. Uh, there'll be interview questions that will ask all of them. Um, And basically we were working on the personas. to who do they need to be geared for? And again, we're working with the onboarding task force to get these little buttons of education or buckets of education where people enter the community, whether it's the website, the Discord channel, the Wiki page, the GitHub, wherever people are coming in, we want them to be able to click to get to them, depending on who they are, where they need to be. So that's basically where the task force for that is at right now. Does anybody have any questions about the documentation task force? No? Okay, then I'm gonna just move on real quickly to the onboarding task force. Again, they're working with the same personas when are people coming on? We did an in-depth study. Again, this is a really speaking again to Arun's point about the success of these task forces. All of these people, well, other than Tracy, are basically new to the community. So there's a lot of new people that are getting involved, which is very, very nice to see. So what we did in the task force is we went to each place where people can jump on and figured out what we feel is needed in those spots. And there was an interesting, the Discord channel had a lot of information to be updated, stuff like the frequently asked questions and directing people. So there was a good discussion on that. And we also saw the presentation from Ben about the new website and what that's gonna look like and how that's gonna have the right tags and to get more recognition and get up in search engines and that kind of stuff. And this is a, I don't know if I'm supposed to be showing that but that was the new logo look that was in the presentation and information. Here is the presentation. I would watch it because it was really, really interesting to see how the future of this foundation is gonna look. And that's right there on this onboarding task force page if you wanna just see that. We're coming up for suggestions to Ben from some of the things that we determined as a task force from looking at the old website, what should be improved. And next, we really wanna get moving on, redoing those places and get the mentee ready. We didn't do a timeline for the onboarding task force yet that's next. But again, get him or her certain I guess I'm gonna use major tasks that they have to accomplish in onboarding more, not so much tasks, but where people come like the webpage, the Wiki page, the Discord, the GitHub and make them all look the same, make them all have the same really easy clickable information to get people to the training materials that the documentation task force is going to be able to support this task force with. So that's about where we are on the two task forces. We're moving forward. We're getting great community support and we're just gonna keep going. Anybody have any questions about onboarding? Okay, great. That's it for me. I'll turn it back over to you, Varun. And thank you for doing such a good job today. Thanks Mavi for the quick updates and thank you. I know we have five more minutes left and no more urgent items, but I want to quickly bring up a couple of items for as a foot for thought. So that we keep thinking about these topics in our upcoming meetings. One topic is about new projects that we should encourage. So if you come across any project within the Hyperledger Labs that you feel like needs like more appreciation or that you feel like, hey, this project is interesting that we should encourage them more. We should bring them up and support them in incubating that. So please bring those projects, please bring those topic up for discussion. And the second topic I wanted you all to start also thinking about is Hyperledger Charter was updated recently and that recent could be months ago now and there were few items that needed more clarification. And that is another aspect that we can start putting down our thoughts and then clarify some of those charter items. And what does it mean for governance standpoint? So these are a couple of items I wanted to bring up and not necessary to talk through today but these are the topics that you could read through and then bring them up for discussion in upcoming meetings. With that, I think we can end three minutes early if there are no other questions and thoughts. Thank you.