 All right, so welcome to the August 5th, 2021, TSC meeting. Looks like most of the folks here are people have been here before so you know all about our antitrust policy. That is one thing that we have to take into account during these meetings and then the second thing that we have to take into account is the code of conduct which is linked in the agenda. Of course, all are welcome to join the meeting. The first announcement is an announcement that you've seen many times over. But if you do have anything for the developer newsletter goes out on Friday, so feel free to add anything that you think is relevant for your project your lab your working group your SIG anything that might be of interest to the hyperledger developers and community. So, any other announcements that people have. And I will point out that Tracy originated the use the raise your hand button thing. So, if you want to say something, please use the raise your hand feature. All right, thanks right. I guess there is no other announcements so we'll move on to just the quarterly reports I see Sarah is here from Eroha I know that not everybody has had a chance to look at this yet. But there was one thing that Sarah brought up, or the Eroha community brought up around the assume CRS is the common repository structure is that correct Sarah. Hi, yes, so we got a little bit confused or we got, we got everything about the renaming master to main we're almost done with this apparently we just need to ask to remain the last two repos we don't have access to them we don't have permissions. But with a common repository structure I remember that someone from the hyperledger team, push something some sort of a tool about this some time ago. What was that tool and if that wasn't this exact thing. Because I think it was that ripple liner thingy. I don't remember the name correctly unfortunately I'm sorry. And this doesn't mean that we, we can just manually get and add those additional files in there. How does that work this it's a little bit confusing for me as a probably not that technical person and the team was not able to help me with this and with this tool. So if there is a way to explain to me in a very simple terms. What should we do and how it is connected to that repo tool. That will be awesome because I got a little bit confused with this. No problem. So what what we had discovered is that the repo link tool didn't work for everybody. So what we ended up doing was creating this common repository structure. I think it's, if you click on that it actually takes you to the link. I think it's in the TSE GitHub repo, which is just guidelines for actually son of wiki. We need to change where that link goes to, because we've created the, the new, the new guidelines on the TSE GitHub repository that basically tells you what the files are that are required to exist in the, in the, in the TSE. So the license, the code of conduct in the security have certain required content that has to be in there and then there's some other files that are required that are listed below and then some optional files that are kind of recommended or should. So if you go through this link, Sarah, it should tell you all of the sorts of files that you would need to have in your repository to be considered compliant with the common repository structure. So we no longer using the tool. Okay, awesome because that one was confusing. Can you please send me the link to the chatters. Okay, see. Okay, great awesome. Thank you so much. I'll look into it and yeah doing this manually might be the easiest way of doing it. Thank you. You're welcome. And then secondly, rise the repositories that they don't have permissions to is that something that you can help. I'm doing it right now. Okay, thank you. All right, any other questions and for for Sarah for the folks who've had a chance to read this me comments that people might have. If not, we can, you know, people still haven't had a chance we can leave this on next week as well for any additional comments. Sure, I'll join next week to if there are any questions or if there are any questions we can also like answer them in comments or anything I'm okay with any, any option here so yeah perfect. Thank you so much for joining. So we also have in the list of project reports that are due a report from Indian areas. So I think you were actually a week ahead of time which is great and we appreciate that. But if anybody has any contacts with the India areas team, let them know that their report is due so that we can take a look at those next week. I think there's also another one that's upcoming for next week as well so take a look at the project update calendar and see if there's anything there that you might be able to help with. Any questions on quarterly reports before we move to the discussion section to quiet morning this morning. No questions. Okay, well hopefully we'll have some good discussion in the discussion section. So the first thing is the incubation entry considerations. So I had a go at why had a listen to last week's TSE call and it sounded like what we wanted to do is kind of break up the discussion that we had into the considerations and the best practices. And then a stab at kind of putting that together at the top of the document, kind of taking what we already had and separating out into kind of considerations and best practices. I thought this would be a way that we could see if we could finalize this incubation entry considerations and so if there's any sort of comments or things that we're missing from this, this is probably the time to bring it up. Thanks a lot for putting this together. This is really nice. I think in the comments on the previous version. I had asked about having a section on community. What do you think about that. I do remember those conversations heart. Did we have anything specific in the community section that we wanted to add. Well, I guess what I posited last time. But we want people to be able to gauge whether their project is likely to be accepted. And one of the things that I've observed is that the TSC is more likely to accept a project that has maintainers or contributors with a lot of experience in the open source community. And particularly those with hyper ledger experience, then a project whose contributors are totally new to open source. And I thought maybe we would want to sort of put this somewhere. In this document, just to let people know that the TSC generally looks more favorably on projects with people with open source experience. And if not, you may want to talk to someone with more open source experience. Just something along those lines. Whether you know this document is totally binding or not. You know, that that sort of matters less to me. Compared to, you know, can people read this document and figure out if their project is going to be is likely to be accepted or not. Okay. I have an idea. Heart, I am in the process of typing something in so that we can take a look at and see if that is what you think is appropriate so the TSC is more likely to accept projects that have contributors familiar with open source practices. And that's what I've typed in. You mentioned, and even more so people who maybe have hyper ledger experience. Is that something that we want to add to this. My concern with that heart is that it may seem a bit insular. And so I'm a bit hesitant to add that clause to this but happy to hear thoughts on that. So my thought on that was that it does. I agree that it does appear to be insular. But that has been the reality of the voting process. Okay. Did you. So I was about to say the insular concern was my big concern with that even though that may be reality. If we put it in words and put it out there it's almost like putting up a big sign. No new people encouraged. And, you know, we could need to find a way to phrase it to encourage people to recognize that's what goes on at the same time still encourage them to join. So I put in some points about how hyper ledger labs is a great place to grow that experience, rather than saying if you're not in the club don't try because I mean it's it's no matter how we phrase it that's how some people are going to view it if we put any soft phrasing on that. So that's that's one risk with acknowledging that reality and writing. I like the cause and Dano I added it right if you wouldn't mind reloading and just scrolling down to the community section, which I added right be right after the maintainers. This is what I've added hyper ledger labs is a great place to grow this experience using the words that you. You mentioned there Dano. That's on on the way this is reading. I know your hand is up and I think you have a comment. Sure. Yes, thank you. So I like this. Can we also encourage people to to reach out. So, so what I, I agree with the, we don't want to appear as insular. What I was hoping is we could say that, you know, look, if you haven't been involved with hyper ledger, you know, please try to reach out with with people that are involved. So, I don't know if we could add something like that and say that, you know, hey, if you're not as familiar, you know, please, please reach out to people. I don't know how we want to phrase that. But I think something like that is good. You know, if you look at the Apache process. They have the whole champion role that is designed to help people that aren't as familiar. You know, get involved and I don't know that we need to formalize that, but maybe we could encourage people to reach out. Yeah, I know in the best practices section, the first bullet is a bit about that reach out. I don't know if that covers specifically what you're looking for heart or if we need to be stronger in the wording there. I don't know why if you wouldn't mind scrolling down to the best practices. Thank you. Before you respond as you read that heart Daniel you have a comment. Yeah, I wonder if we should rather than saying hyper ledger labs is a great place to start if we add another thing, you know, joining existing projects, not joining my joining participation in existing projects or starting new projects and hyper ledger labs is great way to develop this. So, you know, make it accessible to the existing projects as well. Participating in existing. I have added that Dano as a comment heart. I'm sorry, I think Grace is next. Thanks. First of all, thanks for seeing this looks really great and I really like those best practices down there. So, going back to the section above right even it's going up. Sorry. Thank you. So I think that when we're talking about the, you know, I would almost want to say around the community it's a nice to have like or having prior experience it is not a requirement or something like that. Because, as you said, insure, but it is a nice to have. And it's saying, or maybe saying with open source practices, regardless of hyper ledger I don't know exactly what I'm trying to get to but just trying to open that a little bit more because that's because yeah, it is true hearts crack that is how the voting practices typically go, but it's, I don't know, there are ways to just go around it and I want to just make sure we're emphasizing it. Yeah, grace I, I think that's an interesting point I know and a lot of the other in the other sections I tried to use the word should versus must. Right, because I don't think these are 100% finding, as you mentioned, right. And, you know, these are, these are considered things that we consider, and then they wouldn't necessarily stop us from accepting a project but they definitely are things that people should think about as they, as they think about bringing in a proposal these are the sorts of things that we've had, obviously, back and forth discussions on whenever we see project proposals so happy to make that a little less strong, if you will, and happy to take suggestions on how to do that heart. Yeah, I think Grace's suggestion sounds great. You know, we do want to emphasize that, you know, this is what has historically happened but you know it shouldn't stop people we don't want to. We don't want to raise a bar in people's minds about proposing projects. Do we think in the overall considerations kind of where we're introducing the considerations that where that's where we should be saying you know these are not, you know, hard and fast rules. These are things that are, are things that people consider as we look at proposals but wouldn't necessarily stop projects from, from being accepted. Yes, so I think that's exactly what I had in mind when, when, when we started this document. You know, it's not a, it's not a rubric, it's sort of a guide. And, you know, if you sort of the, the idea is that if you meet all of the considerations then you're probably very likely to be accepted. If you meet few of the considerations, you're not very likely to be accepted and if you're somewhere in the middle well, you know, it's, it's hard to say right. But I think that's a great idea to add the point that these are not all necessarily hard and fast things. They're just guidelines that should allow people to gauge whether their project is likely to be accepted or not. And I think you've worded that better than I did. But I agree with your intent. All right. So when it brings up the reload, see if I captured this correctly. Bobby. Hi, I would just like to see a comment maybe directing people to the learning materials working group if you're new to hyper ledger because every two weeks at our call we teach people about the community. Okay, I think that's a good best practice to add Bobby. All right. And Bobby is the learnings material. Sorry. I know I got it wrong. Is the, how do we say this the materials development working group is, is it doesn't meet every other week and that's what you go through or does it. Yes, yes, we start with introducing people to the community, the working groups, the projects, how to get information on all that stuff. And we go from there, depending on who's on the call. Okay. Sorry, I'm typing and not looking at whose hands are up at the moment. And the wiki does support, you know, multiple people editing. So if someone, you know, also want to edit. No hands up. Did anybody have a thought on the introduction to the considerations about the hard and fast rules. I loved what I wrote. Bobby, I don't know if this captures that third bullet point under best practices captures what you have intended. If not, feel free to wordsmith that as you will. That's perfect. Okay. All right, other thoughts on what we have here are we feeling pretty good about this at the moment. I think both of us in chat. Should we ask people to reach out on the TSC mailing list in the community architects mailing list. I think either is, or I think both is fine or the TSC list is fine. Are we. Okay, so I specifically removed TSC Arun from the first bullet point and said existing chat channels mailing list or direct communication with members of the community. This may be my my desire to have people reach out to more than just the TSC. If they're, if their project might overlap with an existing project or their project might, you know, add to something that already exists out there. I think the, the first place I'd love them to start right is with that project or with that lab and not directly with the TSC and so I think that's why I was a bit suspect there and removing that from the which mailing list or which chat channel. Yeah, thanks for bringing up that good point I guess I agree what you're trying to I mean what you're intending to say over there. However, I want some place where it is must in addition to these optional places. So by making it too wide or to scope, but this we never know where a particular discussion happens, which is fine to discuss outside but it's some like we should somebody should know where to look for some new proposals coming up instead of monitoring all these channels. Okay. Are we talking about so in the proposal process we do have the. I think we have a call out to send to the TSC mailing list so are we talking about when the proposal is being formalized or prior to it being formalized. When it is being formalized. So I think that's already in the process, and I tried not to duplicate what was already documented in the process in this document. At the top I do link to the proposal process so hopefully that would tell people that they need to do that if that's not in our proposal process and I agree Arun we probably do need to fix that. So it's the, I'll just read out what is written on the HIV process. Over there it's written as the seed of new project has to be weighted in a public forum like TSC mailing list. It does not mandate TSC mailing list it says like the TSC mailing list. So we probably should then get the proposal process updated to reflect that when you are ready to formalize the proposal to send it to the TSC mailing list because I agree right that's the right place to to formalize the request. And I know, well, I think that's another I've said that I'm thinking about the fact that before we used to do everything via Google Docs, which did proposals via Google Docs and with Firefly we just started using the GitHub repo which obviously all of us should be following the hyperledger hips repo to see pull requests that are coming in. So I think obviously the TSC mailing list is a good place to point out that you have a pull request, but I do think that the hips hyperledger hips repo is the formal place for these now. But we should definitely update the process because I don't think we've updated the process to reflect that. Okay, we will take that as an action item. Let's put together something for that. Let me take a note that I just volunteered to do something. All right, any other comments on this document then. All right, so if there's no further comments, I think we can then move on to our next agenda topic. All right, so our next agenda topic is kind of in preparation for the next TSC election. So I had captured here in the agenda all of our past decisions. I know Rai has a proposal that he would like to share with us. So I'm going to hand this the floor over to Rai for him to talk about that and then we can discuss. Thank you, Tracy. So this is a very rough sketch of what I would propose the hyperledger TSC transform into. And that is something closer to what LFPH does and LFN, which is the central governing board, you know, the TSC, the TAC is appointed in this way where each premier member gets a seat. I suppose that each top level graduated project gets a seat. The working groups in the six each get a seat. And that the how those seats are filled is delegated to the people or those groups so those can be through several elections or however those groups want to report who sits in that chair. And then the chair and co-chair would be elected as before. This would result in, you know, a movie a sea change, but it would be somewhat back to the way it was originally. The original TSC was appointed. And I'm not married to any of this. The goal is to have a deterministic process for getting a TSC seated with more representation from the projects. This also gives an incentive for projects to to reach graduated status. And I'm this, I put it to you. Please send arrows in my direction. Yeah, that's people. Any ideas about what this looks like any reactions, negative, positive. Arun. Hey, I want to first understand what this fell by ways ideas ago meant like what came to your mind why you wanted like that. And apart from that, I guess I have many other questions on this proposal, including, for example, what are we considering top level graduated projects as are they at the DLT level and are we not considering other projects because given that hyperledger is going to change the charter definition, there will be not just the DLT projects but other than that, we are going to consider other projects, but even at present we do have other projects as well. So, yes, I mean, I'll go one by one, sorry. I'll answer your first question. The charter says the charter for hyperledger says that the goal the mission is to create and enterprise grade open source DLT and code base. That never happened. That that was discarded. That idea of having one single DLT was discarded, not on quite day two, but maybe day four or five of hyperledger and the charter has not been updated to reflect that. And that's why I say it fell by the wayside years ago, because we, we are not trying to create a single DLT. Troy. Hold on before before before Troy. The second question was around the top level graduated projects, getting one seat, and that would be any graduated project not just DLT graduated projects but any, any graduated project that we have so right now we have six of them. And that would obviously add additional seats as we graduate new projects. So, hopefully that ruined that answers both of your questions. Troy, you're next. I guess a few thoughts. One concern would be, I think this could end up turning in one vote that we have now into many votes. The top level graduated projects might be a simpler problem but having all working groups and all SIGs all get together and decide seems like you're going to end up with a vote again. And, you know, I'm not sure on the motivation for the premier member point. That seems more like at the governing level than at a technical steering committee. So I'm not sure what that point is is actually in this list right now. Thank you. So I'll answer your your last question first. I was using LFPH and other projects as a model. So that's why it's there. And if you look at our list of premier members. Most of them already are represented on the current TSC. And then your, your first question was. Sorry. It was around the process of how do you get SIGs working groups and to kind of figure out who that one person is that they're going to submit for the SIG or the working group chair. Right. Right. So I wanted to make sure that SIGs and working groups continue to have. I wanted to have SIGs and working groups have a more formal voice. So this was my idea. You're saying it will turn into another election. I'm sure that it will. But that would be an election that would be for the SIGs and working groups. You know, we can point them at oppa vote and say vote how you will, we can enable voting in the groups.io. I just, that's not something that I want to run. Sorry, I wasn't sure if I should raise my hand again. Well, I guess the point here is because you're going across groups, you're just going to end up with another vote. So I'm not sure, you know, I had very mixed feelings about this because on the technical side I do think it's nice to elect and I'm kind of leery of appointments of, you know, premier members sending whoever they feel like. And I think when you go across groups like working groups and SIGs get one total instead of one each. I think you just got back into a vote again. I'm not sure that this will accomplish the goals, what I'm saying. And I'm leery about appointments. All right. But while I saw a hand, I don't know if that was a raise hand. The TSC means the technical steering committee, it should focus on the technology side. So I'm really concerned with giving, sadly giving each primary member a seat. Because they already got a seat in the governing board, right. I would prefer if we give more seats to those projects or those members who contribute to the most code. That should be, that would be better from a TSC side. Thanks. Anybody else have any thoughts. Thanks. Yeah, as far as the technical stuff to, as far as that goes. The TSC really do a lot of technical governance. I mean, I know that was the intent in the beginning, but it seems more to me like it's the TSC has sort of become a some kind of community management entity. Like when was the last time the TSC made a technical decision. So Hart, the comment there is about. What is, is in kind of direct conflict with what Val Wow said, is that what I'm getting? I want to make sure I understand. No, I mean, I, I wouldn't say it's in direct conflict. Wrong words. No, no, no, it's, yeah, it's totally fine. It's just that, you know, we don't appear to be making a lot of technical decisions. That's all. Okay. So the premier members. Yeah, that there's, I think just because a premier member doesn't mean they're going to point people who don't know anything about technical stuff to the committee. I think they're aware of what the committee's purposes are and who they would appoint. So I don't feel the same apprehension about letting tech premier members appoint one of the seats. And the odds are they're going to pick a very technical person in a project they care about who's involved in the project. And maybe we could write that in to the encouragement if this goes through. But I think that was the first thing in second, I'm concerned if we use metrics like whoever's committed the most lines. If we make it an external metric like that that is easily gameable. I'll just commit all the Ethereum reference tests and boom, my line commits are just amazing. So my concern of making it a technical measured number. We just move electioneering to a different area. Maybe. I have a lot of concerns with the way this is structured. For the identity projects we have a lot of contributors but I don't think we have very many premier members though a lot of them remember premier members have become involved over time. And, you know, I don't know what this will do the representation of the technical community itself. The elections, although they're imperfect at least they reflect kind of the general commit level of the code. And, you know, I know we've had a lot of debate and discussion around how you could gain the voting system. But for the most part, my understanding was most of that was academic, meaning we actually haven't seen electioneering or, you know, a lot of shenanigans occur at the at the ground ground level. So, you know, I have a lot of concerns about whether this will affect the ability of the technical steering committee to remain neutral, and to also kind of act as a counterbalance balance to the governing board which already does reflect a lot of the things are a lot of the qualities that are listed in this new proposal. I know you still have your hand up or. Okay, thank you. Other comments, anybody has. All right, I'm going to add my two cents here. So, I, I'm torn. I think there's some good stuff in here I think there's some things that will have to figure out if we go forward with this. One of the things I think we have to figure out is. I don't think for number three we can leave it up to them. I think there has to be at least guidelines or something that we put together for how that vote would work and what that might look like. I think that the other thing that is potentially a concern is I know currently the get contributors that we do not only can includes the projects but also includes the labs as people who are eligible voters as well as eligible people to to bring on to the TSC. I don't see that piece of the community included in here. Things that I do like I like the fact that we are attempting to get more of the projects involved. I don't. Well, I know we do not have people on the TSC today who are part of all of our graduated projects, let alone our incubated projects. I like the fact that we're trying to get more people from all of the projects across the board included in this. I also like the fact that we're trying to get the SIGs involved. My initial thought and that was well SIGs aren't part of the TSC but I do think that going back to our breaking down the silos conversation that with the conversation with the SIG chairs is something that is quite interesting and intriguing. So I like trying to bring more of the community into these conversations and having representation. But yeah, a couple of a couple of concerns, a couple of things that I like about it. Thanks. And as I said, I'm not married to any of this. I mean, I could see you're right. Not having labs on here was an oversight. I could certainly, you know, add something, you know, add a seat for labs, but there's, I agree. Thank you. Daniela. Yeah, I just want to make a comment because our no is not here and he's usually the representative for the TSC on the board that this was not prompted by any board discussion in regards to the seats by the premier members. So I just want to make that very clear to everybody. Thanks Daniel. You're welcome. Heart. Yeah. So I guess one comment is I know that the TSC election is one of the like worst possible things to run. And it causes a lot of a lot of, shall we say pain and suffering for the LF staff. What I'm worried about and what I think, I believe it was Troy who brought this up is that, you know, right now you're stuck wanting running one election. How do you know you're not going to get stuck also running the like working group, SIGs and labs elections as well right, or even the, the top level graduated projects right how are they going to vote on who gets that seat right, you know, presumably it's going to have to be some voting process. And, and, you know, what if each, each project decides to do something else, you know, it could get really messy. So I'm a little worried that this might actually end up that the way the proposal is stated right now might end up being more work for the LF staff, rather than less. Thanks heart. Dana. One of the questions brought up earlier is what does the TSC do what is the technical and I think one, what observation I think that needs to be made is that the governing board is not a public meeting. While they may release notes we don't know who's with the back and forth is like what the tone of the meeting is versus the TSC where I mean recording this and we're putting us on Wikipedia for the basically the world to see. There might be one subconscious thing that we're driving towards is maybe there's a desire for more open governance, and maybe having the TSC be open like this could fill that people's need for the field that there's open governance on this. So that's, that's one thought that crossed my mind that I thought was worth surfacing. No reelection item on it yet. Thanks channel, Nathan. I'm confident that this would cause a lot more work for the Linux foundation staff, even if we as maintainers ran the elections the controversy that it's created every time we've had the election would spill over to the Linux foundation staff to manage and it would probably have already boiled over by the time it gets to the staff, which would make it a lot more tense situation it would make. It would make it a lot more difficult to manage. And to Dano's point if we're really trying to push towards more open governance, we should open the governance board. Rather than try to change the nature of the TSC to where we lose the TSC, and I would also push on all of us if we're really not happy with the administrative nature of our agenda, we need to put better things on the agenda. And it says we can't do more technical architecture work that we can't work harder towards unifying the platform to be an open source distributed ledger framework like the paragraph above says, I think the truth of it is we're probably doing the best things that we can do and these governance points that is rather tedious is one of the best ways we help support the maintainers and take a substantial load off their plates so that they can make good code progress. So, you know, in terms of how we're serving the community. I think a lot of the things that we're dissatisfied with are the things that we have to do in order to take the burden off of others. So, you know, overall I'm not very satisfied with this proposal, though I do like the idea of pushing the SIGs and pushing even the labs to be more represented on the TSC. And I do like the idea of having more seats available on the TSC in general because I think it will help the number of voices that we get to hear and I think it will help balance some of the election problems we've had where some projects have a lot more votes than others. But there's, because there's simply a lot bigger projects. All right, thanks Nathan. Part. Hey, yes, thanks. So, first of all, to address both Dano's and Nathan's comments, I really agree with Dano that the, the TSC is sort of the open governance arm of the governing board. My opinion is that if the governing board is the CEO, the TSC has sort of turned into the COO rather than the CTO. And, you know, I would be all for encouraging more open governance from the governing board. And I think a lot of the decisions that potentially probably should have been made by the governing board. A lot of these decisions have been made by the TSC. So, you know, sort of big things like directions of the project. Like, for instance, when Bessie joined while I certainly supported that, I thought that probably should have been like a governing board decision rather than a TSC decision. You know, things like that, like changing the charter, why is the TSC editing the charter not the charter not the governing board. Well, I would talk a lot more about this if this call or not being recorded but that's another story. With respect to Nathan, yes, for the entire history of the TSC we have tried to push back into doing more technical things and we seem to have continually failed. So if you have any advice or suggestions on how we can be better about that and find good meaningful technical work to do. That would be amazing. All right, thanks Hart. And thanks for my morning laugh. Other other comments that people have we've got some folks on the call who haven't had a chance to speak up yet. Feel free to now is your chance. I can't believe that Gary is silent on an election item. You have the floor. I'm going to say enough, just because you addressed me I was just going to say, I mean, I think enough's been said, I don't have any, anything, any genius comments today. This is David I'll agree with some of the other earlier comments that it seems like this would turn from one problem into many smaller problems, they may not be, you know, they might we might seem they might seem like like they're smaller but they might actually be more work for the staff team. Right, thanks Dave. Other comments people have. Alright so I'm right I guess I'm going to leave the feedback with you. You know, I am not quite sure where we want to take this it sounds like there's pieces of this that people like in pieces that a good number of pieces that people don't like. I think we're probably not in a position to say everybody's 100% happy with this. Sure thing. My expectation was not to come out of this meeting with a decision or everybody 100% happy with things. I want to have a discussion about how we could make the TSC. It's a page title right. It's a proposal for reforming the hyper literature TSC. So that's, that's why I want to get out of it. This discussion. So, thank you all. Alright, thanks for that. Yeah, if there's other comments, you know, feel free to to have those in the TC chat or with right directly if there's something that you think would be worthwhile to to move forward. Grace. One question. You're probably trying to wrap. So, thanks. I agree. Just want to say that with the spirit of inclusion and adding more projects, also some drawbacks just echoing everyone else's comments. But does it make sense for the TSC to be voting on how the TSC is going to change the government board decision like heart was kind of suggesting what what's is this more a board decision. Do we know it's probably a good question. That is the sign that we went through with the expansion. And the way that happened last time was the TSC asked the governing board to make a change and the governing board made that change. So we can make suggestions to the governing board and they can decide what the right steps are. It definitely is part of the charter so it would have to be something that the governing board would approve. Or or disprove disapprove. What's the right word. Decline maybe heart your next. Yeah, grace. I totally agree with you. This is something that ideally the governing board would be doing. But this kind of thing has been sort of continue over the history of hyper ledger this thing has sort of been continually pushed down to the TSC. So you get the TSC doing a lot of things that the governing board, you would think would do, but doesn't end up doing. Thanks heart. Any other comments, we still have a couple minutes before we at the top of the hour so if there's anything else hurt I'm going to assume your hand is just still raised. I didn't want to say anything else I'm sorry I forgot. That's fine. All right, so if there's no further comments. I think we can close the meeting. Thank you all for attending and thank you for the lively discussion and the input. Thanks Tracy.