 Hello, everyone. Welcome to the TSE weekly call. As you all know, I'm sure this is a public call. Everybody's welcome to join and participate. However, there are two requirements to doing so. The first one is to live by the antitrust policy, the notice of which is being currently displayed. And the other is the code of conduct, which governs how we conduct ourselves, and which is linked from the agenda. So, not much in terms of announcements for today. I would like to point out, I sent everyone on the TSE email about this, the new beta chat system is live. And I had channels created for each of the graduated product, not graduated. Whatever we call them now, graduated projects, and a place to test bots. So, I just ask everybody to get over there and kick the tires and see what works or what needs changed. I am glad you're reminding me of this because I saw the email and said, oh yeah, look at this. And then I quickly forgot about it. But can you tell me more? What is this tool? What is it based on? Matrix. This particular chat is using the element client, but it's a matrix server. Any element, or if you have the element client on any of your devices, it works. Not all matrix clients work because not all matrix clients support random SSO. But I like it. I like the client. I like how easy it is to get integrations up and running. I'm interested in feedback. And at some point, once this is not integrated with our support thing, so making new channels is a very manual thing. I have to ask IT to do it. So, that's why I'm keeping the number of channels very small right now. Just until we get our wheels under us. All right. Thank you. Any other announcements? Yes. So, it's not an announcement, but rather a request to all the project maintainers. And so, I see most of the reports submitted in last quarters, maintainers are asking that we have feature roadmap, but we need developers who can join and get this work done. Probably this newsletter, which we see on the announcement tab or on this sheet is a good way to get those developers' attention. And I see this is not that widely getting used currently to attract those developers. So, if you have a project need and you know the feature roadmap that is planned out, it would probably be best place to go and add a note in this saying that we are calling for contributors in this space. So, please go and find what you can do in, let's say, in GitHub issues for this repository. Even that kind of information could be very helpful. All right. Thank you, Arun, for the plug. So, there is indeed the weekly newsletter. So, this is reminded of the existence of this newsletter and the opportunity to represent the projects to highlight what's going on in our projects. Is there anything else anybody wants to bring up now? Okay. If not, we can move on to the quarterly reports. So, there are two that had been around for a while, but they had been submitted fairly, you know, shortly before the previous call. And so, I put them back on the agenda just to give everybody a chance to raise any issues they may not have. Looking at the reports, let's see, you know, a pretty good chunk of the TSC membership has reviewed those reports. I haven't seen any issues being raised that need to be brought up now, but now is your chance. And otherwise, there is the new report, the first Q3 report from the cactus project. And they didn't raise any issues for the TSC, but if there's anything anybody wants to bring up now, I saw Tracy brought up a question about the plug-in work possibility, and there was discussion in the TSC call previously on using one of the cactus calls to discuss the possibility of doing collaboration among projects, between projects around this notion of connectors to the different frameworks. And I saw that the HOT responded saying that they did have that call, and that there is actually work being investigated in terms of actual connectors that could be shared between the different projects that have this need of connecting to different frameworks. So sounds promising. Is there anything, yeah, HOT I see on the queue is going to prompt you to ask if you wanted to add anything. So good. So on this topic, I know that Peter is doing a lot of work on this, and it might be good if we had him discuss his results maybe, or what he concludes, and sort of, I guess, talk about the process once he finishes up. I think it might be a good story for everyone to hear about sort of a cross project. I guess, well, we don't know how it will go, but at this point it's just an attempt, but we obviously hope it succeeds. So, right. Now I agree with that. I think we probably need to give him a bit of time, but we should extend an invitation for him to come and tell us about his experiment. Sounds good to me. Is there any questions otherwise on any of those reports? Anything else anybody wants to add? There is the Q3 report for Fabric is due. Both Dave and I were on vacation last week, so we didn't get around to doing it, but I'm sure we'll get that soon. All right, if there is no other questions or anything on that front, we can move on the discussion part of the meeting. So there are a couple of issues that were brought up that we thought we could take advantage of the call for discussion on those. The first one is he came up as part of the effort that Dano is leading on basically describing a narrative version of the common repository structure, having a file, a page in the TSC pages on GitHub describing what is exactly that is being required from the project in terms of the structure of the repository. And there was a question specifically related to the changelog file. So the initial implementation when we were relying on the repo linter tool, the config file, I believe, required the changelog and there's a question. Some projects say, well, we don't really need this. It's kind of superfluous because we already have the history in the repository available. Why do we need the changelog? So Dano, I'll turn to you and I know Arun, you had a say in this as well. So what do you guys tell us where we stand and what decision the TSC needs to make? Right. So if the decision is to change it so it's not required, that's fine. I think it needs to be delivered TSC decision because going required to optional is not a small change. But I would advocate in favor of keeping it. The main argument is that Sawtooth uses the release notes in the release column for GitHub. But when you fork a repository, you lose that change history which could be useful for the point that you fork it at. So my best idea is that we would all keep it in the changelog and what Basu actually does for their workflow is they keep the changelog as they're doing it and when they release it, they just copy the changelog into the release notes. So there's a workflow where you can do both relatively easily. I'm not going to be a total stickler on that. If they just want to in the changelog say, hey, go to this, GitHub link with the releases, here's the key part change notes, that's fine. So it's kept in there so you know where to look at it. But if the TSC thinks that a changelog should not be required, it is optional, that's fine too. I think it should be a conscious and deliberate decision though. Arun, what's your take on this? After this comment, I actually went through a couple of repositories and not a couple of a few projects under hyperledger and see how different projects are currently following this requirement. And I observed different behaviors across the projects. So there were projects who were dumping the committee street itself from the previous release point. And there were projects who were having a cleaner release history being maintained in the changelog. I guess if we are saying changelog is required, then it also should be defined like how what content should it have. For example, as Danu said, I'm okay to keep this file as long as there is some way of automating it, right? Before we mandate a process on a particular project, if we say, hey, whatever process you're following is fine, it's all good. And here is a tool or command which will allow you to dump information which is already available into a file. So this would be just a new step, one more step as part of your release process. Then I guess it's easy for us to convince projects than just saying, hey, this is a requirement, so you need to do it. So argument which I believe, I guess I know you were also involved in that previous. I guess it was one of the reports if I'm not wrong, where this was initially brought up quarterly reports. And in the comment section, I remember that we discussed and then there was a section where Andy or somebody replied from sort of team saying that they maintain a commit history and then there is a release note mentioned which tracks what was changed and what is the breaking change. So that's where in the chart section over there, we agreed, okay, let's change it to optional. So that was the initiation point. So if we are saying this file has to be mandatory, I guess then it becomes a requirement that we define what should go into this. If we say this, only this file is mandatory and then not having anything in it is also fine, then it's like just having a file there, right? So my concern over here is we should probably either define the format of the file or what should go in here or we should make it an optional or if we are making it mandatory, we should probably define a structure over there. All right, thank you. Any opinions from anyone else? You know, the point on the content is if you could argue this is true for a lot of those things, right? I mean, we went through this like with the maintainers file, for instance, where we say, well, you know, we're requiring a maintainers file, but we're not saying what that contains. And so we can always go further into this, but I don't know how much we want to be prescriptive of these things. So there is a bit of a description that goes with it, if you could scroll down to the next lines, and it's not going to need to go to the file itself. But in line 33 through 36, it says it's human readable list of recent changes. Changes should be at least include, changes should at least include the current release. This file may be maintained or curated or mechanically produced. Continuous integration, yeah. And then let me go to the CI stuff in line 35. So there is some sort of a description of what should be in there, recent changes. And I think if we get too prescriptive beyond that, we're going to read the flexibility because it should be human synthesized rather than just a get logged dump, but that's an option. You know, if you're doing 100 changes and you're saying, well, all we're doing is updating from version one to version two of the spec, that's a great change log entry that synthesizes all 100 changes. Yeah, I agree with the, I'm glad you pointed out that there is some high level description and I agree that this is probably as far as we should go. I mean, I know that in fabric, we have a tool that we actually use and probably does what you just said we shouldn't do, which is kind of like automatically, you know, go through the GitHub, the repository history and grab all the headlines of favorite commit and basically compile this. But that's a practice that is at each project in the site. In fabric, I imagine you have a much stronger requirement that line have useful information. Not all projects require that. So, you know, it's each project manages if their own is fine, as long as there is some standard expectation, there'll be some change log description, what level they put it at and how finally they do it. That's that's project determined. Yeah. Yeah, personally, I'm happy to leave that to the product. But so I'd like to hear from others. I mean, finally, we first have to, you know, decide whether this file is we want to make it optional or if we want to make it required. I see that Dave any arts. I'm muted. I was just going to say to our know that we actually stopped maintaining the change log when we switched over to using GitHub and rather than Garrett, because we could just point to the GitHub history. But was somebody saying there was an issue with that at the beginning of this conversation. Yeah, that no says that people fork the repo won't have the history. So we put our human readable kind of interesting changes in the release notes. Right. So there's kind of an overlap here with the release notes, I think. So maybe the change like should just have a pointer to the original repo. And that way, if you're totally satisfied with that makes it clear it's a fork. Here's where you get your main information. So it gives them what they need to know. I'm totally cool with that. It sounds good to me. So any place where they can get to know the notes, right? Not necessarily the GitHub history, even though, let's say, if these notes are compiled together and then put up in a GitHub page, which is sourd as a website, even that is fine, right? Right. So the common repository structure, we want to get a change log. You open up the repo, you like to change like it gives you the notes or tells you where to get them. And I think that solves the need. Okay. I'm also interested in lines 35 and 36 there, but that's for that's a fight for another day. Because we still have a bunch of projects that are running in opaque Jenkins instances that are hard for anyone to get information out of. So that's a battle for another day. Right. And I have a follow up question on this because the definition of project when we discuss these items are not quite clear. So when we say release notes at the project level, are we talking with respect to a particular repository, which also could include, let's say, some of the dependency GitHub repositories or are we talking at individual repository level that every repository should have this file and should be independently maintained? Every repository because it's a common repository structure. And if they just take the same change log and calculate across five repositories, at least they know where to look now. Yeah. If there is a main one that's like, you know, in the main repository, like if you have a core repository where you actually have the info, you can have the other ones point to that. That's totally fine. But at least people find their way around, which is the whole point of the common repository structure in the first place. I guess we may need a reminder on this then or each of the reports when projects submit. We probably have to ask them, hey, do you have this? If not, then probably here is a document. These are the mandatory files. All right. But so I think that's fine. We can expand on the description so that people understand what this is about and what they can do. But so back to the change log specifically, I think it seems like do we have an agreement that we would keep it as required or make it as required. But we add a note saying, you know, beyond what it says today, that alternatively people can point a link or add a link to where the information can be found, which can be just your GitHub repository history. Does that capture what we were talking about? It sounds good to me. Yeah. I'm fine with it. Anybody disagrees with this or have concerns? All right, not. So I think you guys can update the PR accordingly and I should do it. Is there anything else on that PR that you guys feel like would be worth discussing now? So there was a related topic on release, but it's mentioned as a separate discussion. So I'll hold it on hold on to that. Yeah, yeah, yeah. We'll move to that next on this. There is something else like I was talking about. One other thing about SPDX license info headers are required. Are they based on the old copyright and license policy? Is that binding? If it's binding, I think it should stay. If it's not binding, I'm okay making it as should. Okay. I remember seeing the comments on that. Can you restate the issue so that everybody gets on the same page? So recommended it says Apache license header information in each source code file. This should include the snippet SPDX header identifier and patch it to as part of the header. And the question is, should it say either should have the SPDX or have the batch of two license mandated header? I'm okay with either one, but my understanding is there is a in the wiki display slash TSC slash copyright and license policy. My reading of it says the SPDX is what everyone should have. That doesn't mean everyone's in compliance with it, but that's my understanding of a previously adopted policy. Where would it hide? Let me click on the mind and tell you where to browse to. Tech, let's tear you from the home slash hyperledger projects. It's commented in the PR. If you can go back to PR. Okay. This is the page. So the license section seems to imply that wherever you claim a license, you should have the SPDX location in this space. This is something that makes it incredibly easy for automated scanners to verify when it's there, because I think it's why a previous TSC requirement, if I'm reading it right, it's a requirement. Yeah, it guarantees that there's been a small edit to the license text that you may hear may be hard to, you know, spot. Tracy? Yeah, so I can comment on this since I created it. If you read the very first clause of the statement under license for new files added to hyperledger repositories, it wasn't intended to reflect that all files had to be changed to have this. And so I think that's why it's recommended. But for new files, we did want the SPDX license information instead of the full text. And it's for the reason that Arno just mentioned, right? It's hard to, you know, do a full text scan and not notice something that might have changed. So yeah, for new files only. Okay, I can update that line in the PR I have out. And I will say historically, one of the larger issues with automatically verifying like the Apache license is someone will edit it, and their editor will like reflow it. So it puts line breaks in a different place or whatever. And it's just a huge pain. So it's not just people changing the text on purpose, but you know, tools helping out making the world worse. So yeah. All right, so that's good. We've clarified that point. Thank you. All right, so I think we can then move on to the next topic, which as Arun was alluding to was related and came up from discussion on this. So Arun, I'll leave it to you. I'll give a quick background on this issue. So and this is one of the issue which even I personally had to face at work. And in fact, my team faced at work. So the problem was when some of the binaries which were released were downloaded, the behaviors changed over a period of time, like the behavior of a release binary. It was not expected the way it happened, right? So the release once it's done at the particular tag version, it should either follow an update process to that binary with a minor version release, or it should have a new major version release if it's changing. So from a release, and when I started looking into this release process all across Hyperledger, I know there was one requirement. I mean, so far only the governance that is put up on release is on the versioning scheme. Apart from that, I could not find much more description around that within Hyperledger. And this was similar pattern followed across in other Linux Foundation projects as well. I could not find much of it over others as well. However, I found this one to be interesting on the Kubernetes side. So if you see, they have put some governance around the artifacts that gets generated as part of releases. And how do we manage those things? It could be code branches, or it could be tagging, it could be binary artifacts, container images, release notes. So I feel there is a gap in Hyperledger, and it could not be just us facing this issue. It could be, let's say, somebody who is new learning. If they face such issues, it's probably not a good idea to let it go away like that. So that's the brief about background, why it all came up. So Arun, let me ask you a bit more, because you said the behavior changed. And can you explain a bit what the problem actually was? Yes, I was trying to avoid picking up any project's name here. So let's say I pulled a project X at version, let's say one, two, three. And it's working in some fashion. And then let's say in production, or maybe in some environment, I faced an issue. And I figured out from the code that that particular version, when I pulled the image, it had an issue. The release binary itself had an issue. But then when we see the commit history, it's fixed in the recent, I mean, post that point when we initially pulled that image. And when it is fixed, it is repushed at the same version. So for somebody who is using the same version, release version, the behavior in one environment is now differing with the behavior in another environment. So it is to deal with the, either the binary artifact or the container image that gets overwritten at the same version when a new release is done. I see. Interesting. So isn't that a violation of Sam there? Well, any version system, in fact. Yeah, I was going to say we do have Sam there. And most of the tooling that we have prohibits reusing version numbers like that. I say most. I don't know if that's true of all of them. So in terms of, you know, so this touches on, you know, the governance of, you know, the release process by the different projects today. I mean, at some point we had this notion of promoted releases, which define a bunch of criteria to be met for release to be, you know, to qualify for PR and the event. But we ditched that. And so today, what the only things we really say is we are Sam there and Cal there can be used for versioning of releases by the projects. That's all we say. But I would think that this, this particular example you just talked about this instance, or it would be in violation of either one of those systems being used. But in any case, what you're asking, I think is, you know, can we go into defining some kind of documentation? I don't know if it's guidelines requirements on what is expected from the different projects in the way they do release their products. You know, yeah, specifically around how the artifacts are produced out of that release. But do we need to have a document that says don't override, you know, don't publish different versions under the same number or name? I think it's already covered by our Sam there and cover. Exactly. This is what I meant. They were just in violation. I don't think we need to do anything. Besides maybe talk to them. Probably does it require us to really look into tools then and see why it happened? If you could provide a specific example, that would really be helpful. And if you don't want to do it in a public form, if you could send me a message so that I can look into it. If this was a hyperledger project, I'm interested to see how that happens. So please just send me a message so that I can see exactly what you're talking about, please. Sure. Yeah. All right. So, but it sounds like this seems, I mean, those who have spoken at least seem to be the favor of doing nothing more than trying to, you know, remind people of Sam there and Cal there, whichever they use, they have the option to use one or the other. But then they have to stick to those things anyway. And we don't need to do more. But it doesn't seem like there's appetite to do more than that. Am I wrong here? I think you're right. All right. Is that okay with you, Arun? Or do you feel like, no, we really ought to do more? And I really kind of like this document which is defined at the sick release starter within Kubernetes, because it's telling, it's giving the confidence to this, to somebody who's going to use the project as well. Hey, now the release is all wetted, it's confident. It's the same way in Cal, where if that was the more descriptive like this, or probably have some more information that could help. All right. So look, I, you know, I don't know how many people have actually had to look at this. I'm happy to leave it to people to look into it. Tracy, I see you're on. Yeah. I mean, I'm just just giving through this. And it looks like what project this is, Kubernetes. Looks like they may have a much more defined process for doing this. I mean, they're talking about a sick contributor experience group, a sick testing group. We don't have those things, right? Like, I just don't understand, you know, in the hyperledger space, how some of these things will apply. And I think that's going to be a big challenge. It seems like there's a lot more process, if you will, involved, defined process, prescribed process in this particular document than there would be in what we do typically in the hyperledger project. So that would be my biggest concern is that we are trying to be somewhat prescriptive when in the past we've provided guidelines. And so I want to make sure that we're not, you know, trying to chew off something here that we wouldn't normally chew off. All right. Thank you, Tracy. Okay. Look, I mean, the link is on the agenda. So I invite everybody to look into it. And if you feel like, yeah, there's something here for us to do, please let us know. We can discuss it again. So let's get to the last point in the agenda for today, the incubation entry considerations. So on the last call, we started this wiki page. And Daniel took the lead in, you know, starting to draft a bunch of requirements or criteria, depending on you or the call them considerations, I guess I should say, for what we should take into account when we have, we are trying to evaluate the proposal of a new project to enter incubation. So I saw that several people actually contributed to the content. And I was wondering if you guys want to discuss any of this. If there is any point you want to bring up for the TSE to discuss yet, or highlight. So I saw you guys put your name in front of each proposal. And I didn't know if it meant you're not so sure. I mean, so if you guys could explain the process you're using, I think that would be helpful. Arun, go ahead. Let's start discussing two aspects, which are kind of hard discussion and within the same sheet, right? So it is mainly around the maintainers and the open source code or the governance aspects. And Danu nicely has put up those comments in here. So I mean, we need discussion and agreement on those topics. But so what process are you envisioning to come to resolution on all these points that you guys have added? Sure, I can share my perspective on those two requirements and probably other TSE members can also add in their points and then we'll see which one to follow. So my points on the open source aspect is it's fine for somebody to bring in a project, which was earlier not open sourced directly to Hyperledger and then propose it for incubation. However, the consideration then is, hey, you probably are following your own organization structure. So you're not familiar with the open source processes involved. The question is about how will the governance right over there? So if we try to address that in this open space, like somebody is bringing in their project from internal to directly under Hyperledger, my perspective on that is if a project is in production and somebody can demonstrate that that particular project is in production and is in use by somebody else in the public space, like there are some articles available, which says this project is already in use. So those kinds of backs up the argument for the project's maturity level. And in terms of other requirement, which is the governance aspect, what if one organization then is completely managing our maintainers right on that project. So they should probably come up with a roadmap to say, how will they introduce new maintainers? This can be a probably another requirement for them to propose the project to Hyperledger. We can ask them, hey, what is your plan for new contributors to gain the maintainership? And we don't generally ask this to all the project, but since you are now proposing to incubation, we are asking you specifically. So you should probably give a six months plan or one year plan for that. Now the other requirement which we can put over there could be if you don't want us to, I mean if you want us to trust and then trust on the open governance aspects, show us that it's this particular code base is already contributed by more than one organization or one individual who are independent. And the contribution from each of those should be a significance. I mean, it should be of significant level. It should not be that like do some line additions or do some file additions. It should be rather a significant code contribution. And as far as long as they can demonstrate these, it should be fine. And having said this, it's not that we are questioning them to demonstrate all the time, but if time requires, they should be able to demonstrate it. All right. Thank you, Aaron. And Tracy was gently reminding me on the TSE channel that I'm the one who asked for the names to be added to the, to these points I was asking about. It's amazing what one week of we'll do to you. I completely forgot that I was asking for this, but I think it helps actually. And especially if people start questioning, it's good to know who you can go to. So thank you for doing this. I will defend my idea that I had forgotten. And so what do you guys suggest we do? I mean, are there points you want to get into discussion now? Should we have, I think we probably need more time, but for everybody else to look into it and see if there's anything they feel like should be added, if there are points of contentions, I think they should be highlighted. And then we can discuss those on a future call so we can make a decision as a group. Tracy? Yeah. So under the overlap with existing projects, I think Dano asked a question, which I think is something that we could discuss here. In the hip template today, it talks about dependent project maintainers must sign off on the proposal before it's considered by the TSC. And Dano's question of what exactly do we mean when we say dependent project? I think it's an interesting question. I think that it's, I think the original intention there was probably more along the lines of the conversation that we tend to have if something is very similar to another project. But I don't know if that's really what was intended when this template was originally written because I wasn't part of those discussions. So if anybody kind of has history on dependent projects and what exactly that was intended to capture, that's probably a great discussion point to have. Oh, yeah. Thank you, Tracy Haught. Yeah, sure. So I can answer Tracy's question. The dependent project thing was basically to address things that if I want to build say a fabric rust SDK project, that I should probably have the fabric community's approval to do that. So now as we've sort of seen the rise of libraries, the rise of interrupt projects, like what counts as a dependent project is much more nebulous. And I think it's good that people brought that up because we should probably redefine this. For instance, like if an interrupt project wants to go for incubation, it might technically depend on all or most of the other projects in Hyperledger. Do we really need approval from every single other project if you're an interrupt project? So I think we should probably revise or clarify this rule. Yes, it sounds to me that this is legacy that probably needs to be dusted off. Daniel, go ahead. Based on that description, it sounds like what would previously have been a dependent project is something that would be more suitable for the sub project approach now. It's like you said, the rust SDK for fabric should go straight into fabric as a sub project and skip the proposal process. So I don't know that it's the same impact as it was. I agree with that. This is also the thought I got when you started talking about this is that I think this is historical and came from a different vision of what Hyperledger would be where there is more like a, like it says in the charter, there is one framework and there's a bunch of projects that kind of all a satellite to around that main framework. And now it's clearly no longer the case. So maybe we just need to update the template and get rid of this language. Any other opinions or thoughts on that? I'll go ahead. Yeah, I think I agree with all that and it probably makes sense just to scrap that. I mean, this will most likely come up in the process anyway. So. All right, Tracy. Yeah, I also agree with scrapping it. I do think there is something though that we probably want to talk about when it comes to the incubation entry around, you know, I like the first bullet point under this, right, that we have in the TSC mentioned that we're not really interested in bringing in additional distributed ledger projects, you know, unless there's some distinct advantage that exists for that to bring it in, right? And so I think there is still something that we might want to say about other sorts of categories of projects as well. I don't know what that something is, but it just feels like if I were to say bring in a second project that was basically identical to your first project, but was written in another language, would we say that's okay, right? Typically, or would we say, you know, why don't you go talk to the other project and see about how you might be able to interact with them, right? I think it really is very much similar to maybe this first bullet point, which is if there's already a project that does the exact same thing and it's just maybe a language sort of thing, right, then that might not be a good reason for us to want to accept that. So tell us some other good reasons that we might want to accept your project. I mean, obviously, each particular proposal is going to have to be looked at individually, right, and decided on, but I just feel like there's probably some sort of verbates that we want to put into this entry criteria around this topic. Oh, I totally agree with that. I mean, imagine somebody coming say, I want to do a new cryptographic library, would we create a new project for this? Maybe not, right? So I agree. Mark is next. Hello, Mark. How are you doing? I'm healing well. So a couple of points. One, I think it should be up to the TSC, not other projects in one sense competing projects to decide if the TSC considers something. And I'm fine with the TSC going off and saying, see if you can work with these, you know, these teams can work together and come back and tell us what's different. The other thing is from a practical point of view, something like Beisu, when it came in, how would it have done if this framework was in place? You know, so I'd be curious, and don't mean to put them on the spot, but to hear from Dano and Grace, you know, how would Beisu have fared with this in place when it came in? Because I know that was sort of a fight. Right. So I think for the first thing, the distinct advantage is it grants a type ledger direct access to Ethereum, Mainnet, and Enterprise Ethereum. Borough was not wire compatible. It was not Mainnet syncable. It did support all of the EVM codes, but it wasn't something that you could say used to access all the DeFi stuff and get there that some enterprises might want access to. So for the first point, the distinct advantage I think that we sold it on was it's Mainnet Ethereum. And I think that's the sort of distinct advantage that I think this clause is looking for, rather than saying, hey, it's a DLT written in Java, you know, it's like, well, that's, there's a lot of those go pick a different one, you know. So I think, I think that's one example there. As far as working with other projects, I don't know that we talk too much with Borough above board. Grace would have to talk more with that. She was more of the, more, one would go out and talk with people. As far as the other issues, let me go and give my own copy of this. We have multiple maintainers. The first, the first release we had, they were all from consensus, but pretty quickly we expanded it. Let me, my innovation policy. I'm code base was open source Apache to license the whole way. So I think it was, it was fine. Only the overlapping is projects. I think it's the only one that would have been the point of discussion. And there was about two weeks of discussion on this. So yeah, just echoing Dan, oh, it does look like if we were going back and this was the list that base who was judged against. Oh, sorry, I might have cut someone off by their good grace. Sorry. Just realized it did not raise my hand. But yeah, so it's a good idea. Yeah, I like the idea of looking at each of these and saying how base would fair looking at this. I don't think there anything going back to the Borough question. We did explore and talk to Thales at the time around, you know, what would be integration points? How could we work together more closely? And that was a conversation, but not a requirement, if that makes sense. So I think that's that's worth a clarification. But looking at this from a high level, I think base who would have passed if this was the list when it was through the process, but that's a sniff test more than anything. All right, thank you. Mark assumes that addresses your point. I think it's a good one. I mean, we should, you know, try to test drive this thing by looking back and see, you know, if it actually works. Yeah, it addresses my question and I was just using them because I know they were, you know, it seemed from my perspective, they had a difficult time coming in. And just, you know, it's one of the bigger projects that's come in recently. Yeah, it's absolutely. And I think there's there's the flip side of that is, you know, would that have helped them because part of the issue we're trying to address, right, is the fact that there is no, you know, definition of what what is being taken into account. And they had this sentiment of the moving goal post, which the firefly people also had. And so we're trying to put an end to this so that people who come with a proposal have a better expectation, you know, a better sense of what's expected. Grace. Just to answer your question, if this was here when Basu was going through the proposal, I do think it would have helped us just with the expectations and all that. So from my perspective, it would have helped. Yep. Well, thank you. I would hope so. I mean, we'll have to see how far we need to go. But I would hope that this is better than what we have to do, which is a big void based on, you know, the mushy memory of every member who has been around long enough to have a sense of what is expected. Daniel. As far as the kind of about moving goal post, I think the place we had the worst experience of moving goal post was going to active because some of the things were written one way and interpreted another. And then we had other TSE members come and say, Oh, by the way, you need to implement this standard as well, which was nowhere in the things. So if we're going to do the written things in the idea of not moving the goal post, then we need to stick to it and stick to the written standards rather than bringing up new ones when a project comes to request for incubation or active. Yes. No, I think that's that's a fair point. Obviously, once we have a definition, we need to live by it. And then if there's a need to change it, we should do that. And but probably not when we are in the process of, you know, evaluating a proposal, whichever level it's at, right? It's kind of like the laws, usually when they issue new laws, they are not retroactive. You just say, well, you know, the new cases that fall into this, they will, they will have to live by that law, but you don't say, Hey, I'm processing this case now. And we just came up with a new law. So now you have to, you know, the framework has changed. Yeah, but the change of tax laws halfway through the year and put them in effective money. Yeah. So I think we can do better anyway, we can improve on this. And that would be welcomed by everyone, I'm sure. All right, we're nearing the end of our call. Is there anything else anybody wants to bring up now? Otherwise, what I would ask is, as I was saying earlier, I would like people to, you know, pay attention. Obviously, there are some people who already contributed quite extensively to this, but everybody should have at least a look at it. And, and, you know, see if there's anything they think about they should be added, or if they have an issue with what's written there to flag those. So we can discuss these things on the future calls. And then at some point, I think we'll have to kind of freeze it and say, okay, this is it and have a kind of vote up or down as to whether we agree on what's been captured. I mean, there's no urgency, we can, you know, take a week or two to finalize this for sure. But people need to engage. And I know it's summer and people are taking time off here and there. But hopefully, we can still get through this. All right. So with that done, I think we can close the call on this. I will thank you, everyone, for joining. And we'll talk again next week.