 All right, thank you, this recording is on. Yes, thank you. All right, welcome everyone. This is the weekly TSC call. Everyone is welcome to join. There are two requirements to joining though. The first one is to live by the antitrust policy, the notice of which is currently displayed if you're on the Zoom client. And the other part is the code of conduct, which you all should know about by now. And with that in mind, everybody is welcome to listen in and participate, hopefully in a constructive matter. So is there any announcements? Okay. So we had a whole bunch somewhere. Yeah, I guess maybe we can do it during the discussion items for the election. But my announcement was that the call for nominations has started. I published it in the agenda. So there's a link to a page that shows the email that was sent out to everybody and it has instructions for how to nominate. So basically, yeah, so basically, what Dave is saying, we are started implementing the TSC election plan. There are some issues. And so we will be discussing this later on. But so as I was saying, we had quite a few quarterly reports sent out, some of which were from the week before somewhere late. And we just had a couple more added within the last 24 hours or so. I don't know that everybody has had a chance to look at them. I did go through all of them. There is one issue really that will need to be discussed. And it's the Bezu team is asking about the use of SamVare. They're interesting in switching to a different system, which is calendar based called CalVare. And currently, this is a TSC decision that we really should use SamVare. So switching will require TSC discussion. I think it's, you know, there's enough to discuss this that I don't think we want to get into this now. My recommendation, Dano, is to bring it up actually as an issue. We can open an issue in the decision log to get that discussed because I don't think this is going to be a quick one. We should have a formal resolution. I mean, essentially, there are three ways either we accept that as an alternative, we force everybody to stick with SamVare or we force everybody to switch to CalVare. I think none of the above is an easy decision to be made. And people are going to want to discuss why and really is that necessary and whatnot. So tell me if I'm wrong, but I think this is going to require more time than we should spend during the quarterly reports. Do you want it on the Wiki or do you want it in the GitHub? Yeah, on the Wiki, we have that. You go in the decision log, you create another proposal that says, you know, you can look at what I did for this, the rollover policy, for instance. Got it. I'll have it ready for next week. I like it. It's like a star date then. Basically. But when this got started, like way, way, way back, the decision was, we went with SamVare just to prevent people from having crazy numbers. And so, I mean, it's good to have a system. I don't know that we all need to use the same system. And there's also consequences about what is a major promoted release and what isn't, right? And it was easy with SamVare, we would just say, when the big number changes, right, the top number changes. Because we spend money for promoted releases. We do audits and we do marketing and all that. We already went away from that. That's a good point. You're breaking up. What was that? Heart. I had lost heart. Yeah, I put heart on mute because that was an audio storm. Yeah. My apologies. No, it's terrible. Sorry. Try again. I know he's just muted again. Okay. All right. So anyway, I, yes. Oh, sorry. I was just saying, didn't we go away from the major releases being tied to, you know, 1.0, 2.0. And we said that people could just ask for the TSC for major releases? You're right about that, Hart. But, you know, it wasn't like, oh, everyone, you know, you don't have to do the number, but it was recommended to. Yes. There was a, to get back to Hart's point, we did move away from major releases to what we call now promoted release, acknowledging that, you know, those two things are not necessarily the same. Right. Cause Fabric 1.2 was a promoted major release. What was a promoted release? But so this is exactly the kind of stuff we have to take into account in this discussion, unless everybody agrees right off the bat to say, yeah, they can do Calvary if they want to. And we just have that as an option. I think otherwise it's probably going to take a little bit of discussion to understand the ins and outs, such as what was just bought up. So my inclination is, I mean, it doesn't sound like this is an urgent matter that needs to be solved this week either. So we should just create an issue for this and take the time to discuss it and maybe have some discussion offline. People can react to, you know, and we can get everybody's ideas. I mean, frankly, I had not thought about all the things that had been brought up already just in the last few minutes. So I think more might be brought up if we give people a bit of time to think about it. So is there anything else from the reports that people want to highlight or ask about? I didn't see anything else that needed to take TSE called this time. Okay. If nobody has anything, then I think we can move on to the discussion part. Thank you all for those who have put the reports together. We're cranking. Okay. So, well, so I had planned to talk about the rollover, but given the urgency of the TSE election issue, I will insert the, I thought Dave, you said you were editing the agenda, but I don't see the modification of the page. You've not published that yet. Let's talk about the TSE election first. We need to take care of that. How about that? There it goes. It should be published now in the minutes, not in the agenda in the minutes. Oh, well. Okay. Fine. Let me throw it over into that here. Tell people what do they need to do. It's all right. Let's get to it. Dave, what's the status? What are the issues that are we already know about? Okay. So the, we're currently in the process of accepting nominations for the TSE election. We've been running, I was running the scripts all last week gathering emails and trying to track down duplicate emails and figure out which one they wanted and, you know, remove all the no replies. And we got a pretty clean list. I'm going to do one more pass. I started one yesterday processing everybody's emails and I'm going to do a delta and so we'll send some more emails out the call for nomination once I know the next set of emails, but it's only a handful of people. It's only like a dozen or so. So my point being is that now would be the time to resolve these and get good emails if anybody is having a problem. We sent out an email to the list that I've shared to the members of the election, you know, the observers, right? We don't really have official election observers, but people in the elections mailing list. And I think we had something like 700, 643 emails went out. 644 emails went out. Anyway, we're having issues. We're saying I didn't get it. And let's tackle the first one. The first question was, do we consider Wiki contributions as contributions eligible for voting? Because that's the one Mark raised because he said he wasn't in the list or hasn't received one. Mark expects to be on because he has been contributing to the Wiki. He's also chair of the working group, isn't he? Yes. And I'm on the TSC, which we think is a technical contribution. So, yes. So I just need guidance from the TSC. Should I include TSC members automatically? And do we include maintainers automatically and chairs of working groups automatically? But, okay, so you think the maintainers, they will show up at least in the Yeah, the maintainers will because you don't get to be a maintainer without contribution. I think you're, no, not all maintainers are making commits, right? If I just do a merge because I do a PR review and I merge, that doesn't appear? No, it doesn't appear. It depends on the kind of merge. It depends on the kind of merge. If it's a fast forward merge, then there is no merge commit. If there's not a fast forward merge, then there is a merge commit and your name will get in there. And actually, if you do it using GitHub's tool, I don't think it tags it as you, but I might be wrong about that one. So, what I'm hearing is that the scripts are very narrowly, you know, selecting people because, you know, quite frankly, I always tell maintainers should take on more review work. And if they only did that, that would still be extremely valuable to the community. And if that doesn't count to us being eligible, we have a problem. So I put a link out there on the chat of the TSC election voter selection decision that we made back in February about who would be allowed to be on the election list, which was the people from the Git contributors tool that was run, as well as the email for the work group and task force chairs. And anybody that the work group and task force chairs determined were that they contributed documentation or technical artifacts. So, thank you, Tracy, for bringing that up. So, at least the first question is, does our list, the list that was used, right, for the call for nomination, match this decision? It does not. I will correct this today. I will get the list together. What are we missing? Which part are we missing? The work, the task force chairs and the emails, well, the, yeah, the work force and task work groups and task force chairs, and any exceptions that they submit to me, they have not been included explicitly. I bet some of them have already been included because I bet some of them have made contributions as developers. But yeah, I have not explicitly done that, and I will get on that as soon as possible. That's my top priority for today. Thanks, Tracy, for pointing this out. You're right. We missed this. So, I will notice that these not include wiki contributions, at least not just done, you know, because you're contributing to the wiki. If you do it through a task force or working group, obviously you'll be included, but not otherwise. So, that's the state, that's the status quo. So, does it include people like Grace Hartley because she, you know, does a lot for Bezu and all, and I would consider her work technical, but she may not have contributions. Grace filed an exception and it was approved. So, Grace is in the list. On what basis? She was writing all of the quarterly reports for Bezu. I think was the basis for which she was selected or was accepted. I mean, I have no problem with, you know, with her being included, except that this exception seems a bit like a one-off, which is not in line with the decision. And now, how are we going to do this based on the case-by-case basis, based on what criteria? We ought, I mean, the whole idea was we're going to have a plan that's transparent. People know what we are doing. Now it sounds like, well, we don't know what we're doing. The discussion was on the elections list that you're on, I don't know. Yeah, but this is more than the list, right? I mean, I didn't see the decision being made, but we're in a much better spot than we think, I don't know. And we've always had an exceptions-based approach to this, which necessarily has a subjective element to it. So, you know, I, yeah, this is, and I think it's not really comfortable for anybody to talk about kind of specific individuals in a form like a TSE call. So, yeah. I agree. That's why I was getting back to rules and policies, kind of, you know, what's the rule that we use, and, you know. I mean, I'm all ears for you guys. Satisfied with the approach that we've taken to have this elections mailing list and have this process. I mean, you've been a part of the conversation of how we set this up to this point. So, it's, yeah, it feels a bit frustrating, I think, for those who are trying to follow these rules. So, what is the decision now? What are we doing? What do we need to do? Well, for your guidance, I'm going to get the work group and task force chairs and email them all today personally and ask them for a list of exceptions according to the decision that Tracy just pointed out. That if we're going to follow the rules, that's exactly what the rules say. But again, we have these exceptions. Yes. So, what I could use. We at least need to be in line with the decision we've made and make sure the people we see will be included are. That seems to be a minimum bar we need to to retrain. Yep. I'll report back on the resolution of that as soon as I have one. So, probably tomorrow or the next day. But I could use guidance from the TSC on, are we going to make any rules about exceptions? I always thought it was just kind of squint and turn your head sideways. And yeah, they seem like a contributor to the community. If they can show that they've made significant contributions, I don't see why we shouldn't just allow them to file for an exception and be considered. And really, it's not even significant contributions. It's intentionally intended to be broad to sweep as many folks who have participated as you can. Not a trivial comment on rocket chat or an email list, but on a contribution to the Wiki that's more than just a comment or a typo fix. And so, it's necessarily subjective. And because we have intended to make it broad, if you wanted to limit it to maintainers or limit it to, you know, only people who've made a commit, then you can be more objective about it. I would disagree with that. I would disagree. The charter specifically calls out what should and should not be accepted as a contribution and should be eligible for TSC election. In the past three years, I believe it's been now, maybe just two, we've allowed the workgroups to decide, the workgroup chairs to decide who would be allowed from the working group to participate. So, I guess, you know, obviously, this is a challenge every year, right? And I think that was part of the reason we tried to come up with the decision early in this year as to who would be eligible so that if there were any sort of issues, right, we could talk about it at that point. And it seems like having this conversation again every year, when we've already kind of made the decision seems like, you know, I don't know. It just seems pointless to continue to have the same conversation over and over. I echo your frustration. I would love to have just clear rules and just do it, right? Well, I mean, if you, you know, you could argue the rules are clear. Tracy pointed out what the decision was. And if we stuck to this, some people could argue the rules are a suck, but they are the rules. And until we change the status quo, that's what we have. I think the fact that there are exceptions make the whole thing a bit less certain and obvious and will bring people naturally to say, well, what about this? What about that? So the team is trying hard to do the right thing. And I'm not trying to throw rocks at anybody here. I just, I can allege that this makes the situation kind of sensitive and difficult. Yeah. So what's the recommendation then? Are you, because if there's no change in the well, I know we heard from Tracy. So I'd like to hear from the others. I mean, it's not just up to me, right? How do other TSE members feel? I thought it was, we were taking people that made technical contributions to Hyperlinker, for the most part, that, you know, we explicitly, I think, ruled out work from SIGs because they're not under the control or the domain of the technical steering committee. And we had some big discussions on that. But, you know, they wouldn't be voting for someone to represent them. But other people who made non-code, but technical contributions were, you know, part considered part of this. It's a good only thing. All right. So, but it sounds like your expectation is different from the official TSE decision we have on record for now. Is your position that we should compromise the decision? We have a decision log that describes exactly the process that we agreed to. What are we, what are we going that's different? Yeah. So we heard from Dave, he has acknowledged that the way the list was built is not completely compliant with this. The proposal that was approved says the CAs also email all of the work groups and task force chairs to determine who has contributed. Did that happen? It's going to happen today, Chris. We were just talking about that. Tracy pointed out, I was like, yep, that's right. I forgot that. So I'm going to send that out today. This is why we have a two-week or whatever three-week nomination period. So, okay. So, pardon me. That was my mistake. It was an oversight by myself. I was so focused on getting a clean list from our repos that I did not do that, but I'm going to do that today and I'll report back. Okay. And so in terms of Grace, and again, I think she's made tons of contributions. I think that's great. I think she should have a vote. But I suspect that the process for how she was approved is somewhat sketchy. And if we include the TSC as a working group, which I think it is, essentially, then our know should be able to make that call. Right. I agree with that. The process is undefined. I wouldn't say sketchy. It's just defined per our rules. And it's not very transparent. Well, I don't know who approved her. I mean, it is my point. Well, the process is exceptions are to be emailed to the election mailing list. And the election mailing list is made up of everybody who volunteered to want to keep an eye on it and provide input on the election. And we just discussed it. And it was kind of like, it was consensus. Yeah. And this was definitely this was also this was also posted in the election plan that was reviewed by the TSC. If you see there under the FAQs, there's I think I should be eligible to vote in the hyper ledger TSElection. How do I appeal to be included? Send an email to elections that lists your name, your email. And then it's discussed there. That's the process that was reviewed. That's correct. I mean, the process doesn't go as far saying on the world what criteria you might be eligible, but that's left open and that I guess by design. Well, yeah, by definition by design. I mean, that's what we designed is that it would just be by consensus, I guess, right? Like we would just discuss it. Okay. But it doesn't specify whom who gets to make the decision or under what circumstances they would deny it, right? Which is also important. So I think we're we're in pretty good shape better than maybe it sounded initially and Brian is right in that regard. And so it sounds like there was a gap with regard to the groups. This is the, you know, email to the chairs not being sent out, but it will be. And once this is done, and we collect the people they have nominated will be in back in tape. Is that clear for everybody? Or is there more confusion that needs to be cleared up? Okay, hearing none, I guess we're good. We can move on. Then let's just execute on that. And hopefully this can be so then there was there was one other issue under election discussion, which was did you get the email that went out for nominations? And I just received some statistics from Jessica Rampen. She said we sent out 670 emails. The open rate so far is 34%. There were 627 emails actually delivered. 391 have been opened 49 of them bounced. So and we're getting a report back from the LF about who has opted out of receiving emails from us so that I can personally email them and say, Hey, you've opted out. But, you know, we're trying to send out election notices, right? So I'm going to be handling those personally. It's a small number. Maybe it doesn't or so. But anyway, the emails went out and it, you know, there's 49 bounces. So I'm just curious. I mean, Hart said he didn't receive his even though he's in the list. So I just want to know that I've received mine. But who did it come from? Who sent it? Oh, the email that sent out will came from our marketing cloud. So it should. So Dave, I found mine. It's in my Gmail promotions folder. So it got flagged as a promotion, which is why I didn't see it. So I suspect that there are other people with Gmail accounts who are probably in the same boat. It came from no dash reply at email.hyperledger.org. Yeah, it came from the marketing cloud. So that's just going to go right to the right to the promotions. All right, maybe that's not the best channel then. There's really no effective way to send out lots of customer, you know, lots of direct emails, except to use tools to do it that get flagged as spam tools. Because you're sending out, you know, you're not sending it to an email list, you know, like we, like we have, there's basically no, no great options. And last year, last year we tried to set up a groups.io list, you know, for voters. And that, that also flailed for, for different reasons. So, right. The marketing cloud is our, and by the way, sorry, right. Go ahead. All right. I mean, I was going to say the marketing cloud is our most reliable way to get emails to our community members in Asia as well. So we had problems last year where a lot of them didn't receive the communications. And so we went with that one this year and it's not perfect. It's difficult. So I mean, I think we've resolved this. I, yeah, I mean, if people feel like they haven't, you know, that are on this call, feel like they haven't received it, just reach out to me or email the elections at list.hyperlegio.org and the election at list.hyperlegio.org and we'll deal with it piecemeal. And look into the spam folder. Yeah. Yeah. I thought that I was going to have everything go to my work email. All right. You can apply with Dave. Yeah. Sorry, Chris. What was that? Email address. I had asked that the voting stuff go to my regular, my work email, because my Gmail is just flooded with hyperledger from every it's awesome. Okay. Okay. Yeah. Take it up with me and we'll sort it out. Like email election at list.hyperlegio.org and say, Hey, can you use this email? Because that's how I'm processing these, these email cleanups is all the messages sent to that mailing list. Okay. Anything else on this election stuff? Hopefully we're in good shape to make progress. Thank you. Okay, let's move on to the other agenda item that I put on the agenda for today, which is this, now what I call wall over of projects tied to a single other project. So we discussed it already. Two weeks ago on the call, I introduced the topic that came out of initially a comment against one of the project reports. And I said, you know, we had this kind of straw poll at the end and there were some people were at least interested in continuing this discussion, looking into what a proposal would look like. And so I did put a draft together. And I submitted it for everybody to comment. There were some comments, but very few. I know Aruna was on and he had to drop off unfortunately, but he was interested in discussing this. He actually has a proposal that's in the comment section that goes beyond that. I don't know that we have to get into that now, because it's kind of related, but it's sometimes different. He wants to be suggesting some changes to the project life cycle by adding another phases, another phase to the whole thing. And I think it's somewhat orthogonal to this very topic. So there was a comment from Hart on the mailing list saying, before we adopt this, we should definitely kind of test drive it by the maintainers, a project that would be potentially impacted by this, which sounded like a reasonable thing to me to do. We should, but you know, we have people already significant number of people on the call, not just the TSC members, but maintainers of your projects. So I'm inviting everyone to chime in there. What's the gut reaction? Is there anything you would want to change or want about, you know, any of those things? Do you love it? Do you hate it? I ask that people use the raise hand thing to chime in, please. That sounds like a good idea. Thank you. So Nathan is first. I like the idea that we should ask the project leads. There's a lot about this that kind of depends on the specifics of the situation. And I think that as long as, I think in some cases, these projects ended up as their own standalone thing, because of the history of what's been, what's happened at Hyperledger over time. And we want to make the decision that helps the project recruit maintainers and contributors and, you know, have good project health. I mean, to be honest, for me, the idea of folding it back underneath one of the frameworks, if that's what's appropriate is, to that end, to try to make sure that they have good support from those maintainers of the framework and that issues can be addressed quickly with the most appropriate audience. So I liked the comment of walking through this with who might be affected and seeing what improvements we can make to the decision criteria based on what they tell us. Okay, thank you. Chris? Yeah, I wanted to, I mean, I think, well, okay, so for starters, let me say that I think that the formal proposal could be a little bit more strongly worded to indicate that this is really up to the maintainers. We can't force maintainers to take on some work that they're not prepared to handle and that they don't feel is going to be effectively supported. And so I don't think we can, I don't think we can force a decision. I think this is really more to the point of, if we see that something hasn't happened, then we make a recommendation that the maintainers of the target project, if you will, or the take up a consideration of whether or not to deal with it. But that's the end of that, I think. If they choose to consume it, then that's fine. But if they don't, I think we have to sort of abide by those wishes and either leave the status quo. But I think it sort of then begs the question, okay, what do you do with an incubating project that's still an incubation 18 months after the fact? And so I think that we probably want to have a separate conversation about that. You know, should a project that's been incubating for 18 months have another status of move it into labs? Or I don't know what, but we probably don't want to have things in incubation forever is what I'm saying. But in terms of the decision, I think the decision is not the TSC's decision. I think it's the maintainer's decision. It's just that the TSC should make a plea to the target project and say, hey, we'd really like you to consider subsuming this project. Okay, thank you. I see nobody on the queue. So I'll jump in there to say, I mean, so first, the proposal clearly at the end, it says, talks about due consideration of the specific case at hand and communication with the maintainer of both projects involved. It's, you know, I would hope that this, I mean, convey what you're talking about, which, you know, we, we can't just say, hey, you project become part of that other project with this other project, you know, not even being consulted and agreed to this, you know. So that wouldn't make sense to me. At the same time, you know, the maintainers, we have, it's not like, you know, projects have a single bag of maintainers for the whole project, right? You look at fabric, we have many different repositories with different maintainers, sets of maintainers for the different repositories, which correspond to different sub project kind of things, right? And, and so I would imagine in a rollover, that would be the case, the maintainers of the current project would remain maintainer of that project, they just become the sub project kind of thing. And, you know, they can continue doing their thing just the same way. It means from an organizational point of view, from a hyperledger, you know, structure, we only sees that as one project. And, and I think the TSE has a role to play in making decisions as to what should be recognized as top level project or not. I do think it has to be, you know, as we always try to, to get things, you know, based on consensus as much as possible, I wouldn't want us to say, okay, those guys really don't want it to happen, but screw them, we're going to do it anyway, whether you like it or not. I hope we can avoid this kind of situation for sure. But, you know, fundamentally, I don't think it's entirely up to the maintainers. I think the TSE has the responsibility to manage the overall, you know, greenhouse to speak. And so it's part of managing this to say, you guys really belong to, you know, together, you should merge. So I'm in the uncomfortable position of asking everyone to raise their hand. And I just learned that as a host, I cannot raise my own hand. You just touched on a point that I wanted to raise, which is, you know, weeding the greenhouse, right? I don't think it was, I feel that it was not entirely awesome how composer played out the length of time over which the composer deprecation played out. And I, I mean, it's when we have so many projects at the top level that are small and independent, that that's fine. But when they're small and small and dependent, I think it becomes hard to justify. And I will see the floor to Chris. Go ahead, Chris. Yeah, so composer, okay, so it was not pretty, I agree. But we were trying to be very sort of cautious about things. And so there was an initial announcement that the maintainers weren't going to maintain it any further, other than, I think, to fix critical bugs. And, and we declared at that point in time that we would go through, I can't remember if it was six months, but I think it was six months. And then we would deprecate it formally. And then the deprecation would take a year. So it did take 18 months if I'm not mistaken. And that was just to be sort of an abundance of caution. And, you know, there was a lot of Henry and discussion around that, but you know, you don't want to just yank the rug out from somebody abruptly. And so we tried to do our best. And I just wanted to sort of make that point. I agree. It wasn't pretty, but it was the first time and we didn't really want to upset the situation. All right, thank you. So I'd like to hear from the others. We have a mass of people being silent. And I'm going to put you on the spot, but like people like Hart, Tracy, you guys were, you know, last time we talked about this, you guys were like, I'm not sure where this is going. So I'm interested to hear if your thoughts, you know, if you have your position as involved in any way, you know, pro this or against it doesn't matter, but I'm happy to talk, but I think people who raised their hand should probably go first. Well, okay, put your, put your hands up. Okay, Angelo, go ahead. Yeah, I have a certain, I also don't have a definite opinion on this, but my point is the following. If we are spending money on, on this project and the goal of this project was to serve multiple projects and this goal is not achieved. And again, we are spending money for this project. Then I think we are entitled to tell them a, maybe you go to this other project because we can, we have to spend resources in better ways. This is just the best argument that came, came with so, but if you are not spending money, if you are not wasting resources for this project, maybe what Chris said, I cannot, I cannot go against really that. All right, so this is something maybe the staff can talk to more than me, but it was said before that there was a cost associated with this and, you know, there's a cost which I have been pointing out regarding just the communication barrier we're creating with having so many top-level projects that seem to be independent when they sometimes are not. But beyond that, there is also some financial aspects, resources, dedicated to those projects that maybe they wouldn't get otherwise. Maybe Brian can talk about this. Yep, so we haven't spent any money that I could track at least as on, on Transact. It hasn't been the subject of any, any press or push that we've made. We have not been asked to or consider doing a security audit for it, although, you know, if it were, if they were to ask or if we were on the path to 1.0, it's certainly considerate. I think those are costs that would be largely the same if it were re-emerged back in with Sawtooth. So, you know, some of that it's a rush, I think. I mean, if anything, we would love to talk more about projects that, that you haven't even hit 1.0 yet. So, you know, part of, part of me is just wondering, is this a question about how we help Transact hit its original goal, right? Is there something constructive we can do? You know, I don't think any maintainers from the project are here on the call or even folks involved with Sawtooth are here on the call. So, I would, I would just be, I don't know, again, get back to your question about costs. There aren't really any costs from that point of view. There's a cost theoretically from a larger greenhouse than otherwise, but even that is super hard to measure. But I don't want Transact to be singled out. There's actually quite a long list of projects that fall into that category. I'm thinking of Explorer, Chiello. I mean, these projects are fabric related whether we like it or not. I mean, is the, is the goal here to have a small greenhouse? Yes. I mean, it's to be well curated, for sure. So, I'm just pointing out, it's not just Transact. I don't want to this to become like this is either Transaction be rolled over or not. It's a bigger question than that. All right, thank you. We have other people, so hot. Sure. To me, this sort of boils down to a marketing issue, right? You know, if we have projects merge back in, then as Brian points out, you know, it really doesn't change like a lot of the, you know, underlying costs like security audits, you know, whatever, whatever like that, you know, if any of these projects go back in, then, you know, all of this is still going to be the same, right? You know, we're just sort of putting, you know, repos and saying like, well, we're not even going to change the maintainer structure of these repos, you know, maybe we'll just rename them, move them to a different folder, you know, something like this. So to me, this really just comes down to marketing and sort of how we want to market Hyperledger. And, you know, what are we presenting to sort of outside people? You know, is it too confusing? You know, this is sort of the drawback of having, you know, all of these projects to me anyway, is that like, you know, if I see this like huge greenhouse, sort of where do I get started? So, you know, maybe the thing to do is we just sort of clean up and streamline marketing efforts, you know, like, you know, should we have a greenhouse with only sort of 1.0 projects or something like that? You know, so that's just my perspective on it. And I would be curious if people thought similarly or differently. All right, thank you. Tracy. All right, I think you have a really interesting perspective there, right? I think it's how do we, how do we communicate kind of what might be ready for production usage versus not or whatever terminology you want to use, use that if it makes you happier, right? But, you know, I think when I originally put my hands up, it was for a couple of different reasons. One, I think the proposal is let's kick the can down the road. It doesn't really solve the problem that we have. It really is, I think, important that we have these hard conversations with the projects that we're concerned about. And we have those sooner rather than later. But I also think that Arun brings up some interesting points in his comment. And I think it boils down to expectations and the fact that we don't all have the same expectations of particular projects. And that is what's causing us some of this grief and headache is because we, you know, in some cases expected a project to support multiple other projects and it didn't end up happening, right? Then our brain says, okay, that shouldn't be a standalone project. But maybe, you know, we need to do a better job of documenting what these expectations are as kind of Arun is pointing out, right? Having shared goals, shared understanding of what this project is intending to do and understanding whether or not it's reaching those goals, understanding that at the same point, right? Paths can change, right? It's not always a straight path to where you want to go. And sometimes that ends up meaning that things go in a different direction than you were originally expecting. And being able to understand that and accept that those changes are going to occur and that those goals that you might set out initially or those expectations that you might set out initially are not where you're going to end up in the long run. So in the end, it boils down to having the conversations, making sure that we're understanding where people are, where they're going with these projects, and whether or not that is something that, you know, we can accept and say, okay, now we understand what our shared expectations should be. All right, thank you very much. I do appreciate the fact that you point to Arun's comment. There was one thing that I think is very relevant to the discussion, which is, you know, should the charter have some kind of timeline set into them where that would, you know, say, give us some kind of time boundaries that would be helpful in determining whether projects have achieved their goals or not. And, you know, this is very common in like charters of working groups in standards world. And they often, you know, you often blow up your timeline, and it has to be extended and all, but it still gives you some kind of guideline and set expectations, which currently we don't have in the current proposals that are being sent. The template doesn't ask for any kind of timeline at that level. And so, you know, I don't know, that's something definitely that is worth thinking about. Quickly, because I want to give time to Mark, I wanted to ask you why you're saying this proposal doesn't solve the problem, it just kicks the can down the road. I mean, I guess I've been staring at the proposal for too long during this call, I know, and I've been reading it more closely. When I first read it, I'm like, yeah, okay, this makes sense, right? But like, basically, I don't know what we're doing with the existing projects. Is this only for new projects, or is this 18 months from now that we're going to start having these discussions? And so I think that's my biggest concern right now, just having stared at it for so long. All right, fair enough. And that helps. So I can tell you, I mean, I cannot claim the text accurately reflects that when I wrote it, I actually tried to write in such a way that it's, you know, 18 months from their beginning, whenever that was. So for anything that's over 18 months, and that falls into the category, we could open that up and say, okay, it's been more than 18 months for that project, the illustration, what do we do? So that was, so from that point of view, that's why I was asking why you think it kicks down the road. I would think we would stop looking at the least one by one and say, okay, which project and I named a few others, right, Explorer and Cielo, and maybe there are others that haven't thought about it yet, but we could do an exhaustive review of the different projects to see which one falls in that category, and then bring them up one by one to the TSC to discuss and see what the situation is and whether we need to make it take action. So with that said, Mark, please. Sure. So a couple thoughts here. One would be, you know, the quote unquote marketing angle if someone comes to the webpage and they're looking, and I haven't gone off to look, but you know, if you look at something like grid or transact or one of those and it says, oh, you know, this supply chain thing or whatever, but it's not to actually dig down deep into it that you see it only works with sawtooth, right, so it's not really an all-purpose tool. You know, so that's, to me, also a marketing angle, right? Do we want that up there? But you know, is it going to help or hurt projects? And this is probably the flip side of it. Is it going to help or hurt some of these projects if they got moved under a different one? You know, as far as getting people to contribute to it, things like that, um, maybe it would have no impact. And the final thought would be, we should also, you know, going forward, do we want to consider for new projects coming in that want to be a standalone project if they only work with fabric or sawtooth? Do we, you know, but they claim they're working on working with other ones? Do we want to wait till they actually, you know, support multiple frameworks before they're elevated to a full project and initially they'd start under one of the other projects? Take a look at a project like Fabric Private Chain Code. I think that's gone through the correct type of process where it starts as a Hyperledger Lab project and then we see if, you know, it makes sense, see if it's actually going to work and then we can bring it over and have it be part of Fabric as opposed to trying to set up camp as an incubating project under the, you know, under the greenhouse, under the umbrella and then find that, well, it wasn't really going to pan out and now what do we do with it, right? I think we should be encouraging more things to start in the labs and then if they make sense, they make sense, right? And we, you know, figure out if they need to be a standalone or if they need to be, you know, brought in under another project, but that decision, it becomes less of a hand-reading kind of a thing, I think, if it's a lab than if it's already incubating. So I don't know if we can do anything about what we have today, you know, that's still, we have to do some hand-reading, but I think in the future as people come up with ideas for new projects, I really think that we should be encouraging them to start as a lab and see if they can get some traction. So I do think we do that already at least to a certain extent, right? But if you take the example of a transact that came out of Sotuth or, I guess, Grid is the same and, you know, they were in a project already. So for them going into a lab doesn't seem to make much sense. But yeah, maybe Mark is right that, you know, they say, okay, we want to be a top-level project because our technology is not really, you know, specific the project we are part of. And maybe, I mean, this is, I think, I forget who pointed that out earlier, is that hurt or not? The idea was, well, if we put them as top-level, they become more visible and people have an opportunity to come in and contribute to support other frameworks, except if it doesn't happen, that's the situation we're talking about, then what? So they were promoted a top-level project on the basis that they could be framework-independent, but really it didn't happen. So that's the situation we're trying to tackle here. And it's not easy. I think there are different ways you can find yourself in that situation. And again, you know, I made that clear in my message or in my proposal. It's, you know, I think if these things happen independently of any good will on all parts. So, all right, we're out of time. Obviously, this is a discussion that we'll have to keep going. We won't have a call next week. There's the Hyperledger members submit. Several of us are part of this. So we'll skip next week, probably meet in two weeks from now. But please use the comment section on the wiki. And let's get this discussion going. Thank you.