 Hey, good morning, Tracy. Welcome everybody to the June 23 hyperledger technical stirring committee call. As you are all aware, two things that we must divide by the first one is the antitrust policy notice that is currently being displayed on the screen. And the second is our code of conduct, which is linked in the agenda. All right. So, for the agenda, we have our standard announcements. The first thing here, have a ledger dev weekly developer newsletter goes out each Friday. If you have something that you would like to reach hundreds of developers, please consider leaving a comment on the wiki page that is linked in the agenda. Is there any other announcements that anybody would like to take? Okay, no announcements. Daniel, I can see you come off you but we cannot hear you. I see you raised your hand so can't hear you. Can you hear me now. Yes. Okay. So I guess my AirPods are not working. Good evening. Good afternoon everyone. Good evening. Just wanted to do a quick announcement that the agenda for hyperledgic global forum is now on the event website so you can navigate to hyperledger.org. We lost you Daniela. Yeah. Well, I think as she said, it's on the website and a link will be provided. Post taste promise. Very good. Any other announcements that anybody would like to make. So if there's no other announcements, then we do have a quarterly report that came in a couple days ago. Shortly after I sent out the agenda, the hyperledger Ursa report came out. I did only see a few people had reviewed that of this as of this morning. So, for those of you who have not reviewed it yet, please do take the opportunity to do that. There's only one question so far has gone back to the hyperledger Ursa team it's around the requirements that we have for the inclusive language statement. So we'll wait to hear back from the Ursa community. In general, I think the report is talking about the focus that they have on a security issue. I'm assuming that they're probably working on that and we'll get back to this question here around the inclusive language statement. Any other comments that anybody has on this report before we move forward in the agenda. No, but Tracy, I mean, I scroll down to the page to put the comment and realize you had put exactly what I was going to ask. You beat me to it. I noticed that most of the reports that we've been getting either say no or they actually give a link to a PR which is great so we'll hopefully get a response back like I said. Nathan. Just to add that we did discuss the comments on this document in our Ursa meeting yesterday. The project is working on the security issues first but there's this set of refactoring tasks called operation also that includes checking for any of the language and adding some of the other checks to what's going on in the system and we don't have anything that we expect would violate even any of those checks but we didn't want to say yes until we were sure that everything met with the spec. That's a great update. Anything else on the Ursa report before we move forward in the agenda. Alright, so for the agenda. We have some decisions to make the first two are around lab stewards. So in the initial proposal for hyper ledger labs, it was stated that there was an initial set of lab stewards and that anybody who wanted to become a lab store could volunteer by basically sending us a message and then having the TSC approve their their service here as a lab steward so we actually ended up getting two folks to volunteer to become a lab steward one that you are all well familiar with as he is part of the technical steering committee. He's been a really new nominated and has been working in the blockchain and the hyper ledger space for for some time. So, I had put out on this for a request to vote. But I don't think we ended up with enough votes for either to say that we could move forward with that I think we ended up with on discord five. And for Kamalash and then six yeses for a non so we have to bring this to the TSC for a vote. So, Kamalash, we have your hand up. So, Tracy, if we are just need one lab steward then I can withdraw my application. So, I don't think it's a problem to have to come up with it gets right now we have our know and myself that are very active and I've seen that then start to become active again recently with approving PR so given that we need at least two lab stewards to review and approve incoming labs. I think, I think it's fine to have to. Okay, okay. Yeah, appreciate that thought though. So, let's go ahead and have the vote for published to become a lab steward. So, I don't know. If somebody wants to, well, I'll, I guess, I'll make the nomination to somebody one a second. I will send it. All right. So, Ryan or Sean, I don't know who was the best to vote for published. I'll do it. All right. Is this a roll call vote or yes, or a voice vote. Okay, let's just do a voice for it. I think that's fun. Okay. All of those who wish to abstain from the vote. Please say so. All of those who wish to vote against the proposal before the floor. All those who wish to vote for, say aye. Aye. The motion passes by voice vote. Okay. And then the second one is non a room. I don't know if you want to say just a few words about non to allow for the rest of the committee to to learn a bit more about his role in hydrology. Sure. So, I guess I had a brief introduction of finance role in the discord channel. I mean, as part of his work, he works as a distinguished architect in Walmart within blockchain platforms team, and is based in US time zone, right, the central time zone. His, his day to day work is completely involved in blockchain technology at work and within open source technology has been a proponent of using hyper ledger technology since last five to six years, I would say, and in terms of contribution back into projects. He has been adding some of the tools and let's say utilities that are being developed, but none of them were putting to hyper ledger or hyper ledger labs itself. They're all in this personal. We have repo. However, recently or probably like about a year ago. A project was proposed that's called the channel of connectors that's now open source via hyper ledger labs. So soon there will be additional capabilities introduced and we're also looking into the other aspects to adopt some of the other projects where we go start maintaining few others. So yeah, he's pretty much involved into what's happening within my pleasure space. I felt also to increase, let's say, I am strong proponent, as I said, of bringing in more people having that responsibility distributed across so where everybody will feel that they are welcome that hyper ledger. So that's where I went ahead and proposed and and yeah, that's the brief intro in the background. All right, thanks. Any discussion that anybody wants to have here before we move to a vote. Tracy if you're saying anything we can't hear you feels like I'm living in a Verizon ad. Well thanks for speaking up because every time I'm wondering is it me or Tracy are you back. No. So if someone wants to move to conduct the vote and second it. Let's do it. Hi emotion. To move to vote for. It's an odd or Kamalash for voting for. Not. Not okay I moved to accept a nod as a lab steward, unless there's more discussion. Oh, second. Okay. Everyone who opposes say nay. Everyone who abstains say nah. Wow. Okay. Everyone in favor, say hi. Hi. The motion to approve a nod passes by voice vote and Tracy once you get your audio sorted out. Sorry about that guys. Bluetooth loves me sometimes not so much. So thank you all for moving that forward. Nathan. Just one more thing I think to say thank you to all those who've been working hard to help us as lab stewards. It's often a very thankless job that helps support the growth of our community and a lot of new innovation that's really cool. So thank you all for coming and checking out the labs and thanks to those who volunteered to be new lab stewards and those who've been keeping the lights on there and making it will work for us. All right, thanks for that. Yeah, it's, it's actually a really great place to start to bring in new people who are interesting to be in. It's interesting to see kind of the new things that people are suggesting as they come in. So, looking forward to having published and help us out in that regard. All right, so the last thing on the agenda that I have here, which I don't know is going to be a quick sort of thing is I actually took kind of the comments from last week's discussion on changing from a technical to the technical oversight committee and put together some, some suggested changes to our charter to the hyperledger charter to reflect kind of the discussion that was had. So in general, I think most of the changes here are just around changing it from TSC to TOC. So as I went through and did that. You can see the changes there. I don't think, hopefully that is too much of a challenge to get through but I think there is some specific verbiage that exists in the section where we actually talked about how the TSC is appointed. So if we could scroll down here in the in the document to where we'll see a bunch of green, red, I guess. So right in this section is where the changes have been made. And so these are the things that I want to talk about today. So I didn't see anybody coming in and actually making any other suggested changes to what is here. So hopefully, maybe I'm just pausing here and giving you guys some time to read this in case you haven't had a chance to read the changes that were made and then we can have a discussion on some of the points that I think might be potentially controversial. I'll just give you a minute here. So, hopefully, you've had a chance to kind of review the suggested changes here. One of the things that I did note in a difference between what it is that we currently have versus what is being suggested here is that, you know, the discussion reflected that we want it to have all the containers that have been active in the past year to elect a portion of the technical oversight committee. And the question that I have around that is we in the past have also included obviously contributors, people have made code changes, as well as members of the technical steering committee, the existing technical steering committee as people who could vote for the upcoming, the upcoming in the upcoming election. So my question here is we talked about changing it just to maintainers which I think is fine, which would remove the contributors but it didn't know how that impacted the feeling of the existing TSE members being able to also participate in that election. That's what I have for the TSE. Arno. Yeah, I actually had a question related to that so the way I read this now is, it's the maintainers that vote, but it's, you know, quote individuals who are active who are who can run for it. So this may be the same people but it's not necessarily the same people right. The maintainers is a much smaller set of people who hopefully are active contributors but, you know, so I didn't, I wasn't sure this is what you actually meant. Yeah, so it definitely was I know I think, you know, in Dano's proposal that he had put out. Exactly how he said it but basically it was individuals who are active within the industry scope of Hyperledger Foundation which would imply that even people who don't contribute to Hyperledger would be allowed to volunteer themselves or nominate themselves as somebody who would run for the, in this case the technical oversight committee. And that obviously is a much larger pool than the currently active maintainers for the different projects. So, yeah, it was intentional that those two pools of people were distinct and happy to, you know, discuss whether or not that's, you know, what is wanted or what was intended but I thought, based on our discussion that's where we were at. So, I mean, and, you know, I'm not opposed to this I'm trying to understand the ramification of this choice because, you know, part of the pain that the staff slash right as as felt going through the election process every year is to actually figure out what is this list of active individuals that qualify both for running and for voting. And it seems to me that. So, in this case, I mean, it simplifies figuring out who gets to vote, but in terms of who gets to be, you know, who can be nominated, it's the same. Is that right. I agree with that. And I think that it is easier to prove that you've been active in the community by pointing people in your nomination statement to links of where you've been where you have been active, right, versus, here's the list that I have to go gather in order to send emails to all of the people who need to vote. I'm obviously putting words into your mouth by but yeah that's that's how I understand that. So, I've been working on a an extraction base on the tool that Tracy provided for finding old repos. And I can get people's activity in the org, and what those activities are. The audit log for GitHub has been expanded significantly in the last, I don't know, two months. So the activities are showing up in the audit log include all the things that weren't there before, like PR comments and stuff like that so we could eventually in the future be able to say they made so many PR comments that was on this or it was on these repos and the set and the other so it's it's far easier today than it was even a month ago. So I think that makes sense actually, and I can see how this is so much easier because there are so many people really want to be nominated or to be nominated themselves. And finally, you only need to, you know, to check that they are indeed active contributors in some ways. So, yeah, the burden is much more than what we have. So that makes sense. Thank you. So I think maybe I think we should also have some kind of category where community will select the some community representative with a TSC member because here like it looks like hyper ledger is selecting the TSC for hyper ledger like maintainers from the hyper ledger governing board also hyper ledger thing. So it could become like a close, close environmental what we are thinking what hyper you're thinking, we are just driving that that thing. Maybe we can categorize like for from the hyper ledger maintainers select the four things maybe three will select the governing board, maybe remaining three will select the community via community word, and the people who are in the community members, because because actually user who are using the hyper ledger projects, what they think about the hyper ledger and what they need in the hyper ledger as a project and how they want to see the community growing. So, I think this should be one kind of another category should be added in divides like all this three could have an equal representation in that is Yeah, so come on, I know Daniel's original proposal had. What was it five individuals being elected or selected by the maintainers or that were being elected by the governing board and to that were elected from the selection of the nine individuals. What we discovered in our last meeting was that was too complex, and that people wanted to make this simpler in what they wanted to do, and they want it really just to limit it to the maintainers and the governing board to do this election. You know, when I originally started looking at bringing this back to the agenda for this week, I thought about modifying Dano's proposal to reflect kind of those changes. But in the end, given the fact that there was a lot of requests for making this simple. I decided that I would put the changes directly in the charter, which would hopefully simplify kind of the discussion points as we go through so understand your concern is. How do we make sure that the organization doesn't become somehow insular. And I don't know that I have a good answer for that one way or the other as well. Yes, thank you. I to be honest I found this paragraph a little bit ambiguous. And also I'm a bit worried about the power balance, because I guess these maintainers are the maintenance of the active projects. And if we set this active bar to law, you know maliciously this this projects, you know I work in security so I tend to think about the bad side of things. So what if they manipulate their list of maintainers to get more power at time of election. It's all depending on the way we set this active, this active threshold. So I'm a little bit worried about that part. And also, I would like to have clearly specified the as partially was before so who are the maintenance of the active projects or also other projects, and under which are the rules that govern the active, the this tag that we can define this maintenance active. I think if you scroll down just a bit, Sean on this page, there is the description right at the bottom here of what the maintainer is a little bit far up right there. Starting on the bottom of this page to the top of the next page says maintainers are contributors who have the ability to approve full request or commit code and contributions directly to a project source code repository. So the contributor may become a maintainer by a majority approval of the existing maintainers. So that is the definition of what a maintainer is in this paragraph above. And agree, right. There is the possibility then that we could gain the system by having a single project out of lunch maintainers that they expect to vote in one way or another. But that problem exists in the current setup when it has anyone who submits a wiki entry. I don't think it's a new and I think by making a maintainers reduce the attack surface for that kind of a civil attack. The civil attack is not introduced by this change heart. I'm just going to elaborate on Dano's comment. This is a problem, or this is a known issue we've had for a long time. And if you go back, you know, to the old TSE email lists, I emailed this about this, you know about the contributor list. You know probably five years ago where with a simple script, you could add, you know, easily 10,000 contributors and completely take over the election. So luckily, you know, so far no one has done this and in the past elections, we've, you know, I've explicitly pushed for the TSE to be able to throw out, or sorry, not the TSE the staff to be able to throw out what they consider fraudulent contribution efforts, which I don't think we've seen any, but but we always had that possibility. And Dano pointed out the bar for doing this for maintainers is, you know, much, much higher. So, so I agree that this is certainly an issue in theory. But I'm not sure it's something that we've, we've had to deal with in practice. And I think it would be, you know, much harder to implement practically than attacking the contributor list. You know, the number of people who can add new maintainers in the project is actually quite small. So it would be, you know, problematic from a rational perspective for people to actually do this. Thanks. All right, thanks, Hart. And if we scroll back to the major changes here, the other piece I think here is for the maintainers have been active in the past year. So I think that is an attempt to ensure that, you know, somebody is actually doing maintenance, right, of a project and maintaining that project. From the perspective of approving PRs and coming on issues and, you know, making contributions to the code itself, as it may be. I don't know that that addresses Angela, the concern, but I, you know, I do think that there is some, some verbiage to try and help that but understand, understand your concern as well. Happy to have Angela jump in front of our now to comment on that aspect. Tracy, can I say something to respond to. Yes, please. I understand the thing of the sibling attacks but are we saying now that all the projects must have a cap on the number of maintainers. So I guess there isn't right now already an imbalance between the number of maintainers between among the projects, maybe Fabric, I don't know, has 10 and the other or the others have very few. I guess that as soon as we we approve this there will be a rush on the there might be a rush in increasing the number of maintenance because that will represent more more power so to me more rational to say, okay, each project gets these amount of votes to be that can be used to elect the six people that to me seems more fair. I hear your pushback there, Angelo. This is I think linked to a large number of issues with projects that have no maintainers or no active maintainers and projects that have many people in their maintainer list who are not active. There will need to be something done there by the TSC to say the TOC say who is and isn't a, a maintainer. So, yes, that that is a concern that is a valid concern. Arnaud, sorry to make you wait. It's okay. I mean, I actually wanted to discuss further this very point. I mean, and to be fair, you know, I'm not completely sure where I stand on this issue. And this is why I initially raised my hand and I thought now it's okay. I put it down and then I was like, no, no, actually, I do want to say. Bear with me on that. But I actually think one thing we could practically do is have a common policy on how people become maintainers, how they get retired, because we don't have any consistency in this regard across the board. And I don't think putting a limit to the number makes sense because some projects are much bigger than others. And we already have that today, in fact, right. When just just by the sheer fact that I mean the simple fact that there are projects that are bigger, they have more contributors, and they will have more votes. That's just the way it's been all the time. And so I don't think it changes that you will have more maintainers naturally in bigger projects than smaller ones. If we, I mean, right last year in his proposal, he had, you know, come up with the proposal where the TSE was divided but more equally among the different projects so putting a limit to the number of votes that come from project is not completely easy, and could be, you know, considered but I think one practical thing we could do again is, is come up with the common policy on, you know, what does it take to become a maintainer in the first place. And after how much, you know, in activity or so, because you might, I mean right now it says, you know, a year, but we could have a project that say after six months if you have not been active we kick you out. And yet another one will, so it won't be fair across the board because some projects will have, you know, retired some maintainers while others have not. All right, so on that particular point. Interestingly enough, we do actually have in the trigger itself. A contributor may become a maintainer. And again scroll down just to the top of the next page. It says a contributor may become a maintainer by a majority approval of the existing maintainers. So we actually, that's part of the charter and if our projects have a different way of deciding how a contributor becomes a maintainer, they're probably going to get started today. And secondly, if you recall, Dano had that PR with the inactive maintainer policy. I can't remember Dano help me if I'm getting this wrong was it, did we go with the inactive maintainer did we go with the inactive repository as the first PR that we've ended up merging. The inactive maintainer and it's judged by GitHub actions over the past six months so if you've done nothing for six months. You are pushed down and I think there's a request for a three month extension that can only be requested once. So there is a policy it's the default policy project can overwrite it. But I'm not aware of any project right now that has a policy that is more. I'm not sure they want the default policy as a base who has one they have one for the policy. So it's kind of a legacy policy. And it's basically the same thing after six or two after two reporting periods we check on the quarterly reports, maintainers are proposed for mobile, and we haven't thought about waking up and contributing more but that didn't, you know, I have to look back at the details, some of them, some of them don't realize that they're not getting stuff counted others are like, Yeah, I'm out of here. I mean really what we would like to do is when people leave the project and get a new job on related to basic they resign. But, you know, that's that doesn't always happen which is why we need to have the, you know, in technical speak the garbage collection, where all the unused contributors are cleaned up. at fixed points. So we do have a default policy for moving maintainers to quote unquote emeritus status, which removes their maintainer privileges. All right, thanks. That was what I had recalled but I wanted to make sure. So I think to your point. We kind of do have what you're suggesting in place, whether or not we're doing anything about that at this point is another question. Maybe we just need to make sure that we're enforcing the policies that we have put in place. Yeah, and to be honest, I'm not personally concerned that people are going to necessarily try to gain the system. I think it's the kind of things. I mean I understand in Jillo's background and like, you know, he's wired to think about the worst case scenario. I think in practice, you know, I tend to to be maybe I'm naive but you know I think for the most part we have people are trying to do the right thing and then I'm trying to just screw the system so I'm happy to go with this and if we figure, okay, people are playing games here. We can always, you know, tighten the ship so to speak to say okay, we need to put extra rules protection so the system cannot be game so easy. It might be too late. Well too late I mean come on what's the end it's not the end of the world if you know one year somebody gets elected because there was a gaming and it's like, it happens in politics I believe. Nathan. First I think this, I guess echoes now what I know just said, which is we need to put on our recruiting and marketing hat. More so than our security vulnerability hat. Voting is not just a multi party computation and we're not protecting a civil attack necessarily, as long as we have enough transparency with what's going on. We can hold folks accountable as the vote goes to happen. And we can make it transparent to the elector vote folks who are electing the the TOC members so that because we can trust that the electorate want had a long term stake and what's going on. Even if someone tries to gain the system as long as it's transparent. The voting process can account for that, because we don't have an uninformed voting population. We can make the system transparent so that it has some checks and balances and could be more self correcting. The other thing I would say here is we we did very specifically say that the maintainer policy should be up to the project. And I really worry that if we get into this we're trying to protect every possible vulnerability of the election system will start to be more declarative and enforce more rules on the projects about what can and cannot happen in ways that make it more or very difficult to retain the group maintainers because we're adding all this. Things you have to worry about an overhead and politics around the policy of being a maintainer when the main focus is, you have a whole lot of work to do, and you're actually making some sacrifice to help support the community in that way. I worry that if we get into this, you know, should we shouldn't we are do you actually meet all of the requirements and make the checklist really large that will actually discourage people from doing the work that we need them to do anyway and I like the idea that the maintainer ship buys some more power in the sense that it encourages the project and hopefully the contributors to try to be a maintainer, even if they would naturally shy away from the work, because there's a little bit more incentive around it so it makes the maintainership more inclusive I think it's actually a really good thing even if it does open us up to some, you know, some projects have more maintainers than others well hopefully all projects can get more people who wants to do that work and share that burden of being a maintainer so that didn't bother me, especially because like I say if we have some transparency around the voter role, which if they're all maintainers, I think we probably could have more maintaining more transparency about who is a voter, because maintainers are publicly listed as folks who are there to help support the development process. Thanks Tracy, I'll also point out that the system with with just giving projects votes can be effectively long term gained by fragmenting a project into many smaller projects. Thus getting more votes. You know, we had this sort of in the past where you know every fabric SDK was was a top level project for instance. You know, and if we were really worried about people gaming the system, right, they could just do this they could just, you know, if it's one project one vote they could just break their project. So into many smaller projects. And I think this is, you know, this would also be, you know, really bad and we don't want to encourage this. So, you know, I think, no matter how you structure the election they're going to be issues with gaming the system. So, particularly, you know, if we do it in one of these ways. You know, it's very easy to detect when people are gaming the system. And you know I'm not sure people are willing to risk their reputations to do that. Can I jump in because of my relates to what he was saying about fabric. So fabric does have, we still have maybe like 25 repositories most of those are sub projects that get very little action, but the SDKs and chain codes are included there. So I think if we go forward with this we might want to say something like the maintainers from the core the core project repositories, because we literally have, you know, we have many, many people across all the SDK and chain code. Sub repositories and I'm not sure the intent here is to include all those people. I think the intent is include anybody who is willing to spend time being a maintainer and working on that aspect of contribution. Nathan, your hand is still up. Okay, Jim. Thank you to harp on this too much but I do feel like agreeing with on road and Nathan that I to me, I think the process of nominating and approving a maintainer from my observation of both high pleasure and other projects is a celebrated process that I think people take pride in and take it very seriously. And we should treat it as a cornerstone of the whole process where when someone becomes a maintainer. It carries a lot of weight on the recognition from the community, rather than thinking that this is opportunity for people to gain the system. I just don't feel like practically that's going to happen. That's point number one. The second is really to what what David was saying. I feel like I definitely see the sort of the importance of being a maintainer in the core project versus secondary or supporting projects. I just don't think it's necessarily that if you're maintainer on the SDK or connector, rather than the core piece of a ecosystem that your contribution should be less recognized. I guess what I'm saying is maintainers of all repositories in the in the ecosystem, whether it's fabric or firefly should all be recognized equally. Yeah, that that's everything. Thanks. Thanks. Um, So when I wrote this and I went to maintainers on the intent when I said maintainers was anybody who's in good standing and has the organizational right to push the merge button would get above and I want to echo Jim's feeling there that if if you can push the merge button no matter how small your domain is. Um, you're contributing to the project and you have responsibilities and duties and privileges that you need to, um, you know, that you need to operate it correctly. So if you have the right to push the merge button, I think you should have the right to vote on oversight matters for the project you're in. So that's that's my my take on what was intended. If projects want to limit to a subset of it we could have a discussion I wouldn't be opposed to it but the intent was that if you can push the merge button, you should be able to push the vote button. Alright, thanks Dana. Sean, can we scroll back up. So this whole conversation started, because one I think that people were just reading it to begin with but I did ask the question that has not been answered yet. Besides vain caners do we want the technical steering committee the existing technical steering committee or in the future the existing technical oversight committee to be able to also participate in the vote. Angela. To me no. Okay. I would also say no because the TSC members can talk to the governing board right and give them recommendations so the governing board could consider those recommendations from the TSC. My only worry is is. I'm sorry, go ahead. When the when the governing board has to pick folks that the only concern sometimes is, is are they closely connected enough that they have a really good candidate list. And I think what was just pointed out as long as they're talking with technical community they should be fine. Thanks. I just want to again reiterate whatever was already answered I would say no to that as well. And along with that, I had a question or probably a comment right regarding nomination process which is, I mean it's written as governing board electing remaining five individuals. Do we again want to put rules around those five individuals say that they are part of the same maintenance community or. I mean that was one of the question or another kind of restriction or for those individuals could also be a cap. Some let's say organization. So do we want to discuss those details as well. And today's call. Yeah, we definitely want to discuss everything, because my hope was to try and get this to vote which I don't think is going to happen. But the governing board electing the remaining five individuals, those five individuals would be coming from the initial set of nominees. So the intention right if you look at the kind of funnel here is you have a set of nominees. But then the maintainers select six of those, and the governing board selects from the remaining to come up with the entire technical oversight committee. So it's not that the governing board is selecting maintainers unless those maintainers decided to nominate themselves to run initially. So everything is coming from that initial pool of nominees. Happy to see if we can clarify that in this section. It as. If that would help. Yeah, I mean, if that's the intent, this should definitely be clarified because I didn't. And I was going to say, I actually like this process a little better because it's actually from just practical point of view, it's much easier to just set up and operate that way. Otherwise, you have to have yet another round of nominations just for the governing board to vote. But I thought there was another question you raise before like the TOC members do they get to vote. Yes, that's correct. And so far I've heard only nose. Yeah, but I quite frankly I think this is so I don't know like. I mean in practice, like here today, how many of us are non maintainers somewhere. Do we have people who are not maintainers. Yes. Because my point is I think that the, okay, maybe then my point is not right. I was thinking that in practice. This is the same set of people anyway but maybe that's not right. I think I think there are definitely a couple of folks on the front to see who are not maintainers today. All right, come on. So, like I also mentioned like with this process we are kind of removing the community involvement like when like you can see the price price comment in the document like maybe like governing board can do the selection of fixes like they can decide who to select because there is no kind of community involvement. I think I think this is currently even if we see the other open source communities. If we see the selection of the representative from the closed environment. And then we are not kind of encouraging the community moment, and even not hearing the word community want wants in the in the Hyperledic project and how they want to see the community bring what kind of project and what the features the community need the actual user who are building on on top of such projects. So are you suggesting in that you don't like that this is limited to just major voting. So, like maintenance like the maintenance one, or maybe like a running body like already like representing some of the companies in the board. So, they can also select the specific candidates with the like, but if community like the community people, so it's not basically like the all the DSP members would be like my community but we can also have one category like community member also like some maybe two, three representative some percentage in the in the middle. So that can be here. Otherwise, like for example, in the down line three to four, five years, what is Hyperledic building is building according to what Hyperledic thinks, not the actual user and community people who are building on it. So even what I'm thinking because the studio I had about some companies and they are thinking the same thing like I don't know what is hyperledic doing and even hyperledic is kind of. Reducing his own instead in terms of compiling complexing the project and he having a lot of number of projects and even that is so much complex like even even their manager service managing service also complex. So, if we have done the representation of the community thing and what the user thinks, then in the future it could also become more complex. We will build what we are thinking is a hyperledic project and hyperledic community, not the actual community. So I think there should be some representation from the community itself, the actual users who are limiting it. So I think the intent here is not to limit the set of nominations to only people who are currently involved in hyperledic. But people who are involved in really the blockchain ecosystem or whatever it is that hyperledic, the scope of hyperledic as it may be defined in the future. And so I think that the, the challenge obviously is that somebody new coming in who puts their name in the hat to be nominated and to hopefully come through and get elected. Has to somehow be known by both the maintainers, well either the maintainers or the people in the governing board, right. And I think that's the, that's true today. Right. If you think about kind of the election cycles that have happened for past TSC. It's been open to basically anybody who's contributed to hyperleder, which in some way will get them some initial recognition recognition but doesn't necessarily mean that everybody in the community knows them. As we have voted with the contributors of hyperledger. If you don't know anybody you're somewhat dependent on their nomination statement to determine whether or not you want to include them in the, in your vote. Right. So there's been a number of times in the past when I've voted where there are people that I don't know. Rare, but there are people who have suggested that they, you know, went to run and I've looked at their nomination and said okay who is this person what have they done. So I think that the nomination statement speak to me in some way that means that I would like to include them on the technical steering committee. So I think that that will remain true with this process I don't think that this process is changing any of that. It's just changing the people who are voting for those people. Yeah, I mean, you know, I've always been of the opinion that, you know, if anybody is interested in being on the TSE or later on the talk. I mean, I would expect them to participate. I mean these meetings are open to anybody. We don't shut down anyone. And I think it's, you know, if, if I were in that position and I come to a new community and, you know, I'm interested in this kind of role. I would already act as it's, you know, that's, it's a pretty simple thing to do to, you know, get out of the, you know, the dark and be known and so that once you nominate yourself, you're not an unknown entity. And so I think this process from that point of view already allows anybody to come in and participate and be known so that they don't have this problem that came in issues responded is talking about and by the way, the governing board includes a representative of the general membership, right, which is like everybody in the community. So there is also representation of the general community at the governing board level. Yeah, I think that's an important point, the first point that made right. If you come to the meetings, express your comments and concerns and you actually end up having a voice that people will decide whether or not they think is a good voice to direct the, the community in the future. Right. I think it's, it's not hard, right, you come to the meeting you raise your hand along with everybody else and I'll call on you. I'm not calling somebody because I am not part of the current technical steering committee. You know, this is intended to be an open discussion with anybody in the community who wants to join and participate in these conversations. Angela. Yeah, maybe last thing I was from, at least last thing from my side I was thinking we are the TSC of a block of a consortium that is about blockchain and blockchain started with the revolution of Bitcoin who solved the problem of sibling attacks over the internet. I don't see, like, a blockchain oriented solution to get the votes to decide on on on on any decision that we have to take I was thinking something like a new consensus protocol that we call it proof of contribution. And then we use this we use if we are really TSC of a blockchain project that we should come up with a protocol to solve these problems. So if I find it, if I find the solution and my my company allows me to share our share. All right, and I think that's probably going to be a project that is beyond the scope of what we have today. Just given the timing of when I expect the election to occur, but I do think it's an interesting one, and bring up a lot of thoughts for myself. So, I did see as we were discussing a lot of start of conversations that are happening inside of the actual documents where people are asking questions and responding to those questions that we obviously haven't gotten through. I think it's interesting that nobody actually had the opportunity to review this before the meeting, which means that we're not ready to make a decision on this yet. I think there is still a lot of open questions and concerns before we get to the point of making a decision. So please please please take the opportunity to continue the discussion in the documents. I specifically will not be here next week I am on the holiday. I'm going to run the meeting I know that there are already a couple of agenda items that exist. One around a presentation on the there in March, and then the second one, a room you asked to take some time from the TSE to talk about the security issues and kind of the outcomes from that test force. Happy to have this also be an agenda for for your conversations continued conversations next week. And yeah, I guess with that, I'm going to close the meeting and I will see you in two weeks and hopefully we'll have some good conversations on this document for consideration for next week and come to some sort of discussion on this particular topic. Thank you all for joining and have a great week. Have a good vacation. Thank you. Thanks have a good vacation.