 But I think we can get started anyway. So with that further ado, let's start the recording and get going. The recording has started. So keep going. All right. Thank you. Hello, everyone. Welcome to the TSC call. First and foremost, please be aware of the antitrust policy notice. For those who were actually connected online, you can see it being displayed on the shared screen right now. You should all be familiar with it. There is also a code of conduct that you should be familiar with. There's nothing really extraordinary about it. It's just basically asking everybody to participate in a decent way. So be familiar with this. Regarding the announcement, I had one item which is minor announcement, but so a while ago, we decided to adopt this mechanism to keep track of the TSC decisions because historically, they've been kind of disseminated all over a week in meeting records of one kind or another. The problem is we started using the system which I think everybody has agreed is really a big improvement. Promise there is no history called data in it. To the point, there were questions raised about, so what does it take to be able to publish a first major release, for instance, and I remembered we made a decision on this, but actually finding it wasn't so easy. So basically, the announcement I wanted to make is, I started going back into the old decisions we've made and put them into this. So it's just a very simple record that basically captures the decision that was made and as a link to the actual decision in the previous, the older record for the decision. So as time permits, I will keep doing this as we move forward because I think it's a bit of a pain to do, but it's useful to have a consolidated list of all the decisions so that people don't have to look all over the place for this. And if anybody wants to chip in, please let me know. I'm happy to share the load with anyone else who wants to do this. All right, so without further ado, let's move on unless there's any question, but I wouldn't expect so. So we have a bunch of quarterly reports that were submitted. Some of which were kind of delinquent from last week, some where I'd been submitted just before the call and people didn't have a chance to review them. So I put them all back. I have seen a lot of notifications and just like 15 minutes ago, so I went through all the reports and I saw that for the most part they've been reviewed by most of us. So I have pretty, you know, I'm pretty confident that people know what they contain. I'm going to go through them very quickly. There is nothing special about grid that we need to talk about. For the BESU report, there are two issues that were brought up. There is one with regard to the rocket chat access in read on e-mode. And I think that's worth a bit of discussion. And the other one is to do with the active status, the requirements, that's a bigger discussion that we can discuss later. Is there anything else that people won't talk about BESU or any questions? I think one thing we need to work on is we've said that for the working groups that they're going to deliver a product, you know, some tangible thing they need to have a task force. Are we grandfathering? Yeah, but that's not part of BESU, right? Okay. It was regarding to the smart contracts working group. I got you covered there. It's coming. All right. Sorry. No, so we got to BESU. Can we talk a little bit about this redone access? So the BESU team is reporting that, you know, they feel like there's a barrier to using rocket chat because it requires having a Linux foundation ID. And if you're just passing by and you just want to access some information, you don't necessarily want to participate. And is there a way to get grant redone the access to rocket chat without identification? That's basically the question. And please. There is. Daniel, if I get that wrong, please jump in. So there is. And it's kind of a, this is a side effect of the behavior that they're seeing is actually a side effect of enabling anonymous access, particularly to search engines. So this is part of a discussion that I would like to have in the new year about what is the future of chat for hyperledger? So I would ask, you know, that, you know, we plan on rocket chat issues. Okay. So maybe can you take the action to open and issue them with regard to this redone the access to rocket chat? Does that make sense? Sure. That way we look at it whenever you feel like it's good time, but I just don't want to lose it. Yeah, no problem. So, Ryan, are you suggesting that there should be an alternative approach or reconfiguration or what are you thinking about there? I think that we should reconsider our chat platform. I've certainly got tons of feedback about that. I don't know what that would be. We ended up here for reasons of cost. Yeah. That has to change. Because we couldn't archive, right? Because if we wanted to archive everything, we would have to pay a facility in dollars. Yeah. Right. Slack has the same issue, right? Sorry? Slack has the same issue needing to create an account to get in and start using it if you were to. Right. That's right. So Slack has a different set of similar problems. Mattermost has been suggested. There have been a lot of suggestions about other chat platforms that we could move to. They'd be curious to hear from the basic team their experience with Gitter. So Gitter is driven off of GitHub user IDs. From my experience, it logs all the way back, although that might just be a restriction for open source only, which actually for what's going on with Hyperledger would qualify. The great thing is we can give them a link and they can go straight into the chat room where they can see what the discussions are. And with Rocket Chat, when we give them a similar link, they just get never ending triple dots loading. And that's kind of a bad, that's a feel bad moment for sure. Okay. Well, we don't have to discuss it here. I just wanted to, I was really just trying to get Rai to sort of clarify what he's after. It sounds like Rai, you're suggesting we should look at another platform as you just confirmed. It used to be that you would actually be able to see the channel and there would be a fine in button at the bottom of the window. So there may be an outstanding or an open issue in Rocket Chat to fix that. Yeah. So I don't wanna dig into this. The way the behavior today is because of enabling search engines to be able to index Rocket Chat. So if we turn off the login splash, which is totally a setting we can do, then it's apparently unindexable for some reason. I don't remember. It's been a couple of years. We could either improve the Rocket Chat platform, move to another platform, but I do know that LFIT no longer supports bringing on new projects with Rocket Chat. And I think our experience has been okay, but not awesome. It's not awesome. Okay, so Rai, Rai, could you just have another look at this particular issue? Is there a way we can open the door so that, you know, the situation that I was just describing would be addressed? And then we can table off the trigger. No, then we can table off the bigger question of whether we should switch to a different platform altogether. I don't want to mix the two issues. I understand that, of course, if we switch platform, then this issue goes away. But, you know, it may take a while before we switch. And if there is an easy fix right now to give access, redone the access to anonymous users, I think that would be worth looking into. Okay, so let's keep on moving then. Smart contracts working group. So as Mark was eager to point out, in their report, they don't bring up any specific issues, but they do highlight that they are planning on producing a bunch of reports and byproducts. And so the question is, you know, given the decisions we've made with regard to task forces and the fact that working groups are not expected slash not allowed to produce anything other than through task force, do we have to tell this model of contracts working group that if they are to produce anything, they need to create a task force, or task force if the case might be. Yes, hello, this is Sofia Perzi from the Smart Contracts Working Group, I'm the chair. So I'm here to know everything that we should regarding the task force, if there's something you want to tell us and move the world to the people there. I think we also have the same type of issue with the DCI working group. Is Dan on? Yeah. Yeah, so we're in the middle of producing the survey that was originally chartered. So my preference would be, we've already chartered these things or at least in that case, the DCI one within the last few months. So just issuing more paperwork seems arbitrary and unnecessary, but going forward any new work product that's gonna have some sort of hyper ledger logo on it or affiliation in that you follow the new process that we've agreed to. I've y'all checked out their space on the wiki because they have a space where they've got all their work products all documented and drafting live on the wiki. Right, any opinions that don't hear much? I, yeah, other than Dan, so he's just, I believe to grandfather at least this working group, which is consistent with his position, you may remember he voted against this requirement that working groups can only produce deliverable through tasks, so I understand where it's coming from. But Mark, in your comment, you also suggested maybe we should grandfather this. It was more, you know, just we changed the rules and we didn't account for things that were already in flight. So how do we wanna handle things that are already in flight? I also have another thought that maybe it's a bit tangential, but as far as who's eligible to vote in TSC elections, if we add something when we get the specifications for what a task force should do, if we added a list of contributors there, then we would have a list of people who have contributed in the working groups. But that sort of rules out working groups that don't actually deliver anything. So, I mean, it's a different thing, yeah. Let's not turn that on now. You should see my world. I'm happy to leave that working group alone, let them do what they were doing. Anybody objecting to this? I think grandfathering is kind of the norm, right? Unless we have a really strong reason to say no, they need to stop the way they are doing their thing. Okay, I didn't hear anything. I'm in favor of allowing them to continue on the work items that are already planned without a task force. Okay, do you wanna make a motion and give a second and have a vote, please? Sure, I make a motion that we allow current working groups that have things in flight to continue without going through the process of forming a task force. I second that. I serve that. Right? Anybody in agreement with this, say hi. Hi. Hi. Hi. Anybody opposing it? Anybody abstaining? Okay, so it's unanimously approved. Thank you. All right, so let's keep on moving then with the reports. Ursa, there's no major issues on this report either that I think is worth highlighting, but they do point out that they would welcome feedback from the project maintainers as to what would make Ursa more attractive or what would make it, what would make the maintainers use Ursa. We don't have to take it on now. This is a call for feedback input and the door is open. Please reach out to the Ursa team and let them know. And the final report we have today, oh, well, is there any questions about Ursa before I move on? Okay, hearing none, let's move on. The last report is Explorer. And so there is no major issues with Explorer either. They've issued the first release candidate and for one zero and they are trying to figure out their way to get to the one zero, which we'll talk about later. And they do highlight that they are struggling a bit like many other projects on the diversity aspect. Any questions or comments on this Explorer report? Good morning, this is Nick Explorer. Yes, indeed, we have outages of contributors and I would like to ask if you have any suggestion how to recruit, honestly, I'm being very sometimes direct to developers that are trying to use Explorer and trying to hiring them, recruit, but people just are coming, sometimes they're wishing to contribute and then they leave. So what would be your suggestion in terms of like getting more contributors? Ways to, not sure, maybe some projects can share their contributors or something else. I don't know even what would do. I understand. So typically, yeah, so there's actually some really good blog post articles, whatever you want to call them off of the Red Hat open source pages that speak exactly to that. How to grow your community, how to engage developers and so forth. And you kind of touched on probably the most important one is your users are probably your greatest source of potential contributions that basically you have to nurture it. I think we all have a little bit of work to do in that regard, but basically, when people come and they start using it, encourage them to contribute or ask them if they have any specific ideas about the features and so forth, that's the best way to get them engaged. But I would encourage you to take a look at the Red Hat open source pages or I think a link to community or something like that. And then we just send it. Yeah, thank you. materials. Thank you. What is good about that? I'm seeing that people are using, companies are using it in production. And with some releases that we minified the configuration, I see less complaints on rocket shop, which is a very good feedback and going forward, I think it's going to be a very good experience and to get more feedback from the users. Other than that, as you mentioned, I hope the moving point of getting into the major release one and moving forward to graduate from the incubation, the explorer, so yeah, I would like to talk about that. Thank you. Yeah, so I put that on the agenda as a separate item. So we'll get to that later. Thank you. And quite frankly, just to add to what Chris was saying, this is something obviously a lot of projects are struggling with. I'm afraid there is no magic bullet. And we have been through this over the last four years of hyperledger many times where people are trying to share pain and stories and about even when they're trying really hard and doing everything they can to bring people in, it doesn't always work. So Composer comes to mind, for instance. So there are other projects that have been struggling with this. Okay, well, so. We'll be interested. There's a bigger problem. Right. You don't have to get to it, but maybe it's tied to the rest of them. There's a bigger problem, actually, right? I mean, I actually think that people actually, anyway, I won't get too much into it, but I think people don't really understand sometimes what hyperledger is. And I think that sometimes it's propagated by hyperledger. I think people actually think that hyperledger build products. I think it's a problem. We have a lot of users. Users don't typically contribute, but people think that these are products. And I think that that's an issue. I think on the hyperledger Explorer, what my issue, and I did go back and look at it, so it did look pretty good. My issue on it was that it had been dormant for a while. But it does look like over the past year that contributions did go back up. I think that's the sort of concern on why people were looking at making sure that there's people, more maintainers or whatever, that if something does go into, say, an active status, that it's not just going to go dormant at some point. But maybe when we get to the future conversation, well, maybe there's a stuff that says, well, if that does happen, maybe a project does become dormant or go back in status. I think that's the bigger concern. That was my one comment on yours. So I thought that that was that. I will just say that I didn't update my comment, but I do think that it did look like the contributions had been very steady over the past year. So apologize for my comment on that. All right, let's move on, because I don't want to spend too much time on the reports. I'd like to get to some of the topics of discussions today. The first one is the management of quarterly reports, the TSE, which we just went through. So admittedly it took us, even though I tried to speed it up, it still took us 25 minutes. And so Rai kind of raised this issue a bit obscurely and it created a bit of confusion, but I had a chance to chat with him and basically he's saying, maybe we shouldn't discuss any of this on the calls and we should do it all entirely offline. I don't know how people feel about that. It sounds a bit extreme to me, but I just, you know, that's what this is about. I think we're getting much better at being efficient and going through reports and it gives us a chance to have discussions on things and see broader issues. Yeah, we want to give people who are reporting the chance to bring up their issues to the TSE if they want. I also feel that this is a primary function is to have this kind of oversight and figure out when there are issues and address them and whatnot. And this is an important part of this. And I'm afraid historically we have not been specifically good with working offline and so even though we should keep encouraging this for, we can't just completely rely on it. Chris? So to your earlier point where basically you went through and you sussed out what you thought were the issues, maybe there just should be a section we add at the end for any issues you want to bring before the TSE and that triggers a review on the call. We have that in the template. It's not at the end, it's close to the top but it's in the report template. This is how I came up with those things that I highlighted what's in those reports. So that's done. Okay, so I don't hear anybody saying we should change that we were doing it right now. Is that correct? That's correct. I think it's valuable and when we don't have eight of them on the schedule which we're not supposed to have eight at one time, then it actually only takes a short amount of time. Yes, I agree with that. And then immediately I could have postponed a couple of them to make it lighter. So all right, do we need to make a decision on this? No, I mean, I was trying to withdraw this item entirely after you and I had discussed it. So the horse is truly dead and beaten. So let's move on, please. Okay, that's good. You can mark it as withdrawn if you want. Thank you. All right, so following up on the Bezu request to move to active status, there's of course the big discussion that keeps on going as to the diversity aspect but I think Daniel actually raised the point which I think is fair is that they're saying, okay, is there anything else we need to worry about? They just don't want to have this feeling of having a moving goal post where every time they work hard on reaching one of the, meeting one of the criteria we have highlighted, we'd say, oh, but there's also this and there is also that. So can we, I wanted to ask the TSC specifically if there is anything else? Because I mean, as far as I'm concerned, that's the only one I've heard really being expressed and discussed. I don't know if there's any others. I would just say like use of the hyperledger community tools is the other one, right? And I think that comes with time. I don't think that comes with like, I've done it, check. I think, you know, as we've seen the problem with rocket chat not working well for Bezu, are there other things that won't work well for Bezu with the hyperledger tools? And I think that's just a timing issue, right? Like you've now switched over all of the tools to using the hyperledger community tools. What are gonna be the issues that you uncover? And, you know, that's the big one. I think, you know, for me, when I used to explain what it meant to be active, it was that the community has formed and gelled and is using, you know, hyperledger processes and really kind of understands that, you know, and can do releases and using the hyperledger tools. So to me, I think that's the other one that would be outstanding. All right, thank you. Anything else, anyone else? Okay, so at least we've got that clear, clarified, Dano, is that okay? Yeah, I think we're there on the tools, but it's not worth bringing up for a vote until we can satisfy people with the diversity concern. Yeah, no, but we don't need to vote on every one of them individually. That's fine. Exactly. Tracy, do you have a list of tools in mind that you feel they're not meeting that would make you vote against it? It was required just so they know, I mean, they need a clear target, right? It's not that they're not meeting, right? They've switched over to Jarrah. They're using Confluence. You know, they're starting to use Rocket Chat, the mailing list, those sorts of things, right? These are the tools that I'm talking about, but I just think that there's going to be potential issues as they actually do releases, like with Jarrah, that they're not going to be aware of the fact that this is how this is functioning on the hyperledger side, and they're going to have issues that they need to get resolved. And so to me, that just comes with using the tools that exist in hyperledger as they're going through and doing releases and having conversations with the larger community. So it's not that they're not meeting them. Check, I've done this. It's that, you know, I think it's using them in a longer period of time to find out all of those sorts of concerns and issues that they're going to have with them. Okay. Does that work? Mark. Yeah, I'm just trying to make sure they have, you know, a clear list of things, so. I understand. I think that's a good point. All right, so I don't hear anything. But what do people think that active status buys them? Okay, so that's that's. I don't really want to have this conversation with her. No, no, I'm supposed to. But what do you think it buys them? Yes. So there's the big question of active status. What does it mean? And the fact that, you know, it seems like the one item that everybody stumbles over upon is this diversity issue. The diversity criteria. And I assume you guys have had a chance to look, to read the Hart's book on the activity status versus incubation that he posted yesterday. And the, which is, which raises a very interesting point, right? And it talks about the diversity criteria, which is actually fairly well defined in the, in the exit criteria for incubation. But, you know, it still leaves room for interpretation. It's not completely objective. And so there is one part which is, which is like, you know, you have to have at least three maintainers from different organizations. So the Bezu team is saying we are getting there. And I trust that's true. And then there's the question of, well, which is harder to assess is, you know, whether the project is dependent on the single entity or not. Or another way to put it is whether it would survive if the, you know, any entity involved in the project were to walk away, which we understand they have no intention to do, but still that's the idea. And so I think Hart raises an interesting question and which touches upon what Gary just brought up is, okay, first of all, what is active status about? What does people expect to get from it? I think there's a bit of like a bragging right that people seem to be eager to get. And beyond that, you know, the idea was very much along with what Dan said in his message today is, you know, from a TSE point of view, we all agreed that Hyperledger was about open governance and we wanted projects to be not under the control of any single entity. And we wanted to work hard on encouraging projects to grow a community, which was as diverse as possible. And so we felt the active status was a good way to have this kind of carrot that would make people go for this and work hard towards it. As far as I'm concerned, this is what it's about. I understand it's hard to reach and it creates trouble. Now, you know, I'm not the judge here. I don't know what people think. Hard suggests maybe we should just get rid of it all together. So Gary, what do you have to say? I know you've missed a couple of calls. You wanted to talk about this. Is there more you want to talk about there? I mean, I think Hart covered a lot of the stuff that's in there. I guess, you know, at the end of the day, I think I'm just trying to figure out why people, you know, and I remember even when we did this way back when, right? And I kind of look at it when we were like, you know, pushing forward and pushing for like 1-0 stuff in the early days of hyper lecture, right? And it's a much broader discussion, right? But there's back to my other comment. I'm not, I guess I'm not sure what people really think it buys them or means or, you know, should we have tied this to like a release? Like I guess, I mean, you can give numerous examples of projects that were big projects, you know, outside of the organization that the ASF is the best one to look at, right? It's the biggest one out there. There are projects that were being used that weren't in Apache, have a user base, right? They come in to ASF, they come in as an incubator and some, you know, spend a year in an incubator, right? Because they had to go through a whole bunch of stuff that didn't do it. You know, I mean that people weren't actually using the code. Kafka is a great example of it, right? Which was primarily sponsored by LinkedIn. So I guess that's where I, you know, I don't know, maybe we've made this mistake of like tying things together, right? I think if people want to use, you know, maybe if you're an outsider, right? When you're an outsider and you come and look at hyperledger and you say something's inactive, I guess you want to have the concerns of that this thing's not going away, right? That if I start using the code, that it's not going away. So, you know, to me maybe we, and people are, one, that the code is governed correctly, right? Meaning licensing and all that stuff, right? Because that's put in there. And two, you know, there's a bunch of those good attributes that we have, right? That are why people come to an organization. But I think the most important one is people would want to know, shouldn't stop them from using it, but they would want to know that the code is not going away. I think associating active status with the quality of code is wrong. Yeah, so we've tried to separate those two things and that's why we, but we have tied them in a way with the major release and maybe that's something we could decide to change. We could decide, you know, in light of what we are seeing also in the Explorer case, it's like, well, the code is mentioned here enough and you know, maybe they should be allowed to have a one zero release without being an active status. Let me ask the Bezu team. What's your motivation? I mean, this is an obvious, you know, question maybe, but why do you seem to want to, so eager to get there sooner rather than later? Part of it is that it's an indication of maturity in the community. And it's something that would distinguish Bezu from a project like Composer that was being aggressively abandoned and they're looking for people to hand it off to and no one stepped up. I think the big concern is there's no gradation between incubation and active. It's a big giant wall. You're either on the wall or you're not. And another problem is it's a one and done thing. Once you're done with it, you never have, you know, in theory the TSC could revoke your active status, it's never been done. But there's no gradation between our first day of the door and active status. If there was like a bronze, silver, gold type thing or like bronzes, you're on the hyperledger infrastructure, silvery as you're governing and gold as you have the community. I think that would remove a lot of the anxiety a lot of these projects have about getting to active level. All right, thank you. I also think just to, can y'all hear me? Just one thing is it's not necessarily a motivation. Like we thought we met the requirements. So it wasn't necessarily, you know, because we need the requirements, why wouldn't we apply if that makes sense? So just like looking at it that way, that's kind of our priority and we wanted to make sure that we wanted to, you know, if we, we meet them, why wouldn't we? It's kind of, I don't know if it matters what the motivation is as much. And that was kind of our window, our window of thought. All right, thank you. Anyone else? So what would happen to fabric if IBM decided to leave hyperledger? Do you see fabric being able to go on and continue with the developers it has independent of IBM? You're asking me? Well, I'll tell you what would it, well, there's a kind of a forcing function that it would probably have to happen at least for a short period of time, right? There's enough, so this is reversing it right from the beginning, but there's enough people out there who have built offerings around it. Big players who are taking money that they would likely have to, maybe we should, actually that's a good idea, Mark. Maybe I should just stop writing code and see what the Oracle and Microsoft and everybody else will start doing when there's no one to fix their bugs. But I think that's the interesting thing in there, but you are correct, right? I'm not opposed to Betsy, by the way, not, I don't actually have a problem that it's primarily maintained by other people in there, right? Tracy's points were the more important ones in the process and other stuff. No, my point was just, you know, we're trying to make sure that the project can continue if a particular company pulls out. And so I'm just looking at it from the different angle, what would happen to fabric if IBM pulled out or something, decided they're not gonna continue anymore. Yeah, I mean, there's the question of maintenance of the maintainer's diversity as well. As it was just said, I mean, you could meet the requirements at one point and then it dwells down and then you don't meet it anymore and what do we do? For me, sorry. I think these are good questions. We don't have an answer to, honestly. For me, some of this is setting behaviors that you hope continue on that, all right. Now people understand this isn't just my company's project, I've put it into this community setting in order to continue to mature it. It has to follow these community rules. And hopefully that continues on, but maybe one of those bigger contributors does go away. But hopefully the remainder of the community and the user community that's grown around it continues to fill in in the wake of that departure. I wouldn't be interested in trying to do like a continuous evaluation of whether something is in an active status. I think once you get there and you've established those behaviors, we're hoping you're just gonna continue those. It's kind of like passing a driver's license test. Once you have it, typically you keep it until you're forever. Bad example, they should be testing periodically. But they are not. I mean, it depends which country, but in France, they don't even expire. So you have them for life literally. So anyway, I don't want to spend all their time there because we're a couple of other points I wanted to touch on. But I think we, you know, what I take from this is there are a couple of specific issues we could consider in dependency. There is, you know, the hot question is like, the hot question is, should we just get rid of this for go the whole active status entirely and address this in some different ways? There is the question of whether the first major release should remain tied to this active status or not. And then there's another one which came up, we didn't really talk about it today, but it came up in the discussion that some of us had, including with Dano on the Wiki, which is, is there a way to put some kind of metric or formula to measure what the diversity, you know, what the diversity criteria amounts to? And, you know, if it's a percentage of different companies, a mix of what with the caveat that has come up in the discussion itself is, you know, as you, when you come up with a formula, people will work hard to meet that formula and it's more prone to, I mean, it's more prone to gaming. On the other hand, it's more objective. And the other way is like, it feels very subjective and, you know, they feel like it depends on the TSEs mood, which is not very good either. So, I, is there, did, so I have, I raised like three different issues that I would be happy to capture independently and we can address those. Is there anything else? Does that sound good to you? Okay, hearing none, I will take this as a yes. And so I will actually capture those and we can actually hammer those offline on the wiki. Thanks, Hart, for starting the discussion on the whole, you know, question of whether we should even bother with this still or not. So, let's move on with the agenda. We have a related question. In this case, we have a similar request now from the Hyperledger Explorer project. They actually admitted themselves in their report that they are, the diversity criteria is a challenge for them. I don't know if there is much more that needs to be said at this point, but there is also these problems, even maybe more specific to this project is the tying of the major release with the active status is kind of burning issue for them because they would like to issue a first major release and yet they don't qualify as a four active status. So, when we initially put in the criteria for becoming active before you could have your first major release, it was really about whether or not Hyperledger would expend resources to market around that first major release. But I can appreciate that project that wants to suggest that, hey, we're kind of mature and again, with Explorer, as Gary pointed out, there was a period where it was fairly dormant. It's been obviously kicked up a notch and is fairly active now, but I think there may be a problem of first impressions and people don't realize that and maybe getting to a 1.0 release but without all the hullabaloo might be a good way for them to signal that they're still around. I don't know, but I mean, essentially, I just wanted to highlight the fact that this was really about whether or not Hyperledger would expend resources to market by getting press and analysts coverage and so forth. But maybe we distinguish between, when we talk about a first major release, which would require an active project. I see. So you're saying maybe we could have a first major release with that all the fell far. Without the hullabaloo, right? Yeah. Yeah. I guess you know it all comes down to, I guess what people want to have is external vision, right? There's plenty, right? There are a lot of things that we want to do, you know, there's plenty, right? There are lots of projects that people even make products from, right? That aren't at like 1.0, right? I mean, the biggest one, again, I'll just keep going to it. The biggest one of the biggest ones out there, right? Was Casco, there's a few other ones, right? People out there who are running like early versions. But I like Chris's concept, right? I think there's, yeah, what do you get, you know, on time? Yeah, I think if people want to make a statement about where they think the maturity of their release stuff is, right? And then want to follow the kinds of guidelines, right? Of typical releases and maybe we should separate the two. Oh, we also did the scans, too, right, Chris? There was also the, you get security, you get the security paid for and testing and all that stuff. And you find memories, right? We also made an exception. Was it for Iroha where they had a first release with that, first major release without being in active status because we said, well, okay, fine. No, we were in active status. You said so. I don't think, yeah, this is Aleš from Iroha. I don't think this is true. We were in active status in, we are remaining in active status. And since I'm talking about this topic now, I would also like to say that I see the difference. And I think it would be a little bit funny to have a project at 1.0 being in incubation. That might send a very strange message to the people looking at the project and being confused, what does it mean? So I think we should be following the life cycle that is defined, but maybe redefine the criteria within the life cycle, if that is needed. I don't know. All right, thank you for that. And I apologize for the mis recollection. I don't know why I have this idea that we had some exception at one point, but I can't remember what it was exactly. One just happened like two weeks ago, right? Someone went 1.0 without. Well, that's an accident because they didn't know and they just did it with a telegust. Oh, okay. That's not really, it's not the same as having the TSC say, fine, you can do that. All right, so maybe Nick, since you're on still, can you tell us a little bit more what's behind the request? What do you, is it really the motivation for moving to active status? Is it really driven by this, I mean, the desire to release Explorer 1.0? Yes, as Chris mentioned that the 1.0 may have a trigger on contributors. And I'm very actively on rocket shot and people are asking when the major release is going to be in and I'm seeing a lot of people are using in production, but some of them gave me the feedback that they are using and their financial institution, banking, government, different types, but again, it's very hard to get the real company names. They don't want, they don't want because of the known Explorer issue. And I think that will trigger more contributors. And I want to mention that the project since beginning 2016, well, maybe at some point of time, it was not in a dormant, but still actively contributors like from DTC, Fujitsu, Alturas, Technalia and actively we are responding to people and we are making contributions. So a good point and statistics is to use GitHub insights and look at the commutes that were done against the GitHub. And even if the number of contributors, I think it's around 50, something like that. But that's only to the number of commutes and merges to the master branch, not other branches. So yeah, go to the insights. Yeah, that's a very good, I would say the contributors, go to the contributors to the left navigation panel. Yeah, contributors. So you can see the statistics. So the project was actively, is actively contributing with different commits and so on. So I think this is a very good statistics and metrics we can look at. And you can see diversity, well, me from DTC, Nikia from Fujitsu, Alturas below. Well, it's not specifically by the company because we know the GitHub, so you cannot go to the company email. But I think this is a very good metrics to look at and see how people, yeah, the clones, this is very important. People are using, and you can see unique cloners and then the visitors, they're very good statistics to have. I'm sorry, I'm gonna have to cut you off. I don't want to dig into this further now. I think this touches on one point that Hart brought up in his email, which is there are different ways we can measure diversity, contribution and all that and a take in general. And so I think we can talk about that in that context and the discussions is related to these issues. I'd like to spend the last five minutes we have on starting discussion on a point that I thought was very interesting that Daniel raised regarding the DCO and the use of pseudonyms. And I don't expect us to make any decision on this now and the issue was just brought up and I'm just hoping we can prime the pump so we can have a constructive, productive discussion offline so that we can move further on this issue. But essentially this has to do with this, the question of, I mean, the situation that we all face is that a lot of people use obscure ideas to contribute to open source. And it's, what is acceptable and what's not? How much do we need to know about people's identity? And so if you can click on this, right, open the issue. I saw Chris commented already a little bit and there's a few comments. I don't know how many people had the chance to look at it but I think it's a very serious issue. And we've raised that, we have faced that issue also when it comes to even building the list of contributors for the election, right? We have been facing this. The staff says, well, we have people we don't know who they are. We don't even have it valued in their address. So this touches on this issue. Fundamentally it's like, how much do we need to require people to reveal to be able to participate in our community? Well, if you're asserting that there's some legal basis and legal clearance of the code, which we do assert, then you have a lot more requirements than you do on the normal side, right? Yeah, so how far do you, so what's your opinion? How far do you think it's a requirement? I think you have to know that, I mean, you have a lot of options in there. I mean, you know, somewhere, somebody has to have a recorded record of who the person is. I mean, I'm just not sure why you wouldn't use real, I mean, why people have an issue in there. I mean, that's why you come here, right? That's why you come into a place that's supposed to provide governance of code. Right. I mean, the context here we have, and the whole purpose of the DCO is basically to assert that you have the privilege and the right to submit the code that you're submitting and that you're abiding by, you know, whatever the rules of the license are, in the case of Apache, that means that any intellectual property that you may claim on behalf of the code you're submitting needs to be granted a license to anybody who uses that code. So, and the thing of it is that it's Hyperledger Board decided tomorrow to say, well, we're gonna change from Apache and we're gonna use GPL or something. I'm not saying that that's gonna happen, but if we did, what we would have to do is we have to track down everybody that's contributed code and get them to agree. This is, and Bob, I think was on the call, you know, he tried to do this for Ethereum C++ client and, you know, fell a couple short because, well, that was for different reasons, but basically you need to be able to track everybody down and get their permission if you're gonna do something like make a license change. If we wanted to go from Apache two to three, we would still have to do that, right? So, I think it is important that the email address be something that you can reach. Another problem that we have is that a lot of people are making commits and putting essentially a dev null mailing address, you know, like something that's behind a firewall or something that's on their laptop or whatever. It just, it's not a real address, but it looks like one. And I think that's where we have the problem. You know, they say they're, you know, some fictitious name and they have a GitHub. We don't know who they are. It's not a matter of who you work for necessarily it's really much more about being able to contact you if we need to do something from a licensing perspective. Yeah. So, Dano, you raised this issue and when I read your message, thank you for doing this, by the way. You know, it wasn't clear to me whether you had any opinions one way or another because you put up all these different possibilities with a big range, you know, under the full spectrum. So, I do have opinions on how it should work, but I wanted to gauge the opinion of the, of the TSC to see if there's any existing policy. I agree that DCOs provides traceability to contact them, but if you read further down in the background, there's a couple of other issues. What do people operate under real sounding names? They're actually pseudonyms. And a different issue is can we accept maintainers who operate under pseudonyms? I think the second one is no. They could publicly have a pseudonym, but they would need to unmask to the TSC for maintenance. But for contribution, I think at some level, whoever's accepting it probably needs to know who it is. And I don't think we need to require them to unmask to anyone, but if you're committing someone's pseudonymous commit, you should know who they are. And I think that's a duty that a maintainer would have is if they're accepting pseudonymous contributions that they have as much level of certainty as if they signed the DCO themselves, that the contribution is legit. All right, so we're out of time, but thank you for bringing this up. I think it's definitely worth chewing a little bit more on this and trying to come up with some rules that we could write down and live by moving forward. I mean, to answer the basic question is like, we don't have anything written down on this as far as I know. So it's a good opportunity to do so. All right, so we're out of time. We can make sure we do there or another, so we should step back and make sure, what do we believe that the membership of Hyperledger and the people who are using Hyperledger projects actually believe that they're getting, right? Obviously they have to do their own diligence and accountability, but because I think that's the kind of key, right? I think that's that part of the, you know, the- I agree. So I encourage people who have an opinion to follow up on the wiki and please come up with proposals if people have specific ideas of what the answer should be. Raising questions is useful, but proposing answers is even better. So- And I know we're out of time, but maybe this is something that we should be asking the legal counsel, you know, whether that's Mike or- Yeah, that's what I was actually looking at. Maybe we should be asking legal what the legal deal is, because, I mean, the Linux kernel has been operating under the DCO since forever, and I'm sure they've been through this discussion. Yeah, that's a good point. I won't follow up with the staff. This team can answer right away or maybe Mike. Yeah. No, that's a good point. I will follow up with the staff and try to find out whether they have any answers to contribute. Okay, I don't want to drag this on any further. Thank you all for joining today. I think we had a good discussion. I look forward to continuing next week.