 I have Victoria. This meeting will get started probably in seven or eight minutes. Okay. Hi, good day. Okay. Good to go. All right. Welcome everybody to the June 13th hyperledger technical oversight committee call. I'm sorry, July 13th. Did I say June July 13th. Okay. As you may be aware, two things that we have to abide by on the call. The first is the antitrust policy notice. So basically we need to make sure that we're not. Doing any activities that are against any of the antitrust. Laws across the world. And then the second one is our code of conduct. And then we need to make sure that we have a standard. We have a standard announcement. And then we have folks on the call and their ideas and their opinions. So as we look at the agenda today. We have this standard announcements. The dev weekly developer newsletter goes out each Friday. If you have something that you would like to include in that newsletter, please do leave a comment. For consideration on the link that's in the agenda. And then any other announcements that anybody has or would like to include in the report. We have. Four reports that are out there. Yeah, Peter. I just wanted to say that we've finished the, the draft for cacti last night and I'm submitting the pool. It was right now. And sorry for being slightly late. Oh, okay. No worries. Thank you for that, Peter. So we will be seeing the cacti report coming in lately or shortly. So quarterly reports. We do have an outstanding comments. That requires re-review. Peter. I think that, that one is on you for cello. You did have a. Maybe it has been reviewed already this morning. So it looks like we're good. Maybe we're all set there because I don't see any comments left over. So thank you for whoever did do that re-review. For the caliper one. Oh, this is the one Peter, you've got a comment. I think it has been fixed. At least it says it's been fixed. So if you could just check that and make sure that's the case. And then we can get this one merged in as well. And then we have the. And we have the sate, the report. So for this report, as you recall, right did submit the report for, on behalf of the sauteed community, there is a number of questions that have been put out there. That haven't necessarily been answered. And so we do need the sauteed community to answer those questions. look at the transcript for the recording for the last meeting. It appeared that the sawtooth community thinks that there's maybe just some typos that need to be fixed and there's no real questions that are out here. And so it doesn't look like they're necessarily recognizing the fact that there are some things that need to be answered. So we'll need to reach out to the sawtooth community and get them to answer those questions at this point. So that's kind of where we're at with the sawtooth one. Did anybody actually attend that meeting while I was on vacation with the sawtooth community that could add any color to that? Hey Tracy, so I attended on the second half while I let Peter first talk because I saw like he was on going for the first half. Okay, Peter. Yes, we me and the room kind of covered the entire meeting. I was at the first half and I remember reiterating the points that we've been talking about here as well regarding maintainer, liveness and activity. So basically in the first few minutes, maybe the first 10 minutes of the call, we were talking about the basic stuff that we hear in the TOC always talk about. And I showed up, I was there and I reiterated these things and they seemed receptive to it. I did not get any sort of pushback and that was it. So from my perspective, the meeting went well. I felt like I was being listened to and we were in agreement about these principles or ideas. Okay. Thanks Peter. Are there anything to add? Tracy, so the previous meeting was different from the rest of the calls that I previously attended. And it was also run by new members. And there were discussions of some code being discussed, some code mergers, the PRs, but I could not find any of those references anywhere. So that's the summary. Looks like there is some interest from new members who are not maintainers currently on the existing branches which are released. Whereas there is interest from the current maintainers on new site of code. That's the summary. Okay. So I guess I will reach out and just remind them that there are some outstanding comments on this that need to be resolved before we can merge this and we'll see if we can get some answers to those questions. Then I guess the other report that we have is the basic report. I didn't see anything. I think everybody is doing some reviews this morning and we can probably merge that one at this point because there's no open questions. So we'll get these things merged that have been gotten in the reviews this morning. All right. Any questions or comments on the reports that have been submitted? So I guess there is one question from the Basu team on their quarterly report to the TOC. This is most likely a question to Ray or Sean, maybe. Yes. There was a question on the Basu report. Sean, if you could go to the files changed, we can take a look at that particular question. So it's right here. Scroll up just a little bit or down however you look at that yet. Have we been able to complete the Ask Around Circle CI funding by the Hyperledger Foundation? So Hart, I don't know if you have an answer to that question or if we can get an answer about Circle CI funding. Yeah. Sorry, Tracy. For the Basu stuff, we were working with them to get some funding from the Ethereum Foundation unblocked, which is overdue at this point from our CIP grant that we're going to spend on among other things, the Circle CI funding. So I'm actually talking to Matt about that in three hours. Okay. Great. Perfect. Yeah. That being said, there's still some room to do. We're still expecting to see more unification and more policies on tooling and we're expecting to get some directives from the LF. Okay. We will wait for that information when you guys do get it. I'm sure you'll present it here to us to let us know about what that tooling is going to look like. As it trickles in, we will. Yes. Thank you, Hart. Thank you, Tracy. All right. So for the upcoming reports, we do have the fabric and the catheter report that are due today. Peter did say that he's going to get us the catheter report later today, probably. The fabric report Dave is currently on holiday and he did mention that he would submit that report once he comes back. So I'm glad he's not doing that while he's away. And then we do have the next thought to the report coming up on the 27th, so two weeks from now. Peter. Sorry to interrupt. I just wanted to say the catheter report is now in. I literally just did it this morning as in the document was ready. I just have to submit the pull request. No worries. So we will all be taking a look at that then later on today. All right. So as far as discussion today, we do have the project annual review policy that I think is ready to be voted on. I did make the changes from the last meeting where we did request a few changes come in. They are specifically around the annual review timeline is going to replace the Q1 quarterly report. I did add a secondary TOC member to review and collaborate the findings of the TOC lead reviewer. And then I also updated the template based on what we did discuss in the June 22 meeting to make it more clear and remove some of the negative language that was in that particular template. So I think that one is ready to be voted on, but I would like to see if there's any remaining comments before we do get to a vote. So I don't know if it's probably a dumb question. So we are saying this is going to be in practice from next June or when are we saying it's going to be? Yes. So the expectation would be that the Q1 of 2024 report would be replaced by an annual review. I think that gives us time to also look at the project lifecycle in badging and see if there's any sort of changes that might come out of that that would impact potentially the status, right? Because the central review says that we'll look at the status to make sure it's in the right status. So if we decide on the project lifecycle that we're going to add any sort of backward arrows that we don't currently have, then that could be something that would be taken into account as well in the Q1 annual report. So thanks for the question, Arun. I think that's a good clarification. Other comments or concerns about this particular poll request? All right. If not, do we have a motion to accept this particular poll request and implement annual reviews as of Q1, 2024? Motion. Thanks, Peter. Do we have a second? That was Arun. Was it a second? All right. Thanks. All right. Let's go ahead and, Sean, if you would take us through a roll vote. That would be great. Absolutely. Trace, let me check to make sure I have everyone. All right. Great. In the matter of the project annual review policy, Arun or no, how do you vote? We have lost Arun. Sorry, yes. Wait, that's a yes vote. Arun, how do you vote? Yes. Bobby, how do you vote? Yes. Jim, that's a yes for me. That's a yes. Thank you, Jim. Peter? Yes. Rama? Yes. Thank you, Rama. Stephen? Yes. And Tracy? Yes. That's a unanimous vote. From the attendees, that's a unanimous vote of yes for the project annual review policy. I'll put those notes in the GitHub page after the meeting ends, Tracy. Okay. Good. Thank you, Sean. All right. Next item on our agenda is the Encourage Projects to Set Annual Goals. This is a poll request that Arun and I put in to the project proposal. I think it was the incubation best practices. I forget what this document is called, but it basically just says, yeah, Arun, if you want to talk to it, I forget what the particular file was. Sure. So this goes into projects incubation, entry consideration, along with all the process that I've currently listed for a project that we're saying a project must follow when they enter in. Because of the annual review process that we just voted for, we are now going to say it is required for projects to set annual goals. And the words are used in a way that projects are told that they will be asked questions on their annual goals. However, there is provision for them to deviate away from it, because we all understand that priorities could change between the year. However, we want the project team to reset or reassess, probably in the next cycle. So that's the summary of this proposal. And that's it. All right. So, Sean, if you wouldn't mind taking us to the files changed on this just so people can see that wording again that Arun just described to us. Any comments or concerns about this particular item? Okay, I will take that as a no. Can we get a motion to add this language to the incubation entry consideration? Sure. A motion? Oh, sorry. That's fine. Can we get a second? Second. All right. Thank you for that. So, can we also, Sean, just do a roll call vote on this? Absolutely. For the encourage projects to set annual goals. Arun, how do you vote? Yes. I'm sorry. I skipped. I know. Arno, how do you vote? Yes. Bobby, how do you vote? Yes. Jim, how do you vote? Yes. Peter, how do you vote? Yes. Rama, how do you vote? Yes. Steven, how do you vote? Yes. Tracy, how do you vote? Yes. Thank you all. Again, unanimous yes for the attended TOC members. All right. Great. So we will get both of these merged in then as well. So I think the other item that we have on our agenda is the security task force. Before we get there, I think Bobby did ask for 10 minutes, and I would like to, since I think we have time, allow Bobby that 10 minutes to talk about what was it, the documentation task force that you're working on? Is that correct, Bobby? Yes, exactly. So thank you very much, Tracy, and thank you for always running a great meeting and allowing us this time. So the task force for both documentation and onboarding has been reporting back to the TOC monthly or whatever. So this summer now that we have mentees and learners working on the whole project as a whole, we're going to spend the rest of the summer meeting our goals. So the team right now would like to present what those goals are so that when we come back at the end of the summer for a presentation, we can tick off all of the documentation and onboarding task force expectations. So I'm going to turn the meeting or the presentation over to my mentee who is awesome. So take it away, Arunama. Thank you so much, Bobby, for interesting me with this role. So hello, everyone. My name is Arunama Chaudhary, and I'm an LFX mentee for the documentation task force and will be working under this project with my mentor, Bobby. So let me share my screen. So starting bit to ensure that the Hyperledge of Projects have the best possible documentation. We as a team under the documentation task force have divided ourselves into five into six subgroups that we will be working under. Each subgroup will provide support in a specific area. So the subgroups are Github Templates, Github Read the Talks, Templates, Best Practices, Onboarding and User Crides. And all the subgroups will work collaboratively to address any of the documentation gaps and assist the project mentees in any way possible. Some of the shared objectives are to enhance the overall quality and consistency of the documentation across all the projects, to provide support to the project teams in utilizing the available resources effectively, to streamline the documentation process for a better efficiency and productivity, and also to empower users through user-friendly and comprehensive documentation. So let me start by explaining what each of the subgroups is all about. At first we have Jan Luka. He is the chair of the Github Templates and he will be introducing, he will be giving us a brief on what the Github Templates subgroup is all about. Okay. Hello everyone. I'm Jan Luka, an Italian software engineer and I'm passionate to open source and blockchain technologies. I'm also some skill in blockchain fundamentals and in solidity smart contract language. I would like to contribute to hyperledger project supporting for example the development teams in creating or updating the documentation. And that will allow me to improve my skill in blockchain, especially in hyperledger ecosystem. And in particular I'd like to support the Github documentation if possible, and that activities and starting from requests. So I'll be open to requests for the development team during this summer. And thank you for this opportunity. Thank you, Jan Luka. So next we have the Github Read the Talks group which is led by Tripur. Tripur you can go ahead and explain what the Github Read the Talks group is all about. So hi everyone. My name is Tripur Joshi and I'm a technical writer and a researcher. I'm leading the Read the Talks group and I want to say this is a really great opportunity for me as I'm always interested to contribute to open source and working with Bobby has been really great. She is a really great mentor and what we are going to do this summer is we have started working with Solang and their documentation and we are enhancing their user documentation experience by making it more user friendly and by making it more beginner friendly and increasing the visualization in the documentation. And side by side as suggested by Bobby, we are also making a standard user documentation on which if any hyperledger remember, sorry, should I continue? Please do. Yes. Okay. So I'm also making a standard user documentation in which if any of the beginner technical writers want to take telly their documentation what is missing, how can we improve it and in the upcoming projects and all as the first documentation is always written by the coders if there is no technical writer. So it can help them to take off some things that they may not be aware of. And this is how we want to make the hyperledger community more like have good user documentation and steamlight the iteration process for them. So yeah, thank you everyone for listening. Thank you so much, Tripul for giving us an idea of the GitHub Read the Talks group. So next we have the templates group which is led by Kajal. Kajal, can you please go ahead and introduce yourself and the group? So, thank you Arumama. Hello everyone. I'm Kajal Kumari. I'm currently a final year student in India. So I'm an anger developer and also a technical writer. Like I have contributed in various open source programs in development and documentation field. So I'm very excited to contribute in hyperledger projects this summer. So I have also talked and identified some projects as Bobby told us to find any projects need documentation help or anything. So I talked to some of the projects and I also like went through their projects and understood what help the project can make. So I'm the chair of templates. So like we all know the onboarding of beginners or the member on our website is very important. Like if I'm not able to understand the website then I won't come again there. So we'll be providing the standard and a consistent approach to documentation across various hyperledger projects at the various stage like for user case for white templates for the graphic set or for the presentation. We'll be providing a template like templates having unique requirements and specifications. So our team will work closely with the project team to develop customizable templates that align with the specific need of the project. And by offering such well-designed templates, we strive to streamline the documentation process and enable project team to focus more on building and ensuring that vital information is documented effectively and the users or any person who visit their website who wants to know more about the project they can get more idea. Thank you. Thank you so much Kajal. Next we have Victoria who will be explaining us the best practices group. She is also leading the best practices group. So Victoria can go ahead. Hello everyone. I'm Victoria from Nigeria, a front-end developer and a tech provider. I'll be working with Arunima and amazing mentor Bobby to work to improve the documentation standards for the hyperledger community. As the best practices lead, our goal for this summer is to identify and promote industry standard practices for documentation within the hyperledger ecosystem. This ensures consistent documentation and it also improves them with ability and maintainability of the documentation. Now these guidelines, we are going to cover various aspects such as the structure, the style guide. We're going to use the code snippets, versioning and then for maintaining the already existing documentation. By adhering to these best practices, project teams will be able to produce documentation that is of the highest quality, ensuring a seamless experience for users and developers. Thank you so much. Thank you Victoria for giving us an idea of the best practices group. Next, we have the onboarding group which is led by Akanksha Rani. Akanksha, you can go ahead and introduce yourself. Surely, surely. Hello everyone, myself Akanksha Rani and I am also an LFX mentee for the hyperledger onboarding project this year which is mentored by John, John, Niku and Peter. I'm a huge EIMM enthusiast and web developer by passion and I am an open source contributor. Currently, I am pursuing a bachelor's degree in engineering and I'm also very engaged in learning and expanding my skills. I will be also updating about onboarding stuff in this call. Firstly, talking about the goals. I have divided the onboarding part in six subparts. Our goal would be including firstly the research and analysis that we'll be doing on different users that will be approaching the hyperledger site. Then we'll be planning and scoping out how we'll bridge the gap between a user who is coupling for the first time or the second time on the hyperledger website. Then we'll be designing and working on the development of the new site along with Ben because since we have a rebrand now, there are some designs which are sent by Ben. With alignment with that, I'm working on the design part and we have started on the main website. Other than that, we'll be working on testing and feedback and we'll be working after that. We'll be collaborating and finally we'll be doing the refinements with the feedback of mentors. We also had a call. The onboarding team had a call with Aaron where he also gave his feedback and we are working on the feedbacks he gave along with John and Nico. I think we'll be definitely making an impact by creating a better website and a better platform of hyperledger for new users like the business users, the developers, maintainers and enterprises because these are the three personas that we have divided our main focus into this time. So, I hope that I really contribute my best and work along with the hyperledger team. Thank you. Thank you, account shop for giving us an idea of the onboarding group. Next, we have the user guide through which is led by Agnes. Agnes, you can go ahead and introduce yourself. Hi, everyone. My name is Agnes. I'm a technical writer and backend developer. I'll be helping the documentation team come up with user guides for different projects. What a good user guide might look like and I can share as mentioned taking into consideration the different users that we have in terms of personas. So, I'll be working with both the onboarding and the documentation teams just to make sure that user guides cater to the different personas and as clear as possible. Thank you. Thank you, Agnes. So, that's the end of our presentation and it was, this presentation was nearly a brief of what all the six subgroups under the documentation task force is all about. Thank you, everyone. And if any of you have any questions then you can let us know now. I just want to say great job, guys, and I can't wait to work with you this summer to reach these goals. So, I'm getting excited. I'll talk to everybody on Monday and thank you for doing this. Thank you so much, Poppy, for all the assistance. All right. So, now everybody on the call knows that they're going to be reached out to by this group of people to have conversations about documentation, onboarding, potentially getting some help. I did see a lot of questions coming out and discord from folks about what can I do to help. So, now you know why you're getting asked these questions and hopefully we'll be able to get our documentation in great shape by the end of the summer. So, thank you for that. We're looking forward to really seeing what you guys accomplish and getting that read out at the end of the summer. So, with that, we are now up to the security vulnerability disclosure task force discussion. I know that, Hart and Arun, you've been working on this a lot. So, I think at this point we'll hand it to Arun and you can take us through what you guys have done and what the next steps are. Thanks, Tracy. I'll pull up the document comments quickly. Okay. So, we have had several discussions on this and within the TOC meetings as well. And the previous summary that we had on the TOC call, we saw a hard put up this document and then we took this over to the OpenSSF working group calls on which runs on Wednesdays. And they were very gracious to review the entire document and they have had several iterations. I mean, several people going through this revision of the document and suggesting improvements over. So, majority of the comments that the OpenSSF team has been suggesting us is the emphasis that we need to lay out on the embargo list and the kind of words that we can use or the language tone that we can use, suggesting the importance of the actions that the embargo list should take and the role that they play. And in addition to those, the suggestions also came in around the roles and responsibilities of the security representatives within each project. I know like previously within the RTOC call, we had discussions of having a couple of members identified from each project who are who enter incubation phase and then have those people go through or be a security front for the project. And the OpenSSF team also emphasized that there is need for us to have an expert. And when we say expert in security, it could be from different means, right? So, for instance, there could be someone who is a cryptographer and we may need to jump in as needed and when the role demands, we can pull in additional members. So, there could be specialized areas where somebody could have their security expertise on and it's up to the security team so that they coordinate well with the person who raised an issue. And the OpenSSF team has also emphasized more on the back and forth communication that should happen with the person who has raised the issue. So, the summary of that discussion or the comments that you can see over in this document is that we should communicate well in advance with the issue reporter and we should identify at least if it is a bug or if it's a security issue. If it is a security issue, then the security team who is working on it should follow up further and create a CVE. And not just that, like once we, like the ones that is reported, then there is also expectation in terms of doing a private branch. I forgot the exact term used, but a private patch deployment, I believe is the right word. So, doing that private patch deployment which allows us to develop and perform tests for that particular security vulnerability that has been reported. And then there were also discussions or suggestions around which tools should we use in order to notify about these issues. And for instance, like at a hyperledger level, we could create or we could start using GitHub security advisory which we received. And the security team who is working on those received issues, they are responsible for that. So, that's the summary of different discussions and the importance called out from the OpenSSF team during their review. So, I also assume like at least majority, if not all of the TOC members have read right through this document. So, the idea is that the document will be placed as a template and each project can further improvise on this. But these are the mandatory or recommendations going in from the TOC. And few of the optional areas are called out specifically. I remember, for instance, there is an option of the embargo list which has been called out that embargo lists are optional. So, the embargo list is optional in the sense that if the project team is too small or like they don't have enough support, then it's optional for them to have an embargo list. I'm sorry, I had some disturbance at my apartment. So, the next steps for us from the TOC is that we proceed formulating this like the template which we see over here will be put up in markdown as a recommendation in the TOC for the projects and under incubation. And then each project will be asked to go and update this into their repositories. So, I believe there were a couple of comments around what's the responsibility of the project teams in terms of if they have different repositories such as Ares, whether they should have different responsibilities across different repositories or should they have a unified approach across all of their repositories. That's one thing that I did not see a conclusion on. I also saw like Hart was open for suggestions from the team members. Is there a spot you specifically want me to scroll to, Arun? No, Sean. I think all the comments are addressed. The ones that you see over here is just about a few things that Christopher raised. It's the language which is already called out and yeah, we can always improvise on further. So, if you can see like Christopher is also emphasizing that embargo list plays an critical role and they have been provided with information that is otherwise confidential in nature. So, that comes with additional responsibilities. Otherwise it's the document is in a shape which we can proceed and vote upon. So, Tracy, it's on us to proceed to the next step. If TOC agrees to this process then this will be put up as markdown in the repository. Okay. That's great news, Arun. I think this is definitely taken shape and I think it's great that it's been passed through the open SSF. Any concerns or questions on the security vulnerability disclosure policy that we would like to make sure gets into the document prior to the markdown being created? Any discussion from the TOC members? Arun? So, I don't have any concern. I think this is great. So, thank you, guys. Just one thing. In the introduction it says something about we expect this document to be linked from Security MD file. I would make this stronger. I think this has to be, if it's a policy that applies across the board, Security MD files ought to point to it so that Security MD file is what most people are going to see first. They find the vulnerability, they go to the Security MD file that tells them what to do, how to report it. It's important that this Security MD file points to the policy. So, it's got to be a must, not just like, yeah, maybe, should, or expect. It's a bit too weak. It's a very minor thing. I just wanted to say that. All right. Thanks, Arun. Any other comments, discussion? Peter? I also think it's great, and especially it is a great idea to take it to the open as a self and thumbs up and also sorry that I wasn't, I couldn't be as involved with the creation of this as I wanted to be. Thank you again. All right. Thanks, Peter. Any thoughts on kind of that question that I think Arun posed, which is for projects that have multiple repositories like Aries that maybe the work is somewhat separate thoughts and kind of, you know, whether or not there's a single policy for Aries or potentially multiple policies for Aries? I haven't thought, but I would love to get the other TLC numbers thoughts, especially people that this is going to impact. Yeah, it's interesting. Aries is almost, at this point, it's just the way it's evolved is almost separate projects. You know, the three major pieces of it are operating more or less independently. And so it is interesting from that point of view. We're going through it right now because we've got a vulnerability, but it and it is in a common dependency, which is interesting. So we're we're living this right now. We'll see how it goes. So Stephen, does that imply that you think three separate policies or potentially four for the common dependencies? Or does that imply that a single one would be good to cover all of them? Or maybe you don't know yet? I guess by what you're saying is the embargo list, for example, might be different. Obviously, the policy is the same across them all. What you're saying, I think you're saying is just that the embargo list might be different for the sub components of the project, the four you're right for. Gotcha. Yeah, that makes sense. That makes sense. So maybe that that you have a single policy, but it says for this particular component, this is our list for this particular component, this is our list. Exactly. I don't think the policy at all should change. I think it should be completely the same. However, the application of it might be different across the different code bases. All right. Any other comments? Arun? Thanks, Tracy. So I just want to again repeat and probably call out all the maintainers. If not already seen this, please share this among your group, the other maintainers that you are aware of. Because once the policy is enforced, it will impact all the projects. And especially around the responsibilities from each project. And since these are security matters and we are publicly claiming certain aspects of how we deal with security issues, there is impact to both the project as well as the foundation itself. So that's all. Arun? Yeah, when it comes to this implementation, I think this may be worth adding a question to the report quarterly report template asking, have you implemented this policy, right? Because I think this is something we're going to have to track, similar to what we did for other things. And it doesn't have to be forever, but we might also want at some point to put some some deadline. Like, you know, we want all the projects to have adopted it by whenever we decide. Because otherwise, you know, and honestly, I'm thinking of SOTU, for instance, you know, which has not been very responsive on the quarterly report. I don't know that'll be responsive for this either. And at some point, I think we need to put our foot down and say, look, this is a requirement. If you want to keep belonging here, you have to lay by the rules. Yeah, I like that. I don't know. Steven? About the embargo list, this is a quick detail question. I assume all maintainers, maintainers are notified and so on. They're not embargo list is beyond maintainers, right? That is correct. I think I'll try to answer that question in non-political way and also try to be nice. Okay, so you're right, like embargo list is outside the scope of maintainers. However, the language that is put up here allows for maintainers to have a say and including a specific group of people or an organization in the embargo list. Thank you. All right. Any other comments, questions? Discussion? All right. I will take that as no. So, Arun Hart, anybody else who was involved in this, thank you for the work. We'll look forward to the Markdown poll request coming into the TOC repository once it does. We'll definitely bring this back to a vote for the TOC members to vote on. One of the things that did come to mind as we were discussing this is with the call out to kind of communicate this to the other maintainers that might not be on this call, is there a way for us to do that? Is that the maintainers discord channel? Should we be putting something on the TOC mailing listing? By the way, this is coming. Please do review within a comment. Just curious if there's any thoughts on making sure that people realize that this is going to be a requirement as Arun stated, right? That is going to be needed by each of the projects. And how do we kind of communicate that beforehand versus waiting until we approve it? Any thoughts on kind of the best communication mechanism for that or just, you know, attempt to communicate as widely as we can? Peter? I would say as widely as we can. And the idea I just had is on top of the discord channel and the mailing list that could also open issues in the GitHub repos and say this is just a notice. You can close it as soon as you've read it, but we want to make sure that you see it and then the information itself. All right. Thanks, Peter. All right. So then I guess with that, if there's nothing else, I'll make a call to see if there's anything else anybody would like to discuss before we close the meeting. Peter? Just a quick one. I know I'm a little behind with the automation, the pipeline automation task force, but we will schedule a meeting for next week. So everyone who is on that, please keep an eye out for me messaging about it. Actually, Peter, that's a good point. The automated pipeline task force discussion is next week. We can definitely use the TOC meeting to have that discussion in more detail, if you would like, instead of setting up a separate meeting since it is next on the agenda. That's great, but I also wanted to set up a separate meeting just so that by the time we get to the TOC call, we have some conclusions and updates and maybe we can take the discussion even further down the road. That's ideally I'd want to do that. No worries. Perfect. So we'll keep an eye out for that. Thank you. Yep. Anything else that anybody would like to bring up before we close? No? Okay. Well, thank you all for the participation discussion presentations today. We will talk to you again next week. Thanks all. Thank you, Tracy. Thank you to USC members and thank you to the presenters from the onboarding group. That was awesome. Yes. Thank you, guys. Thank you.