 All right, thank you, Ray. Hello, everyone. This is Arnaud. Welcome to the TSE weekly call. This is open to everyone who is interested and willing to participate. There is two requirements to doing so, though. The first one is to be aware and lead by the antitrust policy, the notice of which is currently displayed on the Zoom client if you're online, which I think everybody is. The other piece is the code of contact, which I think most people know and basically requires everybody behaves decently. With that taken care of, we can move on. We have a fairly light agenda, but I thought it would be useful to still be worth it having a call because we started a conversation, which I think is a good one last week, and I wanted to keep the discussion going. There are three quarterly reports that are overdue now. I do want to point out that some were posted last week and not fully reviewed by all our members. So please, if you haven't done your homework, go back and look at those reports. They are linked from last week's agenda, and hopefully, we'll get those that are overdue now pretty soon. Is there any announcements anyone wants to make? Yes, I'd like to real quick, Arnaud, about the election. I just want to thank everybody who volunteered to help with the transparency of dealing with issues of eligibility for the election. I've gotten a lot of good feedback and help. We're currently now in the process of updating the eligibility lists. I've been running the scripts pretty much every other day for the last couple of days, although I realize I've been making a mistake and not limiting it to the last year. So if you've been using the eligibility site, there is a very, very, very small chance that you might come back as eligible, but you may not be eligible because you haven't contributed in last year. I just want to be transparent about that. I'll be fixing that today. So if you have checked in the last couple of days, I encourage you to check tomorrow one last time. So just to be certain that you are or are not eligible. And again, if there's any questions you may have about eligibility, email election at lists.hyperlogy.org. And that's it. Short and sweet. So when you were running the scripts, the range was not set correctly initially? That's correct. The default for the range is not the previous year, it's for all time. Thank you, Tracy, for catching that. I totally forgot about the range specification for the tool. So I will be running it today with the cutoff date being the first of August 2019. So any contributions from the first of August 2019 until today will count towards eligibility. And the tool will be updated sometime today. All right. Thank you. Thank you. Thanks, Tracy, for catching this. Anything else, anyone? All right. If not, we can move on and get into this discussion. So let me try to restate what this discussion is about. It came up as initially as part of the comments against the Transact Report, but I don't think that matters in and of itself. I think it raises an interesting question, which essentially comes down to the fact that we have a policy that basically says when a project is being proposed, if it is seen as strongly tied to an existing project, typically a framework, we have agreed that rather than get another top-level project, we would direct the submitter to talk to the maintainers of the project it relates to. And this can become somewhat what we loosely call a sub-project of that project. And we've seen quite a few of those for fabric, especially over the years. Now, the situation is there are cases where we may have a project proposal that claims to or that aims to be platform-independent and therefore doesn't fall under that policy I just talked about. And so it's approved, it becomes a top-level projects. And then the feature that was key to the decision just never pans out for whatever reason. And this is not about criticism or what, it's about the fact that sometimes it doesn't happen and a project maybe it originated from a specific project and never really was able to cut ties, or there was just not enough volunteers to work on to support it on other frameworks. We've seen this for Composer, for instance, is a good example of that. The Composer team was willing to make it non-fabric specific and we had repeatedly requests about when they would support other projects but the Composer, the original authors didn't care to support other projects, didn't have the resources to put in this and nobody else came to do the work either. And we are in an open-source environment where it's all volunteer base and so it can't force people to support different frameworks. You have to get people who are interested in doing the work to do it. So the question then is if that were to happen, what do we do? It might be, I think it is reasonable to say, well, after a certain period of time, and this would have to be defined, it might make sense to say, okay, for whatever reason, it didn't happen, we should revisit the question of whether this should remain a top-level project or if it should become a sub-project of whatever other project it depends on. So that's really the crux of the question at hand. Ideally, I think it would make sense to have some kind of policy that we said that says, these are the criteria and there's a certain period of time that is predefined and after which we can look and say, okay, it's been that long, this project is only tied to this one other project, we should just acknowledge that fact and move it as a sub-project. Now, it has been pointed out, I think, rightfully that we cannot take into account only hyperledger projects in this regard because they may be projects that are only used by one other project or none, for that matter, within the hyperledger community, but they may have different uses outside of hyperledger. And I think Aries is one such cases where there's actually quite a bit of use outside of hyperledger with other projects than Indy. Same with Ursa. And Ursa, okay, that's another example. And Daniel pointed out that in the case of Bezu, there may be technologies that would fall into that that are related to Ethereum where there's different softwares out there that could actually share some components. And if we wanted to have that, we wouldn't want to say, well, it's only tied to Bezu. So Bezu is the only one who uses it in hyperledger. And that would be disregarding the fact that it's used outside as well. So I think these kind of aspects need to take into account. But I think we could draft a policy that would make sense and that could work and would allow us to manage our projects more effectively. So that's the basis of this discussion. Now, we didn't really have time to discuss it last week because it came up just like maybe five minutes before the end. So we definitely didn't hear from many people. I would like to open it to everybody now and get reactions, comments. What is, how do you feel about this? Could I ask people who want to comment to please like raise their hand and use the raise their hand function so that we can have an orderly thing? And I see that Nathan was the first to get his hand up. Nathan? Yeah. So one of the reasons we have a TSC is so that we can have discussions and make exceptions where it's needed. So I really liked the idea of having a policy that sets this kind of the standard for how we fold something back into a framework. I think that having more aggressive cleanup on some of our project lists would help focus the development in the community and help people understand a little bit better where to go to get help and also help us coordinate things like releases, especially on some of these projects that just they're so tied to a particular dependent through a library or a framework that trying to manage them outside of that is actually more difficult than just letting fold into one of the the main work streams of a different project. So I really like this idea of saying, you know, you can propose to be your own independent project. We're willing to give it a try. But if it doesn't work out, this is what we do. So I liked the proposal that Arno is talking about here. If it doesn't work out after 12 months, we really should probably fold you back into the other project just because it will be easier for you and your developers to keep track of what's going on. All right. Thank you, Nathan. Mark. I think Mark was next. Mark, you're on mute. Yes, I know. Sorry, I was trying to find the button. No, my thing wasn't indicating that my hand was up. So I wasn't sure. Okay. I think part of this is we don't really have a structure to handle stuff like this. And maybe we need to look at the overall structure, right? We have top level projects. That's sort of it. You know, otherwise you just get sort of shoved under different projects because you're closely related to it. So I'm wondering if we need to look at maybe different classes of projects. You know, what happens if something gets put under fabric and fabric doesn't really want it? But it sort of, you know, decides it's under fabric or under sawtooth. And, you know, how is that top level project responsible for managing this orphan that they may not want? Does that make any sense? Yeah. Okay. I mean, I'm, you know, we've talked about a lot before, right, about different structure. And I wouldn't want to reopen that issue because of what we're talking about, to be honest. But I hear you. I mean, you know, we went through this before quite a bit. And in the end, we decided now, you know, we basically have top level projects. And then whatever happens within each project is their own business. And so from a TSC point of view, it's one project. But I hear you, we'll see what other people think. I think Brian was next. Yeah, you know, I think, I think part of this ongoing conversation as well has always been what's the cost of a high level project in terms of management time, in terms of TSC time, in terms of, you know, call it marketing, you know, you don't want the greenhouse to be 100 projects. You want it to be a well curated set of them. And I think it's, even though I don't think transact is really costing us a lot on most of these functions, I think it's still worth asking, you know, is it really a part of the sawtooth project? Right. And, and I think the thing to look at isn't so much dependency as correlation, correlation between the development teams. You know, that if the two teams are pretty much the same team, if their releases tend to be synchronized, and all that stuff, then then it's probably, you know, useful to combine them. I'd contrast this with Explorer, for example, which is a very different team from hyperledger fabric, which, and I know we've tried to get support for other ledgers on Explorer, I think that path is still there. But I know the Explorer team is certainly open to it. All right. And I so so that correlation and and synchrony between teams, we one of my primary criteria. The other is, and this is a very subjective thing, so it's hard to know if we're being fair about it or not, but is some measurement of good faith, right? You know, if the project has a good faith intent of living up to that objective of being a multi ledger transaction processing system. And, you know, one way you can tell is how do they reach out to the other ledgers, do they incorporate input from those ledgers as they're doing the architecture decisions. And even if it didn't happen the first time, there's always subsequent times for that to happen, right? And so I think a valid question back to the transact community might be, are you planning a next gen architecture, a 2.0 architecture? And even if that's far off, now might be the time to go to fabric and Iroha and Indian borough and and say, you know, how do we, you know, try to incorporate more of you into the next architecture cycle? And I think it should be easy to measure the true faith, the good faith of the 10 of the developers once that question is posed. All right. Thank you, Brian. And I will add to the cost aspect, the mentioning at the beginning that there's also, you know, the cost to the users. And I think, you know, it was referred to earlier on as well is that, you know, I often hear people tell me what's going on with hyper leisure. There's so many projects and they don't know where to, you know, where to go and how to find their way through all the different projects. So from that point of view alone, fewer projects will make things easier. If there is a product that really depends on another one, it just makes it easier if it's part of that project and people don't, you know, not facing more project than they really need to know. So back to the list, Dan is next. Hey, so I think on that last point with TransX specifically, that community has always said, hey, we're not trying to recruit end users. So there shouldn't be a point of confusion on that. Or there wouldn't necessarily be a point of confusion on that. So the issue of guiding perspective users or developers through our portfolio is I think a little bit orthogonal to this one. We should have the people who introduce others to the community should have ways to guide people through. I don't think that we would necessarily want to limit the number of projects that we have just for that reason. But coming back more squarely to the main issue, for me this looks like other attributes of a project's charter is a project substantially fulfilling that charter. And right now our main mechanism is if it's not, that would be one of the criteria that says, all right, well, you're not ready for active because you're not really fulfilling your criteria. And so I would just try to keep that as the consistent approach that we have. I think it would be very artificial for us to restructure projects. We said that we decided on that back when we did read the life cycle, that we were never going to move a project backwards in the life cycle. And doing something like that here would be analogous to changing that policy. I also think that we have revisited this topic a few times in the past. And I think one of the inefficiencies for the TSC is revisiting things that will always be gray areas because we don't have a lot of other topics in front of us to address. And so we can also just consider meeting less frequently rather than continuing to spend time on things that will always be gray areas. And that's my piece. Okay, I really don't think we are discussing this because we had nothing else and I came up with this, but Chris is next. It's been so long, I forgot what I wanted to say. On the point that I think you were making about whether or not a set of maintainers would actually want to pick up and take on responsibility for some project, if you will. Again, I don't know what I'm going to call these things, but I think that's key. There's something to be said for, well, but who's really the maintainer? Is there just fabric maintainers or are there fabric explorer maintainers? Again, I think it's fairly flexible as to how different parts of a project want to be managed. Especially in the context of the blockchain space, there's distributed computing, there's crypto, there's so many, there's front end, there's back end, there's all kinds of crazy stuff that make up a project and a landscape. And so in that regard, I'm less concerned about whether or not there's a project that isn't living up to its well, it wanted to be independent and have applicability to multiple things. Because again, and we talked about this in the past, we had the example of Composer. And Composer I think had the right mindset going in that they're happy to have multiple back ends, but that didn't mean that they were going to build them. That really meant that if somebody's really interested in having a Composer front end, they need to build the plug-in that lets that happen. And it didn't happen. And I think that's sort of the same thing with like Explorer. I think there's interest on the part of the Explorer engineers, primarily DTCC and Fujitsu, if I'm not mistaken, to have that integrated with fabric, but whether it does sawtooth or whatever, given that sawtooth had its own dashboard. Again, it's one of those things, I think they had the right mindset going in that doesn't mean we change anything. We don't take them out of active or don't prevent them from going into active status. Maybe they changed their charter or something like that. I don't know. But at the end of the day, I think it's more important that a project be showing some signs of life than anything else about whether it's associated with this or that or the other. All right. Thank you, Chris. Dave? Yeah. So I apologize that the conversation has drifted away from this. Brian mentioned about cost. Obviously, top-level projects are the only ones that can trigger security audits and promoted releases. So if something that started out as a top-level project, say like URSA, and then it doesn't meet the criteria of being cross-platform or whatever, and it starts to be moved, let's say, back under Indies and Aries because nobody else is using it, that may affect something, right? Because URSA definitely wants to be audited at some point. And if it gets put back on as a sub-project, the maintainers of that project would kind of basically lose the ability to trigger that. Or I guess it would be part of the bigger project. I don't know. I just wanted to point out that there are some costs associated with top-level projects that are significant and should be considered when we're going to change status like this. Yeah, but so that's the reason to want to revisit this status, right? The status... That's correct. Yeah, that's correct. Yeah. Okay. And then you said URSA in this case is used elsewhere. So and again, one thing I want to clarify actually on this is, you know, I don't expect any of this to be automatically done. It would obviously be discussed by the TSE and we would have to make a decision. And there may be plenty of reason we say, yeah, for this and this reason, somebody suggested we should fold this project into another one, but there is all these other reasons we shouldn't. And there may just be one, but everybody is like, yeah, you're right. And so I want to reassure everybody it's not like this is, you know, something that happens automatically and there's nothing we can do. Everything gets discussed and we have to agree, you know, as a whole, as a group, this is the right thing to do. So Tracy is next. Yeah, so I'm wondering if this discussion is being caused for another reason, right? Like the root cause of our problem here isn't necessarily the fact that we want to combine projects or that sort of thing. It feels like there's the reason for these discussions are surrounded by two things that maybe we haven't solved for. One being the multitude of projects that's causing confusion for people as they come into the community. And then the second is whether that activity is really occurring in these projects, right? So should some of these projects actually be closed because there's no activity happening, which obviously I think is a very tough discussion that probably nobody wants to have because nobody wants to make that difficult decision of, you know, Project X has to go away because there hasn't been any work on it in the last six months or whatever the case may be, right? And so, you know, I think we've tried to do things around both of these issues and maybe we haven't solved it yet, right? I know these project reports were intended to figure out what was happening in the projects, right? Whether things were actually going on. We do see a lot of these reports coming in late, be that because we're not notifying them on time or because there's not actually work happening or somebody who's dedicated to this project anymore. And, you know, we've also tried to, you know, separate out into multiple areas, the greenhouse, right, of the different sorts of projects that exist in an attempt to make it clear as to what you might want to look at as you come into the community. So I'm just wondering if it feels like we come around to this conversation of projects, sub-projects, we actually introduce labs, right, as a another sort of level. Is it that we're not solving what the real problem is and that's why we continue to have these discussions? That's it. All right, thank you. Nathan. I like Tracy's thinking here around what are the tools that help us make the best decision. In part, this is where I've struggled a lot with some of the projects that are very fabric-specific. Not because they're not good projects. I think they're great projects. But as a TSC, I think we have fewer tools to deal with them effectively than the fabric maintainers do. You know, I have a hard time evaluating whether they're doing a good job of peeping up with the current stable release, for example, in terms of API compatibility with fabric. Whereas I think internally within the fabric maintainer community, that would be quite obvious. And so having those managed as a sub-project, I think helps keep them active and alive. And I think we would detect things like maintainership problems or maintenance problems faster if they were managed as sub-projects. So I mean, for me, the question here is what is going to give us the best tools for these projects to be able to stay relevant and stay useful in addition to the marketing benefits and the other things that come. To address Dave's point, we have a lot of sub-components, especially in the Aries project. So things like asking or triggering major releases or security audits get more difficult when you're doing sub-projects. But I also think that there's no reason we can't trigger security audits or trigger marketing releases and those sorts of things for sub-components by staying up to date on what's going on as maintainers inside of whatever the main framework project or the main master project, if you will, might be. So I think practically speaking, this gets to what makes this easier for us to get stuff done and collaborate. All right. Thank you, Nathan. Brian, go ahead. Yeah. And in general, I do want to try to avoid myself or other hyperlagers to have wing and on conversations, really a TSC one. But I think there might be a point that some folks might not be comfortable talking about. So maybe I can be helpful with that, which is I think there was a good faith effort on the part of certain fabric maintainers to engage with the transact maintainers to try to see if there is a way to combine efforts. And part of it is that architecturally fabric and sawtooth, which is what Transact has really been built for and derived from, are very different architecturally. But despite some good conversations at the face-to-face meeting in Minnesota around, yeah, let's work on this. I think there was a sense amongst some of those folks who engaged from the fabric side that they were kind of rebuffed or not taken seriously. And I think that's why I think there is some question of good faith here, right? Is there a good faith intent to live up to the commitments that were a part of the approval of Transact as a project in the first place? Which I think we went more out on a ledge to take intent into factor in the project approval than we normally would. And so I think that's, I mean, I know people are underlining motives or that sort of thing, but I don't think it's that very down deep. I think it really is that sense that if a project's approval was based on a promise or something, and that something is very subjective, how does the TSC come back to if that wasn't, you know, lived up to, right? As a measure of faith, not necessarily as a measure of outcome. Like it could be that good faith was there and present and still, you know, Transact was a single ledger kind of technology, even though the intent was to be multi-ledger or other people didn't show up. But I do think in this case some people did attempt to show up and were rebuffed. And I think that is an argument or a premise by which a project could be encouraged to recombine, you know, with some of the projects it was derived from or based on. I don't think that that's an accurate characterization. That's why I said I know some people would be uncomfortable saying it, because, you know, they know it would trigger claims in their response. And I, you know, you can't help how someone feels, right? The impression they're left with when they walk away. And it is subjective and it is going, that's the harder part of managing a community is making the subjective calls, for sure. But so I think, you know, with that talking about maybe the emotional part of how people feel about these things or not, I think just from a technical point of view, I think the fabric team felt that Transact was a much bigger piece than what was expected initially from it. And it meant, I mean, incorporating it fabric would have meant tearing apart a lot more out of fabric, which made the whole exercise a lot harder and more, you know, more non-obvious. So I think for that reason alone, it was felt that, well, doesn't make sense for us to do that. And so it kind of stopped the, you know, it killed the interest that was initially in it. And maybe there's something else that needs to be taken from this, which is, you know, for these kind of projects to really have a chance, I think, they would need to be driven by more collaborative effort from the get go, so that, you know, you would know where to draw the line where it's actually will work for different projects. In this case, we have a team from the sort of group that says, hey, we're going to extract our smart contract engine, generalize it. But, you know, they draw the line where they felt makes sense. It didn't make sense for the fabric team. So maybe there's a lesson in that somewhere. But I think we think that's a much more accurate characterization. There was collaboration up front and putting the project proposal together. And when teams got face to face at the maintainers summit last fall, and they started digging the next layer deeper, it was clear that it was becoming more expensive on the fabric side. So I don't think there was any rebuffing. There was different prioritization happening within the fabric community from when we launched that project. And there was a different recognition of the level of effort. I don't think there was anything about lack of genuine intent on anybody's behalf. And I think that's fine. We can leave it at this. And I want to, I don't want us to drill too deep into the specific transact issue. And because what I said earlier, right, when I was talking about having a policy, along with what I was talking about, I said, there may be many different reasons why things don't pan out the way they were planned. And so I, you know, but faith may be one, Brian. I don't know that there's, you know, I wouldn't easily want to point that out onto any of the situations, you know, put that into any of the situations we have faced so far. It doesn't really matter to me at the end of the day. And this is why I think it only makes sense if we can come up with some kind of policy where we have fairly, you know, objective criteria we can use, just like we have for, you know, the life cycle for moving from incubation to active status and so on. So I think if we have to rely on this kind of more subjective matter, it's going to be very hard to implement and this and maybe not so, this may not be so useful. So there are a few people we haven't heard of, heard from Gary, for instance. Is Gary there? I don't see him anymore. Is he dropped off? And, you know, I'm also interested in people that, you know, Dano has experience in the Ethereum community. I know he's not a TSC member, but. Sure. I mean, I don't mean not to hear from anyone. I mean, if other people have comments, please speak up. So I'll speak up here. So we seem to have this sub-project discussion about once every six months since the beginning of the TSC. And I guess I'm just curious at this point. So this would be a change from what we have sort of thought as a TSC collectively over the past. And I guess I'm just curious what has made people change their minds or think we want to move in a different direction. And I think if we can point this, then maybe we can sort of figure out the best action to take. So you need to clarify a little bit what you're saying, Hod, because I don't know why you think it's so different from what we've. And again, I mean, what we've talked about when it comes to top projects, sub-projects, was to have some kind of formal, officially recognized hierarchy of projects, which is not what's being discussed today. Okay. What's being discussed is whether top-level projects can be rescinded and under which condition they would be moved into an existing, another project, basically. And how it's structured internally in that project is irrelevant to this discussion, in my opinion. Sure, yeah, I understand. So Nathan, go ahead. When we look at the Hyperledger website, we have distributed ledgers, domain-specific libraries and tools underneath used. And you know, when we go into each of them, there's a whole bunch of things there that from an outsider's perspective look like they're whole different projects that are unique or very different from one another. I think we've been very hesitant to make a strong decision or a strong stand about projects like Explorer or, you know, Composer was one that was like this before. And I think, you know, Composer's a good example of a project that drove a lot of user adoption. And I think having it as its own standalone loan project during the time when it was doing quite well, I think was a very positive thing for our community. And then we have projects like Explorer that, you know, I know that there's active maintainers there. They have had some struggles recruiting and some struggles trying to figure out how it evolved as fabric has evolved, where I don't know if it's really a standalone project or not. And being not as active inside of the fabric community, it's hard for me to make that call. And I'm looking for a way for us to have a clear set of questions that we can ask, whether it's part of the project reports, or part of, you know, our review of this portfolio to say, this is where this belongs to help clarify how this works. Because, you know, we've looked at things like Caliper and Explorer from a Hyperledger Indie standpoint, and their requirements are very different than what we need. And there's no reason for us to kind of prosecute or persecute those projects because of that. But, you know, at the same time, if we folded some of those things inside of whatever framework is the one that's the majority use case for them, it does clarify things for people who come to the project looking for, you know, Indian Aries things, if there's not, you know, 30 things to churn through, if the taxonomy or the hierarchy is more clear about when and where a tool is applicable. And so I'm looking for a question we can maybe add to the project report or a question we can ask to say, is this thing really part of one of the frameworks? Or is this thing its own standalone thing? Because I mean, clearly something like Ursa is a library that's kind of a standalone thing. Anyone can pick it up and use it. And then also something like Composer, I think it would be a good thing for us to promote things like Composer to be their own projects. So are there three or four questions we can ask that help us have that conversation? It doesn't matter to me if the conversation is clear cut. It matters to me that there's a template that we can follow to make sure the questions are asked in a way that's fair. Yeah, thank you, Nathan. And I'll follow up on that by saying, you know, for that matter, I really feel like we've given Explorer plenty of time to support different frameworks that just don't. At the same time, you have things like Sotuth, they have their own Explorer that are part of Sotuth. So it's like, well, if I'm a user, I go there, I say, oh, Hyperledger Explorer, here is the tool I need. And oh, it doesn't work for Sotuth. Oh, but Sotuth is its own Explorer. And why are we doing this? If Explorer really supports fabric and any fabric might as well be part of fabric. And then each project is its own Explorer. And that's fine. There's nothing wrong with this. So I do, I also, I guess Nathan and I both see the value in simplifying the number of project that we're presenting people. And I heard Dan didn't feel like this was, you know, worth driving any kind of reward. I disagree with this. I suppose the website could be designed differently to make that more easy to navigate. But I don't know why our organization wouldn't represent this. Who haven't we heard from? Anybody else wants to chime in? Can you hear me, Arno? Yes, Mark, go ahead. I sort of agree with the last few points made. But, you know, instead of using it to look backwards, let's use it to look forwards. What happens when we get more Ethereum type projects coming in? Do we decide if they go under Basu or if they're standalone? How do we move forward with things coming in? You know, what are the questions we should ask? Things of that nature. And then maybe if we figure that out, we can turn it around and apply it to things that we already have and see if they fit, right? Yes. I think the key there is dependency, right? Is there a dependency or not? Right. I mean, if someone comes in and says I want to build this widget and it will work with anything as long, you know, we're going to design it to work with fabric and but it shouldn't really work with anything as long as the other projects write their own their own plug-in for it. You know, is that a good or a bad thing? How does Caliper do it? You know, Caliper seems to be a cross-project thing that works well. You know, so what are they that's working? Well, I mean, they ask people were motivated to actually support different frameworks. So they actually do the work. And again, this is not about blaming anyone not to do this for their projects. It's just, you know, acknowledging that that's the case. In some cases, you have a community that says, yeah, I want to support all these different frameworks. And it makes complete sense not to have them be tied to a specific project. On the other hand, if it just is, then why not acknowledging it? So I think that's really the key point in my opinion. If I might answer something that was asked a little bit earlier, there were several times where we did try to have some sort of simplification to the website so that people could make decisions, people outside the project can make decisions about which project was interesting or useful to them. And that never turned out well. Because, you know, all blockchains are good for everything. So trying to even provide a list of discriminators has turned into a very difficult discussion in the past. And I'm certainly willing to watch you guys revisit it, because I think it would be valuable to the community to be able to discriminate more carefully. But I think if we're going to talk about re-orging the website and all that, that is just, I think that is just a symptom. I don't think that's really, you know, the problem. Okay. All right. Thank you for that input. So if there's not any other comments, what I would like to do is have a straw poll. This is not a vote, right? It's just, to me, what matters now is to know whether we should keep pushing into developing a policy that would address the question at hand or not, right? I don't want to spend more time discussing it if, at the end of the day, majority of people are saying, now when I'm going to do this anyway. I, personally, I'm willing to put the effort into drafting a policy that we could try to hash out and see if it actually can stick. But I don't want to do it if, you know, there isn't enough support to make it worthwhile. So could I have a show of hands for the, whether this is worth pursuing or not? I don't know how we do this. There is a, everyone does have a thumbs up, thumbs down, yes, no. Yeah, let's make use of that Zoom meetings thing. Yeah. Yeah, there is yes and no. Should we continue? Click yes or no? Continue or nothing. I'm sorry? Continue what? The discussion or trying to figure if, I mean, are we talking specifically trans acts, which sponsor? No, no, I'm not talking specifically trans act. Again, I've been trying to stay away, even though trans act triggered this discussion, I'm trying to see if we can have a policy that would be applicable. And then it would be natural probably to have trans act looked at it from that angle. But that's, that's a, that's a separate step in my mind. We're talking about whether we should have a policy that will address the issue we've been discussing. And, and, and, you know, again, I'm not talking about approving a policy because we don't have a policy to look at yet. It's whether we should spend more time discussing this, meaning I would draft a policy, we could discuss it, comment it and not, and whatnot towards eventually a vote yes or no. But if right now, there's a matter of people saying we shouldn't do this, then I don't want to spend more time. So that's what I'm trying to gather. So one thing that sort of hasn't been really brought up is we haven't really talked about, we haven't talked to the maintainers of some of the projects we're talking about, like maybe why they want a separate project or why they maybe they don't care. But I mean, it would be useful to have their input in any kind of discussion like this. That's a good point. So that's something we should probably do if we continue this discussion is, you know, bring in some maintainers asking them, you know, what's their view on this. And again, I mean, you know, if, if these were ever to come, we would definitely include the maintainers of the project that we would be considered to, you know, to reorganize based on that, on that policy anyway, right, we couldn't possibly do that with that their input. So that a lot of people have not voted either way. Tracy Troy, Nathan Hart. Yeah, Angelo. Yeah, I don't know how to vote. I don't know. Not right. You know, I think, I think there does need to be cleanup, but at the same time, like, I just don't know where this is going to go. And so it feels like until I know what this is going to look like, it's hard to say, yes, we should go forward. Yeah, but so let's me put another way. If we have more people voting no now, we stop discussing this issue, move on. If you want to, if you think this is worth investing in, investing more for the TST time in it, then you should vote yes. That's all I'm asking at this point. Yeah, I still don't know. Okay, sorry, I try to speak for you. That's all right. I mean, that's what I'm at. So I wish it was like a maybe, right? Maybe so. I know I was looking, is there an option for like abstain, but there is that, I guess you could put the away or I'm taking a break, need a break. Oh, that's what it is. This is coffee cup. There we go. Should we consider the possibility that they're just not enough data to really get a formal policy? I mean, we have one instance with Transact, which is a very specific case. Are we making a generalized policy too early? Well, this is an interesting point. I agree. I mean, we would have to kind of, you know, try to test it out at least mentally. You know, does that make sense? What does that buy us? I would come back with a rebuttal though. No, we've had this problem since almost the beginning of Hyperledger. And I think we just, we have been willing to make a stand on it more so than, because I think clearly we have this problem where there are things that are not standalone projects, we've labeled as standalone projects. Okay. All right. So I agree. I mean, I do think we, you know, it is easier to agree on approving things than rejecting things or kind of, you know, rescinding things in any specific way that can be seen as negative. And unfortunately, I think at some point, you know, we need to step up to that and then say, okay, you know, it may not be so nice to do, but this is what we have to do here. And so I think we have, I mean, some of us have been around for, since the beginning, have seen this and know that we are going to have to get there. And, you know, it was discussed earlier that there may be other cases where we have to just say, you know what, you just don't leave to the expectation. And, you know, we should shut down your project, whatever that, you know, the exact way we do this is. So, all right. But so thank you all for your input. I see, you know, there's the majority of people in favor of continuing this. So we will do so. I don't know that we necessarily need to have more call time on this for now. But I am interested in trying to write down a policy that I think would make sense and to put it before you guys to look at and comment and trash out if this might be, I'm not offended. And so then we can see how that goes. And if it makes sense, you know, have more discussion at some point down the line. Okay. I think that's about it. I'm glad we had this discussion. Thank you all for participating. Is there anything else anyone wants to bring up now or we can close on this? All right. Hearing none, I will take this as a sign that we can close. So I will call the meeting adjourned.