 Welcome everyone, this is the weekly TSE call. As you all know, this is a public call. There are two conditions to participating. First one is to leave by the antitrust policy. The notice of it is guaranteed displayed and the code of conduct that you all know and love. I'm sure. Got to. So with that further ado, let's get started. First, we have a few announcements. So as always, there is the weekly newsletter that everybody should try and take advantage of. And then Ellen added a bunch of, a couple of items I will let her speak since she's just joined. Sure. I just wanted to remind everybody that the next DevRel marketing meeting is next Wednesday. It's every second Wednesday of the month at noon EST. And just encourage everybody to come so we can help leverage all the great work that's happening out in the community and learn about it and help amplify the work that you're doing. And also the next meeting of the White Paper Greenhouse Task Force, update task force is tomorrow at 10 a.m EST. So if you missed our kickoff meeting last month, they're still, you know, we're still open to new contributors to that project as well. So we encourage everyone to get involved. All right, thank you, Ellen. And then we have an announcements from Rai, prompted by me, I must say. I kind of pushed him, but go ahead Rai. This is a more general announcement that the Azure pipeline and fabric is migrating. There are a few projects left that are using it. Here is kind of the discussion on what's going on. So I can't give you a timing, but it's coming. So if you're depending on ACP, I ask that you move to GitHub Actions to Tweet. Thanks. Is there any questions or comments on that or any other announcements from anyone? Dana? How about CircleCI? Is CircleCI still viable? Do we need a look to move to GitHub Actions? Is it, you know, what's the status of that? Okay, the status of CircleCI is, so ACP as a product is going away. So that's what's prompting me to try to get people to move. CircleCI as a product, as far as I know, is not going away. I would super appreciate it if Bezu moved to GitHub Actions, but it's not a requirement. And because it's working, it's fine. So I mean, that's a discussion that we can have you and I can have or whatever, but CircleCI, as far as I know, is fine. My personal preference would be to get you into GitHub Actions, but that's just a personal preference. Yeah, I think the last time we migrated, actions wasn't open for the world. Are we the only projects still on CircleCI? I think so. I think you're the only project paying for it. I'd have to look. Because we're having problems with our external contributors being able to trigger the CI pipeline. So we might be in the mood for a switch anyway. Well, for a bunch of reasons, that would be awesome. So let's discuss it, let's you and I discuss it offline. Well, we'll do. All right, very good. Thank you. Any other announcements, anybody? Or questions? I'll make one quick one, actually. You know, a while ago, we decided to invite all the other groups within the Hyperledger community to come and present if they chose to, you know, to tell us what they are working on. And that was in an effort to bridge the gap between the different parts of Hyperledger. We have only had a few groups actually take up the invitation, but it occurred to me that we should extend that invitation to the labs. So I took it on myself to inform the labs, although it's kind of hard to reach these people. I basically just posted on the Labs channel, which, you know, I don't know many people really pay attention to. But so if you are involved, you know, in some ways in a lab and feel like, you know, this might be a good opportunity to give your lab more exposure. I invite you to consider this and share the information around. All right. Okay, so let's move on then. Quality reports. There are two reports that were submitted. Avalon has been around for a while. Cactus really just came in very late. So I don't know that many people had the chance to really look into it. We'll carry it over to next week anyway so that more people have a chance to look at it and ask questions if they want to. When it comes to Avalon, I didn't see any, like, you know, need to raise the issues. You know, the project didn't raise any issues. And I saw comments that were positive. I don't know if anybody has any questions or want to say anything about the Avalon report. And I do, to say, Hart quite rightfully pointed out in the cactus report, I don't know why the template asked for the name of the project at the beginning when it's already in the title of the document. So maybe we can update the template to remove that section which doesn't seem to be very helpful. But that's a side note. As I said. Sure thing. Thank you. But so we'll, I see that, you know, a few of us have had a chance to look at it but the majority have not and that's okay. We'll carry it over. We haven't heard from the Quilt and Explorer projects in now a few weeks. So I don't know what's up with that. It'd be good to have some update. All right. That's all I have on the reports. And I mean, I don't see anybody raising their hands. So I assume we're good to proceed. So we have a collection of discussion items for the agenda today. We'll see how far we can go. The first one is the DC Ovalidation during Contribution Review. That's an item that was raised by Dano a couple of weeks ago when we had the last call. At the end of the call, I mean, we basically, you know, said, okay, put together a proposal which he went ahead and did. And there was quite a bit of discussion which seemed to be in support of the approach although there were some concerned about the details of, you know, how much control we should have. And in the end, there's a question as to, you know, whether from a legal point of view, the proposed solution would satisfy the, you know, the legal requirements. So I just felt like, okay, we haven't, it'd be good to take a little bit of time to discuss where we are and, you know, see what needs to be done so we can keep making progress on this issue. So Dano, if you want to restate what I tried to say and in your own words, maybe you can do a better job, I don't know. Sure, you got the most of it. So is there, can you click on developer-certificate.org. It's down in the second paragraph, no, the second section. So this is the legal statement that everyone's supposed to be asserting to when they add the sign off by line and there's four clauses, three of them that are really relevant. A says I did it, B says I got it from somewhere else that is fully licensed and C says that I got it from someone else who did either A or B. And what I'm proposing for the DCO, because in here, you know, having that has to be assigned off by in the commencement stream is not one of the requirements. It's a practice and my question is, is that, you know, legally speaking, is that how we have to do it all across the board or not? So my proposal hinges upon the functionality of clause C. So if someone's proposing a commit and they forget to put it in there and this is only, so to set the stage for this, this is only gonna be valid for projects that use the squash and commit flow. When they take a contribution, it's reduced to a single commit and added to the chain head, not the chain head, the tip of the tree for the get commit. So there's only one commit that comes in from what might be, in some cases, I've seen like 30 to 100 different many commits come in. So it's part of the merge by the maintainers that squashed down to one commit. They rewrite the commit message, which is typically just the condensation of everything that comes in beforehand. Now the DCO checker robot that we use right now treats PRs and the main line of the PR commits and the main line of your project the same when it's looking for DCO and requires the DCO sign off at every single line. So the proposal is for PRs, that if they make a commitment, either at following that policy or in their comment stream, after all their commits, they say, I certify that this is my work pursuant to this in the GitHub comment stream, that when a maintainer does a squash and commit, they can then move that signed off by line into the squash commit. We don't have to go back and rewrite every single little work and process committed in process, which is what we would require the, so what the saves requires the contributor from having to go back and rerun and recertify every single step of their get commit and do a bunch of long nasty get commands that GitHub gets rid of for us. So they've made the certification in the comment stream and then we can take that certification, put it in when we do the squash commit. Now this proposal wouldn't work for baseline recommits because they take the entire PR tree in and it wouldn't work for straight and merge commits and I think that's written into the policy. So it would only be an option for those that do merge commits and to use Ethereum speak, this is basically an optimistic roll up of their commit into whether they commit into the chain. So that's the gist of the proposal is to allow the maintainers to accept the certification some other way. So long as the master, the main line and the other line you produce a release from for every commit has a certifications. All right, thank you, Daniel. So as I was saying, there were some discussions and concern with regard to whether, I think that in a comment on GitHub was enough and whether there should be some, we could enforce that the information doesn't get lost while the merge is done and that we have a check that guarantees that the information is preserved. So I don't know that there is much we can do in this regard. If I might, there are two opportunities here. One is that we do have a process for, and I just wanna say, I really appreciate the way Bezu does the DCO remediation right now and I know what a pain that is. We do have a process for doing DCO remediation, which involves a commit where it has, where it is properly signed off by and it lists the hashes, I did this, I did this, I did this and I can't tell you what that format is or I'll stop my head because I forget but that was already, we already had that discussion, whether or not that's okay and I'll have to dig what the answer was. Yeah, the other opportunity and I don't know who, I don't wanna speak out of school but I know that the maintainers of DCO bot have tried to give ownership of that bot to a Linux foundation employee several times and that employee probably pretty smartly said, I don't wanna own this but perhaps that's something that we could, we Hyperledger could reach out to and fix DCO bot itself once everything is cool. So those are two things to keep in your mind that we do have an opportunity to take over DCO bot and we have already discussed DCO remediation without rewriting history itself. All right, thank you. So it seems to me that first and foremost, you would need, there was a legal question being raised. So the staff has to take this on and there were a few prompts for Brian but Brian seems to be missing in action. He has not responded. I see he's not on the call today. So who is going to carry maybe Daniela is next in line? I think that would be reasonable. I see that Daniela is muted but... Yeah, because I think what I want to get out of this discussion now is a set of basically action items that we can carry on to make sure we're making progress and this doesn't just sit there. So I want to know what the issues are that we need to get addressed. I know there's this legal question so I'm trying to make sure this is being taken care of and I believe the staff is in charge of that in one way or another. What else? The DCO bot I guess would come later once we know yes, this is an acceptable way forward. So there is, we don't necessarily have to rewrite the DCO bot to initially to implement this policy. Maintainers can go in to a commit and disable the status of the DCO check and make it pass anyway. So if manual intervention is acceptable then that's something that we don't have to change immediately, but I would prefer it to be honest. Yeah, and do something like this. So what they could, Jmetrix done, that's awesome. So they would check for that in there and it would include those in the acceptable lists. Yeah, so this is, I'm not gonna say this is canonical but this is pretty close to canonical. Troy? Yeah, I think the two important points other than the legal piece is having a bot that can enforce this. And I think one of my big concerns is this remediation needs to be documented on if this mistake is made and a commit without DCO gets in. What is the remediation that doesn't involve get history rewrites? Because in the project Simon I really don't wanna see get history rewrites. So Daniel, I think you guys, you don't do history rewrite but you possibly go back and fork. So yeah, it's basically a fork. If it's a DCO contributor, we ask them to rewrite their PR because that's the only way to bring it into compliance or close the PR and start a new one which is history rewrites by different name. Sometimes on occasion we mess up the squash merge and don't include any signed off by lines. In those cases, we have a check in our Gradle build scripts that will fail before it compiles everything. So we can't get a build off of mainline until we fix that. So we have to go in and rewrite that one commit that we did and then do a force push over it. And the policy is that we have in our practice is you have to do a statement to base your contributors and I'm rolling back for DCO commit and you give the old commit and the new commit hash and you tell people if you happen to have this in your tree, you'll need to re-sync and re-update. So with squash and commit, there's the opportunity to do a fat finger mistake and the remediation is just to go immediately fix it as soon as possible. And that's what I've observed. These breakages don't linger long because the pipeline breaks and everyone, it sets a fire alarm off and everybody's had to fix it. So. Okay, Troy you're next, but I did want to point out that, and I was unaware of this if you scroll to the bottom of the page on the Wiki page here on the GitHub page. This is news to me that there are Chrome and Firefox extensions to do this. So anyway, Troy. Yeah, I was just going to comment what was just described is exactly what I don't want to see. I really don't think we should be force pushing domain because of DCO problems because we disabled a bot that made us, we didn't have to do that. So I definitely don't want to see that personally. So we did disable a bot. GitHub has no hooks on a squash commit to check to make sure that you have anything in there. There's no changes that we're doing there to remove it. So it's a GitHub shortcoming. Right, what I meant by this is right now there is a bot on the commit itself. So by not having that bot enforcing DCO on the commit itself, these things can happen and result enforce pushing main. I don't think force pushing means a very good practice. All right, so it sounds like for Troy, I think that DCO check is important and the must have. But so who else, is there any other, yeah, Tracy? Yeah, I mean, in my comment, Tray, I think the important part is that we need to ensure that the people who are using the code are not going to be subjected to any sort of legal ramifications if we skip DCO sign off, right? And we do it in some other way. And I really think it's important for us as the TSC not to be the ones making this decision. It just doesn't seem like we are the right people to do that. It is going to impact all of the member companies. It is going to impact anybody who's using any of our projects in any of their short spaces. I think this is a high risk as far as opening up things to get slipped into the repos. All right, thank you, Gary? So I guess, are we saying here, so to me, all right, if this fruit passes legal muster but I guess Bessie's already doing it and a project so chooses to do this, I guess, whatever, that's not for me to say. But we're not saying that all projects have to choose to allow this, right? I think it should still stick. All projects are required to have DCO sign off and optionally can have this other thing if it passes the muster because I'll be honest, I will not do this on fabric and I doubt any of the maintainers will either. We don't have this problem. Bessie's not doing this process right now. Any PR that comes in, all the PR commit lines have to have a DCO sign off. Okay, but you just said, oh, so you were just describing what the process would be for your squad commits? But put it in any case, put it in any case, that's fine. So you're not doing it today, that's cool. I guess I don't want this to be the policy for every project we have. All right, so that's a good point. So this was specifically asked by the Bessie project and I hear people saying, okay, maybe they can have that but we don't want to recommend it or definitely not impose it on everyone. Correct. Okay, so I hear there are still two questions at hand, right, it's the automatic check and the legal aspect. Okay, I think we can leave it at this for today. Get that taken care of and so I guess it's all in the staff, right? You will be the conveyor of that message to the staff, please. For you, Arnaud, of course. Thank you. All right, let's move on then, badging implementation. So there was quite a bit of discussion and confusion as to the state of the badging proposal and its implementation and especially with regard to automation. So I actually did my own research, went back to recording. It's great to have recording primates, it takes a bit of time to go through them and but I eventually found the exact time when this was discussed. And I sent an email yesterday about my findings but I'll repeat it for everybody. And the bottom line is, so there was general support for the badging proposal but there were concerns with regard to the cost of the implementation. So we say, let's not rush into imposing this on everybody. Let's do some experimentation. And of course, if we get some automation, mechanism that would leave the burden a great deal and then it would be easier for us to say you really need to do this. And so when it comes to the automation part, nobody committed to do anything but Brian said, I believe that this is something that would be of interest to a lot of people beyond Hyperledger in the Lunar Foundation. And I'm pretty confident we could get resources to work on this. But so that was left at this. I mean, Ryan mentioned initially, well, we could maybe add that to the Insights tool which sounded great, you know. And so again, Brian is on the hook as far as I know although he has not firmly committed to it and we haven't really given asking formally, please go ahead and figure this out. And so in the meantime, we said, yeah, so maybe Project can experiment doing it without the tool which we don't have for now. And so Daniel volunteer said he would do that for the next quarterly report of Bezu. And I said, maybe we can look into it for Fabric as well. And that's where we stand. So I don't know if there's anything else that needs to be done, but I wanted to take the time to get everybody on the same page. Does that answer everybody's questions about where we stand? Or if there's any other thoughts, you know, please speak up. So again, I mean, I, you know, right, I think this is an issue for Brian to see if there were, you know, if there were resources available that could really look into the automation of this, making this system. It would be nice if that could be, you know, looked into and come back with an answer so that we can proceed based on whether this is something we can expect to have at some point or if it's no go. Arun. Hi, thanks Arun. So I'm still of opinion that we should try this out and go with the proposal, rather asking if we can do this completely automated at first hand. So I know if you volunteer to do this on Fabric and I'm willing to do this as well. I don't have access to Fabric, but I can try this on some project where I have access to some of the repositories or maybe on that. All right. Yeah, and I mean, at this point, you know, anybody who is willing to experiment with some project, you know, is welcome to do so and then report back once they have done, once they have gone through the exercise. I mean, we are in a, you know, gathering facts phase type of thing where looking for feedback with regard to experimentation. I will point out again that I have a separate org for testing stuff. So it's explicitly something that I created for messing around without annoying people on the main project. So if you want to mess around with how stuff works in an org, let's fork some repos over here to Hyperledger CI CD and let's make it happen. You're talking about like if people want to experiment with the automation or? Yeah, if people want to experiment on badging and they don't want to put code in their repo and they don't want to use their main repo or their main org at work or whatever, I have a throwaway org to experiment on. Okay, thank you. Just want to make sure I understood what you're saying. All right, anything else on this? Okay, if not, I suggest we move on. So for the rest of the agenda, really it's all about, you know, I've been going through the decision log looking at issues that have been left pending and, you know, try to figure out what we can do to move forward one way or another. And I think, you know, so the first one is the proposal I made of renaming the active status and colleague graduated. We had a discussion, there was general agreement that renaming it would be a good thing because, you know, there is no doubt that active is not the best name and has been confusing. There were some, you know, concerns with regard to the confusion using graduated could lead to because we also talk about labs graduating to projects. And so people might think, well, if you call it graduated, it just means you've graduated from a lab or at least it'll be ambiguous. And there were some discussions about using some different names and especially Daniel proposed to use Premiere but it was more, in fact, come the way I read it is more like a different type of level with more criteria built into it. And it's not, it's more for like a badge type of thing that you can gain or lose and that would be reevaluated. And so, and then there was this discussion, well, we are talking with badging and why should we bother with the life cycle which may completely go away if we adopt the badging mechanism we just talked about. And so my idea was, well, you know, the badging may take some time and I believe this has already been proven to be the case. And I felt like renaming active to graduated is the low hiding fruit. So I'll date with the caveat that, you know, I recognize regarding the possible confusion, but, you know, we have similar confusions like, you know, even though we said people shouldn't talk about lab projects, they do all the time and we have to kind of correct them. And yes, it's not ideal, but for me, it's kind of a pretty small cost. I still feel like, you know, we would benefit from changing the name to graduate. So I, and, you know, I'll totally respect if the majority of you would say, no, no, we don't want this. It's not worth it either because the name is confusing or because we prefer holding on until we have the badging sorted out. But I felt like, okay, we need to go back to this issue and decide when we're not there. So that's why I put it back on the agenda. Any comments or not? Otherwise, I'm actually happy to vote up or down just to, you know, move on. But if there are any questions before Arun. Quick question, what is the cost of having this changed? So my understanding is this fairly minimal because we have a few labels on the websites and we have the life cycle document that needs to be revised, but that's pretty minimal. And so we would, you know, Tracy actually did us a favor by searching for graduated in the websites a while ago already. And that's why she found a few references, instances in which we're talking about labs graduating. But so I believe, and please, you know, if anybody believes otherwise to speak up, but I believe the cost of implementing this is pretty low. It's just a few documents that need to be updated. And I would, you know, as I proposed there, I would still keep the name, you know, as like formerly called active in the life cycle so that there's a reference. So if anybody here's active being referred to, they can find what this is. There's no point in ignoring the story. But we would just, you know, stop using it actively. So it's no pun intended. So, I mean, just looking at the DCO sign off earlier, I mean, they're on 1.1, right? So could we just do project life cycle, you know, 1.1 and say we renamed active to graduated. And if you find this, do that, instead of keeping it hanging around, Varun? So yeah, I'm now thinking about another case where, so we had a project that was active earlier and then end of life cycle or that project was then planned to be deprecated, right? For example, there was a tool using which we could have set up fabric network. I seem to have forgot the name, sorry. So calling it graduated and all projects, I mean, when we have labs project graduating after high pressure and then if we don't distinguish between them, the projects which are actively maintained versus not actively maintained, how do we? When labs graduate to projects, they become projects in incubation. So there's no ambiguity, it's just in the transition, how they are being referred to as transitioning from one to another. So if you graduate from a lab to a project, you go from lab to project in incubation. If you graduate out of incubation, you become a project that has graduated. And I concede that it's not ideal, but I haven't heard anybody proposing, so there are two or three options in front of us really. It's one is, we just kill it, forget it. I'll no thank you, but no thanks. We can accept it or we can say, yeah, it's a good idea to change the name, but graduate is bad one, but somebody will have the burden of coming up with a different proposal. So if that's the case, I would say, we really just kill it for now until somebody has a better proposal. That's the choice. Okay, if nobody has any more comments, I will call for a vote. So does anybody object to the proposal? Oh, wait a minute. We had this happen last time. There was a vote. There was no second. Yeah, sorry. Does anybody want to say again the proposal? If nobody wants to. I'll second it, but I just want to say, I know I cannot believe that respective leader like yourself is forgetting our rules of engagement here. I'm kind of disappointed. I apologize. We may have to have Tracy step in for one week of attendance. Okay. Okay, so we have a speaker. So if the TSC members want to vote by emoji or you can do your roll call, however you'd like to do it, I don't know. No, so I have to say I know I'm lucky guy to stand on the insights executive board and the way they do it and they play everything by the rule, the Roberts rule by the letter. And they, but they don't bother having this kind of roll call where everybody's called one by one. They just say, does anybody want to object or abstain? And in general, there is silence and it's approved in an emergency. So this is what I suggest we do but Tracy has her hand up. You ask the question. I abstain. Okay. Tracy abstains. Anybody else? Abstain. Dino. And me too. Abstain. Maria Teresa, okay. I will also abstain on this. Arun. Anybody wants to object? Hearing none, this is approved with significant amount of abstain but no objection. Thank you. Can we count that? Do we, did we get Nathan and Mark? Cause I'm pretty sure that with the quorum you didn't get enough votes. How do I get enough votes? Nathan and Mark are not shown up. You had four people abstain. Grace isn't here, Mark isn't here. Nathan isn't here. That's eight people. Mark got kicked. I think Mark got kicked off in Zoom. Is Mark the person that I asked to change his name? He's back with the R9, is that Mark? Well, there's someone that has a name of R9UM, blah blah blah. I sent him a message and asked him to change her name and they didn't reply after a while so I put him in the waiting room. So if that's Mark, then I apologize. Well, Mark said he, Mark texted me and said he got kicked off. That's all I know. All right, so let's see who is in support so we can count. Maybe we need a roll call. Yeah, I was going to say. Let's see who from those who haven't spoken up. So I'll start. I'll know, then we have Gary. I'm a yeah. Yeah, so I'm looking at the list. Angelo. I second. This is for approval. Yeah, or nay. Angelo, do you vote in favor of this? Yeah, I will do favor, I second, yeah. Okay, Arnaud is yes. Arun is abstained. Bow Wow. Do you vote in favor of the proposal? Yeah, I would vote that. Bobby. In favor. Dano abstained, right? Right. And David. Yes. Gary. Yes. Yay. Grace is out heart. Yes. Maria is abstaining. Then we had Mark Wagner, if you're on and would like to vote. I saw you unmute, but it didn't, I didn't hear you Mark. If you want to say it in the chat over in the TSC channel. Tracy abstained and Troy abstained. I said, I didn't abstain, I said yes. Okay, let's see what Mark has to say. Okay, so that we only have abstains and yeses, there's no, no. Doesn't mean it's yes anyway. That's a procedure question. Do you need a majority of the entire quorum voting yes or you just need more yeses than noes? I think that's the open question. I have to. You need a quorum, you need a quorum to attend the call and then you need a majority of that quorum. Yes, I agree with that. If that's the case, then I think we are, I think it did pass. Let me come back and count the votes carefully after the meeting and I will. All right, suspense. We'll have a recount. It's in fashion, that's all right. Okay, I don't want to spend too much time on this. I really wanted to dispose of it one way or another. So we'll leave it to Wright to figure out which, you know, it goes. I have another one. Well, you better change your email address and your home address could get ugly. Okay, the next one on the list, I actually just created the entry, but this has been, we failed to capture it with the, with an entry decision log, but this has been discussed many times and there was a separate effort, you know, to try to come up with a proposal, but it has to do with the current, you know, requirement to have a lab sponsor for lab proposals. And there were discussions as to the role of the lab sponsors. There were many discussions as to the challenge that it has been for people out there who want to propose a lab but can't figure out a lab sponsor. We've been going back and forth, you know, and it was part of the six feedback we got when Tracy reached out to them was, it's too hard to create a lab, the requirement to have a sponsor is stopping us. And we have actually seen that. And I say, we, you know, I'm one of the labs stewards and we've certainly seen proposals sit there for weeks and tell people pretty much give up just because they failed to get a sponsor. And we've talked about how we could get people to volunteer, but it just doesn't happen. So I want to go back to this and say, okay, let's buy that bullet once and for all. The reality is there is also some misunderstanding in what the role of the lab sponsor is. I know that Brian for one thought that the lab sponsor was going to, you know, do some hand holding and help and ensure in fact that the lab behave, you know, according to our roles, whatever that is, you know, policies and make sure we have DCO sign-offs and all these good kind of stuff. This has never been agreed upon. Lab sponsors have never signed up to this. The only definition we have is written here in the proposal and it really comes down to, you know, doing an assessment of the proposal and say yeah or nay. And so the labs towards actually do that. I know that I do that on all the proposal whether I'm a sponsor or I'm least the sponsor or not. So I don't see any difference. I think there's been, you know, a lack of documentation as to what we expect from the lab in terms of, you know, how they conduct themselves, especially with regard to things that are very important like the license. And I think this is primarily due to lack of documentation. So I already remedied to some of that by adding documentation that specifies the license that is expected labs to adopt. But at the end of the day, I still very much feel like this whole business of a lab sponsor is misguided. We should just get rid of it. So that's my proposal. But again, you know, feel free to disagree. I mean, Bobby. Hi, as someone who is trying to get companies and people into our pipeline and get them working and developing, it is important that they know that there is an avenue for this. So again, I left a comment on this about lab champions as opposed to lab sponsors. And that would be maintainers and TSC members who keep their eyes open for projects and introduce the project, proposed project to the lab sponsors. Yeah, I do about it. We're like, we're all working together to make sure all great ideas get where they need to be. But not so formal. Again, when I tried to sponsor a project, I didn't know, and I was the one whose project had the wrong license because I didn't know that they had to pick a license. So again, I wasn't really the sponsor for the lab. I was more a champion. I was trying to get them into the labs and working. And I think if we all put that hat on, we can get more great ideas into the labs that way without any pressure of what does a sponsor do. That's all. Thank you. Thank you, Bobby. And I agree. And to the next day, you could say, well, lab sponsor, I think a lab sponsor. I mean, the other approach would be to go the opposite direction and reinforce or expand the role of the lab sponsor to be more in charge of the project and then mentoring or however we call it. I can understand how some people might feel like that would be a better proposal, but short of people willing to be signing off for this, I feel like the way we have the whole, and I feel strongly about this because the whole lab stuff, I came up with it initially. And there was really, the idea was to give people a sandbox. They can stop playing with that any hurdles. And we have created a hurdle there, which I was not in favor initially. And that has proven to be a problem over time. So I would really very much appreciate if we corrected that mistake. Of course, I see this as a mistake, others may not. Bobby, you have your hand up. Is that you want to speak more or is that just left? Yeah, but I just do have a quick point. The community isn't aware so much about the lab program and how they can get support. So I think that that's another hurdle is to make that more everyone aware in the community that that service or that support exists. All right, thank you. Tracy. Yeah, I think when we proposed this, when we wrote it up, I think we were in California, but I think the idea, or maybe we're in Spain, I don't remember which, but I think the idea was that there were two things that I think are potentially holding us back. One, we don't even pay attention to, which is that somebody actually has to be a contributor to Hyperledger before they can propose a lab, right? Which we as lab stewards don't even look at to see whether or not they are truly a contributor or not. We figure if they're there, I guess it's okay. The second one obviously is this lab sponsor being somebody who is already in the community who thinks that this would be a good lab to bring to the Hyperledger community to build on and that sort of thing. And so I'm torn. I still think lab sponsor is a useful sort of thing, but at the same time, it could be a detriment to bringing in new ideas into the community and new people into the community. So I don't know which way I land on this idea of whether or not a sponsor is correct or not. But I do think there is something that we were trying to get to with those two pieces, right? Which is somebody in the community thinking it's a good idea and then also people who are already contributors within the Hyperledger community being part of this. And I don't know how we achieve that without something. And I don't know what that something is that we were looking to achieve with those two things, but I just wanna bring that up as something that I think we should consider and think through as far as like, is there something that we're looking forward to ensure that we're just not a dumping spot, right? Are we any better here with Hyperledger labs than just creating a GitHub repo on your own and going that direction? So yeah, I don't have an answer here. I don't know whether or not to say yes I'm with you or no, or I'm against you. So I'll stop talking now. And I know this is fine and I don't take it personally so don't worry, but do you think adding the lab sponsor requirement today achieves that goal of we add initially? I don't know because I'm not sure what it was we were trying to accomplish, right? I really do think maybe we were trying to accomplish, not just being a dumping ground. And in that way, right, are the lab stewards good enough for that, right? I think we have four lab stewards, two of them have to say, yes, this is a good idea. Even when one of those stewards is a sponsor today, right? That that steward can still say yes. So, you know, is it really anything that the lab stewards are already taking care of? Maybe not. Maybe we're the, as lab stewards, the people who basically are the gatekeepers to labs to allow things to come in or not come in. I seem to recall there was maybe one lab where we were like, this isn't anything that sounds relevant and we declined it, but most of the things that do come to labs are things that I think we've basically said, yeah, this looks like something that could be of interest to the Hyperledger Treaty. All right, thank you. Heart is next. Hey, yeah, so I think one of the biggest benefits that we suggested about having a lab sponsor was that it sort of forced interaction between the people proposing the lab and sort of the Hyperledger community as a whole. I think part of our motivation for this was we didn't want people to be totally detached from the community. So I think that was at least some of the missing motivation. As far as being gatekeepers go, I mean, I don't think anyone has any problems with the lab stewards doing that. I mean, the lab stewards already do a good job. There's no massive benefit from requiring people to wrangle an extra person. So I think what we were sort of going for was that sort of community connection. And if there's some way that we could potentially replace that community connection without requiring the lab sponsorship, I think that would be the optimal way to go, I guess. Does that make sense? Yeah, and I agree with your recollection on that. I do think that was definitely a motivation to have the sponsor. I would claim though, we do not achieve that goal currently with the sponsor. I don't believe so. Maybe there are cases where it is, I don't know, but, you know, Tracy. Yeah, and I would add to that. I don't know that as stewards, we would be that we do that either, right? We don't say, oh, hey, that's a really interesting project. Maybe you should talk to these people over here who are doing something similar, right? Maybe I've done that once or twice when something like is similar to another lab that I've seen come in, like, hey, have you taken a look at these other labs that are out there already that already do a similar sort of thing? But beyond that, right? I think that we don't do that as stewards. We probably don't do it as sponsors. And, you know, maybe that's something that we need to be cognizant of and think through as these labs do come in. Here's a group of people who might be interested in that. Right, I agree with everything you said there. Haunt. So I guess I will say I did have one very positive experience as a lab sponsor where I don't remember exactly how, but I got asked to help sponsor a lab. I had some meetings. Then it turned out that the people who were working on this lab were in fact like working with a former collaborator of mine. So we had another meeting to discuss stuff and it just sort of turned into a positive process. But I'm willing to concede that that is certainly the exception rather than the norm. So there's a possibility which is to have it but not make it mandatory. I don't know if that helps, but... Mark asked a question that I don't have the answer to in the chat, which is, do we need to consider how we protect hyperledger? Is that part of the lab steward role? So I think the stewards definitely play that role of safeguarding, I mean avoiding the dumping ground aspect which is a valid concern. There I'm very positive about this. I think as it was said, I mean, the idea of the sponsor was really more about this, creating some linkage with the rest of the community. And I'll be the first one to say I regret it's not happening but it just is not. So that's why, it brings me back to what I said earlier. I invited the labs to come present to the TSC. I don't know if that helps but maybe there are other things like this we could try and do to bring them on board more with the rest of the community. All right, we're out of time. So we're not gonna call for a vote on this but the rest of the agenda was basically to go over the decision log and basically I want to do better housekeeping. I think there are quite a few issues that are pending that are more or less tied with other things. And so I think we could close some of them differing to others that are still open. So on this, I will close the call. Thank you all for joining.