 All right. Welcome everybody to the January 26 hyperledger technical oversight committee call. As you are all aware, two things that we must abide by on the call. The first is the antitrust policy notice that is currently displayed on the screen. And the second is our code of conduct, which is linked in the agenda. For announcements today, we have the standard hyperledger definitely developer newsletter that goes out each Friday. If you have something that you would like to reach the hundreds of hyperledger developers that we have in the community. Please leave a comment on the wiki page that is linked in the agenda. Any other announcements that anybody has for today. Okay, I will take that as a no. So for quarterly reports, we still have the outstanding q for hyperledger Ursa reports. We have the sawtooth report that's coming in today. I did get reached out to you from the sawtooth folks they are currently working on a release and then they will get to the report probably later today. So we should expect to see that coming in. Check your inboxes or your task list to see when that does show up. And then Stephen was ahead of schedule I guess it got us the hyperledger areas report ahead of schedule so I saw that a number of people have had the opportunity to review that already. If you haven't that one is waiting for your review. But for those who have had a chance are there any questions on the hyperledger areas report that anybody has. Okay, looks like we just have some updates for the data from the insights report that needs to come in on that so we'll expect that get updated here. I'll be shortly. I'm just laughing I'm watching the participants come in we now have two people who are hyperledger project folks so I just think it's amazing. Okay, anyway, next, next thing that we have on the agenda here is to talk about the moves the project reports to get hope. We're probably ready to make a decision on this today. I did see a number of people who have agreed to this on the chat and have provided some input as to where they think these reports should be hosted. Any questions or comments that exist on this that we need to talk about in the meeting. Any concerns that anybody has they'd like to bring up I know last week the concern was whether or not we would have any objections from people who submit project reports didn't see any that showed up on the chat. Any other comments or concerns that we have with this. So to see this is on. I have no problem. I just think that obviously we will have to update the documentation so I am thankful for buying me the effort to to elaborate on the process being proposed which you didn't have visually I think this all sounds good but we need to capture that somewhere else then in my tissue eventually right. Correct. That is correct. We'll have to make sure that we redirect people to where they need to go to create to create those project reports in the future. We'll put a link there directly and then I think there's a few other places that we talk about project reports that we should consider either updating and or moving from the wiki. I think there was a document that we had wrote two years ago maybe about the value of these project reports and why we create them. And that could potentially be moved over to GitHub as well as just a kind of introduction for this particular section on the on the TOC site. But yeah we'll definitely have to go through and see if there's any other places that we'll have to update. I talked about reaching out to the projects to us the maintainers typically fill out those reports so they felt about it but we haven't heard back from anybody. So I did reach out on the maintainers discussion channel. The only thing that I saw was a few people who said yeah this looks good and a few thumbs ups. If you will, there. I didn't see anybody who objected to the request. So I just, you know, it'll be interesting to see I mean people submit the next report on the wiki and didn't get the memo changing and using GitHub instead. For sure for sure. It will be a data point on how effective we are at reaching out to maintainers projects. Any other comments or concerns. No other comments no other concerns. Did we want to make a motion for moving the project reports to get help. Speaking and just one question so what will happen with the existing project reports, which we have on the wiki do we also migrate them to get up to have everything in the same place. That's my plan. I've already, I've already explored them as HTML, and I use pandoc to convert them to mark down. Those will come over time. Because the HTML export doesn't preserve the voting status. So I need to, I said voting status, the checkbox status. So my plan is to move those over. So that most probably will also mean that we will violate the proposed protocol in order to basically review and approve on GitHub or the existing project updates, I guess. Yeah, so I think all the existing project updates. You know they've already obviously been approved by previous to C's or TSC's has the case maybe. And so, yeah, I don't think we'll necessarily need to have everybody in this to see approve those before we can get those merged over. I think that was your question right Marcus. Yes. So I mean, if there is a way to transfer the old stuff, I mean, the GitHub, I think it's great but can we just leave with that you can link from Gita to the wiki and say for all the reports go check that out over there. What I would like to do is mitigate this durability point to right. We've lost founding documents. And I want to get them into get. Okay. I don't plan on deleting them from the wiki. But I just want to get them somewhere version controlled. That's not the wiki. Okay. Thanks. The other comments concerns questions before we go to a motion. So I move. All right. Thank you. Do we have a second second. All right. Thanks to room. All right. So, right. Do you want to just take us to a objection abstain, approve. Sure. All those who object, say, nay. All those who abstain, say, abstain. All those who approve, say aye. Aye. The motion before the TOC passes by voice vote. All right. Thanks, Roy. All right. So for a next agenda item. We have a discussion about some proposed task forces. So just to bring up to speed, those who may not have been on the TOC last year. We had. Last year moved to running tasks forces during the second half of the TOC call. With the first half being. Used for discussion and decisions. Potentially. Depending on the agenda, we did tend to go beyond the half an hour mark. But the intention really is to run task forces so that we're getting some work done by the TOC. And how last year, I think we had. Four different task forces that we ran during the TOC. And then a number of those task forces also had like off cycle meetings where they met and get, got some work done outside of the TOC calls. So I think the, the intention is to continue that practice here. We did have quite a lot of suggestions and goals that people had in our first TOC meeting this year. Where we can possibly create some tasks forces. I did try to create a list of those. I did have some people add to that list earlier in the week. And so you can see the full list here of proposed task forces that were based on both our goals, discussions. And other things that are ongoing in the. In the community. So I first wanted to start with a conversation about whether or not these look like the right set of task forces. I don't think we can obviously do all of them initially, but I think we can start with some of them. And then as those close up, we can bring others on to the list. But I do want to see if first of all, if there are others that we should be adding to this list. Bobby. Yeah, I was looking at the list all week and kind of thinking and trying to get a higher view looking down on these task forces. And I kind of think the list we have. When you start with the project best practices, I think out of that task force would flow the badging, the documentation. And possibly security so that. You would have the best practices and then possibly get badges for those, but I think that. You would have the best practices and then you would have the incorrect documentation guidelines again, the documentation would be a task force in and of itself with the suggestions for the community to use. You know, the best practices would be decided and by task force or whatever, but there would be a place where people would be able to go to see. Badging is the lack of better word. And I think that those three kind of can be tied together into one. And then I have comments on onboarding for later but that's just for those three right there for me it just seems like they are kind of in the same family comments. Yeah, Bobby, I agree with you. I think that project best practices is a very huge task force and I do think we probably have to break it down into some sub task forces because I still I think like the best practices for automated pipelines might fall into project best practices as well right. And so, you know, I guess the question is, do we start with trying to figure out what all the best practices are that we want the projects to focus on, and then create some task forces around those. You work on what might be the smaller task forces around documentation and automated pipelines, and those feed up into the project best practices task force at a later point. I mean, I understand I think I have the same sort of question in my mind and so I don't know which way is the best, right is it breaking down the project best practices or is it building up the project best best practices if you will, or no. For those of us who've been around for a while, you probably remember that the way we define task forces was something along the lines of something that is, you know, that has a very fairly narrow scope with a clear mission that is expected to be delivered in a fairly bounded timeline. And so for that reason, I do think it's better to have smaller scopes and like topics. I do think that you know best practices is indeed too broad and or he would have to be something that, as you're saying, the goal of which it becomes like spawning off other smaller task forces that are more narrowly focused and experience shows that it's much more you get a lot more momentum when you have a fairly well defined narrow scope that you can execute on and deliver quickly, because people get, you know, you do get a boost out of, you know, the satisfaction of having achieved something. And then people are encouraged to participate in more task forces because you get a sense of achievement, rather than having some kind of really long-winded task force that just never seemed to add that it becomes much less obvious what you're achieving and it can become Yeah, I agree. I put a link into the task force guide that we had created in the chat for this meeting. And in that document, it does talk about being the task forces should last no longer than six months. As far as time to complete that they have to have the introduction and of what the task force is and the tasks that are to be completed and the deliverables or the work product, right. So, I agree that we definitely want to make these things smaller. As far as what it is that we're trying to accomplish with each of these task forces and if we were to decide that the project best practices task force was something that we wanted to start with then it would definitely be a case where I think we start with a list, right. That's the initial task that needs to be done, a list of what we believe these best practices are that we would include there. And Dave, I know you have your hand up. You were also the one to recommend that in the goal so I would appreciate your thoughts on this as well. Yeah, can you hear me. Yep. Yeah, so my intention with that one was not to boil the ocean and do all project best practices under that task force, but to pull together some of the existing information that's in various places. So that it's like a one stop shopping place where people can see everything, and then also have a structure such that we can link to other things as they come in with these other task forces. So from that perspective, it's kind of a focus thing just to pull together a structure of how we want to expose the stuff to the outside world. But then yeah, there'll be a lot of open items that the other task forces will complete over time. And I don't know I guess back to your point right about smaller task forces that's also why the security has to separate items that are listed there I think even hard had been talking about trying to make those you know, discrete tasks that could be accomplished in the short time frame that we would want from the task force so completely agree that we want things that are smaller in nature. All right, if we could go back to the meeting record. So that people can take a look at these. See if there's other ones that they think might be something that we want to include, or possibly, you know, have if anybody has questions on kind of what we think these task forces might be. Obviously that will be up to the chair to really define that but you know, love to have any additional thoughts of other task forces that we might want to focus on short term job. Yeah, thanks. I just wanted to comment on a little bit of you know where the learning materials development working group is looking to go this year. And so we've talked about focusing on the onboarding task force, which is, I think the fifth item down there. And really being able to get people who are interested in the hyper ledger ecosystem engaged and being either contributors or maintainers. And also looking at as part of that delivering some educational content that would be a regular series of meetups that can be promoted by hyper ledger that we can, you know, continue to go through and provide educational or instructional content. And also, you know, just look at continuing to focus on the career fair that we've had for now two years in a row, and make sure that that's on track for 2023 as well. So that'd be my only comments about task force this year. John, I guess I have a question. So the onboarding the education pieces. Those are distinct and separate task forces that you are thinking about doing in the learning materials working group. And so the great thing is Arun is on the call here, you know, he's done a great job of working on the start here that hyper ledger.org. And, you know, going ahead and collaborating with Arun and that team, and really continuing to build that out, also providing some resources that are accessed a lot on the hyper ledger.org website. So people know, you know, really what's popular content. And, you know, making sure it's really a good onboarding experience. And if there are people that come to the community and want to get engaged, you know, being able to really point them in the right direction and get them going quickly is the thing. And then I've also been conferring with Jim Sullivan around doing these instructional content workshops, and, you know, being able to have more of, you know, the library that we can offer to the hyper ledger community around these instructional workshops, and including them in the hyper ledger YouTube channel. I first I want to just put it out there that john has stepped up to be the chair of the learning materials working group and congratulations and I'm so happy he's done that so hats off to john for that. I was thinking with the new task force for the TOC that documentation and onboarding become one of those. I would gladly take a leadership role in that and work with john and Arun to make that happen. So onboarding definitely has to be parsed out a little bit I think you have onboarding citizens onboarding developers onboarding sig chairs onboarding maintainers and onboarding TOC members so there's definitely a lot of onboarding that needs to be talked about and determined so again those two, john and I have, you know worked well together and we would gladly keep moving with those so if anybody has any suggestions or information that they would like to help us and I think the badging process might come from some of the work in those two task forces. That's really interesting Bobby I think that I wanted to see if maybe I can edit this list, because you had onboarding sig chairs onboarding to see members onboarding. Maintainers. Maintainers onboarding developers. Okay. And citizens. What are citizens. People like me who my first year here just was involved in calls going to meetups scheduling meetups creating meetups. You know we're not developed we weren't well on the develop but you know just people who want to be in the community community members is a good word. Okay. Okay, any other ones that I should include here. Okay. Yes, I wanted to capture that because I do think as you look at, or as we look at these task forces we should, as I know mentioned right make sure that these are distinct and small enough to be covered in the six month time period that we have set up for task forces. So I appreciate you kind of expanding those if you will. David. Thanks Tracy, I plus one I just wanted to plus one what both Bobby and john said I totally agree that onboarding is a broad topic so it's nice to. We're clarifying what we're talking about and you're right in the way we onboard one of those groups is going to be different from the way we onboard another so that makes sense to me. I also think the task force structure is going to be a better format for the work that people in the learning materials working group want to do than perhaps the working group model itself I think this will be an interesting experience to see if the task force brings more people into those efforts. I also think it's great to try to combine those I mean, I think we've already mentioned it, but you know for example the work that Arun and the India chapter has done around start here has been great and the work to learning materials working group has been doing has been great to but those have been separate efforts, you know I think it's much better to have one combined effort at bringing new people into the community than having multiple ones so I'm really excited that people seem interested in the onboarding task force and then I'd be happy to support all that. Thanks, David. Yeah, I think the. So we talked about kind of the project best practices. Stephen you had suggested the automated best the best practices for the automated pipelines as a goal to try and capture so I did include that here. Hopefully that one is self explanatory to people. But Stephen did you just want to remind people of what you what you were thinking when you brought that up as a goal. Sure. We're doing a lot on in the various projects we have on what I consider sort of reinventing and rediscovering what's the best way to produce artifacts where to produce them and so on it also goes back to what are are no talked about last week which is you know handling dependencies and things like that looking for, you know what tools we're using for making sure our artifacts were producing our safe. So, going through that we had a huge effort on indie to basically redo what had been done, and it, you know it was pretty extensive but it was, it was very manual and and difficult to use and bringing it up to to current best practices I think I think it's there and and applying those would be very helpful so that's that's sort of the idea of that one. Okay. Dave I added these two bullet points to the project best practices. I think those were what you had suggested as what your intention was was to gather the current best practices and determine gaps that might exist as did I capture that correctly Dave. Yeah, that looks good. Yeah. Okay, great. So the badging life, life cycle one that exists here is one that we have talked about multiple times in the last. Well, I don't know probably ever since I started joining PSE PSE calls. We're, we're trying to figure out how people can best determine the status of projects. We've talked about potentially coming up with a number of different badges that people can make sure our current and accurate. We've talked about, you know, is her life cycle the correct life cycle do we need to do anything to change kind of the status of where projects are. Do we need to have some sort of yearly review cycle or that sort of thing and so I think this is a task force that I added specifically because the governing board had a discussion in December regarding this and so I think it's something that they're sending back to us to take another bet and see if we can get it right this year or not. So that's what that one is all about. The documentation task force, I think there was some comments in our initial meeting about the where we store our documentation and to the format of our documentation and making them more consistent across the board. And so I think that is what that particular task force is all about. Does anybody have any additional items that they remember from from the documentation body. I worked with that with one of the community members Ben and he did a great job. We just really don't know where to put it it was more suggestions and again I know that it needs to be updated and needs to be looked at but there was great momentum on that, just to make it more maintainers and developers to transfer their GitHub stuff into a unit not a uniform but an accepted hyper ledger format with a lot of leeway for them to pick, you know their own styles and stuff but just to give them some basic guidelines. So I think that that was one piece of the documentation task force and then the other where I think there might be another opportunity is with the documentation almost like a hyper ledger library for people to go and you know not research but look up and research actually information that is available to the community. Okay. And Steven. I want to add that a bunch of the documentation challenge is the tooling involved in in publishing a decent documentation into a format accessible to the set of onboarding people that are listed below. And so common tooling for doing that and just being able to spin up a repo and have, you know, all of these things like the best practice for automated pipelines but also documentation there so it's more a checklist and and the ideas are already there of how to do it. So to me to me read me and mark down files are so 2018 and we have to get up to 2023 and that means actually publishing these out to a more accessible in a more accessible way. But one thing that we could do is get up does have template repose. So it would be, it's possible to have a, you know, have a repo that's a template that contains all of that. You know, it might be overkill in some cases, because the first commit would be someone from the community immediately removing all the stuff that doesn't matter. I don't have a strong feeling about it. But, you know, it is, it is something that's available. Okay. All right. Marcus. So I think about documentation so sometimes I said if I go to some documentation of several projects so sometimes the scope of the documentation. I think it's not really clear and maybe it depends on the lack of some guidelines to define okay what should be in a good documentation for operators for end users for just people would like to get the gist of a project. So documentation for a new contributor to project a new developer should maybe look completely different. And so I think there. Yeah, maybe some guidance on how to define certain scopes or the audience would be helpful. Okay. Great. All right. So down here to the support it project. So in the latest version of the charter, we introduced a concept called supported projects supported projects are those that have separate technical oversight pursuant to a separate technical charter. And those projects are called supported projects in the charter. What one of the things that we need to do is find all of the places where we need to update documentation of how we would deal with a supportive project from the technical oversight committee. For example, do we require quarterly reports from supportive projects. What do we do when a incubated or a new project proposal comes in for incubation, and we would be reviewing that as far as the project that's coming in like is there anything that we have to do to the life cycle documentation that sort of thing. I think it's at the very top in the very first section. It's the very last paragraph of the section talks about supported projects so those are the sorts of things that I was thinking about for that particular task force is just understanding what that truly means for us. And I have those as part of the charter and might expect to see some of those projects coming in. It would be good if we have an idea of how we want to handle those before they actually show up. So, yeah, that's what that particular task force was intended to represent. And then, I think that the last two are security task forces. I don't know. I don't know if one of you want to talk about these from the perspective of what exactly you were thinking here. I'm happy to talk. Do you want to talk. No, it's all right. Go ahead. But so that's why I was first. No, I just, I was still puzzled about this concept of this supported project. Maybe someone can give an example. The example is, let's say we have a project that already has a brand associated with it. But they want to bring their source base into hyper ledger. They want to basically be whatever project name a hyper ledger project, instead of hyper ledger project name. So that's why I think this is a supported project. They have, they will have their own technical charter that they will work under. And beyond that, I'm not sure that I can actually give you much more information about how that's going to work within hyper ledger because we don't have it. And that's why I think that task forces is really important is to really try and understand what would that look like for us as a project comes in. And that project. What's what additional steps would need to be taken to make sure that project is remaining healthy. And that there's nothing that we would want to do from a to see perspective. So that's like hosting it but not only is that the right way to understand it. So the source code will be hosted in hyper ledger repositories but we don't. We don't have the quote unquote on that. The copyright of it, or the license of it. Like we do with the regular projects. I believe that's correct Daniela any thoughts on that. Any additional ideas you can add beyond what has been said. Or heart. I don't know if one of you have a thought to add to this. Can you repeat the question please I apologize. No, that's okay Daniela the question is the supported projects or the projects that are coming in as a hyper ledger project, but are not branded with hyper ledger. They have their own brand. I think that the question is, are these projects that we would consider hosted by hyper ledger, but not necessarily owned by hyper ledger or, you know, we're trying to understand them better I guess in this context. Yeah, they would be part of the hyper ledger foundation. So they would be governed under the talk. They would have their own project charters if they sort of wish, and the same governance and support project services etc that we have today for a hyper ledger xxx project would be applied in the same way. What is the key difference. The key difference is that they don't need to have the name hyper ledger in front of their name. It's a marketing thing more than anything else. Okay, and then the fact that it's still governed by to see does that mean how they elect maintainers how that community grows would still follow. It's just like today's projects, right. So, yeah, exactly the same as, you know, hyper ledger firefly project the same way that you know the maintainers are selected the processes within that project are selected. It's the same thing. Maintainers are kings here in Queens. Gotcha. Thanks. Tracy did that address the question. Yeah, I think so, although I still think there's a bit of just confusion about what a separate technical charter truly means. You know, and you know, is there anything that's going to need to be a concern for this to see and the sort of processes that we currently have around, you know, would we expect these projects and projects to still report to the to see I mean based on what you said it was, and so maybe there's not really any changes that have to occur here but I just, I feel like when we looked at the technical charter that was created. It's a non credits project that I don't know if we got rid of at this point. I just feel like there were some concerns around what was stated in there and the way in which it's potentially conflicted with the hyper ledger charter and the to see processes. parts got his hand up I'll let him address that part. Yeah, heart. Yeah Tracy, you're totally right that. Suggested charter that we thought about using for a non credits was was not workable. But in response to the project charters, like one thing we want to encourage projects to do is to have more documentation about things like how maintainers are promoted how releases are handled. You know, what policies, you know, does the project sort of use all of this stuff that would sort of be in a charter document. So one of the things we want to do is to encourage projects to document and have this. And while this isn't exactly a charter. It is sort of in the same vein and spirit. So we think that if we sort of encourage projects to have stuff like this, it won't be too different from, you know, a supported project, having its own charter in the long run. Does that make sense. Yeah, I think that's from the heart. I think I get it. Not sure everybody else does but Jim did it. Yeah, so maybe the last question for me that that helped me that the need for creating this new type of project is it to allow a rather mature community to come into high pleasure but maintain their own brand. That was basically why we need this because sounds like everything is the same. Yeah, that's one thing. You know, another thing is we have, we have talked to projects that might be interested in coming into the Linux foundation. But they, you know, they don't have enough, say, you know, funding or whatever to become their own top level project. And, you know, they're they're related to blockchain, but they're not, you know, specifically blockchain right. You know, for instance, if you had a project that was, you know, exclusively focused on zero knowledge proofs, right. You know, hyper ledger might be a good home, but you might not want to market that as, you know, specific or exclusive to blockchain right because there are a lot of different other applications. So, so that's sort of the another scenario we were thinking about. In addition to the branding one which you correctly bring up as an important one. That helps. Thanks. All right, so back to the security task forces that are listed here. I didn't. I don't know who, who won the fight there was there no one hurt. Okay, although as a side note, I had a side conversation with with heart, and I think he's suffering from the same. It's like a challenge that I used to have. And, you know, I used to encourage right to speak up on the TSC calls. He felt like, oh, as a staff member it wasn't for him to speak up. And I think we have a lot more to gain from having those guys participate actively than not. And so I've been saying the same to heart, since, you know, especially he was attacked or TSC member, and we benefited from a lot of his participation over the years. And I think it'd be a shame that now because he's on the staff side, he just becomes quiet all the time. So, with that, sorry, hard to put you on the spot but I hope this way, you know, it clears things out. If anybody disagrees with me but I read, I'd be very surprised, speak up anyway. But so on this very point, if you know if it discloses what I've talked about before, which has to do with, you know, the open SSF as published best practice guide, kind of thing that describes pretty, pretty in pretty great details. And so the kind of processes open source projects should have in place the kind of documentation they should have in place to handle, you never did disclosures reports from security researchers for instance, and the process how to, how you get into the actual dialogue and documentation, the protocol you should follow to handle those reports and the security researchers who, you know, by the way are not they always they're easy to deal with. This way. And so this task force is about looking at the very specific aspect of adopting this broadly within hyperdager, making sure you know developing your policy as to what that actually means to implement this across the board for all the project to have to have that. And if there's any question about this, otherwise I can talk about the second one. Maybe at your urging, I'll jump in here Arno. So, you know, as all of you know, or many of you know Arno is heavily involved with the open SSF. And, you know, they have a lot of nice tools. One thing that we really noticed was that they didn't have, you know, a fantastic template for a vulnerability disclosure process. So what we'd like to do with the task force is to write, you know, default vulnerability disclosure processes for hyperledger projects that, you know, projects could use and maybe we have one maybe we have a couple. The idea is we would have a defaults template for vulnerability disclosure processes and says that says some, you know, and the idea is basically do this, unless you know you know what you're doing and you have good reasons to do otherwise. So, you know, I went to the open SSF working group on vulnerability disclosures. Yesterday, Arno was also there. We have this in quite the detail that they want yet, or that we want yet, or they want, and they're actually willing to work with us on this. So if we come back and say hey, you know, can you help us with this, they've already said they would say yes. And we can push whatever outputs that we have, you know, as examples to the open SSF so you know we can sort of be like the, you know, the umbrella project setting the standard. You know, for this. And you know I think this this would be a really good collaboration that could help both us and the open SSF. You know, and looking ahead. We also want to do something similar for the six store stuff which is the next topic but I'll, you know, I'll stop for now. Are there any sort of questions on this. I think we'll add on this disclosure thing that you were just talking but essentially the document they publish describes the process and tell you you need to publish your process, but they didn't go as far as actually giving your template that you can just start from to say okay this is where we're going to publish and maybe we need to make some adjustment. And that's what Paul has been talking about. Exactly. Thanks for the clarification. The last point on the security artifact signing. It has to do with this notion of, you know, a big problem that, you know, we have today is there's all sorts of artifacts and this is meant to be very inclusive but it refers to, you know, any kind of software, whether they're container images, whether they are packages, you know, like a node, the GS package or something. And we include those with that much verification as to the provenance of those packages and there is a series of tools now that are being developed to help with the process of first signing those things and then be able to verify those signatures when you're on the consumer side. And so we all produce in the hyper major projects artifacts such as container images and binaries. We should get into the process of signing all those artifacts using some of the tools that are available. They're all open source, they are free to use. There are, you know, infrastructures in place with servers that are for free to use that we can leverage for that purpose. So I think that's a kind of a low hanging fruit that we should, that is a best practice that we should definitely start doing implementing in a hyper major. Okay. Thanks. So now that we understand what all of these different past forces are, are there others that people think we missed so that we should potentially also include in our list to prioritize. I am on mute. Thank you so much. I think we should start jotting down people who are interested in the task forces, it might be a good idea. If we, you know, if we keep track of, you know, whoever's suggesting the task force might be an excellent person to lead the task force. Yeah, so I think given the timing that we have just noticing that we're about five minutes out from the end of this one. I think that we should do similar to what we did last year where we voted to express interest in these to see which ones we might address first as the different task forces that we want to focus on. And then, you know, from there. Yes, maybe the right lead is the one who initially suggested it, or somebody else wants to step up and actually lead that task force. How does that sound. Sounds like a good plan. Thank you. Okay. So my intent then would be to in the TSE channel, create a poll similar to what we did the poll for where we should put the GitHub project reports. And then before next week, I want everybody to vote. Let's say vote for your top four. And what it is that you think is the most interesting and the ones that you want to prioritize for the start of this year. I think that the other ones will revisit in the second half of the year as we move forward. So, yeah, any thoughts or comments on that. Yeah, Tracey I mean does that imply I mean when we use it for people are expressing an interest to participate in those task force as well. Yes, for sure. Because if he's just saying, yeah, yeah, you should you guys should do that, but don't count on me to do it. I, you know, we might have things that get voted high and we don't have actually enough people to do it then it's not very helpful. So, would it be more. Would this be better served as issues on the TOC repo, because we can't really comment on polls. Sure, we can definitely do that. And I thumbs up on the issue if you're interested in it. Yeah, or comment or whatever, say I would like to chair this or something. Exactly. Yeah, definitely would love to have the people stand up to be chairs. That would be great. Okay, so then I will create the issues for these. I'll send out a message to the TOC chat and ask you to vote slash comment on the ones that you want to participate in. Yeah, sorry. Since the last GF been considering creating interoperability task force. But we have other activities going on interoperability around the world including trying for having a working group under the idea so can I think about this further and add to this list later, all of this list going to be set in stone now. No, definitely. There's ever a task force that anybody thinks is something that we should focus on. We can always add those. We do have that task force process, I think, where it actually suggests creating an issue in the TOC issue tracker so that's probably a really good way to deal with that. Okay, any other comments or questions before we close out the meeting. So then with that, we will close out for today. Thank you for the discussion and the information on what each of these task forces should be in the expansion of those task forces as well. So have a great week everybody. Thank you. Bye. Thank you.