 All right, the recording is on. All right, thank you. Hello, everyone. Welcome to the weekly TSC call. This is a public call. Everybody is welcome to join and participate. There are a couple of requirements to doing so. You must be aware and live by the antitrust policy, the notice of which is being displayed if you're online. The other piece is the code of conduct. So please be aware and live by those. So we have a couple of agenda items. There's an announcement first. I don't know if Jessica is on, but she asked me to echo an email she sent out a little while ago on the TSC list and a bunch of other lists as well. There is a marketing opportunity. The Hyperledger team is organizing webinars. So each project has the opportunity to put a webinar together. It can be of two different kinds. There is the one hour version or the 30 minute version, one being more hands-on, demo kind of oriented. And so there is a requirement for people to have the backup of a sponsor, which has to be a maintainer of the project you intend to present for. But other than that, it's a great opportunity to put educational material for your project out there and get the whole communication team of Hyperledger to socialize it through social networks and the likes. So if you're ever interested, there is a form for you to go and fill out to get the process started to submit a proposal. If there's any questions you can contact Jessica and well, anybody around the team, I'm sure can help you get to the right people if needed. All right, so we have received a quarterly report for Hyperledger Indy. It came in a bit late. There is no rush. I saw that a few people, a few among us had the chance to look at it. Nobody raised any issues yet, but I'm happy to carry that over to next week. There is no, you know, there's nothing in the report that calls for some immediate action. So I'm very comfortable doing this. Let's just keep it to next week. There are two main items for the agenda today. One is I would like us to make a decision with regard to the proposal to move the beef lab to a project and then later we can talk about the common maintainers management policy issue. Regarding the first, I don't know how much people want to discuss and ask questions. I saw, so following up on the TSE call last week, Hart posted on behalf of their team behind the proposal, a fairly extensive email trying to provide additional information and answering some of the questions that had come up during the calls. And then Peter sent, posted some slides yesterday. Is Peter on? Yes, Peter, if you want, I can give you five minutes to go over your slide. There's really one slide. And if you care to do that, I can accommodate. But I really don't want us to spend too much time. I'd rather we focus on trying to come to a decision as a group. So if there's anybody who has an urgent question, you know, before they can make a decision, obviously, if you have some still the need for clarification, you will have an opportunity to do that. So Peter, you want to present your slides? Oh, I was just posting those slides on behalf of Fujimoto Sun. So I'll forward your question to him. He's also in this call, right? So, right, if you click on the latest slides link in front of you there, that will get you to the email from Peter. And there there's the attachment. It's a very simple day. There's really just one slide. The first is the title. And so do you guys want to talk to this slide? Shingo, would you like to say something? Yeah, he's got his hand raised. Oh, yeah. Yes, please go ahead, Shingo. Thank you for this single for Fujimoto from Fujitsu. This slide is showing that as a response to the previous meeting, the request, we need to show the use case and non-financial use cases like the simple use cases. So this one is showing to the token ratio and marble, the ratio will be integrated as one single service. And actually the main member of the BIF agreed to provide this example as an implementation as an example of the BIF. So you will see that this one is in a few months later are the workable that is only the same for the slides. Thank you very much. I'd like to take your questions. All right, thank you. So I don't know if people needed that, but hopefully it adds to the picture. So now with in mind the fact that I'm going to call for a vote on whether we should approve this proposal to create a project out of the BIF lab or not, it does anybody have any questions for the team here? I don't know, this is Angelo. I have more a question for you actually for the other TSC members. And this I've seen also in the emails that are in the thread of emails. I don't remember who was questioning which are the actual criterias that the TSC will use to make a decision on such a move. So I would like to ask the others or the other TSC members about which are the criteria that we should use to evaluate this decision? Because I'm a bit confused. So it's depending on this criteria, I might take a decision. I will definitely, to me I'm not convinced by the proposal but depending on the criteria, I might change my decision. All right, so we don't have to directly answer your question. We don't have a document that defines the criteria. What we do have is what is called HIP Hyperledger Improvement Proposal which is a template document that people are being asked to fill out that provides what was considered to be key information to make this decision. And they have done that. This is what's linked from the agenda, the first sub-bullet blockchain integration framework beef proposal. That's the Google document that follows a template that provides, as I said, key pieces of information. This template was put together at the beginning of Hyperledger. Nobody has asked for this to be updated or questioned it. So that's what it is. That's all we have. But we have Chris here who has even more history on this than anyone else. If Chris wants to add something, I don't know. No, I mean, you've pretty much said it. There really isn't, you know, it's kind of like the definition of obscenity when we see it, I don't know. But I'm still, I gotta say, Hart, I saw your note and I appreciate it, but I'm still, I looked again at all the use cases and they're coin, coin, coin, coin, coin. There are two non-coin use cases. And I'm still struggling, maybe it's just my, I'm just not sort of getting it, but I still don't see what the difference is between this and Quilt. Sure, I mean, I'd be happy to explain that in more detail. Quilt is, you know, specifically using, it's using a very specific mechanism, I guess, to do inter blockchain transactions, right? Where's the BIF is totally pluggable. And I guess, again, in our document, I guess we've probably presented too many token applications, but the point is it's flexible. You can do anything you want. So is there something, so Hart, can I just, can I just add something real quickly? Sure. So Chris, my interpretation of this is Quilt is a protocol about a very specific kind of transaction and a very specific kind of asset. BIF is really an SDK. It doesn't tell you what a good application is, but it does allow you to create these applications that involve transactions that span blockchains. So when I read it, I read it as an SDK for building something. Some of those some things are gonna make sense and some of them are not gonna make sense. But that SDK itself is something that I think is pretty valuable. So, I mean, again, as I've said a number of times before, as I've said a number of times before, I think that if we were going to try to come up with an SDK that could be portable from one platform to another, then you can write clients that they don't care what's behind the curtain, right? The APIs are all exactly the same. And the implementation of how you do consensus and whether you use a Merkle tree or whatever irrelevant. So from that perspective, I mean, it's the one place in our architecture that I think makes sense to start working on. But I think that we need to walk before we can run. And so now we're putting together a SDK that you're intended to plug stuff into the back end. And I suppose that's one way of doing it. But I would think that it would be better if we can come up with the model that says if this is our data model, this is our model for how transactions are made, then we should be working to get the frameworks to adopt that model rather than try and shoehorn in things that don't necessarily fit. If you follow me, I mean... What do you mean by shoehorning in things that don't fit? When you have to build in a shim and implementation of a driver that's going to make the back end calls, there's an assumption made that the models are basically, maybe not isomorphic, but they're extraordinarily similar. Right. You're going to have a situation, I think, where you're going to be trying to adapt a platform. And its SDK, its protocol, its APIs are going to be a square peg for a round hole. There's a big difference between the kind of SDK that Chris talked about before, which was to have some kind of common SDK that allows you to plug your application to different networks. And this actually implies that you're talking to multiple networks at the same time, right, doing these kind of transactions across networks. Well, I think that's a secondary thing. I think that comes afterwards. I just, I don't know. I mean, look, and I said this before, I said this in the thread part that you cited in your note. And the last comment I made was, I still think that it makes sense to make sure that everybody, all the maintainers and the contributors to these various projects are essentially bought into the same model. And I don't know that we're there. I don't know that we're even trying. So, you know, I guess sure. But I just think we're. Yeah, I agree with you totally that the best possible solution would be if everyone agreed to a common data model. But I'm not sure this is even a reasonable thing to ask within Hyperledger, much less outside of Hyperledger. Like, you know, a lot of the business applications that say, you know, Accenture does involve Corda. Are we going to be able to get Corda to collaborate on a data model with us? Are we going to be able to get Ethereum to collaborate on a data model with us? I hear what you're saying. And yet at the same time, I'm also very mindful of the fact that the integration happens at the application level, not the blockchain level. And so in a sense it almost doesn't even matter what the underlying data model is. But one way to think of this Chris is that this is your application level SDK. I mean, yes, it's not sitting on the client, but this is how you build your application. And the criteria that I would ask you for is not, is it a perfect data model? The question is really, is it useful? Is it useful for building applications? And I think the reality is we're not going to have consistent data models. It's unrealistic to believe that there's going to be an effort among the maintainers to coordinate that kind of activity. So the question is, how do we get usefulness out of this? You've got two companies that are Well, but I mean, okay, I hear what you're saying. And yet at the same time, let's say I'm trying to do the food interoperability use case that's in the white paper. Let's assume I'm doing that. And organization A's blockchain uses GS1 data models and organization B's uses ed effect. That's the application data model. These things are not the same. There are some ontologies that try to make them somehow rather somewhat interoperable, but that's a huge thing. It's not just some smart contract. It's a whole right. Well, to go farther on that from the identity side, we've learned that having different data models is actually a big advantage and one of the drivers behind having separate chains. So it's not about just telling everyone they have to follow the same data model. And so this adapter type approach has a lot of business value and application value because it allows you to have loose coupling between the ledgers while still having some sort of, you know, agreement between the two systems about how translation between one and the other has to occur. And so there are ways of making it so you can validate the other ledger state natively on your chain. I think some of those are stronger from a trust architecture standpoint, but it's clearly there's business need for this as a, as a solution with the companies we're seeing sponsor it and having this kind of tool set to make those types of adapters gets us closer to those steps that I think are farther along in kind of how we evolved this in terms of interoperability going forward. And I don't think the intention is to solve every one of these data model problems. I mean, because you're pulling out something that's an extreme example, it may be common, but it's extreme. The question isn't, can we solve all problems? The question is, is it useful for solving some problems? Or maybe enough problems to justify being a project? And, and, and I think that's probably the case. Sorry. Yeah. So to follow up on that, I wanted to keep and try to give some answers to, to Angelo's questions about, you know, what are the criteria? I mean, the kind of information we've been looking at before to try to assess whether, you know, we should approve a proposal project proposal like that. We're things like, of course, you know, does that fit within hypervisor? That's an obvious one. But beyond that, it was like, is there enough support to make it a viable project? And I think, you know, having two companies was always considered to be a good sign, which is the case here. And, and then, you know, at the end of the day, it's like, do we think this is a viable project or is it, you know, does it look viable enough to, to be worthy of investing hypervisor resources supporting this project, you know, beyond what is afforded to a lab, right? That's, that was the whole idea of lab. They are very cheap to, to have projects are more expensive. They, they are under the governance of the, the TSE. And there is, you know, they have all these resources are located to it in terms of the IT infrastructure, but also, you know, communication and so on. So like the security audits, all these things cost money. And that's why there's a difference between just a lab and a project. So hopefully that helps a lot. Yeah, I don't know. I think the same. And I was thinking to myself, I was asking my, to myself, why, why then hypervisor fabric private chain code is still, it's still a lab project. So it has a massive amount of source code. So it has sponsored by two companies, IBM Intel. It's very, it's full. So there is code there. You can run something. So, but this project is just a proposal. It's sorry if, if I say that, but it's very questionable because it doesn't say how to solve the huge problems. I mean, the fact that you in the answer, you say, oh, yes, you can plug privacy. Thank you. That's, of course, that's a tautology. We can plug privacy, but how? I mean, you are, that's a hard problem. How to make, how to, to, to realize privacy, you know, that's the hard problem. So to me, if we accepted this to become a project, maybe there are also other projects that needs to become automatically project other labs projects that needs to become projects automatically. So this was my, my, my, this is personally what struggles me to understand. So either we set criteria precisely. There is also in terms of a code availability. So for example, it's important that there must be something running that they should this, they have to show. We have to pretend them to show a game. Give us something. You say that this is useful. Give us something that we can evaluate and say, oh yeah, you give us something that is showing is promising. It's going this direction. Notice also that fabric private chain code. Now, of course, I'm, I'm sorry, I'm, I'm from IBM. So maybe I'm, I'm, I'm definitely biased, but there is also a publication accepted at the, at the conference. So the, the, the work has been also being reviewed, which I don't see for this, for, for this project. Okay. But Angelo, so let, let me say one thing first. The private chain code, you know, there's not been a request made to the TSC to turn this into a project. I think in fact, if anything is going to, you won't hear one. Not to distract, but I think the point was nobody said no to FPC. So saying that FPC isn't a project. Therefore this shouldn't be a project doesn't make logical. Exactly. That's beside the pot. So let's leave that aside just for the sake of it. And then the, you know, so then there is not going to be more specific criteria for you to make the decision. I gave you as much as I can. If anybody else has additional information, please go ahead and provide it. But if fundamentally, you know, if you believe there's not enough, well, then you shouldn't vote in favor of it. That's just the way it is. And by the way, this is a lab, right? So, you know, people may decide, you know what, it's not, they haven't convinced me that it's, they have made, they have enough to be worthy of a project yet. And we can say, you know what, keep making progress as a lab first, show me that you can actually achieve something. And then we'll talk again about making it a project. That's a reasonable position as far as I'm concerned. So, and at this point it's up to every one of us to make their own call. So let me turn again to everybody before I call for a vote. If, does anybody have any other questions they need to get answered as much as possible before they make that decision? This is Troy. I was putting into the chat that I think the difficulty is evaluating earlier projects or projects that have less sponsors. So the decision seems to become very subjective. And I haven't really resolved that issue at least for me. Yeah. No, but that's true. And I mean, I've pointed that out before and I think heart was frank enough. And he said, you know, if anything, hopefully this will make it more visible and attract people to the table. One of the challenges they have is they want to create this like super API kind of thing. And they want to have as many people involved early on as possible so that they don't have to redo it as people become aware and interested and come in and say, yeah, your API is good, but not quite right for me. Can you make it so and so and so. And every time they have to refactor everything. So I can understand where they're coming from. But that's the way it is. So any other questions or remarks? Otherwise, I'd like to go. I think looking at this as a portfolio decision, which is not something that we necessarily do, but we feel like we need more kinds of projects that look at integrations or look at ways to stitch things together. And so it should never just be a blank check that if you, if you're trying to solve that problem, you get in as a project. But we don't have a lot of strength in that area right now. And we could say that we do have quilt, but I would not put all of our eggs into the quilted basket to make some metaphors. That's all I have on that. All right. Anything else? Any other wise comments? Well, let's try again. The other comment I made is I still see struggle with this labs designation. And, you know, this bullying category of labs versus projects seems to be a bit problematic. I'm interested in that. Why is that a problem? It just seems that maybe project or lab projects are seeing an advantage from being a lab. And I guess the key concern I saw in the proposal was they don't want to just be a lab. So I don't know what to do about that, but it just seems like a problem. Well, we can ask them what, you know, again, hot. Maybe you can speak for the Tracy for the group on that one. What's the primary motivation at this point in time to try to move from a lab to a project? Tracy, would you like to talk or should I? I mean, I think it really does come down to the community. Right. Getting the, the wide diverse set of opinions and contributions to the community that maybe we're not getting currently as a lab. It feels to me like some people on this call are saying labs are bad, which I, I don't think is the case, right? Or they're lesser in some way. I think it's just a way to start begin or to start building that community. But, you know, I think there's a obviously, you know, we weren't getting this kind of discussion before we brought it up as a project proposal, right? We weren't getting the opinions, the people looking at it in a different way until it was brought up as a proposal. So, uh, yeah, that's, I guess where my brain is right now and heart, please add to that. Yeah. I mean, another reason is we want to, we want to use the tools like, uh, you know, Peter and some people were talking about, you know, setting up basically their own CI CD. And, you know, we, it would be, you know, easier for us if we could just do that once, uh, in hyperledger and didn't have to like do it now. And then, you know, do it later. It's some other status and change everything if we became a project. So, so some of the tooling is, is also a reason, but, um, Yeah. I think Tracy said it. All right. So with that said, I would like to call for a vote. So, um, would like to make the motion to call, to approve because that's the proposal, uh, moving the blockchain integration framework lab to a project. This is Dan. I second. Thank you. Okay. So we're going to call for a vote. Right. Uh, Angela. No, I'm against. I know. Actually I'm going to abstain and I'll comment a little bit because it's not to come on to abstain, but, uh, I'm really torn and, and on the one end I feel like, yeah, this sounds like interesting enough that it might be worth a project at the same time. I feel like a bit more work could be done in the lab, especially since there is two code bases, trying to show a little bit how you integrate those things already would be a good first step. And I'm hoping that having raised this already as a proposal will have given it more exposure and attracted more interested parties that you can actually at least achieve some of what you were trying to achieve by moving to pro to project. Chris. Well, I guess I'll say, okay. Um, I want to say non-committal or something. I don't know. I, I, I. I'm not overly thrilled with it. I mean, I tend to be very skeptical about any integration, but, um, I don't want to get in the way. Okay, Dan. Can I just say approve or do I have to? Sure. Okay. Gary. I don't know if Gary. If I can get him off of his other call. I have him. I have one slack. Hold on. He said on the chat that the, let's move on and then we'll see if he catches up. Hart. Yes, Mark. Uh, yes. I hope that will bring extra visibility and, you know, that the team will welcome more input from a wider diverse audience. Okay. Yeah. Yeah. Yes. Yes. Yes. Tracy. Yes. Troy. I'm staying for the same reason as I know. Um, so I was just chatting with Gary who's still on the other call and he says he's not against it. So is that a yes. Yes. Yeah. It's really simple. Like yes, no. He says here, are we voting on the Biff and he says, I'm okay with that. It seems like there's no harm. Okay. So I think we're done. There's no objections. There's only approves and a couple of abstain. So therefore the motion is passed. Angela. Yeah. Angela voted against it, but. Oh yeah. Yeah. Sorry. Yep. You're right. My bad. There's one vote against it. But so that's done enough. Okay. It's not unanimous, but the motion is passed anyway. Mazel tov. Thank you. All right. Okay. Congratulations. Let's move on. So I, I would like to continue the discussion. We started a little bit. And I tried to. Put a bit more meat around the bones. In putting up together an issue in the decision log. And at least a few existing policies regarding how the projects are maintaining. Or managing their maintainers. Least. And there are variations for sure. The issue for me is, you know, in keeping with what we try to do with the common repository structure. Is, you know, trying to provide some consistency across the different projects. And to be clear, I don't mean necessarily that there is one policy that's very like, you know, constraining and that's adopted by everybody. I think at least I would like to have some basic policy that would be the default for projects that do not have one. And, you know, happy to adopt whatever sounds reasonable. And, and then, you know, maybe it will influence some of the existing projects to have some to, to, to align their policy. And then, you know, I think it's bad that so many projects do not document how maintainers are being, you know, elected or selected. And, and so at the very least, we should have some kind of documentation of how this is being managed at the project level. And so as part of that, we have some kind of documentation of how this is being managed at the project level. And so as part of that, we have to kind of define, you know, what are the key elements of management policy that you would expect to find in that, in that kind of policy. And so at this point, I don't have a specific proposal again. I just started the, the, the, the, you know, trying to gather information about what the current state is. I only found like a handful of projects that actually are found, like a handful of projects that actually have one. So there are quite a few projects for which I even found any, I don't know if they have one. If you do, there's a list there. It's, you know, it's a wiki. You can update the page. And once we have gathered enough, I think we can start putting together the elements that are common and maybe what is missing and what seems to be reasonable. And together we can kind of start building what seems reasonable, you know, and, and again, we don't have to decide this is the one and only one, but we can at least have some common ground. So that's the premise. And this is what I'm trying to achieve here. I saw there are several people have actually started commenting on the issue. Thank you for doing that. I would like to open it to everybody to discuss and share what they think about this. No, no takers. I have to say, I will add, if you look at the list, in fact, there are three different ones, different policies. We have one for Bezu, which is actually, I have to say whether you agree with it or not, it's very well written, very detailed, and they explain exactly the process they go through. Fabric is a pretty good one, too. So-tooth is a good one, too. But then, you know, all the other projects are basically, we're built out of so-tooth and they all share the same. And I don't mean to say it's not as good as the others. I just want to point out that, in fact, we don't have so many different variations. We only have three different types of policies in the works today. In use today, I should say. Yeah, I think so. This is Chris. Oh, sorry. Go ahead. Go ahead, Chris. No, you're good. Okay. So I was just going to suggest. That what really needs to happen here is that we get the maintainers of the various projects together, like we did in October. And virtually, obviously. We're not going to let them, let them hash it out and come up with something rather than us telling them what it is. Does that make sense? No, but we have. A lot of us how maintainers too, right? Yeah, that's true. But not for every project. That's true. Okay. Yeah, I was going to. Yeah, I was going to think, I believe Gary commented on there and it made a lot of sense. That we have some kind of like core. Policy that, that people can adopt. I mean, sometimes we need like a slightly different policy. And I mentioned Ursa as an example there. Where, you know, You want to sort of break out into like types of maintainer and other stuff like that, but I think Gary's suggestion was excellent. And. You know, that, that sounds like a good way to go. So it's Gary on. I'm here. Can you hear me? Yes. So to speak up to this. Yeah, I mean, I guess what I was sort of proposing was it was kind of all on the lines of what you said. I thought that maybe we could at least have a set of, you know, a couple of like standard. Types of policies at least like what, you know, the. How do you become a maintainer? Right. Like, you know, what's going on here? Here's, here's that you become a maintainer. Here's a retirement policy. Like there might be like maybe three or four different types. Like I guess attributes, we can call them attributes or whatever that might be in the policy that people should have. They could know off one if they, if they say, hey, we don't have one for that. But that was the, that was the basic concept, right? Pick a couple of these standard things in a life cycle of being a maintainer and say, Hey, this is what you should at least document. How you do it, right? Here's how you become a maintainer. And it, you know, if you do X, Y, Z and it requires a majority of the maintainers to vote for retirement of a maintainer or whatever we want to call for inactivity. We define inactivity as this amount of period. And again, it's a vote of majority. You know, and maybe if there's something, if there's not maintainers available for something, I don't know, you know, we could. So, I mean, there's at least two. How to become one and how to retire one or make one inactive. That at least people would, you know, that that would be kind of the standard that we would have. And you could pick your own, how you want to do it, but you would at least document those two, at least those two processes of the maintainer. There is one that's not covered here explicitly. And I don't know if that was an oversight, but a Roja does their maintainer elections in GitHub chats. And for the group like a Roja dash iOS dash maintainers, they have a discussion there and they vote there. I know back when we had Garrett, you know, you, you could vote there on it to make everything public. And, you know, you can make your argument, but yeah, I'm totally in favor of making this as explicit as possible. And right. Do you know if there's a documentation about their process somewhere? No, I don't. We have anybody from the project on who could speak up to this. So I think that. So what are we saying? Are we saying that we're going to have a framework that you need to have? How do you become one? What are your responsibilities? How are they removed or retired or whatever is that? I think what we're, what Gary was saying is that at least we should have, you know, a requirement that every project has a policy that's documented that that and the least of items that you expect to be covered in the policy. A framework, right? Exactly. Yeah. I'm good with that, but I guess coming up with that framework, I mean, maybe it's not that hard. I don't think it is because we already have some, so, you know, I'm happy to. But I still think that you want some buy-in from the main thing. We want to impose anything. I'm not hearing that we have to have a unified one. Yeah. Okay. But I still would like to. It wasn't unified. It was, I think it was to say, one, you should have a policy. Here's some common policy stuff that we expect you to have. And you can do it. And we can, you know, like, like our government likes to do, we can make it a recommendation, but not a mandate. Right. I like Chris's idea of bringing it to the maintainers, but I think, you know, we are a technical steering committee. We are not a technical governing board. So there's a balance we have to do there. Yeah, I can see us saying here's some guidelines that we hope projects would follow and steer them in that direction versus thou shall have all of these covered. Yeah. Well said. I kind of like that. And are we also making a recommendation as to where that policy is defined? I mean, we see there's a number of different places here. Well, it's for us to decide. Personally, I actually kind of like the basic approach. I actually kind of like the basic approach, to be honest. To have it in the maintainers file. Yeah, I like that. I think at least having a link from there, if it's not there, is an obvious place you look for. Another thing worth noting about our maintainer policy is we also do our governance on GitHub. If you want to add someone, you do a poll to the maintainers and the discussions and the votes are in the GitHub comments. So it provides a semi-permanent record for it there too. So we're kind of like a Rohan in that sense. Fabric is the same. Yeah, because it's the easiest way to get a voting mechanism and an auto log, as you said. So at least we could point that out as a way to do it. Right. And that might influence those who don't have a way yet. And not like, how do we do this? Whether they reinvent the wheel every time they might say, hey, that sounds like a reasonable way. Let's just do this. And then we at least get some kind of, you know, harmonization across the projects. I really believe that a lot of the disparity we have, the variations are more accidental than, you know, intended. It's just because there is no single way to do it or not even a recommended way. So people say, oh, we should do this. Let's invent a way. If we even showed one way as a possibility, I think people would naturally adopt it at least for a new project. They don't have one. So I'm going to suggest that I'll take a stab at creating a PR against the TSE repo. And we can review that for next go round. Oh, that's great. Thank you. And I mean, to get back to Chris's point about getting the maintainers involved, I agree. And I think once we have at least the beginning of an answer, we can definitely, you know, highlight it to the maintainers app to send an email to the maintainers list and tell people, Hey, we are working on this. It will impact the way you work. So you might, you know, if you care, please comment on the proposal. And so we can include them in the process. Speaking of the, the. The hypernager repo. Right. I know you were working on this for the, the document. The governance document we're supposed to start putting together any updates on this, the repo exists. I would defer to Brian on that. Yeah, that's, that's on me. No progress on that yet. Okay. All right. So I think anything else we want to add to this question. I think we have a plan. Thank you. Tracy for volunteering. If nobody else has anything to say on this yet, let me ask, if there's anything else somebody wants to bring up before we close the call, we have 10 minutes. And I don't think anybody minds closing 10 minutes early. I'm happy to do so. But if you have a burning needs to share something with the TSE, now is your chance. All right. If not, then I'm going to call it. So thank you all for joining and we'll talk again next week.