 I think let's get started to start the recording, please. Recording started floor is yours. All right, thank you, Ray. Welcome, everyone. This is the TSC weekly call. It is a public meeting open to everyone to join and contribute. However, you need to be aware of our anti-trust policy notice, which is currently displayed on the screen if you're looking at the Zoom window. Otherwise, it is linked from the agenda. I request that you make yourself familiar with this if you're not already. The mark has the wrong dial-in number. Is there a problem with the calendar that's going on? Is the why mark has the wrong dial-in number? Yeah, the calendar is messed up. Well, is Dave on the call? Maybe he can give us another date as to what the real number is. Can I have one of my invites, because I've got four. So don't go away. I mean, this is kind of ridiculous, that the calendar's integration is still so crappy in 2000. OK, hold on, guys. Sorry, I just wanted to sit there and say why mark wasn't on, because I saw him in the TSC chat. But you're on now, Mark. Did you get on, Mark? Mark is on. Yeah, I know he's on. Wagner? I don't see him. Yeah, he was on the chat. Hold on. So I posted the thingy for Mark. Thanks. OK, so I'm just saying, we have one more person joining. It's just he got lost. Yes, thank you. So as I was saying, we also have a code of conduct that you need to be familiar with to basically request that you be here. So without further ado, I would like to proceed with the agenda. First, I want to make an announcement. Next week, we won't have a call, because it's actually US Thanksgiving. So I expect quite a few of our TSC members to be busy with family matters. And so we will skip next week, which, given the agenda, I think we're going to afford anyway. So as I was saying earlier, I don't know. Does anybody else have any other announcements they want to make? OK, hearing none, we can move forward. So as I was saying, there were three quarterly reposts that I do. Mark Ford just published the Hyperledger grid. I didn't have a chance to look at it. I don't know when you posted it, Mark. I posted it yesterday afternoon. OK, I didn't get the chance to see it. Yeah, I would have liked to have posted up a little bit earlier, but I was waiting for some feedback for involved parties. So I went up a lot, 430 a lot, on yesterday's central standard time. So one thing that could help in the future is I saw that in your report, you're missing the reviews section with the names of the TSC members. When you put that in, we actually get notified by mail and other things. Oh, I didn't know how that works. My apologies. I'll make sure that's done for future ones. It's all right. You know the checkbox thing? And so you can do that by just copy pasting from another one. You know, I think I remember I did do that for one of the sawtooth ones. And I just missed that step. So I apologize to everybody on the phone. It's OK. It happens. But so in the future, you know, if you do this, it actually notifies us, which makes it easier to know there's this thing for us to review. I think we have a template for that that automatically does that. I'll have to check and make sure that that's true. You know, I think that happened when I put the transact one up, where it just when I posted it, it got put in. And maybe that's why I didn't do that for this one. But I think it depends. What happens typically is we add things to templates, but then people copy paste and hold the one in which it wasn't. And it doesn't catch up with the latest template. So then you don't get it. Would it be helpful if I just do a quick scan of the updates since it was posted a little bit late yesterday and see if anybody has a question? I guess you, I mean, if there's anything you want to highlight specifically, otherwise I'd rather wait. We can go back to this next on the next call. Oh, that's totally OK. I don't want to take every time. No, it's just I think it's we have a better discussion when people are at a chance to look at the report beforehand. So I'd rather we postpone the going through the reports, including grid one, even though you published it. We can do that on the next call. I'll carry over those three items in the call for the call in two weeks. All right, I'm good. Thank you. All right, thank you. All right, then so you can see from the agenda, it looks very familiar to what we had last week. We were a bit rushed at the end. And we didn't have a chance to finish the discussion. Plus we had some disruption thanks to Zoom. So I felt like it would be fair to put those back on the agenda and have a bit more time so we can more calmly discuss this. I don't really want to rehash what we said last week. Let's start with Bezu, which is what we ended up on last week. I think the main item that was conveyed by several people, including me, was this notion of the lack of diversity in contributors and maintainers. I had a question specifically with regard to the governance, which used to refer to some benevolent dictatorship. And I was told last week that this has been removed for future reference. I think it's useful to answer those questions also on the wiki because I've been looking for the answers on the wiki. And I realize that you guys, I'm talking to the Bezu team now, you've actually been diligent in trying to address some of the questions, but not necessarily answer them on the wiki. And it's unfortunate because we just don't know you've done the work. And so I think as a guidance for the future, if you can answer or let us know through the wiki that things have changed, it makes it easier for us to keep track. So I know Gary actually wanted to talk about this active status. I had a brief chat with him. He couldn't make the call last week. Unfortunately, he still couldn't make the call this week. I cannot speak for himself. But the thing he did want to highlight, which is, I think, in line with what I was trying to convey last week on the notion of status. And he actually sent an email a little bit about that, too, where he was saying, I think there's some misunderstanding about the meaning of the status. And he actually suggested we further describe this. Maybe we need to do a better job in the documentation online, but the way he captured this and conveyed it to me was he said, the status simply denotes where the project is in terms of adopting the governance process of the code. And I thought that was quite an elegant way to put it. And so it's really more about governance process. And as I've said before, maturity of the project, how the project is organized and conduct its business. And it's not about the maturity of the code. So I just wanted to, I remember last week, we had discussions about maintainers and some of the people from the Bezu team had started talking and we ran out of time. So I'm going to turn to you guys and give you back the microphone and let you say whatever else you think you would like us to know about the status of your project and that you didn't really have the time to convey last week. Thanks, Arnaud. For reference, I did answer that question with the governance in one of my comments. So I'm happy to direct you there. And if there are any other feedback or questions you all have that you didn't see addressed, happy to answer them. But. So before you go on, just bear in mind, the Wiki kind of sucks because when you respond to inline comments, those are almost invisible unless you know to go looking for them. And so, again, it could just be that people aren't finding them because the comments are being responded to inline and only the person who made the initial comment would get a notification. So I just wanted to sort of put that out there. But first, if we say you have to use the Wiki, we need to give them away. Yeah, I think this is a work in progress that we need to all collectively figure out because it sucks. I mean, my recommendation is simple. Do not use inline comments. Yeah. But that's not simple then because then people have to know to step out of that page somewhere else. So I think if you set a watch on this page or just a watch in the space, you'll get notifications of the comments. Yeah, OK, but it's still, they're well. All right. Yeah, that's the easiest way to make sure you get the comments without having to burden everyone else with remembering and not having to go back to Google Docs and have a decent commenting strategy. No, just set a watch for the space and you'll get the stream. Brian, I get it. OK, guys, let's not get sidetracked too deep into this. We can talk about it. What do we cast for? But I think it's fair. I mean, I take your comment and it kind of is unfortunate because when I tell them, you should answer the Wiki and then you say, well, but the Wiki, we don't know what's going on, which is true, unfortunately. So Grace, continue, please. Yeah, thanks. No, I think just wanted to call that out. So if you all have any questions or you didn't see your response, we were fairly diligent. So please just call it out and we're happy to answer it here. And also, I'll take the Wiki if it's not an obvious spot for you all. So anyway, so we've kind of gone through and I think you all have done a very detailed review at this point. And one of the questions that you all had is particularly around diversity of the project. So currently, my understanding and the requirements in the incubation exit criteria is the only way diversity is defined is by or the only requirement is the three organizations which we have, which we have, I think, representation across two of the three right now that there will be joining later in the meeting. So I guess the ask from you all, is there anything explicit that we're missing at this time? I think we're eager and excited to be considered for active status. And I think we just asked the DSC to kind of evaluate based on the exit criteria listed now and just want to kind of understand if there's anything missing explicitly. But happy to answer any questions you all have. I did send the email about our contributor base over the last six weeks or I guess almost two months now since we were accepted. So we had 21 contributors based in from the Pegasus team and then eight from outside of the Pegasus team. So that's about 27% diversity if my math is correct. So anyway, and we're really eager and excited to be working on that. And it's one of our core missions as a project. But anyway, so open the four to questions and how we can kind of work with you all on this. So speaking for myself, as I said, I think you have to give yourself a bit more time to build up a more diverse list of maintainers because as I think somebody sent an email or commented, we have this kind of easy way to test is if the project relies so strongly on a company that if they were to walk away from the project, the project would collapse. And if we look at this from that point of view, your maintainers are mostly from, I mean, if not all, from the same company. So if all of them were to walk away tomorrow, clearly you would have a problem, right? The project could not sustain itself. So that's one criteria that we have actually in our executive criteria that you don't seem to meet. Around maintainers in particular. So I think we have, to Dan, I was kind of actually created a really fantastic objective maintainer process to continue to build that. And anyone's welcome to build a submit becoming a maintainer with five commits. I totally hear you and that makes sense. And if that is what the TSE is asking for, for having X percentage of maintainers not be Pegasus, that's fine, that's just not, and we're happy to work with you on that. It's just not an exit criteria now. So just asking for more explicit directions because that'll help us continue to improve. And as far as the one company, the walk away concern as Bob Summerwell expressed last week, Bob Summerwell is not Pegasus, he's not consensus. He's an independent company, ATC cooperative, running the other theory helping support the Ethereum classic chain. He made it very clear that they have the money and they will bring money in to bring engineers if Pegasus were theoretically to walk away, which I mean, let's be honest, that's not gonna happen. But it's hypothetical that we're required to look at that ATC cooperative would bring the money to get the engineers to maintain it. Basu has been identified as one of the three strategic key clients for the Ethereum classic ecosystem in addition to Paragon and Multigeth. And ATC cooperative has publicly said that they will do whatever funding is necessary to keep Basu working on Ethereum classic. So it wouldn't disappear if Pegasus were to disappear. And yesterday we had a 1.3.5 release. There were six major improvements and of those Pegasus provided only three of them. The other three improvements came from outside of Pegasus. Ethereum classic support came from ATC cooperative pay. External mining came from White Block Antoine Toulou and Morefields and the transaction receipt came from Web3 Labs. And those were all completely outside of Pegasus. So we definitely got active, diverse contributors contributing to current releases as well. Somebody is typing or there's some background noise. It's interfering with the discussion. They're muted now. Sorry, Daniel, go ahead. Guys, this is Angelo. I have a question for the guy from Basu. Just to understand what's the status of the, what's the compliance to the Enterprise and Ethereum Alliance specification? Are you already 100% compliant or there's still work in progress there? Nobody's 100% compliant yet. We haven't run a scoreboard yet we're one of the leading clients for full compliance. We're specifically adding features with EEA compliance in mind. A lot of privacy work that we put in was deliberately in line with what EEA requirements are. So no one's 100% there yet, but we're one of the leading clients if not the leading clients. Could you give a number? It's 60%, 70%, 30%. I don't have that number. I don't have that status. We would have to ask the Australians who are currently asleep. They know that number. I can chime in very quickly. These numbers will be a little old so they don't reflect the latest and we can send an email update. But the EEA specs is divided into must, should and could. And I think we, last I checked we were over 80% of the musts. I don't know about the others. Got it, thanks. So are no or whoever, are they missing things from our checklist of this is what you must have done in order to get, you know, to change status? Well, as I said, I mean, for me that was this main point. Number of maintainers are all, but one from consensus slash because. But is that a quote unquote legal requirement? I mean, do we have it written down in? You must have. I mean, this is not a mathematical formula that you just crank and it gives you yes or no, okay? So this has always been subject to discussion on the TSC. So, you know, from that point of view is nothing new here. I think, you know, the feeling I have and that others I've seen expressed is that it seems a bit premature because we don't see a large constituency, you know, diverse constituents involved in a project and which, you know, is expected for this project that just came into a hyperledger. Mark, you were right though that if you look at the exit criteria document, we have a section on community support, but it is, it's very vague, right? The only strict requirement we have is that there are at least three legally independent committers. So perhaps, like, regardless of what people, regardless of the particular instance that we're talking about, so regardless of what we want to do with Bessu, we should probably flesh this out and provide some better criteria for this rule. Even if we don't, you know, say, even if we don't formally change the rule, we should provide sort of some examples of what is usually considered good and what is not. So this is Troy. There's a few things in the chat. So the count of the maintainers is 19 out of 20 from one company. To me, this is what is the concern because it's just not clear that with that list how this project would continue without Pegasus and that would be my main concern as well. And maybe this has to be fleshed out more in the documentation, as you said. But I think that's the most important piece of this puzzle is to say these projects will continue even if a main contributor goes away. I think I just expressed that earlier, maybe on the week here, forget on the call, you know, that they are asking for us to be more specific about what we are expecting. And so I agree that, you know, and I think I did say that before, that if we need, we will have to update a documentation. I don't think there is much contention as to the expectation. But, you know, whether this expectation is captured, you know, well enough and communicated well enough that new people like, you know, the Bezu people can get it. That's just another stretch, right? That's not necessarily true. I think it's fair feedback, I know, and Grace and team, that, you know, we could do a better job of articulating that, although again, for the many of us who've been around for, you know, three plus years now, we had exhaustive discussions that sort of led to writing up the criteria where, you know, we expressed, I mean, so it's not as if we're, and I hope you appreciate this, that it's not as if we're trying to be a personicity or, you know, somehow or other, that, you know, we're trying to, you know, prevent you from getting to active status. That's not at all what this is really about. This is really about making sure that the community, as it grows, that we have projects that are sustainable. And for that to happen, the reality is that you do need to have a diverse set of maintainers and contributors. I'm, I think it's great. I think it's fantastic. And maybe, you know, we've used to need better awareness that, you know, the new feature development came from outside of the Pegasus team. That's fantastic, right? But still when you have all but one of the maintainers, that makes it sort of difficult to conceive of the fact that if Pegasus were to sort of, you know, have a change of heart and walk away from it, that there's really enough leadership. I mean, yeah, and, you know, Bob, I think everybody does, right? And, you know, the fact that the, you know, the ETC is willing to sort of, you know, to pony up and make sure that there are engineers and so forth that are willing to work on it. But that doesn't mean that there's going to be continuity of the project because you need to have people that are able to sort of step in and have the sort of the continuity of understanding of the code base and so forth. And so it's not just a matter of dollars. It's a matter of having the sort of the tribal knowledge to continue. Sure. I think that's a good point about continuity. And I think we've, you know, I think Bahab does speak well to kind of how the project is evolving and we're continuing. I think what's interesting is that being a part of Hyperledger we've really picked up steam too. And it's been a really, you know, we've seen the growth in our contributor base and it's been a really, it's been a good thing. So I guess my question would be, you know, let's say, you know, today, right now, you know, what they've listed is my understanding are the requirements, basic needs, you know, and if maybe, you know, maintainer status is something you all want to add, you know, and let's say that's something that's added in the next six months, is there any reason we could then be demoted to incubation? Why would we not go to active right now? Let's say, because we meet the current requirements and then, but let's say if as it continues to evolve and we want the continue to build and be stronger and, you know, and if it doesn't, you know, I think it's interesting to also, I would propose to the DSC thinking about not just incubation exit criteria, but active exit criteria. So you know what I'm saying kind of on that kind of transition, because we want to continue to meet and I think that's really important, but we also want to, I guess, challenge you all about, you know, the current status and the future status. Grace, I think it comes back to a conversation around what we have documented is not necessarily the spirit behind the way that Hyperledger has moved other projects to active, and I think that's causing the back and forth here, if you will, right? It's not that, you know, I guess as we've documented it, you're right. If this is what we say, three committers, not three maintainers, then, you know, that's a problem, but I think when I read that statement about three committers, I really think about the maintainer diversity, not the committed diversity, if you will, right? And so I think, you know, the challenge is that what we've documented is not necessarily what we've thought about in past discussions when it comes to moving a project from incubation to active, and I don't know what to do from there, right? Obviously, there's a disconnect, and but I just want to point out, I think that's why the conversation is happening in the first place, is because understanding of what the TSE members who have definitely been here much longer than I have and have had these discussions about moving projects to active in the past is probably different than what is actually written down on a wiki that isn't necessarily what's being thought about, right? So like I said, I don't know what to do. I just wanted to kind of point that out. But I think this is a unique situation too, because I think the way the criteria and stuff are written are most of the projects come in, you know, very new from a code-based perspective. This is something that's come in, that's a shipping product already for their company that they're donating. So, you know, they don't have a wide spread right now. You know, I think they've made great strides in the short time they've been here, but because it was proprietary code that's now being open sourced, that stuff needs to get done, you know? And I think they're making great strides on that. I also think that, you know, there's a lot of projects that would not survive for long if the main contributing company pulled out. So, you know, I think we need to rethink that a bit, but I agree we need, you know, the main concern for us should be the health of the project if the main sponsor and company leaves. But, you know, I think this is a unique situation. It's not like, you know, you had an idea and you started a lab and got promoted and now you're trying to gain people to help. Okay, but Mark, you say it's a unique, I kind of disagree with that statement. I mean, we have different projects, some were quite new, some were not that new, right? I mean, IGM's code that had been open sourced before outside of Hyperledger, we then contributed it. It'd been around for a while. Indeed, maybe even longer. So I think different projects have different, you know, track records and some more public than others, but, you know, you can't just say, oh, this is the first one that has some mystery prior to Hyperledger. So, the other thing I wanted to point out and, you know, it's a bit, in following up on this situation, things can change over time. I mean, and I want to get back to the point Grace said, we could, could a project basically go back to incubation if we then, if things change back. And I mean, that's the situation we have not faced yet, but we do have those quarterly reports that are actually, you know, meant to help us keep, you know, keep track of the health of the projects, right? And supposedly, you know, if things went really bad for a project and almost everybody were to walk away, we would hopefully, you know, get that through the quarterly reports. Of course, you guys are so new, you haven't even had a single quarterly report, but I would expect you to start doing this, just like the other projects. And I don't know, right, by the way, if they have that on their agenda, but, you know, so that's definitely how we would capture that, whether we've never considered, I mean, we actually did talk about whether a project could go back to incubation and possibly back to a lab. I don't think we have said we would do that. So I don't expect us to do that. It's more like, you know, if you really have a problem with maintaining your active status, maybe you would go back to, I mean, go forward into what we call those, retirement or pre-retirement, something like this. Well, how long did it take for composer to go from incubation to deprecated? Like, there was a year where the quarterly reports were filed, you know? So if we're gonna have a process, we should stick to a process. And the process that we have right now, you know, as Hart just said, it's kind of what does the TSC feel on any given day? You know, I really feel like we're kind of inventing stuff here for Bezu. Well, but we are, and we've been doing that. No, we are not inventing them for Bezu. We're inventing them for Hyperledger. Not for Bezu, no, right, but for Hyperledger. I mean, we are working through this. I think it's also important to mention, and I'm not gonna mention any names, but we did actually approve a project for active status. And it really wasn't ready, right? And that showed, and you know, through the quarterly reporting process, we actually had to sort of go through and you know, kind of like at Harvard, you know, we had to provide some, you know, sort of some extra help to get, you know, to get the project on sort of track from an active perspective. And, you know, so I understand that there's a little bit of trepidation. We don't wanna go things too, to move things too fast and then find ourselves in a situation where we have a project that really isn't ready for the status. And I'm not saying that that's the case with Bezu, but I am saying that, you know, we sort of got burned because we were, you know, okay, so it, you know, it met the criteria. Then we had to have a lot of discussion about, you know, whether or not, you know, the project really was equivalent to the other active status projects. I think that's the case now, but that wasn't the case maybe a year or more ago. In the context of, you know, again, I think as we go forward, we're testing all of this stuff out, you know, Composer, well, the people that were working on Composer and I'll admit it was IBM for the most part. We decided we were gonna walk away. We said, you know, we'll continue to fix bugs for some period and then after that period, we're like, you know, nobody stepped up. And so you can say, Brian, that it was a year before, you know, when we didn't finally, we weren't doing it intentionally. We announced that pretty, you know, pretty plainly. And, you know, yeah, maybe we should have deprecated it right then and there. I don't know, but I think we're figuring this thing out as we get to these different stages. And, you know, as the composition of the TSC evolves over time, I think there's gonna be discussion. So, look, I think certainly Basu is moving in exactly the direction that it should be and that's a good point, right? There's diversity of contribution, although it's hard to tell where people are coming from because everybody's got a Gmail address or a GitHub address. And then, you know, it'd be really nice to see the maintainers diversify to- All right, thank you. I would like to, you know, but I don't know, is it ready? I don't know. Okay, I think we have talked enough about this diversity aspect. I would like to know if there's anything else anybody wants to bring up about this, Basu and the request to active status. And otherwise I'd like to move on to the other directives. Hey, Bob Samuel here. So just a few points to clarify about Basu. Basu was never closed source. It was actually an open source project for a full year here before it came to Khyberledger. Before it came to Hyperledger, I'll just reiterate again that the cooperative are committed to supporting Basu irrespective of the actions of Pegasus. That's not reflected in maintainer status. And the reason for that is, well, firstly, you know, I guess it takes a while to go through that. Secondly, that the cooperative ourselves would not be doing the work that we would be funding teams to do that. At the moment, all of that work has been done by ChainSafe. That's very likely to be the case moving forward. I believe that at least one or maybe two people from ChainSafe will go through the process to get maintainer status. So in terms of thinking of your process, somebody had spoken about wanting maintainers as opposed to committers, you know, that that was a better signal and I can understand that. But yeah, I guess there's just a few different aspects of maturity or breadth of support within Basu, which perhaps don't get captured well by the current criteria. So that's just something to think about with those. Thanks. All right, thank you. Do we have a vote? A vote on what? Whether we move it to active status or not. Or have you decided it's not going? I don't even know that we have a quorum and I wasn't planning to have a vote because I don't feel like there's enough agreement in general to put the motion forward. That's my technique. I think speaking from the Basu project would challenge for a vote to help us then know where we stand with the current requirements and then if we need to work with you all on defining what the additional requirements might be, that's okay, but I think the Basu team would appreciate a vote if you are willing. We understand if you want more time though until the next meeting to think about it or something like that, but I do think that's a priority from our end. I'd make a motion, we have a vote. But wait, do we have quorum? I didn't hear we had quorum. Rai said we don't have quorum. Yeah, we have eight. We have nine of 11, so. Okay. Do you have quorum? Anybody second my motion? Guys, this is Andrew. Actually, personally, I would like to see, for me, a project should become active if it delivers something that is already useful. So I would like to see first the numbers of the compliance to the Ethereum Alliance specification published. And if they are good numbers, I think the project should become active. Otherwise, I would vote against the person. Okay, so I mean, I think several of us have reason to vote against it. Mark pushed the motion. I mean, he asked if somebody wants to second it. Hold on, can I ask you a question, Angelo, though? Cause that's a very different set of criteria than anyone else has discussed thus far. Yes, please. Yes, of course. Yeah, I mean, so I think earlier in the call, it was made very explicit. My understanding correct, this is what I'd like to clarify, that it wasn't actually about the maturity of the code or how the code was used. It was about the compliance with hyperledger governance and community best practices and sort of establishing the code base, right? It's about the maturity of the community around it. Yeah, so I just want to clarify that, we will get you those numbers on EDA compliance, but that feels from the discussion to be a separate thread. Yeah, but you know, I understand that. I understand that point, but I'm a scientist. So I can analyze, I want to see numbers that are more, I can better understand. The maturity of the community, it's something very, I don't know, how do you assess that? What's the point? So tell me a criteria to assess that and I will understand. I mean, we've been asking for the same thing. I agree with you, you know. Okay guys, I'm sorry, I'm really taking the microphone here. I heard Mark made a motion. He asked if somebody wanted to second the motion. I haven't heard anybody. Okay, so there is nobody to second the motion. So we're not gonna have a vote. All right, so I would like to leave this because we spent 40 minutes of this call on this and we're going to move on to the, I said we had a light agenda, but still there are a few other things I wanted to talk about. So let's move on. I'm sorry for the biggest team that wanted to have a vote, but I think hopefully this, you know, gives you a sense of where people stand anyway. Great, I think, I mean, frankly, it's just left me a little bit more confused. I don't understand what the requirements are and what's the expectations are at this point. Okay, sorry. The main feedback is that 19 out of 20 maintainers is not yet enough. You know, or one out of 20 maintainers being non-pegasus is not yet enough. Yeah, so that's the point we'll take and we'll look on that. Is that like the broad consensus? Is that, I think what Grace has been looking for is sort of explicit definition of the criteria so that when that does happen, the response isn't something like Angelo's, which I understand where he's coming from. I completely get it, but it's a different set of criteria. And can we edit the exit criteria document to provide sort of what people think about this and to provide some quantification so we don't have to have this discussion every time? Like I think it would be good if we said like, you know, here are some cases. But I think, but in the heart, on that point, it really should be that we come up with a specific proposal for what the change should be. Sure, yeah, we can do that. I'd be happy to like write up some examples that say like, you know, if your project is X, you will probably not get approved. Well, I think the diversity criteria is clearer than others. I think what we've been looking for is where there are other mitigating circumstances that despite the diversity criteria not being met could also justify the graduation from incubation. And those will always be more subjective because we're looking for kind of, well, it's not quite there, but are there other good reasons why? But if they admit the more objective criteria in terms of maintainer diversity, then we wouldn't have to be looking for those other justifications, right? So I think there's sort of this an inescapable degree of subjectivity to it, but the more objective criteria we can get at, the better. And this is an iterative process, I think. But like, I mean, I think Brian is touching on a very good point because at the end of the day, if it were purely mathematical, you would just fill out a form and there would be an answer from the machine itself. And we have a TSC review for a reason because there is a part of it which is subjective that has to do with the history of how we got there and what we want this organization to be like. And all of that, some of us who've been around from the beginning kind of have that built into ourselves and we're trying to communicate and be transparent about the expectation is. And I second the effort hard if you want to make proposal on how to improve the executor documents. So let's do that, please. But let's not fool ourselves about what is going to take that this is going to solve any need for discussions later on anyway. So with this, again, I would like to move forward with the agenda, I'm sorry, but we cannot just dedicate the whole agenda to this. For the sake of it, I'm not going to spend time on the TSC election, voter selection. I have said last time, the status quo is what's on the agenda basically. And what I'm asking is, if anybody feels this should be changed, they should speak up. Otherwise, soon I'm going to propose that we resolve the question by endorsing the status quo, which is what's written there, which is what we've done for the last election. So if people have opinions on this, they should take it up and, you know, bring it up on the Wiki, discuss, make proposals, whatever. There is a TSC election, voter selection issue page that can be used for that purpose. And I encourage you to do that if you have any opinion and want to change the status quo. So with that, I wanted to spend the last few minutes we have on the implementation and actions of the TSC decisions. And Silona, I'm going to turn to you because, you know, we have, and I'll take the blame on this, you know. I think it was Tracy, for one, who said, wait, we make decisions and what's the action item? How do we actually go at implementing it? And I say, well, the staff can figure this out. And of course, it was a bit like hand waving and say, hey, the staff, you go figure it out. And basically Silona is coming back saying, okay, what exactly are we supposed to do? So... Well, the thing is, is we do need this more specific criteria. I can't have my team sit there and go out and look for these different things. If, you know, like I said in the chat, I thought that you wanted percentage of code donated from contributors, not maintainers. And that's an example of the specificity that we should be looking at. You know, what should those types of criteria look like? Otherwise, it's not enforceable by my staff and we can't sit there and do those pieces for y'all. Otherwise, we're the ones doing the interpreting, not y'all. And we know where that direction goes. Okay, he's there. So how do we, I mean, do you have any specific questions? Do you need the TSC to look at and say, okay, for this, this is what we want to do? Are you looking for more general, like how we end all this moving forward? Well, from all the discussion, so for example, I asked Nick to join the call. And the reason I asked Nick to join the call is because he was asking me going through this different stuff that was there and we sat down and Nick and I were reading through the decision logs. And he's like, I don't understand what this means. He's like, does this mean this for Explorer? What does this mean that for Explorer? And I'm sitting there going, you know, Nick, I really can't answer those questions for you. I said, what I would do is go ahead and fill out the forms, put those things before the TSC, have them go and do the commentary on them, and then the TSC can decide better how to evolve those forms. I don't think that it's something that my staff can simply come in and re-edit for you and have it be accurate according to everyone in the TSC that has not voted on them. Just like how legislation is written, this is not actually different. We're creating laws and rules and structures for people and we have to do that in a systematic way and we don't have it. And so that's what's so confusing and that's what makes people so upset about this is because it isn't very clear and they can't clearly sit there and go, okay, am I ready? Because they can't determine that from what we've created for them. Okay, I hear what you're saying. I just don't know what you want us to do practically speaking. Well, I think that there may always be some kind of judgment call with this stuff, but if we can sort of provide more specificity on what's likely to be approved and what's not likely to be approved, then that might be very useful for people. I think the question is for those decisions that we've approved in the last month, let's say, probably longer, but maybe just since we've become TSE members for this particular session, right? What is it that needs to change in the wiki, on the wiki to make those relevant and active? I think that's what Saloon is asking for. They're also very diverse too, because for example, Tracy did a wonderful document on the fabric exit criteria. And so that's what I pointed Nick to, but that's a DLT, Nick's a tool. And then Quilt is a library. Exit criteria for those are different. In my book, I mean like, sorry, when I was doing this at PayPal with large amounts of code, I had very different exit criteria for each of them. And right now, sitting there and saying to Nick, okay, you need to do everything the fabric did, is prohibitive. And so that's the sort of things that, it's a lot of detail, but it is one of those things that we have to consider in regards to the guidance that we give people. Now, if you want, I can go and write all those, but I'm gonna guarantee that if I do that, a number of people are going to be very unhappy with what I write. And that's just the problem that we have and then it needs to be voted on and all these other different things need to happen. But there are standards out there for y'all to start with in regards to what typical exit criteria are, what these typical, what does it mean to have a good open source community? What do all of those things look like? And I would start from there. I would just go and grab some of those and go, these are good and let's go with that and vote on them. Rather than sitting there and saying, the intent is, it's important for people to understand the intent, but in the end, the intent doesn't give the things that people can actually follow. I like to think of everything as a democracy, but that doesn't mean, we don't have to sit there and figure out how voting works. So you talked about the exit criteria, did you mean for the major release or for the active status? Both, both for the releases, for the active status, for all of those different pieces. We have to go through what those actual criteria are. And like I said, I think that they should be different for the major categories. It shouldn't be a significant lift for a library, but it should be a significant lift for a DLT. So actually, I mean, as we all know, I think major release has been, you know, the point at which we trigger whole bunch, including marketing, communication kind of activities. And so there was a fairly high bar. And are we going to do the same for releases of like libraries like Ursa and other things? I don't know what the expectation here is. And I don't know that anybody knows because we have not faced that yet. So in my opinion, I mean, I hear what you're saying. Though we have different categories, they should be treated differently. I really don't know where anybody stands and what the expectations are in this regard. I'm not clear in regards to what's the question for me in regards to that. For me, the question is how do I create forms and different things for people to come through with their proposals and give them guidance in regards to preparing for applying for the different statuses? And what I'm saying is based off of the decision logs, I don't have things that are concrete for me to do actions on, which is why I so completely appreciate Tracy adding in the action items, but they need more meat. Yeah, I mean, as far as Ursa goes, we have sort of toyed around with thinking about active status, but you know, we sort of recognize the procedure is very subjective and dependent on the TSC members. So we sort of floated it to a bunch of TSC members, got pretty negative feedback and then just kind of dropped the idea for now. So. Okay, so I think you see what brings up in a real concern, we have a problem. So how are we going to move forward on addressing it? You all have to write actual documentation and approve it. Yeah, I know, but I hear that, I mean, I guess what I'm missing is. How it's worked in every other nonprofit I've ever worked in, is that the board does that? I don't disagree with you, Silona, but are you going to make those proposals, documents and whatnot? Well, I typically do, but I do that when I have a certain amount of content. But right now, like I said, I sat down with Nick yesterday and Nick and I spent several hours discussing it and I'm just like, I can't tell you. He's like, well, what does this mean? And I'm like, I can't tell you. I said, put as much information as you can and have discussions before the TSC and see what their input is from it. But that's the main thing. Right, so honestly, I think the only way to, in my opinion, to move forward and this is to make progress is to have you formulate the exact questions need to get answers to, you know, I'm not hearing anything anymore. Did I shut everybody off or am I disconnected? You're still here. You're here, Arno. Okay, good. You're here with Tracy. Welcome all of a sudden. Thank you. Okay, we're almost out of time. So I don't know that there's much we can do on this, but you know, I'm not hearing anybody jumping and volunteering to take this on. And I fear the reason is because people are struggling trying to figure out what I could to make things better. And so I hear the pain and the problem, you know, I'm willing to help figure out an answer. I just don't know how to go at it. And so I've opened the floor to everybody else. Does anybody have an idea of what we can do and answers to in answer to Silona's ask? I'll talk at the same time, please. Oh, no, I think it comes back down to specificity. Are we being asked to revamp every single governing document that we have? Are we being asked only on the exit criteria? What exactly are we being asked on the decisions that we've made that haven't had action items? What specific actions do you want the TNC to take? Okay, thanks, Tracy. I mean, that confirms my, I mean, that this is also my position. I am not clear exactly on what's being asked in terms of, you know, it's not specific enough for me for it to be actionable. So I apologize, Silona, if we leave you hanging there. But we're out of time. I'm going to call it closed now. I think we can have a chat offline maybe to help. And okay, for now, I'm going to call it closed. Thank you all for joining today. Not all discussions are easy, but hopefully we're all making progress towards a better future. So thank you all for joining. Talk to you in two weeks. Happy Thanksgiving for the US folks. Thank you, Silona. Thanks, Silona. Thanks everybody.