 But then without further ado, for your recording. All right, thank you. Hello everyone, welcome to the TSC call. I hope you've all taken note of the antitrust policy notice that is in front of you. If not, please have a look again. You should also be aware of the hyperledger code of conduct. Everybody is welcome to join this call and participate, but please behave. So with that being done, let's move on with the actual agenda. To start with, we have a couple of announcements. So Dave. I wrote a bunch there so that I could speak fewer words and keep this short. So the high level story is we are reorganizing the community calendar so that it can be managed through the list.hyperledger.org interface, which means that all of you out there that are maintainers or chairpersons of a SIG or working group will now have direct control over what meetings are scheduled and when they're scheduled and things like that. We finally worked out how to aggregate them all into a single community calendar, which we'll be embedding on the wiki and making available to anybody to subscribe to. But I've been running into problems with the fact that people who subscribe to mailing lists don't use their normal email addresses and so tracking down all the people that I need to work with has been difficult. So I thought I would come to the TSC meeting and I will be blasting this out on the TSC mailing list in a little bit. To get this going. So it really breaks down into four steps. The first one is if you are a maintainer of a project or you are a chairperson of a working group or a SIG, I need you to email me as soon as possible. My email address is right there. If you make the subject line, the name of your project working group or SIG and mod me, then I can filter them all out and deal with you as quickly as possible. Ideally, you would email me from the account you use for your mailing list address, but if you don't email me with that address, please put your mailing list address in the email because I need to map you to what you're known on lists.hyperlegia.org. So once you've emailed me, I will give you moderator status. And then the next step is to go into the Hyperlegia Community Calendar and look at what is scheduled for your group and make new meetings over on list.hyperlegia.org. And I have a couple of instructional videos there on how to schedule a meeting and how to delete a meeting. That's step one. And then down below on step two, subscribe or check out the feed from list.hyperlegia.org. That's the aggregate feed right there and verify if you can scroll down a little bit Arno or Rye, scroll down a little bit. Yeah. And once you've moved your calendar events over, go ahead and subscribe to the aggregate feed, verify that they're there. And once they're there, then go ahead and email me once again and say that your migration is complete so I can take you off the list. And hopefully we can make this migration as smooth and quick as possible. And then we can hand over the control to all of you and each of your groups. This, the reason we're doing this primarily is it removes me and Rye and Solona from being critical path for handling the scheduling of things. That's really what it is. And it's a nicer interface for doing an aggregate calendar for the community. So that's all I've got to say. So I have one question. I mean, there are plenty of entries today in the calendar. What happens to those? Are we supposed to delete those or what? In the community calendar, the existing one? Yeah. Well, the idea is that you would duplicate them over and into list.hyperlegio.org. Once I've ticked you off the list and confirmed everything, then we're gonna clear the old community calendar and delete it. And everybody will move to the new community calendar which is what I put there, that ICS link. Okay. All right. Does that make sense? Yeah. We just don't wanna get caught with nothing on the calendar at the moment, right? So we're gonna have both for a day or two, hopefully. So listen. Yeah. Are we... So I just tried to open that and it downloaded something and not opened it. Look, it's an ICS file. Yeah. So how do you actually view it? Well, you can go to calendar.google.com and underneath other calendars, you click the plus button and then you select from the list from URL and you paste that URL in there. Now, I don't recommend doing that because Google Calendar only refreshes external calendars once every 24 hours. So you're not gonna be able to see your changes immediately if you're trying to verify you did the right thing. I recommend using, I don't know, Apple Calendar or any other calendar viewer. I mean, Google Calendar is fine. Just know that there's a 24-hour delay. It'll only refresh once every 24 hours. This is why it's important for you to use to make sure that you've registered your other one, the correct one with Groups.io because you shouldn't be dependent on the Google Calendar. You should be depending on your own personal account under Groups.io. That's correct. The Google Calendar is for that aggregate view and so that people can do the subscriptions that they need. It's not for an individual to be using. Correct. So is there a way from Groups.io that I can get to the calendar view? Yeah, if you log in to Groups.io and then go to your account and click Calendar, that will be the aggregate calendar for your account and your account, it will show all events for all Groups that you are currently subscribed to. Right, so how do I see them for the Groups that I'm not subscribed to? Well, then you would need a calendar viewer and you would need to subscribe to the aggregate calendar, which is linked to in the TSE agenda for today. Okay, so my original question before I clicked on the link was, you want the folks to move these over instead of you guys moving them over? Yes, and the reason is just because, yeah, that's the request. And the reason is is that when you subscribe or when you've signed up with Groups.io, a great many of you, you use different email addresses than what I know you as. And so I have a list of all of our maintainers, but that is a map to the email addresses in Groups.io and I need to go into Groups.io and grant you moderator status so that you can manage the calendar for your group. And so I have to do the mapping between the list of emails I have and the list of emails that Groups.io has. And so I'm asking that you all email me and say, this is what I signed up for or signed up with so that I can track you all down and moderate you. So just because I know this is true, there are people who don't attend the TSE calls there are people who are not on the TSE list. There are people who don't even subscribe to their own project mailing list or their own group mailing list. How are we going to make sure that everybody gets this? I am going to email them. Oh yeah, to answer your question, Tracy, it's a good question, right? So I'm doing this to get the low hanging fruit. This will get probably the bulk of you. And then the remaining ones, I'm going to email them directly using the maintainers list I have. And hopefully that will work. And if there's any remaining ones, I will email their mailing list and say, hey, does anybody know who's running this? Can you email them? And we'll track them down. There'll be a long tail. It'll probably be a couple of days, if not a week, tracking everybody down. A couple of days, I think you have seen me speak, but. Yeah, you know. I'm going to do my best. Well, another issue that we're trying to resolve here is we have a lot of meetings that don't exist, right? Yeah. There are just duplicate entries and we don't know who has them. So there's a lot of cleanup that we just can't do through Google Calendar easily without deleting everything and starting over. So yeah. And leading us to this point. That's essentially what we're doing here, right? Sorry. That's essentially what you want us to do. You create a new calendar, eventually we're going to get rid of the old one. That's great, yeah. And as you create the new one, you want to make sure you know who owns what. Correct. And I want to make sure that we are, the ones that are accurate in the community calendar get properly moved over to the new system. Yeah. And they have control. So from here on out, you don't have to come to us anymore. Everybody has control of their own stuff. And we've also been noticing that some of the other groups have been doing other small things that haven't even been registered with us and this becomes a way for them to all be registered now. Yeah, I mean, it's kind of novel that the open source group dedicated to distributed systems is now going to distribute control. Okay. I've given you enough of the time of this call. Thank you. Thank you. If anybody else has more questions, please reach out to Dave. And if there's things that are valuable to everybody, at least mail it to the TSC list or put it in the TSC chat. Yeah, chatting me if you need me right away is probably the most efficient way. All right, let's move on. Just quickly, I wanted to echo an email that Jessica sent a few days ago. There is a contributor marketing committee meeting and every maintainer and a contributor to one of the Hyperledger project is invited to attend this meeting is to try to get a better connection between the marketing folks within Hyperledger and the technical folks. I actually attended that call last month and I thought it was quite interesting. So I encourage you to do the same. There's a link there to the email from Jessica. If you missed it, it does all the details on how to join this next week. In terms of quarterly reports, there were two of them that were due. We received one from Hyperledger borough. I don't know if there's any questions. There was a comment or kind of a call out from the borough project to the TSC regarding drawing more attention. They are, you know, I think it's fair to say so. Less for one has been banging on our door for a long time now, trying to get more attention and, you know, getting people to help out with borough. And so I noticed there is another call of such call in the report. I don't know that there's anything specific we can do right now, but I just wanted to highlight that. And I wanted to ask if anybody else has any other questions, otherwise. Most people have reviewed it. I didn't see any comments. So I assume we're okay with this. Yeah, I think that marketing committee meeting that you just mentioned is probably something, I see Sean is on the call. So that's probably something to attend and maybe you can get some ideas there for promotion too. Okay. Let's see if there's more in there. Okay, so otherwise the performance, the working group report is due. So please try to get to it when you have a chance, Mark. So let's move on to the crux of this meeting. I am a bit ambitious, but I, you know, we'll see how it flies, but I, so Mick is on the call. I delayed this discussion last week because Mick had informed me he would not be able to join the call, but the working group task force has been busy and came up with a whole series of propositions, proposals to the, to the TSC. And I kind of put them into formal proposals to the TSC under the new decision lock system we have. And I think I can kind of summarize it, although maybe Nick wants to do that. Or maybe I give it a shot to try to expedite this. And then Mick, you can tell me if I'm missing anything. As I said, now we can figure out if you understand. Yes, exactly. So, you know, essentially it comes in two pieces, right? The first, and I kind of reverse this from what the task force put together, but I'll explain. So the general idea is we create a new type of group called the task force, which is limited in time. And as a clear specific delivery, they're deliverable, okay? The launch is that, you know, somebody has to put a proposal before the TSC and the TSC has to approve it for the task force to get started. At the end or by the end of their timeframe, the allotted time, the task force must report on what they have completed. If they need to, they can apply for an extension, but it's not automatic, it's up to the TSC to look at this. So if we agree to do that and, you know, I'd be inclined to, you know, have one vote that encompasses those four, then we can say, well, if we have task force, we don't really want to keep going with the working groups as they exist. So we can transition the existing working group to a new type of group that is, doesn't have this, you know, characteristic of having a clear deliverable or set timeframe. We can call technical special interest group or technical interest group for shorter. I saw a deep in mention, we could make it shorter, which is fine with me. Let's not fight over the word now, the name. And then we just stop creating new working groups, which is the last piece, working group shall be dropped. It's essentially, it doesn't mean we're killing the existing working groups. The existing working groups get transitioned to this new TC got TIG, but we no longer create working groups. That's what the last piece is about. Mick, how am I doing? That's right on the ball. You got it. So, and again, this is just, this is really a reflection of a couple of things. One is that, the working groups are having a hard time describing any form in which they can have impact on the projects in their current structure. Two is that because of the frustration with trying to do both sort of work items, membership in the working groups for everyone that I've talked to has been going down. They're challenged with the current structure to get people interested and excited in it. And the task force model seems to be working really well. So let's just formalize that. That was the gist of it. I have a quick question, Mick. Do you see the TCIGs as being sort of the long running meeting place and then seeing task forces spinning out of TCIGs to get work done? Like serial task forcing out of a TCIG? That was kind of exactly what we had in mind. That in our experience over the last probably 12 months, specifically with the architecture working group, the meetings that are most well attended are the ones that are informational. So we bring the Avalon team in and we say, talk to us about privacy and how the privacy works. What are the expectations for it? And it gives us a way of doing kind of some deep dive informational exchanges on it. And then that comes out with information that a variety of projects can start taking advantage of in their own project spaces. So it becomes a way of just sort of educating. And then my expectation would be that things can come out of that, which would be a task force like, oh, we need to have somebody that can sit down and actually give a definition for privacy and confidentiality that Hyperledger will use consistently. I mean, and that becomes a task force. Excellent, thank you. Any other questions regarding any of this? Yeah, wonder if we could reach similar ends by just setting timelines in the existing working groups? It was one of my observations with the working group health was that it seemed to be related to its duration. So like the DCI working group is young and so the deliverables for that group are still relevant and the activity around it is still strong. But a working group that had been created maybe near the inception of Hyperledger has kind of grown distant from its original goals. And I think that's a factor in decreased participation and decreased focus. So if we just took the existing working groups and had them recharter with a specific deliverable and a specific end date, then we wouldn't necessarily have to create a whole another set of, I don't know, group structures here. So how would you make, for example, something like performance or architecture or even some of the educational focus once fit into that model? They are, and the reason I ask that is because they are in fact long running communities of individuals who are trying to interact with one another. The specific struggle that they have has nothing to do with their shared interest. It has everything to do with the fact that work products that are created there in that charter have historically not had any impact on projects. Yeah, so I think that's the thing is finding the work product that rallies support and engagement. And so I think- Could you give me an example? Right. And I hear what you're saying, Dan. I'm struggling because I have a hard time coming up with examples of the kind of work items that could come out of there, which are not things that fit very naturally into what we've been describing as a task force. Yeah, so I've got an example and a counter example. So the counter example would be, actually I just lost my counter example. So the example would be maybe for something from the architecture working group is doing an assessment on consensus and designing an idealized consensus API and then issuing that out. And that's not a requirement for the projects to adopt, but if it has intrinsic value, then the projects are directly motivated to want to adopt it. Right, but that's exactly- That kind of work item is exactly the one that has failed in the past because those of us who end up participating in it spend a hell of a lot of time putting it together with the knowledge that there's no way for us as an external group to be able to get adoption of that, so it's really wasted work. And that's the perception of that kind of deliverable right now, which is what we're trying to get away from. Let me turn around to the example that I think is a better example is the paper that the performance working group came out with, which had influence on caliber, which is defining the set of metrics, the language of performance, and then aligning calipers work with that. I think that's the best success story that we have right now for high-level, top-down driven work coming out of a working group, but that's the exception, not the rule. So the real thing, Nick, on that is why did that one, I think is why that one works versus one like architecture doesn't work, right? And I think the performance one works, right? Because there's a shared concern there, right? And people are looking at performance and people are starting out on the tools. I'll be blunt, why do I actually care about the architecture working group? Nobody in the architecture working group contributes to products. You shouldn't, that's the point. Our projects, sorry. Right, so yeah, so I think the point is, right. Well, we all do, but we all do, but it's a bit of a different way. The old head didn't contribute one line of code to any project, right? So. Well, I think maybe that's an old statement, but the. No, it's not. Well, he never contributed a lot of code and that's fine, but then what the expectation of the group is, right? So that's the best real year thing, right? Is I don't have a problem with people having groups, right? It's just like he said, you know, was there some expectations that the group was actually gonna do something that was going to result in something and then maybe people like Nick and others will get frustrated because it doesn't. That I guess, what do you do with those, right? So, so I think what we're saying, Gary, I think what we're saying on this is if there, when we formed the, when we formed the working groups four years ago that the idea in mind, at least from the architecture was that we will come up with the idealized architecture and that there would be some teeth associated with that and we would drive some convergence around that architecture, right? That the convergence, that the sort of target goal for convergence would come up with, that's a completely unrealistic. I mean, it's a completely unrealistic goal, right? We know that, okay? What has been successful over the last year in the architecture working group is really much more focused on informational and educational, right? It's bringing people into the projects and trying to get cross-project communication happening and education happening rather than driving a model of consensus around it. So that it's that model for, that's what we were trying to call the T-Stick, right? So that the focus is not on work products but the focus is on dissemination of information which can seed other things which might lead to work products specifically in the task force. So it's kind of an acknowledgement of what you were saying, which is it can be a useful environment even if we're not contributing. No, exactly. I wasn't saying that it's not useful, right? I was just saying that it was, like you said, it's just hard to measure things that's deliverable. So yeah, that makes sense. So T-Sticks, we call them interest groups, I guess, right? Versus we don't want to have another term of community or whatever, right? But yeah, they're basically like community of like-minded people that want to get together and... Share information. Yeah. So, I mean, back to Dan's point about the naming and stuff. I think, you know, there's a little bit of overhead creating a new kind of group at the same time where, and, you know, we're going to eliminate working groups. So it kind of begs the question, can you just create the new kind of group and do the same old name of working group that I can appreciate the task force as some, you know, there's some semantic associated task force which is much more like task driven, short lived that you probably want to carry through within the name. So I think in overall, it's a reasonable approach. So in the model where we've got SIGs, it seems one of the risks would be that like the working groups, when there's not a deliverable to drive to, it's harder to maintain active participation. How would we address that? So, Dan, we... In the working group or the new groups, you mean the TK or TC, whatever we call them? Yeah. Dan, we've actually found the opposite to be true, that the more somebody is focused, the more a group is focused on deliverables, the less participation becomes. So... He was scared. So people just, it's hard to get people to do work. And if you focus on work, you'll have less people show up. That's, at least that's been my experience. Yeah, I've had slightly different experiences. I guess we don't need to get into the ins and outs of those, but I guess the relevant one from the performance working group would be that when we were getting towards producing an artifact, we had a lot of discussion and engagement. And after that work product was complete, even though we occasionally had presentations from performance-related speakers, there was never quite the same momentum. And Mark, you can... So Dan, I appreciate the concern. I think it's not a big danger though. I mean, we'll have to keep an eye on those new tigs or whatever we call them. And eventually, if something is really dormant, we can always pull the plot, yeah? They are fairly low off. I want to also point out that that is one of the few documents that the TSC gave teeth. If I recall, there was a lot of talk that, you know, Caliper needed to follow the recommendation of the performance-scale working group. And that was something that the TSC indicated had to be done. So that was one of the few working group deliverables that actually had some kind of teeth. That's a good point. All right, so any other concerns? I would like to get to a vote if there isn't any major obstacle. Oh, no, I just, I want to echo your comment about the names, right? Just in thinking about all of the changes that have to happen to our existing, you know, the Wiki, the mailing list, the chat channels, all of the places where we call these things working groups. If we change the name, we have to change all of those places to reflect that change as well. So just echoing kind of your, what I think you were attempting to say, right, which is, do we want to rename them or do we want to just repurpose what they are into these discussion groups? I believe the name is the same. Yeah, that's kind of what I was inting on. I mean. Sorry, I think that comes in to you, right? Yeah, and Tracy, I don't, I was going to say is that I don't think we're, sorry, I don't think we're bound to a particular, yeah, I don't think we're bound to a particular name. The only reason that I wanted to make sure we called it out here differently was to just make sure we reinforce the point that there is a change in role. So it was not about the naming of the other things. I mean, make the decision about, keep calling the working groups and just drop the requirement for deliverables. That's perfectly fine. The only advantage in the name changes is that it does reinforce that there is a change in role. Can a working group still optionally create a work product? Yeah, of course. Okay. I will point out that I did just create a GitHub repo for I think the identity working group on the depends request. So I think that's, you know, was created with the assumption that the identity working group would be creating work products. So I think the answer is, yeah. All right, so I think what we're talking about now is not to create the teams or TCs but to keep working groups for that. Is that right? Yeah. So it would affect the last two proposals. But so I would like to move to approve the first four as the first step. So basically approve the whole task force? Yes. Process. Yeah. Okay. So let's, Alpha, Bravo, Charlie and Delta one, A, B, C, D correct? That's correct. Okay. Maybe it was to say again, this? Second. Second. We have just a click on the item so we know everybody has the text in front of them for specifically what we're voting on. If by everyone we mean the ML, then sure. I don't remember what we're doing anymore. I need to translate. That's why I asked you guys to look at those before. Then you signed off on every one of them. You've looked at them and you? I have. You looked at them at the time. And on the first one, I did have a question like, what does it imply when we're creating a task force? So this is one of these things where we don't necessarily have action items on there. I guess those action items are pertinent to the motion itself, but when we create a task force, what kind of infrastructure are we imagining around that? It's probably a pain if we create a mail list that goes away. So I'm thinking probably not mail lists, but maybe Wiki space is implicit or we just do all those things on demand. Okay, I appreciate the question. And it's a bit like, you know, Tracy commented, what's the action item? And to me, this is an implementation question. I would like us to agree on the principle and then we can sort out how we implement it. And quite frankly, I think we could let the staff, you know, come up with how they think we should implement it. And then we can go from there. So we already had it was posed. And did we get a second? Is there going to be a vote? Yes. So I didn't want to. I mean, I don't know if Dan was kind of objecting to moving forward with this. I was objecting. I just wanted to make sure that we were all clear on what we were doing there. Okay. So there are certain details that are not sorted out yet. Is what basically this comes down to. And I, you know, I'm happy to acknowledge that. But I think we would be moving forward if we could agree to those four first proposal. So I'll ask everybody who agrees to say aye. Aye. Aye. Aye. Aye. Aye. Doesn't have to be sequential, you know. Okay. Anybody who is objecting to this. Anybody wants to abstain? Okay. Hearing none. I'm happy to declare it approved. Thank you. I think that's a victory. So one question. On a previous topic. I had the impression, I guess, that task forces were for the work product. And I guess we just said working groups would also have work products. So. Perhaps I'm a little confused on the difference between these two. Structures now. So I think task forces are aligned around work products. Working groups are designed for informational exchange. But if they do create work products, they do create work products. Does that make sense? Also, the task force has an explicit timeline. Right. So the working groups are not timeline still. And could produce work. Okay. It'll be interesting on how you differentiate if you should do the task force or working group, I guess, but. Yeah. Is there a recommendation to the working groups to recharter as task forces and ticks? No. So it sounds like we're not going to rename a working group to a T SIG or whatever. That's right. So, okay. Right. I appreciate your eager to mark all of these. Result, but I'd rather we move forward with the agenda and get to the other proposals. I do think as Dan just talked about, I think we are basically based on what we said before, we're not really going to do the E and F, which is the working groups transitioning to some other names. And so we're not going to drop the working groups. And, you know, my take on this is, I don't know if we want to come up with a new proposal on the fly. We leave those alone for today. And for next week's agenda, I can put a new proposal that says exactly what we do with the working groups. I do think we need to. Yes. Somebody wants to say. That's going to say we can probably do a proposal on the fly. Okay. So I think we would not approve any of those two proposals. And instead, what is it? I think it would just be to drop the work product requirement. Okay. Yeah. We just say that working groups shall be focused on information. Exchange. And not have required work products. We should just say working groups. I think we should just say working groups don't require a work product. Because it's a working group. So working groups don't have starter end or. Anything other than they're there to talk. That's right. Yeah. The basic communities. And the work product is, if they make one is supposed to be. A summary of the talking. No, it could be whatever they want. Do whatever they want. I think there's just no mandate. There's no mandate. So a task force is, you think about this way. It's like a task force. I'm going to come up with a mission. That mission has a timeline. It has an end deliverable. That's a task. Right. I get. Quick stuff. The working group. We're just putting no restriction on what a working group can be. But it's basically people can meet together. Discussing. Whatever. Common topic they want to do. And then they can have any outcome they want. Could be chat minutes. Could be nothing. Could be some handshakes. Could be some friends. Could be a work product. With no timeline. And really. Okay. And do the working groups launch the task forces or the projects. Or either. Hi. It's not a tricky. Can I give you a good example from my work group? Okay. So. When we get recruited from the edX people to edit. Of course that's going live. That would be a task force with a timeline. But when we supply templates for the projects to do. Use cases or white papers. That's something we work on all the time. And that's there for everyone to. Access along with all documentation from the projects. So that's something that's continually. There from our working group. As opposed to a task force item. Like the edX updates. Does that work? Ready. I think that. This makes sense to me. But I. I think there's still the. A question around. Does that work? Does that work? Does that work? Does that work? Does that work? Does that work? Does that work? Does that work? Does that work? Does that work? I don't think that works to me, but I. I think there's still the. A question around. What do we do with like working group. Working group updates, the quarterly updates. Are they hanging around? Are they going away? You know, is it only the task force that's going to be reporting back. So. I mean, I'm. I'm perfectly fine with where we're going. I just think there's. More for us to consider as we move forward. All right. I'm going to move on. I think we, it's not working out really well to figure this all out now. I don't think that's the best way to use our time. So. I'm going to stop the discussion on this now. And we can all think about this. And hopefully our discussions on. We can bring that up to the agenda. We can all go online. As to, you know, what we should do. And we can put that up next week on the agenda. And instead I would like us to try to close the next set of issues, which are related to the project life cycle task force. So we had a good run with the life cycle. Task force. We closed a lot of issues. But there was one. I've motivated the whole thing in the first place was this notion of how we deal with sub-projects. And, you know, it was on my plate to go back to what the discussions that, you know, where the discussion had left us. And I did that yesterday, and I figured that actually we could probably close this because they seem to have convergence about what to do. So there's a set of three proposals. The first one basically says that sub-projects are not formally defined, which means they don't come directly under the governance of the TSC. And so there's a bunch of things, and maybe this is worth clicking on it if you haven't looked at it because there are some, you know, additional implications to this, including the fact that it means that the top projects have to, when they do their reports, for instance, to the TSC, they must represent all the different efforts related to that project and not just maybe what might be considered to be the core one. And there was the, it does imply that there is some kind of governance mechanism within the projects themselves, which can become fairly large, including things like fabric, where we have quite a few different repos and different sets of maintainers, and all these people need to figure out together how they govern themselves, how, you know, who gets to become maintainer of what, and ideally all of this really should be documented. And I'm expecting that the repository structure task force will take that into account and address that by specifying, you know, what should be there so that we would have some consistency over all the projects. At the end of the day, of course, the TSC remains the arbitrator, the ultimate arbitrator. So if there is a conflict within the project, they can't figure it out on their own. They would escalate to the TSC and TSC would take care of it, but that wouldn't be the first thing that happens. So that's the first part. It's pretty big. So maybe I can stop there and ask you there are questions about that particular aspect. So I put a question into the highlighted area. Yeah. Project should document, yeah. So this project should document thing. Does that become an artifact that's reviewed by the TSC then? At what point? You mean from... I mean, that is a separate question. Yeah, I don't know. I think, like I said, I would expect this to be addressed as part of the structure. So I mean like... I think the answer is no. Well, there are two spots that we review artifacts now, right? One, you go into active and the project proposal, but I guess my comment was the TSCs, I guess primarily a governance oversight kind of body. And I would have some assumption that the underlying governance of projects might be a reviewable item with that kind of scope. So that's why I was asking that question. Dan? I was just saying that, no, I thought that the short answer to his earlier question was that, no, we don't specifically review that as an independent artifact. I think guidance... Shall we say why not? I think it's open, I guess, to review at any point that we would be at a milestone, the milestones that you were bringing up. Okay, so if I understand that right, you're feeling like it should be reviewed. It's not independent, but it's part of milestones. So I think what Troy is touching on, tell me Troy if I get that wrong, but maybe like when we have the change to active status, is that something that should be documented and that should be checked as part of the course of graduating to active status? Oh, I guess my first question was the generic, like I thought it should be. And then the second part would be at what points, but sure. So maybe you shouldn't have asked the question instead you should have said, I think this needs to be reviewed. You're correct. My intention was, I think it should be reviewed, yes. Okay. At this time, I'll rephrase it differently. Because yeah, making it an open question leaves everybody wondering, what's the right answer here? I don't know. Okay. Like I said, I just feel like basically the TSC does governance oversight stuff, like I said. So this just seemed like a direct governance thing. No, I think that's reasonable. Any other questions or comments? Otherwise I'd like to move on to the next one. I was just gonna say, I think the repo structure can provide guidance around making sure that it's included in one of the documents that goes into the repo. And then I agree, we could review it at the point at which a project decides that it wants to go active or whatever that state is that we decide that we need to make sure that people, to me I feel like going active is part of making sure that your community is set up to succeed, if you will. I can do releases and part of doing releases is talking about really how decisions are made. So to me, active status kind of state makes sense as a review milestone. Okay, so I think again, so you agree that they should be addressed as part of the repo structure stuff. So let's wait for the repo structure task force to complete its mission. And then I would expect once there is a repo structure that we all endorse that we make that as an exit criteria to move off incubation. So let's go back to the list, right, if you will, and look at the next one. So there are two related proposal. The first one is housekeeping is that there is a bunch of projects that were officially labeled a stop-level project because they were brought through the heap process. And even though we've never actually handled them that way in practice, we don't have quality reports from any of those. And so this is just housekeeping, say, okay, once we agree about the former, we can just say, okay, all these projects that were created as top-level projects, but really were not handled as such will be officially rolled into the related project. In practice, I believe all of the ones that are impacted by this are fabric related projects. So they would all become part of fabric. And as far as any of us knows, there's no actual artifact that needs adjustment on the Wiki or the web pages or anything like that, right? Yeah, it's just because people have asked the question now and then say, hey, what about this? And so we would just have a record of that. Yeah, well, they might have been brought up as project, but really they're all part of fabric and that's it. So hopefully that's not controversial. And then the last bit is about the how we handle proposals and in practice, I mean, this is just endorsing or making official what we've been doing. I have to give it to Dan. I mean, he kind of led the way there. In, you know, when people proposed the TSC new project that seemed to be very related to a specific project that exists. And we've seen a few of those, for instance, related to fabric. And what this basically says is, as a first step, we'll encourage the proposers to bring their proposal to the related project, see if they can just join that community, that project, become part of that project. And if that works out, then everything is good. If it doesn't, then they can come back to us and then we'll look at it again, see if it deserves to be created as a separate project or what. So this is how we've actually been handling the last several project proposals we received. So, and it seems to have worked quite well. So this is just to make it official. Any questions or comments about any of this stuff? Okay, ring none. I would like to propose we approve those three proposals in bulk, like we did for the previous set. Seconded. Thank you. So, everybody in favor says hi. Hi. Hi. Hi. There are a lot of silent people, but okay. It's not very loud crowd today. Okay, anybody wants to oppose object? Anybody wants to abstain? Okay, hearing none. This is hereby approved. Thank you very much. I'm happy to say that this not only closes those issues, it actually completes the mission of the project life cycle task force. We have no more open issues related to this at this point in time. So, thank you. All right, so we have a few minutes left. I wanted to try to get back and I put that last on the agenda because it's a bit more open-ended. The last point is, no, the last point is the TSC election voters election. We started talking about it last week. We're a bit all over the map and I would like somebody to take a crack at coming up with a proposal on this. And, you know, I don't know, I mean, I haven't tried myself. Maybe I can do that if nobody else does, but I thought maybe somebody would be willing to do this. So I guess the question is, if we start from the simplest and then see what's wrong with it, maybe that's an idea. Like the simplest would be collect the commits from the get repose. Yep. Yeah, and my understanding in the past is that there were a bunch of things that were not collected when we did that. We wanted to have a way of including those things. And the first effort here in the comments is to try to move as much as we can to get so that, you know, papers we write and other things start to show up as get commits. And then the second question is how do we catch things that might not, that might still fall through the facts and how do we have a coherent process for that? So I'm really good back to Rai because he was in there last week and so Rai. Oh no. You're the one who had the trouble of handling this whole thing and the like the moving target over the years. So what are the biggest problems with the way things are? Of things we did last, I mean, this year? It was the inconsistent way that we gathered who was eligible to vote and the inconsistent understanding of who was eligible to vote. You know, at one end, then, you know, the proposal, you know, if it didn't get, you get to vote. If it's not, you don't. That's a very attractive place to start. The thing is a lot of people, particularly on GitHub, don't use valid emails. So that's another problem. And other difficulties were, you know, the email addresses change over time people change where they work. And even if they were valid at one time, they are no longer valid. And then beyond that, it was getting in touch with people and getting into the vote, which led to probably a very low voter turnout. So I know that last week, Tracy pointed us to this script that she is. They'd love to try to gather the new stuff for everybody and all that. But it seems to me that- I still heard back afterwards that none of the Chinese actually even got the vote from the software that we're using nor did the Brazilians. So there were also problems with that, even though we had double checked and gotten emails from them that should have worked. That sounds bad. And I don't know exactly what to do with that because that isn't something we can fix easily if we do things driven by email. And Condorcet is part of the charter for the TSE. So if we're gonna change the way we vote, we need to change the charter. Yeah. So I mean, you can see on the page right in front of you, 43 comments. So it's not like people have no opinions on this. The problem is when I went through all the comments and to now at least, it's a bit all over the map. Those who go say, hey, let's just go. You know, let's restrict the list to the commuters, the commuting and make sure they are like valuable contributions and to know anybody can, we should include everybody, the lab, the TS, no, the SIG, what is it called? Yeah, SIGs and whatnot. So my, because problem right now on this issue is, I don't know how to, you know, what to aim for to try to gain convergence. So I don't know if anybody has a magic bullet there, but... Well, the closest I've heard on this call is, we stick with commits as the eligibility and then the operational challenges of dealing with emails. We probably need some more discussion on how to resolve those, but that could be even just better communication in the contributing guide. I agree. And maybe it's, you know, isn't valid then, then I mean, maybe not part of the vote. Yeah, I mean, I think it's fine to, I mean, I know Solona doesn't like having a public email. I can see that in the chat. But I kind of think it's mostly okay. I mean, like, if you do any kind of like paper writing, then your email is already public anyway. So... So what is the alternative that someone registers there? I have a diversity problem with that. Requiring me to have a public email means I get some really insulting letters just from being female. So I am very opposed to sitting there saying that I have to keep up and monitor and do things like that with a public email. I think people deserve the right to have privacy. Can I ask a question? Yes. Sure. So, I mean, the alternative to that would be, if you want to vote, you would have had to register your public email address privately with Hyperledger staff. That's cool. And then it would be a simple association and... Yeah, and if they don't end up in the vote. Yeah, if people want to do that, that's totally fine. We already have this in place. I mean, LFID could be used for this, right? If you used an email and a password rather than a social login. Yeah, I mean, I think an LFID is not a bad way to go here. Yeah, but LFIDs don't always have an email address. So that alone doesn't solve the problem. We're out of time. I'm just saying, yeah. Yeah. So this confirms what I figured is that, you know, this is not an easy one. So I am not sure if anybody has some bright idea, please chime in. Otherwise, I don't know, we're gonna make progress on this. With this being said, I'm glad we... No, I'm sorry, we have time, we have to close this. Let's keep it going next time. Thank you all for joining today. I'm glad we have managed to close quite a few issues, some of which are pretty significant. So thank you, good work. Talk to you next week. Bye.