 All right, welcome everyone to the June 9th hyperledger technical student committee call. As you are probably all aware, two things that we must abide by on this call the first one is the antitrust policy notices currently being displayed on the screen. And the second is our code of conduct, which is linked in our agenda. So, for announcements today, we have 1 announcement, which is the standard 1 that we see every week, the hyperledger, the weekly developer newsletter goes out each Friday. If you have something that you would like to reach hundreds of hyperledger developers, please leave a comment on the wiki page that is linked in the agenda. Any other announcements that anybody has. All right, so if there's no other announcements, we have the hyperledger cello report. It's been on our agenda for the past 2 weeks, maybe 3 weeks. I guess 2 weeks. I checked it this morning. We still have quite a few TSE members who have yet to review that quarterly report. So please do take the opportunity to do that. And, but I will ask, I didn't see any comments, but are there any comments that anybody has on the hyperledger cello report? Okay. So if there's no comments on that, I have one item on our agenda for today. And that's this hyperledger technical student committee transition discussion document. Just as a point of reference there, we've been having discussions around whether or not we are going to or want to change the technical steering committee from a technical steering committee to a technical advisory committee or a technical oversight committee. So, as you are probably aware, and we can go to the second slide, right, that's fine. When we when we started hyperledger, we had a single source base that we were expecting to bring in. And that was to create a distributed ledger framework and code base. And since that time, we've obviously increased. I think at our maximum we had 18 projects. I think right now we have 14 projects within the hyperledger foundation. So we've changed the mission to reflect the fact that we are building more than just a single source base, but a set of source bases that are focused on platforms, libraries, tools and solutions. And so kind of with that change, if we go to the next slide. We're wondering if we have a need to evolve from the technical steering committee that we've had since we initiated hyperledger because of that mission and charter change. And then also the current technical steering committee, we're not really filling the role of typical technical steering committee. And so this leads to some confusion, it leads to some expectations maybe not being met as you join the technical steering committee and are expecting one thing but actually end up getting a different thing, which is more oversight or advisory of the entire foundation and all of the projects underneath it. So, that's kind of the, the reasoning or the thinking behind that. Also, we have in the past seen that some projects are having a very large voice within the technical steering committee and some projects are not even included in the technical steering committee. So let's move on to the next slide, Ryan. This is just a view of the governance at CNCF, which has a technical oversight committee that defines technical vision approves and removes project and sets common practices across the community. That should sound fairly familiar because it is pretty much what we do here in the hyperledger technical steering committee. Each of the projects within CNCF would have their own kind of steering committee within them. So that's the way that CNCF works. And if we look at another project, which is LF Networking, they have what's called a technical advisory council, and that council will facilitate communication and collaboration across the different technical projects. And again, each of their individual projects within LF Networking have their own technical steering committee. So if we jump to the next slide, obviously, you should all know what this is. I shouldn't have to read this. But we do have our technical steering committee that defines our vision approves and removes projects and sets common practices across the community. And I said that one from CNCF should have sounded really familiar. The actual technical steering happens within each of the projects or within a set of projects by the individual maintainers of those projects. So if we jump to the next slide, there is also that's one piece of this discussion is the name change. Do we change from being a technical steering committee to a technical oversight committee or a technical advisory council? That's that's one piece that we have to discuss. The second piece that we have to discuss is what is the makeup of this organization that we are today. So today, as you know, we're all elected by the community, the hyperledger community and the people who have contributed specifically to the projects or the working groups. And then the second question that we have to think about is, is that the right way to do to create this new, if we do decide to name it differently organization or is there a different way in which we should select kind of this group of individuals who represent this organization? So if we move to the next slide, there is kind of a proposal that's been put in place. I'm not going to read this yet because I think we have some questions that I would like to start with before we get to the details because I think there's a lot of details around how we might go about selecting this organization, assuming that we want to change what we're doing in the first place. So with that, maybe we jump to the questions. And then before I ask the questions, just general comments or thoughts before we we get into the details of questions. Yeah, the easy one to say an opinion is the name change. I think that's easy and I support it the rest of it. I'll probably have to think about and also the other people's opinions and arguments or against, which is the name change that's Okay. Thanks Peter. Anyone else have any comments at this point. I wanted to understand what is the term end user tabs shall select to me. That was in the previous slide. Okay, so within CNCF, it says the governing board shall select six technical oversight committee members, the end user technical advisory board shall elect two technical oversight committee members and the non set box project shall select one, so on and so forth. So this is a this is the organizational structure within CNCF. I don't think we've have any suggestion for creating an end user technical advisory board for seeing for hyper ledger as CNCF has. That's, I guess, you know, could be a future sort of conversation that we have but at this point, this was just language that you could see as an example of how other organizations are selecting their technical oversight committee. Thanks, Tracy. That's interesting and read about it. And we what when we put this slide deck together or when David put the slide deck together. We looked at the two biggest, the two comp projects here at LF to give examples on how other projects are managed. Nathan I apologize. Oh, no worries. That's how the project technical steering committee would work relative to a technically technical advisory council. Especially, it seems like it would acknowledge some of the core maintainer roles that have kind of happened organically over time anyway. I really wonder what it would do to some of the projects that are smaller to where that they don't really have enough maintainers to where it justifies a technical steering committee for the sub or for that particular code base. Yeah, so Nathan, I think, if we were to go to the questions you'll see that the third question is, do we need to one more slide, right. No, I didn't know this slide was here. Can we just jump to the question slide. Thank you. One of the questions was, kind of, do we even need to formally name these groups as technical steering committees for the existing projects or do we allow them to just continue the way they are in the way that they function today around the task that they do, right, developing road maps really driving the technical direction of those projects as they do today, or do we need to give them the formal name of a technical steering committee. So Nathan, I don't know if that answers your question, but there, I think you're, you're getting to the point of the fact that each of these projects that we have within Hyperledger Foundation are different in the way that they do kind of manage the project themselves from a technical direction. Well, and, you know, I couldn't say what the effects would have on fabric but it sounds to me like this is something that formalizing it would help kind of the family of fabric related projects because it would give more formal authority to that group of employees to have a discussion with all of those, those, those code bases. I also think it would help in a project that's as large as Aries, where there's lots of different sub projects that coordinate between them because formalizing the role is you're not just a maintainer you're part of this steering committee for this umbrella part of Hyperledger. That makes sense to me. How would affect a project like HRSA, where there's not very many maintainers at all and our focus is more on trying to expand the project as opposed to governing the project. Yeah, it makes sense, makes sense, Nathan. I don't think that we have an answer to that question at this point, at least not within this slide deck. I think that is probably something that we would assuming that we want to move forward with the name change and with changing kind of the technical steering committee makeup that we would have to maybe think about what we want to do when it comes to the the projects or project families as you called out. Peter, this, this is just a devolution of power to where it actually is. I mean, personally. Yeah, makes sense, right. Peter. In the case of smaller projects. I think we could just call it what it is and the set of maintainers as a project has is implicitly also the technical steering committee. Just because the number of maintainers is not big enough to need a core subset and we could also leave it up to projects to decide for themselves if they want one or not. And that way, no one would feel like you're pushing this extra chore on them unless they actually feel like it could be useful for one of those reasons that they would have liked it. Peter. Other general comments, thoughts. Maybe we should go back to the what does not change since I didn't realize that slide was there. So, in general, the responsibilities of what we're doing here in this group does not need to be changed. We're still doing the same thing. It's just a question of, should we be better named to reflect what it is that we're actually doing. And the second thing that we don't think really needs to change is the way in which projects make decisions today and how they select maintainers. None of that really needs to change when it comes to how we how we name ourselves and potentially how we organize ourselves. So I think Tracy and all, I think, I think, having a changing the name to like, TAC and TLC and technique advisory and oversight. I think it's very generic or I think don't have a great taste like technical esteem committee. So, are we going to dissolve the technical esteem committee and just changing the name or we are having a two separate kind of thing like one technical esteem committee have a different role in responsibility in creating a different TAC and TLC. Because like, for example, there are many institutions where everyone is having their advisory board. And even they don't play that matter, even I'm part of the couple of this advisory councils, but I'm not doing anything there. So, I think there should be two different things. One is the technical esteem committee like here, maybe can decide the roles in this one. And the other kind of TAC and TLC is a kind of another like other projects following. This is my thoughts. Yeah, so Kamala, I think that the general idea here is one to change the name to reflect better what it is that we're doing in this group. Since we're not necessarily stirring the technical projects themselves. The other name is the technical oversight committee, or whatever the C stands for at the point. And then the second piece right is what is what is the makeup and the makeup is more along the lines of increasing the diversity of this organization, ensuring that there are voices from each of the different groups as well as potentially making us a smaller group than what we are today. You know, initially, what was the size of the technical steering committee was it seven, nine, seven, I think it was. And then we increased it to 15 a couple years back. And so, the question is, is that too large. Have we, you know, have we lost any the service by increasing the size of the technical steering committee. And so, you know, I think in the end, these two things are grouped together, because if we're making a change for one maybe it makes sense to make the change for the other to increase diversity in the voices here. There's been no discussion as far as when this would take place. My assumption is that this takes place when the term of this group ends, which is sometime I think in the fall, September, October, I can't remember when the exact timeline is. But I think that's the intention for that. So does that answer the question how much. Yeah, so other things like suppose I think someone also mentioned about like having a TSC and the different project families. And then having this TSC and TOC is a is a is a higher level of advisory on our committee. So maybe those kind of discussion and those kind of decision need to be made, because I just kind of deducing the number of technical people and keeping the same roles and responsibility for the number of projects, because I think unlike the other other foundation projects, Hyperledger is a broader umbrella of projects to see and manage. Yeah, that's that's right. Con Lush is that Hyperledger foundation is got a number of projects underneath it, which is very different than how where it started right where it started was the intention of being a single source base a single project. And so there's been that that shift and I think that's that's what's really important. Now, you know, I think that the, the question here in my mind before we get to the details because there are a lot of details that have to be ironed out, if you will. Does anybody have any sort of objections to this do we generally agree that this is a good idea. Not changing the what this group does. But changing its name and changing it's the makeup of who is involved in this group. Yeah, I mean, I think I've raised this point previously on a proposal like this but I've been cautious about the idea that the majority of the members are basically elected by the governing board instead of from the technical community and I see that's in the slide again so I'm, I'm again cautious about that point. So that particular point. I'm really not sure about still. Yeah, Troy. So, right, if we could go to whatever this slide I think that has kind of the makeup that I did not discuss in detail. The direction sorry. The one that has all the detail. So the, yeah, you were the proposed selection makeup slide. Here we go. Thanks, right. So the the idea here right and what I didn't read each graduated project it's just like one representative. Each incubating project may select also a TC member who would have observer status but not voting rights. This would also provide that incentive for projects to move to a graduated state. And then the governing board selects some number of people. The expectation is not a large number of people, which I think is your concern here Troy. I think originally when this document was written it had to from that, but we hadn't decided whether to was the right number or not. And then the, the recommendation to ensure that no single company may have more than a certain number of members on this, this committee. The direction Troy really is to give focus to the projects and make sure that the projects all have a voice, which they do not have today, which I think is where I was getting to with the makeup when he was scrolling through the slides. If we were to actually look at the, the makeup we don't have people here from, I believe, devil. We don't have people here from Roja. Let's see what else. I guess we have me from devil room from devil so caliber cello grid transact Ursa. We don't have people from, and then we have some some folks who are part of the working groups or the chop, the regional chapters that make up kind of the current TSE representation. Troy, I don't know if that that helps. Obviously none of this has been decided and so those numbers all get to be a discussed in detail as far as what we're going to do but hopefully that helps. Yeah, I mean, maybe I missed it when you presented that slide because I was, I guess, oh you didn't okay yeah because I was keying off the, the example slides I guess from the other communities, where they seem to have a fairly large governing board of elected representations I wasn't sure if those comparisons were the proposal or or not so I guess you've clarified that. Yeah, yeah, my, my, my bad Troy for not not going into detail on that. I knew that that slide would probably bring up a whole bunch of questions and so I was somewhat avoiding it until we at least got to some sort of general. Yes, this sounds like a good idea. Before we started talking about the details. Yeah, my bad. Dave. I'll just answer your question do we think that's generally a good idea. I personally I do. So I think the objectives are good around diversity and having it be a mix of projects and maybe some folks from premier members. So I think generally it's a good idea I think the devil's in the details and I'm sure there'll be plenty of debate when we get to that. That's it for now. Thanks Dave. I agree with you. The details are going to be the sticking point right and having the sort of discussion there. Peter. I also think it's generally a good idea. In my mind it mostly hinges on the parks on the slide that are TBD specifically what I'm thinking big picture wise is what would be the ratio of the sums of elected and unlected positions. And I'm thinking we should maybe try to keep that somehow 5050 at least, or, or maybe even with a majority for the elected positions. I'm not sure if we can configure the numbers in a way that actually happens. Because there's moving parts in that like the number of projects is changing it could be more it could be less in the future. So it's not as easy as it sounds and I totally get why those numbers are just TBD for now. And then I have a question, which is in the first bullet point where we say that each project can delegate or send or whatever the word was. Each project gets to send one person. So does that mean that there will still be an election and then people can pick someone from the project maintainers or the project maintainers themselves are responsible for organizing an election themselves and then somehow figure it out. Yeah, it's a good question here. I don't know that I have a good answer for you. Right, or David. Was well did either of you have thoughts on kind of that first bullet of how do we get people from the projects to send their representative. So what is that is a decision that devolves to the projects. And I mean, my idea was probably someone from the maintainers, but I really personally want to get out of micromanaging, like exactly how people work and do things. If there's an election or the maintainers said, we're sending our senior maintainer or whatever. I'd be fine with it. David, do you have anything. No, I think we're on the same page and I think it's a best practice and open source to push whatever the phrasing is push responsibility or delegate authority to the edges and like, yeah, I was assuming the same thing that a project can make that decision and they may choose an election they may choose come up with guidelines around that but yeah my initial assumption was it was it was a project level decision. Thanks. Thank you. Yeah, thanks, Tracy sorry for my loss. I just also want to say that I agree with this. So I'm positive with this proposal I think we should definitely change the name how to better reflect what we do. And I also suggest that we should dedicate as much time as possible to discuss the details, because I think this will take a lot of time to decide on the numbers and the proportions and who is who gets the right vote vote. So, yeah, let's give a high priority to this. Alright, thanks, Angelo. Yeah, definitely I didn't, I didn't schedule any sort of task force discussion because I knew this was not going to be a quick discussion that we were going to come to any sort of resolution quickly on. So hopefully we can have some of the detailed discussions starting today and we'll continue probably next week. Um, I guess my comment probably echoes what Angela just said and that is, there's some things here that that seem really helpful like can we make groups that are smaller that are more engaged so that we can get more work done in parallel. I think that the task force work we've done recently has kind of indicated that there's room for that that will be a net benefit to hyper ledgers a whole. But there's other things here that, like others have said, making very, very uncomfortable like, how do we balance a project that has, you know, a very large number of maintainers like fabric with a project that mainly have, you know, just a couple. How do we make sure that we're not causing problems for our inclusivity, you know, because we're we're doing an open election amongst all the developers of preference choice voting I think we get a better diverse group out of the contributor base, whereas if we just say the chair of each sub projects steering committee, you know, we have a lot less options to try to get a diverse set of voices, maybe not from a project standpoint but from a perspective standpoint so it feels like we're, we're definitely playing with fire with this proposal. So we have to careful but you know I think the spirit of it is right. So I've heard a lot of people saying, I think what Nathan just said the spirit of this seems right. Are there people who have concerns that this is not the right direction to go. You know this isn't, this isn't set in stone at this point this was really to bring this to the group to ensure that if there were concerns that we listen to those and hear those so that we don't. As Nathan said, take us down a path that basically we don't want to head down. So we obviously need to be careful so any sort of objections in general to what's being talked about or any other sorts of concerns that people want to bring up at this point. Nathan. Um, it feels like there's more formality to this and I think process wise it's going to create some default decisions that are different than what we have now. I wonder if it'll make us a little less agile about adding projects to the overall greenhouse or whatever we call it now. And, you know, we should all think about what are the default choices we're making now and how that this refactoring might change the default choices because a lot of how some of the decisions have been made in the past it's kind of a. The friction of going through the process affects what what what's proposed. And this should change that friction, some ways that might change it in ways that really help us some ways it might affect, say, if one of the other blockchain projects in the enterprise blockchain says, Hey, should we do our work at Hyperledger or not. And we might not necessarily see that so, because they might just not propose that project to begin with so I think there's we've got some time to think through that and let that inform our decisions as we talk about proportional representation, how to set up a project's own technical steering committee all the things that sounds like this will make us have to formalize. And Nathan, I think, Peter, you mentioned the fact that, you know, as we add projects as projects graduate, you know, that's going to change the makeup of the voting versus the people who are, you know, just participating to have their voice voices heard for their project So I do completely agree that Nathan, some of the things that we're discussing here are going to have a greater impact right they're going to be changing the way that this group is made up of is changing the way that this group thinks about things the way that this group thinks about the decisions that they're going to make so Definitely something for us to keep an eye on as we go through the details. Troy. Yeah, that statement kind of keyed me again. If the members are coming from the projects, does that mean their responsibility is to represent the interests of that project and and more so not not just their own interest right like they're there as a representative of their project and would that be how this is represented externally. It's a good question, Troy. I mean, I think they're, each of us has motivation for why we're here. Right. And I cannot say that I understand the motivations of everyone on this group and you know why they're participating in the sorts of ways that they think and vote. And I personally have enjoyed the these sorts of conversations where you hear a number of different voices, because you start to see things that are happening in the community that you might not see otherwise. You start to hear some of the concerns that you know you hadn't thought about before it that makes you stop and think about those things. So, yeah, I don't know that I have a good response to that Troy but I do think that everybody who joins this has motivations and whether or not those motivations will be somehow different if we have people who are specifically focused on their project, you know, being sent by their project to represent that project. I don't know how that's going to change things. And so, you know, this is, this is all if anybody has ideas about how that might work. You know, understanding the motivation that you have as being part of a project and also representing on the technical steering committee I think, you know, it'd be interesting to hear those things. Yeah, I think actually it's very important to decide that particular question. When we start allocating the representation by projects right we, I actually think has to be very clear that either that is the case that because you've allocated by project that your, you are representing your project and the views of your project or, or not, because I think it's the same, or similar to what Nathan was saying right like, or, I don't know if it was Nathan, but you know that the characteristics of the pool who you're choosing from is quite different between an election among the entire community and basically saying this is composed of the projects plus, you know, a couple other types of seats right and it actually does feel like a pretty important thing to figure out from the Yeah, I agree. I agree. I think there's, there's definitely some, some thinking that needs to go behind this particular proposal. Thank you. See, so I like some of the ideas from this proposal for this having an observer group who do not participate in noting but but then we need to define the roles of that observer group because we cannot just ask somebody to come in the call and have no role in participation. So maybe they need to define those aspects and other aspect that I liked here is differentiating the technical steering versus the oversight decisions. So I know many of the times we don't end up discussing details of a project rather it should be left to the project and it boosts for each projects to either group with other projects for instance that could be a family of projects not necessarily a single project right and they may all want to work together and create their own steering committee and how they want to lead those projects what they want to see next in those group of projects. And this, this kind of work set up or this kind of setup would bring in certain certain challenges to those challenges would be. So let's say, if a TAC is going to approve a new project, and we are looking into expanding the kind of projects we have it in hyperlature, probably just moving away from having multi party systems and blockchain to all the tools that would help us and building such more and more such use cases using these projects. So that would require having an appointed members only and having no representation from white spectrum, those could be a conflict or maybe like there could be some conflict of interest coming in, when it comes to those aspects. And other aspect that I liked in the proposal is with respect to advising, I mean delegating responsibilities for each group for instance, somewhere one of the slides where I read was, there is a group that would go and suggest how much in which project should be prioritized based on the needs and necessities. I guess that was related to LF networking charter. They had a finance advisory board. I know some of the questions related to security. It deals with that. So maybe it could be governing board for hyperlature but this particular group of members they would have that responsibility to go and report or probably give their study or suggestions. So, yeah, I just wanted to add in these comments because we could delve into details. Thank you. Yeah, thanks. I do agree. I think, you know, we do have to define what these groups are, why, why they exist and what they're going to do differently if we have observers versus voting members. How do those differ? What are the expectations for those participants? And, you know, one of the things that came to my mind as you were talking about that Arun, and I'm sorry Nathan Ford jumped to your raised hand but one of the things that they come to my mind was, you know, if you're only an observer, and I think people may see it as that. Right. What is the, what's the reasoning for wanting to join and participate in the actual meetings. And I know we've had discussions earlier this year about how do we get people to feel like they want to participate more and contribute more to what this group is doing is by providing classes of people within this group. And how does that somehow stop them from, you know, wanting to participate. And so I think that's a, that's definitely a question that we should think about and something that we should, something that we should look at as we define the details behind this. So, appreciate you talking about the details and I think that's going to be key for us. I just wonder if we could write down a list of test cases or thought experiments that we should run to compare A to B on the change like will this, what will the effect of this have on a project that's dying and trying to hide the number of contributors it has. What effect will this have on a new project proposal that might compete with an existing project of hyper ledger. What effect will this have on a project that's might maybe is having a maintainers dispute. What effect will this have on whether we decide to spend money on a security audit of something that's not quite in graduate graduated state but it's a dependency of some other projects that we have to consider. So, having kind of a list of things we know have occurred in the past, or things that we hope will be better underneath this new option, so that we can each kind of walk through that thought experiment for ourselves, and have hopefully a little bit richer debate about, because I think some some of the details we've talked about, we agree with because we think well that doesn't seem like it will change it too much, where someone else in the group is thinking oh that makes a huge difference that will change exactly how all these things work. Some of these details are like, we're all imagining the best case option of the migration, and we need to get to exactly how are we selecting folks to be part of this. This committee, exactly how is the governance of a large project versus a small project going to work we need to be able to imagine that in a way we can all have a shared picture of what's going to happen there. And that's interesting, Nathan, I wonder if the responsibilities page that Arnaud had created and we approved is something that we could use as a starting point for that experiment. Here's the sorts of things that we do within this group. And how do we think that the changing the makeup of this group will impact each of those different sorts of responsibilities, not having looked at that page since we approved it. I don't know that that's a great place for us to start but it could be a something that would give us some insight into the sorts of things that we're doing here within this group. All right, Jim. Hey, thanks Tracy and sorry for being late. There was a pretty important customer call I could get out of. So my main concern with the. So first of all, I think overall on the outside, I like the overall goal of the change. I think it's much needed agree with most of the proposals my main concern is the differentiation between graduated projects versus incubating and voting versus non voting. I feel like the with the change of a primary goal should be how can we revitalize and get more participation from communities get more exciting projects into the foundation. And that should be like, looking forward to what the future holds in terms of critical technologies that need to that this space needs and I don't necessarily agree that a graduating project versus none is relevant. That's number one. So related to that, if at least personally I participate in in TSC so that you know I can participate in making changes to introduce some impact. So as a voting observer that greatly reduces my incentives to participate. So that's that's just speaking from the bottom of my heart, just just speaking truth. Yeah, so that's that's my point. I think that's an important point for us to all consider right. I, I completely agree Jim that there could be some issues that come about from having the voting versus not voting the separation between graduating incubated. I also understand why it was at it. You know from the perspective of a number of the projects that we have have been in incubation for quite some time, and therefore, you know, what's the incentive for them to move from where they're at today to graduate it right. So I can see both sides but I think for me personally and maybe leaning a bit more towards where you're at Jim, then giving that additional incentive to graduate. If I might. I see in my humble opinion. I think the next two projects to graduate are going to be, you know, firefly and cactus. The, I guess the, the, the other side of that would be to to game this out a little bit. It would be easier to stuff the TSC right instead of having. Project X, you know, a member company could split that into three projects, right, or something of that nature so they get more seats on the board seats on the TSC talk talk whatever we call it. So, one of the questions mentioned earlier is, what would observers do and I think one of the things, you know, we maybe call them liaisons, one of the values I think of having these non voting members from every project because there's been times I said, hey, what's going on project X and there's nobody on the public can answer for it. So that, you know, I think is one of the values that they provide by having a designated attendee, even if they don't vote on formal processes. So when we ask, you know, how does this policy impact that project, we actually have someone who can answer for it. So I don't think you know observers necessarily that you know you're a second class and you're, you're not as valued. I'm getting someone in here from those projects at the top would be a major improvement. Because there's a lot of projects that don't have anybody that shows up this meeting and I think we're missing important perspective from them. And as far as you know stuff in the TSC. I mean if you can get that many graduated projects. You know, it's how you know that's probably good for the community to have a lot of projects that meet the graduated standard. So that's, you know, that is a concern but I mean, how bad is it that they're growing it's the point where they can get that level of recognition is another, you know, devil's advocate on that. And I would say, you know, as far stuffing is concerned there is that recommendation that then I know in your comments you said we should make that a very strong statement, not just recommending but truly being. This is the limit sort of thing for the number of participants from a single organization so I think, you know, if we, if we think that is of concern with people or organizations trying to, you know, control this organization. Then, then, you know, having strong language there will help us. I know you still have your hand up is that additional comment or. Okay, Angela. I was puzzled by I think so if I understood correctly one issue is the size of the TSC. But now if we say that for each graduate, the project that is a seat. We are not putting a bound an upper bound on the number of members of this new of the new this new committee so if tomorrow there are 20 graduated projects will have 26 staff. Yeah, Angela, you're exactly right. There is a discrepancy between the makeup that is being suggested and the stated goal of trying to reduce the size of the TSC. Now, on the other hand, if we get to 20 graduated projects. I think that says something about this organization as a whole. And maybe at that point we talked about what we want to do with the makeup of this group, and whether or not that's 20 is too much but yeah it's it's something for us to think about right each of these data goals that we have there's ways that those data goals are not going to be met with this particular proposal. So one thing I've seen other projects do with this issue where, you know, if you're graduating project and maintaining your graduate status of it's too many. They'll say, you know, from the set of graduated projects, we will select X number like for, and it'll be between the graduated projects to decide which four groups get representation. Similarly, you know, if we were to have premier members get a seat. I'm not restricted to say so no more than three premier members the premier members will select among themselves to do it because that's some of the things that I've seen in improves the structure of other projects how they've dealt with this oversized issue. I personally would love to have the problem of 20 graduated projects and I look forward to dealing with that to be honest. To be honest all these layers that complicated I leave me Switzerland so here we have direct democracy. I mean at this point at that point, let's let's everybody vote for a set of people as we are now I mean all these layers then we have to choose subgroups of subgroups of subgroups subgroups it gets very complicated. But let's see. One of the things I liked about the proposal initially, you know one argument is that you know it should be directly representative of the members, but every year there's always a huge argument about you know what's a member who gets a vote. Why don't I get a vote why is there a contribution more significant than mine. That's, that's not good for the community. Another issue is small growing projects might get eclipsed by other large projects. And, you know, so we have underrepresented projects who are you know the growing edge of what hyper ledger should be, and because they don't have the five, six years of background in the industry, that particular project might get crowded out of the very important governments process. So, while it is complex while it does have many checks and balances. When I do like about this multi layered approach, is it to make sure that projects get appropriate representation of what they're doing. And this tack. It's not like, you know, there's there's not a lot that has to be done. A lot of the powers are ready to evolve down to the projects and this is mostly dealing with inner project and hyper ledger as a whole representation. And for those types of votes, we need representation from all aspects of the community not just representation from the largest parts of the community. This particular structure can be made to make sure that that smaller projects that are critically important, but don't necessarily have a bill dealing customers behind it can still have a say in the process and a representative and their views are addressed in the meetings. Whereas right now I really don't think we have that. Thanks. No, but how do you, how do you decide which are the small projects that are critically relevant to decide what's what's criticality here what does it mean critical. I mean, it's, you see the more the more complexity you put in the system the more you find you go into legal aspects and the words of the main the exact meaning of word. So, I'm not necessarily against what you said to be honest, I made a lot of sense but again words, the meaning of the words very complex. Okay, so. All right, so I think, you know, in general what I'm hearing is that we think this sounds like a good idea. As somebody so elegantly stated the devil is in the details. And I think we need to get to the point where we are talking about those particular details. And so what I would like to discuss as next steps is you each have a link to this slide that it is open for comments. So, maybe take the take the time in the upcoming week to add your comments to this. And think about the sorts of things that we need to expand on. Maybe, as Nathan suggest, they go through and think about the typical use cases that we deal with here in the technical steering committee, and how changing the makeup of this group would impact those particular use cases. Whether you think that's a good thing or bad thing. You know what are the risks that we have in this makeup of this group. And really just, you know, start to start to write some of this stuff down so that other people can see it in the comments and react to that and reflect on the sorts of things that are important aspects of this proposal. And then, you know, we can take in set aside next week. And I think, again, another hour for additional discussion on the details and trying to get to some place where we can, you know, put out some specifics around this particular proposal, be it the specifics about if we have observers versus voting members what do each of those different groups do. If we have a, you know, particular, this is the recommendation for how many people from, you know, premium members we want to include or this is the recommendation for the total number of people from a single organization who have a seat at this, at this table. That's the sort of thing that I think is important for us to get to that level of detail. And so, yeah, I guess please take the time to do that this week. And then we'll continue this discussion next week. Any other final comments that anybody might have before we close the meeting. Okay. Well, I appreciate the feedback in the comments so far. As I mentioned, let's add some to the document and look forward to continuing this discussion next week.