 All right, welcome to the March 17th TSC call. Happy St. Patrick's Day for those of you who settled rate. As you are all aware, I've been to this call before and probably many other hyperledger calls, but there's two things that we must abide by. The first one is the anti trust policy notice that is currently displayed on the screen. And the second is the code of conduct, which is linked in our agenda. Don't be a jerk. So with that, we'll hop to the announcements. So the first one is one that we talk about every week, the Dev Weekly developer newsletter goes out tomorrow. If there's something that you want to add to that, please leave a comment on the wiki page that is linked in the agenda. The second announcement is the CFP is now open for the hyperledger global forum. And that CFP closes on April 29th. So if you have any talks that you would like to give at the global forum, please submit those at the link that is provided here on the, the agenda. Are there any other announcements that anybody has? Seeing no hands, I will take that as no. So the first thing that we have are quarterly reports. We did get the hyperledger firefly report in on Tuesday. And I have seen that there are some of us that have had the opportunity to review that, but not everybody has had a chance to review that. There is some conversation that is ongoing in the, in the reports. I will apologize for not being up to date on those. It's been an early morning for me with the time chain. So I guess the, the first thing that we have is related to getting more people interested in becoming maintainers. And there's a discussion ongoing there around that. Is there anything that anybody has as far as suggestions for the firefly folks as far as other ways that they've had good luck in getting people interested in being long-term maintainers on the projects. No additional suggestions other than that. Nathan. Being a maintainer is a lot of work. So I'm less worried about whether or not. All the maintainers are from one organization and more worried about when all the maintainers, maintainers are from one organization. It's easy to miss communications details. And make it hard for anyone else to kind of get in the door. Or it can create a situation where pull requests have a lot of friction to external contributors. So I think part of the, one of the questions that it's kind of underlying this thread is not just how can we make it more friendly for an external maintainer or how can we help you get an external maintainer? But. Is there any way we can help measure. Kind of if some of this invisible friction might be happening. Yeah. I think that's a really good question. Yeah. Hi to see. So actually I also commented in the report section. I actually, when this one point zero release cams on that time also should come with some details about the. Usability in the production deployment of the. Firefly because. In the user adoption perspective. It depends like how, how much production deployment of the particular. Framework is and. And how people are adopting it. I think like, like, like this is a, only Clidio is a maintainers of the project. So. Kind of getting the. Maintainers and contributor. Other across different. Organizations. This is important to be. To be. Project as a, as a wide adoption. I know that if I finalize a very good. A concept and kind of multi-party system. Because. Is complete. Not just only blockchain. There are multiple components and systems are there. And is. Is good. But I think when we come to this is stable or. LTS kind of release. In the future. We should also come up with this. Details. About the. Production deployment. In the. Customers. That's. Yeah. Come on. I think, you know, if we look at. The funnel. Right. It starts with people using. The projects. To determining that they need to contribute. Because there's either a feature missing that they want. Add it to it or there's a bug that they need fixed. And so they jump into contribute. And then those contributors are. What end up being maintainers in the long run, right? So it's obviously is a funnel. And. Yeah, come on. I think, you know, if we look at the funnel, right? So it's obviously is a funnel and starting with the users is a. There's a place that we can think about how we get more people interested in the project as a whole. Arun. Thanks, Tracy. I see firefly as a beneficial project in multiple fronts. And there is an idea that probably firefly team can apply or probably try out. This has been work. I mean, this has worked for. The last group at least as a, as I see. The approach would be that we, so the way the reasonaries group has been so successful is so that each repository or each. Framework that they build in different languages is kind of independent and independently maintained by different organizations and what features they keep adding could would follow a spec. But it goes in its own phase, right? So firefly being a project that has similar features, not, I'm not saying through, I mean, technically the same features. I'm talking in terms of how wide a spectrum it covers. So there are components that deal with different blockchains protocols. And then there are components that are more generic in nature and how they deal with providing some of the capabilities. So if firefly team can focus on those aspects, maybe they would be people who are interested in those individual components and they would jump in and maintaining those individual parts at least. So that way there is more contribution coming in. And then probably eventually they will realize there are some aspects that they, they can get involved in the core as well. And that way they can grow further. So yeah, that's my thought. All right, thanks, Arun. So Niko, I see you've joined us and I appreciate you joining us today. Questions or comments on kind of what you've heard? Yeah, thank you. I appreciate all the questions and the thoughts and the feedback. It's helpful. And I, yeah, I agree that it's a funnel and, you know, I think David Boswell and I have had many conversations about how that that it is indeed a funnel and trying to grow that funnel at the start and getting more people to use firefly. We have, we're working on a workshop coming up next month to try to get more people just familiar with how to use it. So, and Arun, I like your suggestion as well of like having having maintainers of some of the like firefly has a lot of features and it's a micro-service architecture. And it was actually designed that way intentionally so that the barrier to entry for being able to contribute additional pieces to it would be lower so that folks don't have to understand all of the detail of how the core itself works in order to make a contribution to one of the, you know, connectors or other pieces. So yeah, that's a great thought as well. Yeah, I appreciate the thoughts and the feedback. I know this was a topic on the last report. So I want to do at least comment on it. I know it takes time and I just, yeah, the, I think the, the reasoning for the extra comments that I added on this report was just to emphasize the fact that like it's something that the firefly community is acutely aware of and something that we want to keep working on, but also recognizing that it does take time. Yeah, definitely Bobby. I just have to speak to the project we did with Firefly with the giving chain. And I think the reason why none of the people moved from using the project to maintainers is they were through the mentorship program and they were all students. So students are looking for permanent jobs, not, you know, being able to maintain it. So that I think was possibly a disconnect that maybe in the future we could try to figure out how to solve that. So we've seen not just through the mentorship program too, but through a lot of other connections that we've made students discover the project and say, Hey, this is really cool. I want to make this as my first open source contribution. And they make a contribution, which is great. But then they move on and, you know, they've, they've been able to now put on their resume that I've made contributions to open source projects and it's great for them. But like I said, it doesn't bring that kind of long term consistent contribution that we're hoping for someday. And Joe. Yeah, thank you, Tracy. I must admit, I always, I would, I want to say something generic, not related to Firefly. And I always thought about this tension between the fact that most of the projects in hyper ledger, they are backed by companies with a clear strategy. So maintainers is more than just, just putting in a few, some contribution. It's also someone who has an impact on the strategy, the directions of the project. So it's something deeper. And I'm wondering what it means. How can someone externally to the main company that is behind the project jumping this through can be true also for fabric. So please don't. It's not something that is only for Firefly, but for many projects in hyper ledger where there is a strong company behind. I see that there is a tension. I don't know. I must admit, I don't know how to resolve this, this tension. I think, I think there's definitely a tension there that we see across all of our projects. So not just Firefly. As you mentioned, Angelo and, you know, I think if we, if we kind of go back to that, that final idea is very possible that as we get more organizations that are using the project, they become more interested in helping to, to guide the strategic direction of the project. And then obviously becoming maintainers as well. It's, you know, it's probably not the, the answer, the complete answer, but it is probably part of the answer. Come wish. So what Angelo saying, I think, I think everyone will be agree because even like, whatever the projects we have, there are not a kind of mixed majority of the different contributors, whether it's a fabric or like Firefly or whatever, like even Aries Indy. And I think, like, suppose you take an example of Kubernetes, like open source project in the foundation, Kubernetes diversity in the kind of contribution, whether it's a Google product or Google contribution, but I think maybe it will take time that much reach that level, like one project or project having more than 50% diversity in the contributions, maybe down the line four to five years, I believe. But I think that is very important to be successful of any open source project to be, I think not just the hyper ledger, but it was when we take a, can talk about the like, it's emulated projects like consensus forum or other thing. This is also company driven projects. Yeah. Thanks. Thanks, Kamlesh. All right. With that, Jim. Thanks, Tracy. Just want to add one more aspect. I think in general, we observe that people get confused of what Firefly does, how it fits into the picture. We often get questions of, can you tell us how Firefly compares to fabric to, to pursue your questions like that? You know, for other projects bevel, that's for infrastructure cactus interop, very clear, very clear labels that, you know, get people to understand what those projects do. We need like a easy to understand label like that. I think we were using, we were experimenting with multi-party systems. Don't know if that's being effective. Honestly, we probably need to think about another marketing term to give Firefly so people understand what it is. I'm sure the marketing team may have ideas, but we should talk about that in the future. Yeah, I would agree with you, Jim. I think how do we, how do we get people to understand why you would use Firefly, when you would use Firefly. Those are the important pieces to help other people to really see the benefit. Angela. Yeah, I think what, I found very interesting this comment and I want to report something that I found also a bit strange from my point of view. I saw a blog post with Cactus Weaver and Firefly and there was a table in this blog kind of comparing the three things and that was a table where Firefly was sticking more green lights and to myself I was asking, Firefly is not an interoperability tool. So why is there, and first why sticking more so it looks like Firefly is better than Cactus and Weaver, but they seem to be a bit different beasts. Probably I misunderstood the blog post, but that blog post at least misled me. Yeah, Jim. Yeah, I think that's part of the problem with Firefly because it sits on top of the ledgers. So architecturally it does fit in where the interop components do and it does address a lot of the requirements in the same concerns with interop. And because it does so many things, it's hard to give it a concise label like interop or infrastructure. I think that's part of the struggle we're in. All right. So definitely some good commentary I think here on Firefly. I'd like to move us on in the discussion topics so that we can reach all of our topics today. Just FYI for the TSC, the Ursa report did come in. I saw it show up in my inbox for us to have a review. So please remember that that's out there waiting for you to take a look at. And then as far as the discussion topics go, the first thing that I wanted to do, I know the mentorship project selection task force was created last week. And I know we have a short turnaround as far as the, as far as when we have to have the mentorship project selected. So I wanted to see if we could get a quick update from the folks who are in that selection task force to see how it's going. If there's any help that is required. I think that was Angelo, Peter. I can't remember the other two people who volunteered. Yes. Go ahead, Angelo. Oh, no, sorry, sorry. I thought that was a mute. I was saying that, yeah, sorry. Yeah, so any updates? Angelo, Dano, Kamlesh, Peter. So I didn't come this year. I mean, I said some kind of reference last time, reference point, how we will do this last time. And she just asked the confirmation whether this process is correct or not. And then we all, I think we'll see the flight to that main and we agreed like this, we can follow that process. And then now we mean we'll create the, that particular evolution sheet for the mentorship projects. Okay. So you guys do have a way forward and path forward. Yeah. Great. Angela. Yeah, just to say that I saw many, many amazing proposals. So I really appreciate all the, and I want to really thank all the, the contributors of the proposals. Some are very great. Very good. Good to hear. All right. So I'm glad that you guys have a direction forward. I wanted just to check in there quickly and make sure that there was nothing that we could do to help out with that, but I just wanted to make sure that you guys, let you guys continue with that process and hopefully come back to us here shortly with your recommendations so that we can take this forward. All right. The next topic on the agenda is the hyper led your documentation style guide. So this is a topic that Daniel brought up in the chat. I think it was. Yeah. There's a question that exists in the, the basic contributors meeting where they, they wanted to understand kind of what the, what the hyper ledger recommendations are as far as. As far as. Guidelines around how we do documentation at hyper ledger. Is there anything that we have in place for style guides? I'm thinking to a bunch of different style guides across say Microsoft and consensus and probably some others within the, the basic documentation for how they do documentation. So then I wanted to kind of have this conversation. And then I think the second piece of this is also the discussion that we started last week with the grid. Hyper ledger.org. And whether or not we want consistency in that. So I, I probably massacred your, your request, but if there's something else that we should add to the description of what this is, please. No, I think you've got most of the core of it. There's about at least three threads coming up related to documentation. And it seems like there's a lot more of these questions coming up for documentation, such as style. You know, for example, including the EI statements in there or how and where should we do that? Do we link to external styles? Should we have a consistent style of documentation for each individual project? Or should we have all the projects or let each individual project do the wrong thing? And the reason I wanted to discuss this in this group was because Bobby's raising her hand and I wanted to see what her opinion was on this. I just know that from a documentation perspective, we had received at the learning materials working group, some documents from the marketing committee. So on the homepage right upfront, there's a hyper ledger style master template, which is applied as to what hyper ledger uses for their style. It's not a build your documentation style guide. I know we have the beginnings of that somewhere else like what format we should use to create documentation in that way, but that'll get you a head start as to what hyper ledger has put out publicly as the style master template. And it's just a link to a Google drive. I'll put it in the chat. If you have to ask where that link is on the front page with a chat link would be great. I think, I think those templates are mostly for presentations that we would do within hyper ledger. So I think, Dan, oh, you're talking more about the read the doc sites or whatever the documentation site is, is the user guides and the developer guides and the contributor guides and those sorts of things. Is that right now? Right, that was more like good presentations and outward focus things are one thing, but when people come in and look at how to use the projects, what the standard should we go to use the doc? Should we load it on the weekie? Should we load some stuff in the weekie? Should we use a weekie docs inside of GitHub? Those are some of the, do we want to standardize those things? Do we want each projects the freedom to do their own thing? Is more the scope of the question I was looking for rather than use questioning whether we use active or passive descriptions when talking about configuration options. I think we don't need to go into that level of description, but I think some of a higher level infrastructure experience, how do you come in and experience the document might be some of the more valuable things and projects might be happy having different entry points. That's an option too. All right, Arun, I'm going to skip you for a moment because I want to see if Bobby has feedback on the conversation that we're currently having before we move on. We also have on the learning materials working group, a best practice page, which basically gives the start of what we're talking about for all the different standards for use cases, white papers, webinars, courses and chapters, that whole thing. It is not complete because our numbers have diminished at the learning materials working group, but it would be something that I would be interested in pursuing to get that down and get that something the community can use. Thanks, Bobby. Thanks, Tracy. I just wanted to understand more the reason why this kind of question is coming up. Let's say we have multiple projects. It's difficult for us to standardize across all different kinds of projects, how the documentation should be structured around, or probably what we can help through or what we can think through is, hey, does this documentation cover a way for somebody to go back to, let's say, search for other options at Hyperledger or probably understand what Hyperledger is and how far can we get involved in what does the mission and vision statement for each of the project. We can define these kinds of things as opposed to defining the structure around the project documentation itself. I think it's kind of abstract for me still to think through anything for this proposal. Yeah, so I think if I had to, if I had to take a stab at this, right, kind of off the top of my head, I would think about the different sorts of recommendations we would want to make guidelines, if you will, for the sorts of things that we should include in our documentation, the same way as we have guidelines for what we should include in the repo structure, right? So we say we should include RAIDME and the maintainers and the contributing and those sorts of things. I think we could do a very similar sort of things with recommendations for what I think we would want to include in each of the different documents, be them, you know, the inclusive language guidelines that we provided, you know, thinking about the different audiences that might exist as we would want them to be able to come in and experience our projects from a documentation perspective from people who are using the projects to people who want to develop within the projects to people, you know, who even want to become a maintainer, right? I know in the fabric documentation there's stuff about the steps that it takes to become a maintainer and I think even the basic one has information about what it takes to become a maintainer. So this was things that I was looking at actually when we were, when I was reviewing the Firefly report and thinking about that. So I know I ran across those in our different projects. So I think, you know, you know, correct me if I'm wrong, but I mean, I think that would be the start and then I don't know if there's other things that you would expect to see as far as guidelines or recommendations for, for what we would include in documentation. Right, I think that's anything beyond that starts getting into how technical it's steering, when does steering become direction? I think, yeah, the high level stuff just standard places to enter, standard things to expect. I think would be a good start. Does the Learning Materials Working Group have a regular meeting? Maybe I should call in there to get a feel for what's going on there. Yes, we meet every other Monday at 1 p.m. It's on the calendar. Okay. And I put the link to the, I put the link to the template guide in the discord. Okay, thanks. And Bobby the time zone 1 p.m. Eastern daylight time. Thank you. Okay. So. Other thoughts on, on whether or not this makes sense. If we want to continue down this road, if we want to see about building on what the Learning Materials Working Group already has in place. I'm thinking I'm going to call the Learning Materials Group and invite anybody else interested to call in this next Monday. I'm going to call the Learning Materials Group. Okay. They seem to have a lot of their hands around what needs to be done already and have a good understanding of what the gaps and what the needs may be. So. Okay. Well, the next topic is brainstorming and creation of task forces. Do we think this requires a task force? That we should add in our add a choice. Box. Yeah. Or do we think that Learning Materials. Okay. Perfect. I will leave it up to you guys then to. To drive that forward. And, and definitely come back to the TSE. Right. We think you have something that is, is worthwhile. I think we can definitely put this out on TSE. Hyperledger.org as a guideline. Similar to some of the other guidelines that we have. Okay. Good. All right, then. Yeah, the next, the next topic is brainstorming some creation of task forces. So. In the last meeting, I think I heard loud and clear. We think that task forces are, are maybe the, the right way to do the right way to get people involved. And participating in things that they're interested in. And then really driving forward a particular work product as, as those task forces meet and. Do a specific task and then come back to the TSE with their recommendations and how they would like to move something forward. So hopefully I heard that right. I felt like you guys are screaming at me that that's what you want it. So if I didn't hear that right. Let's, let's have that discussion first before we move forward. Okay. Okay. Yeah. I'm sorry. I'm sorry. I'm sorry. No one's screaming at me the opposite way. So. I'll take it that I did hear that right. The. So I think the first step that I want to take here is really just. Doing some brainstorming, right? I tried to capture some of the things that I heard in the last meeting, which you can see in this checklist below. Around documenting the TSE responsibilities. So I think that's one of the things that I think is important. Is that it's important to think about the public blockchain ecosystem. I don't think that came up during a call, but they come up in a conversation that I had immediately following the call. And it's maybe a bit more on the technical steering side, if you will, right? Thinking about what projects we might be missing. Within the hyper ledger ecosystem that we should think about how we bring into hyper ledger. But I think that it's important that we have a very specific approach to this. To go through our project. It's more up offline. And it is more technical in focus. And then. Other pieces here are things that we've had on the agenda before, but I think maybe just require us to go off and. Have very dedicated time focused to. Project help dashboards that we can work with the. That we've been talking about at least in. Well, I think for a while, but also directly in one of the meetings that we had this past month. So with that, I'm going to see if we have any other ideas for task forces that people might be interested in starting as we as we move forward. He's looked like a good start to me. Okay. All right, so if that's the case, then we do actually have a poll that we can maybe do some voting on and see where we end up with what people think are the top ones that we should focus on. Daniela before we go there. Yeah, I just wanted to just highlight a couple of things. And it doesn't mean that we need to add these task force today to the discussion, but recently the diversity and inclusion working group had you know they've been having conversations over the last few months in regards to taking more of a task based approach to DCI initiatives under the TSC. So, Lindsay knew on who had been serving as the chair for the DCI working group actually posted a note earlier this morning on on that list. But obviously it's a, you know, it was a little bit a couple hours before the start of the TSC so I would anticipate that future task forces will be, you know, brought forward specific to DCI initiatives. So I just want to let everybody know that. Yes, Daniela. I did see that email come in. And I do see that Lindsay's on the call. So Lindsay welcome to the call. Is there any sort of task force that you know immediately off the bat that the DCI working group would like to start up as they think about moving more towards this task force model. Yeah, I'm sorry about that. Thank you so much Daniela for bridging the gap there. I know that there were two task forces that were proposed by the group, as we talked about the shift to this model. One was led by Peter obviously the Lent project and that is finished now. The second one was more around partnerships and engagement. That is a really key element to making sure that we continue to, you know, try to rope in different groups proactively, and not just kind of waiting for people to come into the fold in the community. I heard somebody mentioned earlier, also that you know, one of the goals that some of the other, you know, projects share is making sure that we try to hit those, you know, hit those marks to improve the diversity within the projects and I think that maybe in lieu of creating a completely, you know, different task force just to focus on partnerships. We think about how to work with each of the other task force to create an environment that's, you know, sort of a right for folks to come and contribute who might not have been in the communities that are already present. Yeah, and I, I seem to recall discussion around also is trying to bring diversity inclusion and civility back to the TSE right from the perspective of let's not have this so far removed from how we think about this on a day to day basis and putting it in a working group but thinking more of it from, you know, how do we make sure that this is a focus area? It's not something that is often a group that nobody joins or doesn't participate in so I think this is definitely something that we can consider. Do we think the partnerships and engagements for DCI is something that we want to add to the poll before we start kind of voting? Yeah, I would definitely like to see that added. I think it's an important. Yeah, let me do that. I think one of the things that maybe had been thrown out early but it was just kind of a seedling of an idea. What was mentioned it actually was that in the same spirit of just sort of looking across the ecosystem to see where the benchmarks were that other people had around this area that maybe we should go and start there to see, you know, if we're putting the right goals if we're setting clear and attainable sort of benchmarks for people to strive for. So, I think that might be a bit more of a, you know, conversation to continue rather than something to, you know, put in a working group at this time, but I definitely would love ideas on if the TSE has already maybe started to think about that or if other people maybe had any interest or activity there as well already. Yeah, I don't think we have any specific goals that we've set other than what has come out of the DCI working group. I do think that that is something that, you know, we should continue that conversation on. Perfect. That's totally something I think that a lot of the folks who were consistent attendees would love to do I think the core of what we had all hope is that we would be a resource and a support system to folks so that we weren't supposed to be the expert at all but that we were working to be a resource to each of the different projects. So, yeah, we definitely love to continue that conversation to figure out how we, how we do that in a better way going forward. So, so the list of potential task process we listed this TSE planning to create this task forces or we need to vote to select one off from the list. I'm not sure I understand the question. Are you saying we're, I guess. I'm saying I'm saying I'm saying I suppose we listed documentaries to a certain piece of technology project health gap analysis. So all these are potential workforces are going to be created, or we need to have to select one of the task force, which you have to create from this question. Okay, yeah, so I think the plan was that we would basically run this as a poll to see where people's interest were, maybe see what the top priority was amongst the TSE. And maybe, maybe there's multiple, right. It doesn't have to just be one that we we start sooner rather than later as as we move forward, right, so that people can can start to participate in my mind. I'm kind of wondering, and this is just a thought and it cannot. It doesn't have to be right but if we say let's say we ended up with three task forces that we thought were immediately important that we were going to go off and and attack. If you will. Then maybe we changed the TSE call to be a monthly call and the other weeks are used for running the task force calls. You know, for the other three weeks of the month if you will. So I don't know if that's going to work. It really does depend on the TSE and what the TSE is interested in doing. But it was a thought about, you know, is there a better way to to make sure that people are getting involved and having the time on their calendar to actually be involved since we all have this calendar calendar slot blast, if you will, and then move forward from there so keep that mind I guess maybe as we think about this but it really is, let's see where your interest lies more than anything. And, and if we have enough interest in a particular task force and maybe that's the task force we kick off, or the set of task forces that we kick off. Okay, okay. Jim. Thanks, Tracy. I have a specific question on the second bullet analysis. I don't know if that's the right time to ask now or later. Yes, definitely. Yeah, I feel like the debate between, you know, permission chain or public chain is over. I feel like most customer landed where both have its places. Can we broaden this to what, what can hyperledger do to to encourage the integration between public chain and permission chain. There are many repeatable patterns. There are things like this, not just what can we do to make permission chain better so we can compete with the public more favorably, which I felt is what the current wording is meant to say. Yeah, I don't think that's what I meant to say there, Jim. I appreciate you asking that question because I do think it's, it's a good one, right, to try and understand what these task forces are as we, as we decide that we're interested in them. What I was thinking about is this lends itself to if you've actually been with following the TSC for a while. There was a proposal I think that Dan Middleton had put out about, you know, what are other projects that we should be considering bringing into hyperledger. I think I use this as a gap analysis between, you know, maybe the public blockchain ecosystem because it was something we could compare to. Not that we are better or worse or that it's an either or sort of question but are there things in that space that we should be thinking about that we're not currently thinking about because this hasn't occurred to us that we should be. So, to me, I'm thinking more about when I think about this, what are the projects that we're missing within hyperledger. So happy to reword that if it helps as people are trying to think about the task forces that they would be interested in. And that is just a link for everybody's reference because I think it would be helpful to just have a top of mind is what the, you know, current process is for the creation or sort of dissolution of working, I'm sorry, task, task forces. And if we're going to put a little bit more structure around that, if it's a voting system or whatever or if we're changing that completely and proposing something new just curious about that as well. So, you broke up right at the beginning, I didn't hear you. So, I think the question is around what are these task forces or did I not get that right. No, I'm sorry, my connection is horrible. My question was around the creation, the process for for task forces. Is it going to be, you know, kind of informal going forward where people just propose and then you vote in a sort of ad hoc way, or is there going to be, you know, more structure to the process. Yeah, so we actually do have Lindsay a task force guide that we had put out. This is sort of outside of that guide, if you will. But I will put this in the TC meeting thread on discord. It's a link to kind of when this question had come up before around, how do you propose a task force with the approval process, how do we report on completion of the deliverables how do we request an extension on the completion date. So, while these task forces here are more coming out of the meeting that we had last week of, you know, we think we can do things better if we start to work with task forces more than trying to participate in these TSC meetings as such. And I don't know that, you know, we've necessarily come to any sort of agreements on how these task forces will run, as far as like what their timelines are what this, what the actual work products are. I think to me I wanted to just see if these were interesting task forces that the TSC was interested in, and looking at or if, you know, we were, I was going down the wrong path, more than anything. I think that helps. Yeah, that definitely helps quite a bit. Yeah, just your market for further discussion pretty much. But thank you so much for that. Appreciate it. Yeah, no problem. Any other questions. Kind of these task forces, what they mean. Jim, I did this hasn't refreshed on the screen but I have updated the poll to reflect a change in that second one to more. I'm going to say what projects are we missing within Hyperledger. So, hopefully, yeah, thanks for whoever did the refresh. You can see kind of the current set. My plan is at this point to take five minutes and have you log into Confluence to a poll that I'm going to put in the chat and have you guys fill it out to see which one kind of shows up as a, as one that you guys are interested in participating in. Also, you guys are all on Discord. And we copy my link again because I think I'll end up copying the TSC one if I don't copy again. And have a look at the link that I just put under the 317 22 TSC meeting chat. Let me know if you guys can't find it and I'll make sure you guys can see that in one way or another. So, from here, you should be able to log into Confluence. Click on whichever ones you're interested in. And in the end, we'll see a chart come up to see which ones float to the top. I know. I want to go back to the scheduling aspect because I was, you know, I really like the idea, you went a bit too far in saying maybe we only have the TSC call once a month and use the slot for the task forces. But, you know, maybe it's not, you know, we don't drastically cut down to once a month but maybe we're using the same slot without being just maybe you could skip every, maybe every other every, you know, every three calls to make room for the task forces. I think it does have an impact because I'm sure others feel the same I'm like, oh man yet another call to fit into my schedule. It's much harder and in fact, I would think that it's hard to tell. I mean, for the sake of the exercise we can put aside the scheduling aspect and just answer based on pure interest, but I suspect the answer in practice would be different based on whether it is within existing time slots that already blocked by the TSC or if it's something that's going to be added yet to the agenda. You know what I mean. Yeah, I do. I do. And I think that's really for us to decide what works best for everyone. You know, I think, I think we've been trying with our task forces to do this as a separate call, which I don't know if that has helped us or or not. But I, you know, definitely would like to have that discussion and see what we do and where it is that we spend some time here. The other comment I would make on this is, you know, my experience I've been spending quite a few task forces over the years, and the most successful ones are those that have a fairly narrow scope where you are very achievable goals within a limited time frame. Yes, once things start to be a bit more vague as to what the end goal is, then you quickly lose attention and it's hard to keep people motivated and calling in all the time. I completely agree. And I hope these are all very small in their, what their work scope is and not huge. As we look at them, if that's not the case, then let's break them down even further if we need to. All right, I see that we have at least five people who voted. We have more at this point. If you haven't had an opportunity yet or you don't know where to find it. Let me know. Happy to send out the link you can also click on the which task force would be, would you be interested in participating directly from the agenda link. Sorry, I think there's a one, one task force idea about the public blockchain where is it and not wanted to open it. Yeah, so it became the what projects are we missing within hyper ledger, so that we weren't comparing directly to the public block chains. Okay. Yeah. No problem. Maybe, maybe if you're done with doing the poll. I'll ask you to raise your hand in zoom, so that we know that we're not waiting on anybody. Bobby. This is not a good time to want to say something though. Yeah, I know. Other folks need some help. Finding the link or even I know you voted. So your hand is probably up as well. So I think we can use the checkbox instead the checkmark. Yeah, that's what I just did. That way if somebody wants to pick up, they can raise their hands. So, this is a good. So I think we have the projects are missing within hyper ledger seems to have the most votes here, followed by the project families website revamp and the document the TSC responsibilities, followed by the project health dashboards. So there's four, I've got more than one vote each. I didn't realize I could click on that to show who had voted I was trying to figure out a way. All right, so, yeah, I think, just in the last couple minutes here. I'd like to, I'd like to see if we can kick things off. So, maybe I'm asking at least for a volunteer to chair. The task forces that are the first four. If you have anybody would like to speak up for the what projects are we missing within hyper ledger. Bobby, is that a hand that you fill out or a hand that you want to volunteer or hand them a question. Okay. Before sorry. No, no, it's all good. Any, any volunteers for the what projects are missing within hyper ledger. Come lush. Yeah, I would love to be what you did. All right, so. I think, you know, maybe the question is back to the timing issue. Do we want to try and set things up as separate meetings or do we want to set them up as meetings that run in line with the TSC calls. I think you see calm. Since we have for we could, you know, have the first half hour. The first week is one, the second half hours, the other, and then the TSC meets every three weeks. You could also start, you know, the beginning for a more general announcements or, you know, items on the table and then do breakouts. These are all good ideas. You brought your hand up. Yeah, I just wanted to speak up on this part. It's been hard to recruit people on the task force itself. And there are definitely people who would be interested who will join every time there is a task force meeting called for, but I guess reusing TSC meeting is probably going to benefit us. And I mean, that's a committed time and we could potentially ask more people to join and see, let them see what we as a TSC do. Okay, so we're at the top of the hour. Let me take as an action item to write out a few options, maybe have us think about those options and respond back on the TSC mailing list to which option you think works best. As we move forward. So, apologize for running along today guys. I will get that email out and hopefully we can get started on these task forces as we move forward. So thank you for joining today. See you guys Tracy. Thank you everybody.