 think we could get started. Great, I'm now recording. Thank you. Alright, welcome everyone. This is an open call, as I always say, public call. Anybody is welcome to join. However, you should be aware of the anti-trust policy and as well as the cut of contact, which pretty much sums up to saying you're welcome to participate as long as you're a decent human being and don't act like a jerk. Alright, so I don't think we have an agenda. I mean, any announcements per se? Do we, Silona? Not that I'm currently aware of. Okay, so does anybody have any announcement they want to insert in now? This is your chance. Otherwise, we can just keep moving along. There was one quarterly report that was submitted, HyperledgerIndy, and I think it is worth taking a moment to look into it, because I saw it has generated several threads of comments, and I know that HyperledgerIndy is going through quite significant refactoring due to the split with Ursa first and now with Aries. So maybe we should take a moment to discuss this. Nathan, you want to talk about it? Sure. I should also point out that Lynn Bendixon is on the call. He helped prepare the report. A look at the Indy report. We're kind of in a transition period with the code moving over into Aries. It's up to you guys. If you prefer Lynn to go ahead. I don't mean to ignore him, sorry. Sure. I hope everyone's had a chance to go over to read the report, so we won't bother reading through it. There are a few things to point out. One with the transition from Indy to Aries. We've had some, a lot of debate about how the SDK, that was Indy SDK, is refactored into the Aries SDK, and then the pieces that are Indy-specific remain in the Indy project as the Indy resolver. And that process has been taking more time than we expected, mostly because the commercial vendors who depend on the code base have been much more excited about building up the infrastructure on the Aries side as opposed to refactoring the SDK. So the Aries project is still largely depending on the Indy SDKs on last stable release as opposed to having finished the code reorganization and re-released an Aries SDK to depend on. We expected that would have gone a little faster, but there's still parties interested in it, so going forward it's just taking a lot longer than we expected. And the other thing that's happening on the ledger side is we kicked off quite a while ago what we call the ledger 2.0 effort, but because of all the excitement around Aries, that effort has been delayed time and time again, and we feel like we're having trouble recruiting as contributors to that ledger 2.0 effort as we expected. I know Chris raised the question in the comments of, isn't that a good opportunity for maybe some platform consolidation across Hyperledger? And I guess my comment to that is exactly. That's actually part of what we've been hoping for, but we've had a hard time getting ahold of maintainers of other frameworks to talk about things like state proofs and how the BFT algorithm we've been using works. I know that Sawtooth put some effort in on adding BFT support to their platform. We haven't really heard a lot from where fabric is on that relative to the, you know, their changes with how CAFTA does their gossip protocol and things like that. So those are conversations we're definitely interested in continuing to have, and we've got some questions around whether promoting plenum as a more of a generic framework would be valuable because it seems that it's still somewhat unique in terms of support for a BFT consensus protocol at global scale. But it's also not really the same kind of framework as Sawtooth or fabric in terms of its modularity. So that's something that we're interested in opinions and feedback on. We're also interested in any advice or suggestions about how to handle the marketing between the different projects that we support with Aries and Ursa and Indy and trying to keep the messaging between the three of them clear. I think the community is doing a pretty good job of pushing them each in their own niches where Aries has had really good success getting some cross project collaboration to happen. I think it's messaging is doing fairly well, and then Ursa as a cryptographic library is really well established as being an independent kind of thing. I think the bigger question is how to make sure that Indy doesn't get lost in that messaging as Aries and Ursa are more of the new hot thing relative to Indy, which has now been around for a while. All right, thank you. If I could add something really quick so I could interrupt. This is Lynn. I'm not sure Nathan said it. I didn't hear him say it, but I wanted to point out that right at the beginning there are mentions that there's additional contributors and 2,000 more commits this quarter. Indy is still alive and well, making lots of future enhancements and changes and fixes and it's still going strong. I decided to mention that, I think. All right, thank you. Nate, this is Chris. Do you have a specific set of requirements for a compatible ledger for Indy? The requirements are fairly basic in the sense that our transaction set is fairly small. We also, we require finality in terms of how the BFT algorithm works and we're... Well, does it have to be BFT as my question? Yeah, pretty much. Well, if you can create an algorithm that has full finality, it's okay if it's not exactly BFT, but you need to be able to look backwards in time and know that a potential state at a point and that makes it so proof of work based approaches are really difficult. I'm sorry, there was like some horns beeping or something when you were talking. You have to be able to go look backwards in the past. So let's say, you know, someone's house burned down, you want to look backwards in the past and know for sure that the insurance company and the government and everyone else who's involved in fulfilling that claim agrees on the state backwards in the past at that specific point in time. And if there's, you know, any sort of block height measurement required to know whether there was finality, it creates controversy around whether everyone agreed at the exact same point in time to the same state when you look backwards in the past. Well, so fabric has finality when you commit to a ledger. So... The other component there that's really important to us is the ability to make sure that state can be verified offline. And that's where the feature of state proofs is really important to us. And, you know, we've had some success talking with the different frameworks about the idea of being running in a BFT mode or having finality. We haven't really ever been able to get into the conversation of state proofs with any of the other frameworks yet. Nathan, have you considered... Can you hear me? Yeah, go ahead, VP. Yeah, have you considered hard stuff or any of the variants of that which are open source and which seem to have much more scalability in the BFT realm? There's about 12 different algorithms that we've evaluated. If you join the Rocket Chat channel indie ledger next, you'll find a whole bunch of folks that are having this conversation on an ongoing basis. And there are also links available to a lot of the analysis that we've done on the different platforms. We've looked at a few of the other open source communities that are working on BFT style algorithms. And we've also looked at, of course, all the different hyper ledger frameworks and tried our best to gather some of the requirements of what it is we're looking for. As we did a lot of those evaluations, we came to the conclusion that Plenum was actually a lot better than we thought it was in a lot of ways because we've already had quite a bit of production in production experience on a global scale doing BFT, which a lot of the other frameworks just aren't really interested in. They're doing BFT in controlled data centers or in isolated network environments, which means that we are subject to and suffer from a lot more corner cases and a lot more bugs that, or we've fixed a lot of bugs and corner cases that they haven't even hit and run into or addressed yet. So as we did our first round of evaluation on that, we actually came away a bit disappointed that there weren't more options for us to switch. But there must be reasons why you're searching for a different BFT algorithm, right? Well, the core reason is we'd love to get more throughput. BFT algorithms are pretty expensive. We're talking right now about the idea of dropping down from RBFT down back to an Ardbark-based approach just for performance reasons because we haven't seen a lot of leader attacks on the production network and recalculating the leader in an Ardbark algorithm is not that much more expensive than RBFT. In theory and in practice with the way Python is written, RBFT has enough of a performance penalty that it isn't really buying as much in terms of security on the types of things that it's supposed to help with. So we're considering dropping the redundant views and just using the more of a pure Ardbark-based approach on our BFT algorithm to help with scalability. But we don't want to give up offline credentials support and we don't want to give up the finality of being able to compare revocation registries across multiple issuers. So it's kind of where we're at as a result. But Nathan, I'm not sure I understand why BFT is a requirement for you given that your permission network, even though you're public, I mean, could you not work with justice towards being able to validate transaction? Well, there's a few reasons for that. First, because the network's public, anyone needs to be able to audit and verify it regardless of whether they're an issue or not. So all state must be valid. You must be able to validate all state independent of whether you're a validator node. And having that finality helps with that process, it also means that everything ends up recorded in state on the ledger. That doesn't affect the BFT nature of the system as much. The thing about the BFT nature of the system is you want to make sure that everyone can consider their own internal system, the system of record, and that the ledger is really just is the public oracle for resolution. And when you lose finality, it makes cross silo credential comparison more difficult. It's certainly possible. You can do it the same way you would with Bitcoin where you say it's not on the ledger, it's not real. But that ambiguity creates some controversy for different use cases that's easier to avoid if you don't try to address it. Right. But you're talking about losing finality. If you have a ledger that doesn't lose finality because there's no forking, I'm not sure. That's right. That's right. You equate finality. There's other practices that are possible. Okay. Because in fabric, we don't have BFT, but we do have finality. So I mean, one does not imply the other. Right. There is work on, you know, in a various outside of hyper ledger, you know, working on various sort of BFT versions of the ordering service. But again, that's why I was saying what exactly are your requirements? You're saying BFT, but what you're really saying is you need finality. You need to be able to sort of validate or, you know, to verify a value and identity. And then you mentioned something about offline validation. Right. Yeah. So you wanted to know the offline validation. What does that exactly mean? Does that written up anywhere? Yeah, I think so. There's a few documents that describe it. They're mostly described in the areas RFC for the credentials exchange protocol. The idea is that anyone can have retrieved this the state off the ledger and you can pass it peer to peer. And the peers have the ability to validate that state without having to talk to the ledger directly. So we're using the permission nature of the validator pool to make sure that clients can validate whether something's part of the current state of the ledger without having talked to the ledger directly. As far as BFT, I used to think about business team faults a lot more than I do these days. But I think the consequence in a network like the one that the indie supports would be that if you have an actor, even though it's a known actor, if that becomes corrupted intentionally or inadvertently, so it's just not following the protocol. Again, whether that's a malicious protocol violation or an inadvertent one, you risk corrupting the state across the network. So it's just that added protection that not only will the network continue to survive if some number of nodes crash, but if some of them start violating the protocol, you won't start having a broken network. We've got maybe state committed in different ways and different nodes. Yeah, and because most of the identity transactions are very read heavy and don't incur very many rights, that's really why we air very heavily on the side of safety so that you know that you own and control your own identifiers and no one can front run a duplicate identifier and you don't have any ambiguity on revocation registry state. As we're hitting use cases where people are trying to model different business cases using revocation, we're seeing people look for higher throughput in order to say, you know, I'm going to issue say a credential for prescription, a drug prescription, and I want to revoke it when that prescription is filled. Those sorts of use cases are starting to hit higher throughput revocation on the registry and that's where we're kind of looking at it going, is it worth the safety trade-offs to try to get something that's faster? I think we should stop the discussion now, but I really don't want it to stop either. So I would really, I mean, as you all know, we've been, you know, promoting the notion of convergence for years and it seems like there's an opportunity here and we should definitely continue this discussion offline so that we understand exactly what the requirements are and what the possibilities are. I mean, I think it's fair for the indie folks to say, well, you know, we don't have anything that meets our needs right now, but we should, it shouldn't be accidental, right? So we should make sure we understand the ins and outs of what's possible and so that we have a good idea of why things are the way they are. I would be remiss if I didn't mention with this that we are, we have an event in December that is the Aries Connectathon. If there's anyone who's interested in kind of how this, how the protocol works or in how their ledger relates to the protocol, that's a good forum to have an in-person discussion with the architects that are heavily involved. That's good. Maybe you could put a pointer to this in the comment or something or add this section. If you just comment to the reporter, it'll be fine so that people can find out more if they're interested. Okay, let's move on then. The two upcoming reports that I know of, Hyperledger, Borrow, and Performance and Skillability Working Group, so please get at it. They are due for next week officially, so the closer we can get to that, the better. And then so we can get into the discussion part of the meeting. Not that we didn't have one already, but it's good. I'm glad we had that discussion. So we already went through a quick debrief of the Maintainer Summit. There was an effort ongoing about gathering the different reports that the different groups have put together. A lot of them were posted live, understand on different channels, and for those who were out of the meeting, we didn't get a chance to attend the meeting. It's hard to know what happened, and so it would be nice if, at least on the page of the summit, we had pointers to the different reports. I'm not asking for people to go ahead and write full reports, but I think if we could help people find the relevant information that has been disseminated through the different channels, it would be good. And, you know, Rocket Chat does link, so all the text really is to find where the entry was and figure out the link and put it on the page, can put that in a comment, and that should do it. When I went there, I didn't see really anything you there, so I think it has not been done, so I would appreciate if everybody made an effort to do that. I don't know if there's any, anybody who wants to add to this or ask questions, otherwise, related to the maintainer assessment. Yeah, I think that people maybe shouldn't necessarily about having missed out on content that you could capture in a report, and you're careful not to make decisions and things like that. You don't leave anybody out. For me, I think a lot of the value is in sitting down with people that you normally don't have time allocated to sit down with and doing through the exercise of feeling what it's like to do a pull request on their project and do those kinds of interactions. It's kind of a live interaction. It captures well into the report. Who was the dog's barking into the back? Oh, sorry. That was Gretel. Well, it was Dan. I mean, come on. And I think Gretel has criticism about the members of it. Well, she's get some commits in and then we'll see. She didn't get a vote. Otherwise, I will add to the maintenance. I mean, Brian has heard the desire to have those maintainers submit and is committed to facilitate for those to happen, at least with some frequency higher than zero, which has been the case for the beginning of the year or most of the year, I would say. So hopefully we can make that happen. All right. So unless there's anything else to this, we can move on. So the next one is the common repository structure. So you know, I have to fall my sword on that one. Chris suggested we create a task force last week and I was like, come on, we don't need that. Let's just get to it. And then of course, nothing happened. So this is my request now. I'm like, okay, I guess we do need some task force and maybe we don't have to have a full fledged task force per se, but at least somebody's got to take the action item to try and work on it and making the discussion happen. I mean, essentially what it comes down to is, you know, somebody has to come up with a proposal and, you know, get people to comment on them, you know, beg them to comment or hit them, whatever it takes. I mean, not physically, obviously, but you know, to get the discussion going because otherwise nothing happens. So yes, Chris, you want to volunteer? Sure, sure. I'll volunteer to be the task force. Since I suggested it last week. Yes, I think it's if you talk about it, maybe you should take it. No, no, I already did my mea culpa. So that puts, you know, okay, but yeah, I mean, I'm happy, I'm happy to do that. I think, again, there's sort of two aspects of this. One is, you know, what files are expected, maybe which ones are suggested. And then I think within a couple of them, there's specific content that we may require. Yes. And so maybe we can, you know, like I said, maybe we could just, you know, get a discussion going. I'll see if I can set up a call between now and next week. Okay. I mean, whatever, you're in charge. So whatever you think, you know, is necessary to make the, to make progress, that would be good. Thank you for volunteering. Sort of. Thanks for throwing me under the bus. Unless there's anything else on this, I'm happy to move on. This was the, that was my goal of this, you know, putting this on the agenda today was to do just that. Do I just ask, Salona, I know Ry is not on. Is somebody, does somebody create a wiki spacer page for me? Or do I do that? So there is a page there. If you click on this, this is a, but this isn't really a task force or I mean, I mean, I'm happy to try and get this, you know, resolved in the next year. Yeah, yeah, yeah. So you want me to create? Yeah. Well, I think in the past, we created a task force page just so that it's clear what it is. Do we have a space for that for these kinds of things? We've, like CICD, we've created spaces, right? We have a task force space. Right here that I'm showing, that I'm showing on the screen. It's not really anything specific that we've created in the past. Chris, it's just a page that you create over here in the task force. Can we take the existing page and move it? Or maybe you could just work right off the existing page. I could create a page and link it to the other one. I want to say what minor conversation there is to mostly be talking to myself. Well, there's already discussion going on on the pending topics or TSC page, right? So maybe just hijack that page and create that sort of pages with minutes of any call you have or anything like that. That'd be my suggestion. No, I just wanted to sort of, I mean, since we sort of agreed that it's task forces. Okay. Well, create a page under task force. And link that to the common repo structure. Yeah. Okay. But do I do that or is that something that the staff has to do? You can do that. I can. Okay. That's fine. That's fine. I don't. All right. Chris, let me know if you run into anything and I'll help you straighten it out. Does anybody want to join the task force? And if they do, just hit me up on market chat or whatever. Hey, Chris, I'll help. Thanks for this. Yep. Me too. This is Dave. Dave. Okay. And I think Rai's already volunteered himself because he's contributed to the discussion as well. All right. All right. Thank you. Let's move on. So next on the agenda with decision log, and I know Tracey has been working on something there. So I think we're ready to vote. So you may have seen some of the decisions showing up having the page properties at the top status outcome minutes. So I've created a template that will automatically create a page that kind of looks like this, right? It has the page properties at the top and overview of the proposal and then kind of the formal proposal or proposals, if you will, right, that we're talking about. And then I've also created the TSC decision log on the TSC space. So if you click on the TSC decision log, at the bottom left corner in the actual page list, right there, you'll see that basically we've got a list of outstanding decisions. And then if you scroll down, you've got the closed decision. So I've gone back and I've retrofitted all of the decisions that we've made to have the page properties. And then I've also retrofitted any pending topics that we have to also have the same page properties. I only show the title and the status on the outstanding decision because obviously outcome and the minutes are not really required. And then at the very top of this, if you click on create new proposal, it will create a subpage here that basically looks like this, right? And ask you to basically put the overview of the proposal, the formal proposal, and then actually includes the reviewed by as well so that we know that there's something new coming at us that we should be looking at. So this is what I've come up with, happy to change any of the page properties if we think we need more or the format of this. But that's kind of where we're at. All right, that sounds great. The only other thing that I recommend it is that we move our closed topics and our pending topics for TSC under the TSC decision log so that everything's all together. And then the TSC decision log is basically an index of all of the outstanding or closed decisions that we've made. So that's where we're at. I think it's definitely worth it. So I think last week we ended, we were basically ready to make it formal, you know, have a formal decision on using this. And so we kind of ran out of time and then I wasn't sure everybody understood what was implied. So now that we actually see it, thank you Tracy for doing all the hard work there. And I would like to suggest we approve this decision now. Motion or? Sure, I'll make a motion. This is Dan. Second. So we can do a positive vote. Everybody is in favor, says hi. Hi. Hi. Anybody abstaining? Not hearing anyone? Anybody against this? Okay, hearing none. So this is hereby unanimously approved. Thank you. I will move the existing pages then under the TSC decision log and we'll go from there. Very good. So I think I want to insert one aspect that is related to the decision log though, which came out of some of the discussion and questions that have been raised, which has to do with the fact that obviously, I mean, we make those decisions and we've made quite a few decisions earlier this fall and we got to the life cycle for the projects, right? Project life cycle. But we don't necessarily translate that or implement this into actual documentation for anybody to find. Sometimes we do, sometimes we don't. And I mean, we're not very, I'm afraid we're not very rigorous in how we do this. And it leaves people sometimes looking for information that's not necessarily easy to find. And I mean, Silona, I think you mentioned, we had a discussion the other day about this. Do you want to say more about that? Sure. So we have documentation like the project life cycle, the project incubation exit criteria, things of that nature where we go through and we have these different defined policies that are being changed in regards to the different votes that are happening, but it's not being reflected. For example, first major release, there were some major changes, but it doesn't reflect in the documentation. And I was suggesting that perhaps we should move a lot of our governance over to GitHub. I'm not sure what's so loud in the background. I think the ones that wasn't me. Yeah, I just put them on mute. It's a number. It says 3349. But so sorry, whoever you are, you're on mute right now. But I was going to suggest having the documentation be in GitHub so that the TSC can help maintain it better through pull requests, and we can have discussions that way via doing the wiki documentation. Because right now, if my team was to maintain it, we don't really have a set approval process for this for these things to be updated correctly and maintained. All right. So I think this is, I mean, the move to GitHub is an important step. I don't know whether we want to do this or not, but I think the point about ensuring that we have an implementation of all the decisions being made that is, you know, beyond the recording of the decision itself is important. So as Silo and I was pointing out, regarding the first release, for instance, we define set of criteria that, you know, that goes way beyond what's available that you can all see on the on the screen right now. I forget the number of the issue, but it's one of the issues we just resolved the early September. And, evidently, there is a problem of responsibility as to who has to implement the decision. And maybe as importantly is, how do we keep track of what has been implemented or not? I don't know if we need to have some kind of, you know, flag or something on the decision log to say yes, and now this has been implemented in the documentation. But we need to do a better job at keeping track of this so that all the decisions that impact our processes are indeed people who are new and didn't get involved in all the discussions can still, you know, get the right information from the documentation without having to pass through through all the decisions we've made that may have modified the documentation they're looking at. Any comments on this? I think if it's possible, the decision should include the impacted references to the impacted documents, if possible. For example, the 1.0 release impacts the lifecycle document impacts Dave's document. So maybe we need that either as a comment or as part of the decision itself. Yeah. And what about this idea of moving the documentation to Github? I like that. It does, though, imply that we would take a lot of the conversation on the evolution of a change into the PR process. That's probably a good thing, but it's definitely different than what we're doing here with the commented threads. I think one way you could look at it is like the conversation in the threads and here on the TSC is a conversation about requirements and specifications. And then once that's agreed upon, then a change to what is essentially the source code for our governance, which is the documentation for how our project works, how we work, becomes just like in the requirements in a software project, an open issue leading to a pull request, leading to various plus ones and then a merge. So I think it's pretty clear that the intent and the balancing act of priorities and policies and such should still happen with the decision log that was just approved in the conversation here. And this is really just about how do we map that to how we work. Does that make sense? I think the biggest challenge, and we saw this, I think previously, is having multiple places where people have to go look is a challenge. Do they go to the Wiki for this information? Do they go to github.io for this information? Where exactly am I supposed to be looking? Because I think we've hopefully mostly trained people that they should go to the Wiki when they want information about the hyperledger in the community itself. We haven't trained them that they need to go to github.io, if you will, for looking at the governance of the project. And so that's the only concern that I have is when you have multiple places, then people don't know where they should go look. Yeah, it's a good point. And you can prune them and you can cross link obviously docs in github from the Wiki. Still train people to go to the Wiki first. The challenge is search, right? Because the search on the Wiki won't turn up links over on github. Well, I mean, we don't have to decide this today, but I think this is something people should think about. I mean, the first point, I don't think there's much to think about. We ought to implement, you know, ensure that documentation reflects the decision we've made. That's just a failure for us not to do that right now. Yeah, I mean, on the decision log one, I put a bunch of action items at the bottom to make sure that I remembered what it was that needed to be done. We could do that, right? Just add to the template and action items section where, you know, it's obviously blank to begin with, but people fill in kind of the places that need to get updated once this decision gets approved. Who has edit rights on this page, for example? I believe everybody has edit rights. It's only that note that's stopping people from doing the wrong thing. We could also roll it back to if they do so, but yes, and we do have notifications watching on that page. Yeah, I mean, I have no problem with this. This is standard wiki behavior and setup. It's like, well, the history is there to tell us if somebody is screwing with the page, we can divert it. That's it. I have no problem with that. But so I get, looking back to your suggestion, I like that Tracy, if we can add something to the template with an action, and then that can be marked as completed when it's done, I think that would already be an improvement from where we are today. Will it be assigned to who's going to be doing the changes and when? So that is an interesting question. There's the question of who is whose job it is to do, but I would hope the staff can help us there, but it doesn't have to be the staff. I'm sorry, somebody tried to speak. I was just saying, I think with the checklist items, you can add wiki user on that. So if it was going to be myself doing one of the actions or Saloma doing one of the actions, that way it's just not ambiguous. Maybe that's just a process thing that we check. Are the action items done before we think about, not done as in completed, but are they listed and do they have an owner before we actually approve the decision? There's also questions about interpretation for when things are moved over, because they typically, the way that they've been written in these pieces, they don't really kind of fit directly into the documentation as it's been created. Also, one of the things that my team tries to do are these templates. So when someone's doing a proposal or project, and we did this one quite some time ago, Tracy, you did it in November, then there was another rough draft of the form that was done in, I don't know, I think this was February, but hasn't been implemented yet, because it hasn't been approved. So do we want to create things that are forms for each of these to make it easier for people to fill out the requirements and do the different things like the versioning, the exit criteria, just as we did with the project proposals, you know, things of that nature, is that something that we have a discussion period about in regards to it and is there a process for it? Like does my team create a rough draft, and then it goes through an auditing process where everybody, that's why I was suggesting GitHub is because once we create it, what's the process going to be for the approval of it? Is it going to go through the same thing as the decision law? Well, I don't really want to over engineer this stuff either, so I'm in favor of keeping it at the adding an action item, and then maybe if we do like Tracy was saying, we review when the action items are completed, people are given a chance to review how it was implemented, and if they want to raise issues, we can look at it again, but hopefully it's not an issue and we just move forward. I would prefer that my staff and I do have a review process that's put into place in regards to it where maybe we can put the different ones up and we can put the word rough draft or something like that, and then it comes back to the TSC and then y'all can have the additional comment because I found even with implementation, there's room for discussion, and so having something where we do that and then do the rough draft and then have that go through the review process would be helpful. Okay, so we need to figure out the mechanics on how to implement that, and one possibility is to move to GitHub, so let's leave it at this for this week and people can think about this. I think one that can be a workaround is what Tracy was saying, where she was saying, have that be a thing that's assigned and a date's put on it, but at the same time understand that there's going to be one more bounce at it, which is once it's in this documentation, everyone still has to go and read it and review it and say that this version is okay. Does that make sense? Yeah, I think that's reasonable. Anyone else? If not, let's move on. I think that's does it for this week for the decision log, so let's move to the next agenda item, which is back to the TSC election. This is the last issue we have. It's basically who qualifies to participate in the TSC election, and it's both who is eligible for nomination and who gets to vote. So I think we've heard in the past that it's been a pain for the staff to figure to put the list together just because we don't have a very good grasp of contact information for all the people who participate, contributes. At the same time, there are different opinions as to who should qualify anyway. On the one end, we've been pretty relaxed about the fact that, well, yeah, somebody might just fix a coma or a period in a documentation, and if it gets committed, then they are on the list. We have added working groups, we have added a bunch of other things, so the labs I think have been suggested, which I think makes sense personally. And so Silas posted a comment saying, well, some of these commits seem to be just for that reason, basically, or maybe it's not the TSC election itself, but they just want to pump up their Github profile by adding commits, which fundamentally don't have much value. So I mean, we definitely have a whole spectrum of opinions on this. How do we come to closure? I don't know, you have yourself remarked that this is the over, you know, spreading of the electoral vote, I mean, voting population does not seem to have much effect because what we observe is 33% participation, which indicates that even if there are a lot of people gaming the system, they all don't seem to be voting, which is kind of pointless. I mean, yes, they could be gaming the Github results for their own personal profile. But that has nothing to do with whether they can vote or nominate in the TSC elections. So we may be rushing to solve a problem that doesn't exist. You had suggested this earlier, and it kind of resonates with me. I think we just make it simply a commit, and that seems to get everything, and I can't imagine there's a lot of people willing to get in commits because they really want to get a vote into who is on a steering committee in an open source project. But for, you know, if you're working on a white paper or something as a contribution at some point, that reaches a level of maturity where it should be version controlled anyway. And that can all be put in with commit that has all of the contributing author's names. And that also unburdens the working group chair from the year after the fact, trying to remember if somebody was a contributor. So I posted it in the TSC chat. There's actually a lab that has the contribute script that are used for deciding or for pulling the information from the different repos as far as who's done a commit. So there's a list of repositories that are used as well as kind of a mail map file that basically maps. So when somebody has used multiple email addresses within the year or within Hyperledger as a whole, you know, mapping to the one that they prefer, if you will. So, you know, obviously, all of this can change, but that's, that's kind of the mechanism that's used today. So now that's just shifting the deck chairs though, because now you have to maintain the mail map file. How is that version controlled? And do we do a commit hook that says, hey, your email address is new to us? Do you, you know, have you committed before? Do you need to add it to the mail map file before we let you let it code? There's, there's all kinds of stuff. Like the ultimate goal here is to be able to calculate who can vote, right? So, yeah, well, but the mail map is only required if you've used multiple emails. Or if you've used like a no reply for your GitHub address, right? Other than that, you don't need to fill in the mail map because the first, you know, email that you use it will be used, right? Because this is only to clean up all the garbage that exists from people committing on different machines or that sort of thing. I'm just saying, I'm expecting limited utility from that because there's lots and lots of these. And this would be one more hurdle that people will have to go over and they won't know about it. It's definitely something we should do. It's just not a silver bullet. What about authors? I mean, the committers can be different from authors and even in GitHub. So are you checking the committers or the authors or both? I don't remember. You'd have to look at the scripts to see what it's using. That's why it's out there is for people to look at and to comment on and make fixes if necessary. It would be whatever it's whatever it was two years ago that they that I was asked to put this out on GitHub so that people knew how we were actually pulling this stuff. So it was transparent to people. So it's been out there for a while. Yeah, I have had a look at it, Tracy. I don't remember whether it was authors or committers or both. But anyway, I'll take another look. Since you don't have to do the heavy lifting every time. Okay, but so I think, you know, I think it would be good to document. I mean, are we comfortable with saying, hey, just look into there if you want to know what we are actually or should have some documentation that says this is what we mean to select. And then that script, whatever it is, you know, is just an implementation of that. Yeah, but that goes back to the problem of whether it's just the committers or others who have contributed technical artifacts to Hyperledger. Since we have multiple ways of contributing, this doesn't cover all the ways. I know what Dan is saying, but I don't agree with it. You know, basically, we have had this discussion for a while for a reason because people are getting excluded from the list. And my contention still is that it's not people getting excluded. That is the problem that is the people who are on the list not voting also, which is a bigger problem. So it seems to me that we would make progress by already documenting what has been done, let's say at the last election. Do we have that written somewhere? I'm guessing who did that? Ry did it, right? So he's not here today. So maybe we can follow up with him and I'll be happy to take that action item, I think. And then we can look at that. That's the status quo. This is the starting point and see if we want to make any changes one way or another. So to Vipin's point, it's not so much a matter of collecting the people as much as we have all this list of 600 people and only 200 of them or whatever it is actually vote. And so what about the others? So it's been pretty consistent. Some of it is possibly due to not being able to contact them. Some of it could possibly be due to the fact that we have this in August when everybody in Europe is on vacation. Some of it is just because people really don't care. So I think we've moved the dates to September so that we can not be trying to get people to vote when they're at the beach or the lake or the mountains or whatever. And we can obviously seek to improve the ability to reach out to people. That's a continuing effort. Again, somehow or other, ideally somehow or other we would tie it to the Linux membership. But even that I think has problems with emails because you don't really I think Rai has actually said that even the Linux foundation email doesn't have to be real. But the more important thing though is the third piece and that is the people just don't care. And so I think on the one hand we probably should try and work on that to sort of so that people do care. I think we've been moving towards a little bit more technical conversation ever since the whole discussion around consolidation and various other things have come up. And I think that maybe is something that will hopefully get people more interested. Certainly there are people who were complaining about the last time. They should be interested then in the outcome. They should vote. But I do think that we could be working a little bit more. And maybe some of that is just raising awareness and maybe the timing will be what gets people to care a little bit more because they're actually not on vacation. So again, I tend to think that instead of focusing on the mechanics of are we chasing commits or are we not getting emails, let's maybe focus a little bit more on well we have 600 people and 400 of them aren't voting for some reason why. And maybe if we did some sort of a survey to find out, so you were eligible to vote, why didn't you vote? Or maybe the email is going to some spam folder and they just aren't getting them. I don't know. But I think we could focus a little bit more on why didn't they vote and that's what I'm suggesting. Yeah. Okay. So we're out of time. So I'm going to close the call on this. I will take the action to follow up with Rai to at least document what we have done for the last election. And we can follow up on this. I will point out that to me, it's very much in line with what we were talking about earlier about the implementation of the decision because we've made modification to that selection list, which I'll probably spread around in different decisions at different points in time of the TSE life. And we don't have the consolidated results of those decisions. So I think what we discussed earlier about decision implementation is very relevant to this. But with this being said, I'll respect everybody's time. And so I will close the call on this and I'll talk to you again next week. Please try to make progress offline in the meantime. Bye. Thank you for joining.