 All right. Thank you. Hello, everyone. This is the weekly TSC call. I think I only see familiar names, so you're all aware of the antitrust policy. We also have the cutoff conduct. You'll know all those things and love them and defend them, right, help hold them, all the good stuff so we can stay out of trouble. Thank you. All right, let's get going. So, a few announcements. First, a reminder. Once more, there is the hyperledger developer newsletter going out each Friday. It's an opportunity for everyone to highlight what's going on in the project, working groups, things or whatever. Do you want to say something about this, right? Nothing beyond we are, we would love to have more participation. I see that Helen has unmuted Helen. I was just going to say that, yeah, it gets a pretty decent open rate. So folks that might think, oh, you know, it's, you know, what's what, I don't know, it might not see the value in it. It actually gets quite a lot of eyeballs. So if you're looking to expand your, your project looking to, you know, get the word out on something you might need participation, what have you. Go ahead and drop your notes in that wiki page for the developer newsletter and I'll incorporate them in contact if you have any questions but again it's actually a pretty decent tool to get, get the word out. And, you know, breaking down silos and barriers between projects, it's, it's, it's fairly effective in getting some eyeballs on it so absolutely, I would absolutely have more contributions and announcements I go out searching and use kind of my news judgment on what I think is kind of, you know, the things that are percolating to the top each week but would absolutely love some guidance from the different projects to include the announcements, the worthwhile announcements for that publication. Yeah, I feel for you because I've been in charge of editing a newsletter like this, and it's pretty gruesome. The clock keeps ticking no matter what and you're struggling getting content and all. So I, I can totally relate to the pain. And one more thing though is, you know, again on the call about the Sega feedback and that Tracy shared when I wasn't there, you know, there was quite a bit of talk about how the newsletter could be used as a vehicle to fill in the gaps and you try to bridge the different parts of the community. I mean, all those sound all of that sounded really good. But if we don't actually act on it, it doesn't work right so where we seem to have put a lot of hope in being able to use the newsletter to, you know, solve some of the issues we are facing. But we have to actually make use of it. Otherwise, you know, it's all words and nothing really improves. With that said, we have a reminder also for call for maintainers. Right. Sure, that that call will follow this call. And I plan on giving a fairly high level overview on where insights is and how insights can help maintainers, you know, better understand their project. So, please. I'll be there. And finally, the global forum, who wants to talk about this. I think that's going to be Daniela or David. I think we covered this last week, just a reminder should have gotten an email from Karen about looking for volunteers for doing the project. Overviews and ask me anything. If you didn't, and you would like to do one, please do reach out to anybody on staff and we'll work with you on that. Once again, it's 15 minutes. The goal is a five minute overview of your project with a 10 minute Q&A. And we'll do that too. I don't think I got it. So I'm a bit curious. I'm not sure who sent the fabric is carried on. I will take that off. It was Dave. Yeah, that's Dave. I got it. So one question there. Is it an overview like for beginners or is it like an update since last year or so. An update would be great. Okay. So Dave, Dave, that's mostly, you know, the people that will come to those kind of sessions where people that would be looking for updates, new information and ability to talk to you all. All right. Any other announcements anybody wants to make. If not, then we can move on and go on to the courted reports. So we did get the report from the quilt project. So it was kind of long overdue. And it raises some important questions. I mean, basically when you have one person working on it. And he's saying don't expect any, you know, activities for the foreseeable future. And it does raise a question as to what we should do about this. So I actually put that on the agenda. You may have seen further down as a discussion point. Is there anything else beyond that anybody wants to bring up on this. Okay, I take that as a no. So that's cool. Let's leave it at this for now then and move on. We also had a report from the fabric project that was actually made available last week already. I didn't see any comments that require discussion there was a question Dave asked about the state of the repo linter implementation. We're still in the works. We still don't have a final answer as to will, what should really be done. What it comes down to on that front is, you know, some of us have been working on the common repository repo linter configuration file, and people expected to make. I'll start with it and, and suggest changes. I just merged one from Troy, as a matter of fact. So, there's still work underway and by the way there is another PR from me on that. I would appreciate if somebody could review it. Anyway, on the fabric front. Is there any questions. Don't see anybody raising their hand so I'll take that as a no. And we can therefore move ahead. And we also just received. I think it was yesterday report for from so to it didn't raise any questions to me. I didn't see any comments earlier when I looked. So I don't know if there's any anybody like this project is cruising and there's no issue. Okay, let's still see nobody raising their hand so I'll take that as a yes. I mean, I realize some people may not have a chance to look at it carefully. And I will put it back up the agenda next week so you'll still have a chance to raise issues if you have any or ask questions. In the meantime, the period on the wiki page is the most effective way. We're still missing a report from the explorer team, starting to wonder what's going on there but so if there's anybody in contact with the explorer team close to them, they can talk to them. That would be interesting to ping them and say hey, what are you guys up to your report is longer redo. So, let's get back to the let's get Tracy please. Yeah, I just wanted to mention on the explorer front I did see come through the get a release. I think it was yesterday sometime this week, version one dot one dot five which was some sort of bug fix for explorer so I think there's still things going on there I just think we need to figure out who the right people are to contact for getting a report. It concerns me that you know, despite all the, the reminder I sent on the TSC list. There's no reaction which tells me there's nobody from the explorer team paying attention to the TSC list as a as a project I would expect people to be at least connected with the TSC enough to be aware of those things and, you know, but yeah. Thanks for the piece of info Tracy. All right, so, again, let's go. Let's move on to the discussion. As I started stated earlier, there's a question about the quilt project. So basically, we're in a situation where the project itself. I mean, there's, you know, this project has always been. You know, that minimal in the sense that there's one person working on it and it went through different phases they were times when it seemed to be going dead completely. And then, you know, we had one person step up and say no I'm actually interested I'm going to work on this so it was like okay this is good. I don't know if anyone has to attract anybody else. So we still only have basically one maintainer, David fueling and then so he himself says I don't know what should be done about the, the status of this project. So, I honestly don't know either. I know that, you know, I've chat with Ryan it was saying, should this be moved to a lab. And the thing is, in the past, we have actually talked about, you know, the possibility of rescinding project from one state to another and we said no we'll never do that project can stay indefinitely in incubation. That's okay. So, I mean, you know, just saying, we can just say yeah let's put, let's move that to a lap, because it's would be at odd with what we've decided before. It doesn't mean we can't do it. It just means it requires a little bit more form. If we want to do that because we would have to agree that, you know, this is at odd with what we've said before, and maybe change a policy as to how we can dispose of projects when they are in limbo. But so, the alternative is, you know, we could move that to like towards archiving it. But, you know, he seemed to want to work on it again eventually. So, is there much to gain in putting in, you know, archiving it now and then he will come back and say can I resurrect this project. I mean, of course, then we could say, yeah, go make it the lab if you want and it would be a way around her policy. I don't know that there's much to gain there. So, I don't know. I'm happy to hear what others think. So I see Daniel is first on the queue. And if we're looking at what other open source umbrella organizations do, we can use that as kind of a guide to what happens in situations. Apache has something called an attic, where when the PMC can't muster up enough votes for releases or other such issues. They move it there and it's something between deprecated end of life. There's still a PMC that overlooked over looks it still kind of grows it can still do releases. But one of the unique things about the attic is if you get enough people who want to be responsible and lead it, it can come back out of the active and go back to the beginning of the Apache life cycle. So one of the things that's missing from our life cycle I think is it's all straightforward it's incubation active deprecation end of life. So I was wondering if, you know, to solve this, you know, we'd be a little less answered by moving things to deprecated and end of life if there was a way for them to move back to the incubation state, when they get sufficient activity to warrant it so it's not a death sentence, when they get moved to further you know down the road it's not the total end of the line of the project. There is a path back to activity, if they want for it. So something that I think we should probably think about as one of the options rather than just moving stuff back to the labs is to give the option for projects to be resurrected, possibly in the labs, but I think a more appropriate place might be for back to incubation that that's the standard it needs to be incubation where before it gets moved out of its quiescent state. I mean, it's kind of like shelving it for the time being we don't have a shelf to put things on. Nathan is next. Part of what I wondered is I read through the proposal is, we don't know a lot about the overall health of the interledger protocol itself. You know, what's the trend of the underlying community beyond hyper ledger related to this project. And that that could tell us a little bit more about what we should do with it. But it does seem like we might need a state. I don't know if I like calling it the attic, but like a maintenance state that says, you can use this project. But it's probably not going to get bigger is probably not going to have lots of development effort beyond bug fixing. It's in maintenance mode, so to speak. That would hopefully indicate that, you know, it's not going away. It's not dead. But, you know, help set the expectations and maybe we could put it on a different reporting schedule and a few things to make it easier for someone to get involved without having as much overhead. And hopefully serve as an invitation to say, if you want to bring this back to a more active state. These are the things that need to happen. And I agree with down that we don't really have that kind of state right now. That's right. Thank you. Anybody else. I'll just mention I dropped in chat that the Apache attic is intended to be the end of life situation I think. Just distinguish between or maybe think of a way to describe is the difference between projects that are simply out of gas, you know where there isn't enough contributor energy to really muster of release that is trustworthy, you know, and that's where something like quote could go versus something where the contributors actively recommend that you move on from the tool, which I think was the case with composer where, you know, there's the original maintainer saying, you know, really we're going to be in SDK or in point of view there's no one around to update composer and composers kind of reached its, you know, a point where anyone using it should be using something else. There's fields like these are two different end of life. Those are two different statuses those could both be in an end of life status with just different guidance given to people. You can still go find the composer code, but and in both cases, you might want to warn people away, but in both cases you want to keep wiki pages around and documentation around on the process and the premise that it's useful as mulch to the next thing that comes along at the worst case so I kind of feel like what quote is asking for is moving down the deprecated to end of life kind of thing. And, and, and yeah. All right, thank you, Brian. Nathan, are you back on or just left or. Okay. Anybody else. Come on. Aaron I see you've been typing in the chat window whether to speak up. I think Brian summarized it pretty well. In this case it's not that maintenance saying we should end this project rather that even though that we still have activity, even though it's just one maintainer or one active contributor over there. So we should not punish the project for for just for the reason that he's not he or she's not getting additional contributions. I think Brian summarized it well. So it occurs to me that I mean there's one option that's obvious, which is to just do nothing right, we can leave it like this, and we can advise them, maybe to put a comment on their homepage saying you know, there's no current active project, we don't have plan new features and, but you know we'll be there if you need to, if there are bugs will try to address them and leave it at that. This is totally acceptable to me, of course, you know the notion of incubation is a bit harder with that but funnily, there is no cost to doing this, and they could pick it up, or pick up the pace anytime, and it would be fine. Yeah, I agree. I don't know. I think if you read through our life cycle that's where it needs to stay is right in incubation. Our life cycle says that the next state would be active or deprecated and deprecated says that the maintainers have to say that they want to deprecate it. Right, and then the TSC has to agree to it, so I don't think the maintainers have said that, they basically have said they just want to put it to sleep for a while, right, until there's more interest and more focus on it. So, based on our life cycle, the right answer is we don't do anything. And that doesn't mean that we can't change our life cycle, but based on where we're currently at, we do nothing. Yeah, but would you, I mean, what do you think about the proposal we heard like maybe to insert a new state like attic shelf or whatever we call it. Yeah, I think the difficult part there is what what is the name of that state. And is there a different state for projects that are moving from incubation to that state versus projects that are moving from active to that state. You know, are there two different states that we have to introduce, I think there's a whole lot of questions and discussion that we have to have if we introduce new states or states. Yeah, that's a good point. Thank you, Aaron. So, it also raises interesting question in the sense that what if a project so now I'm not sure when was this project mode and if we had that fine line criteria for project to be moved into incubation when when we first proposed. But now that we have a different process that project will start in and then incubate only when it meets certain criteria. So, the other question which it raises is, have we defined the process where for a project which is an incubation I believe this similar question came up earlier for relating to another project. I would not bring up the name here, but when it does not meet its charter goals or like agreed upon maintenance they move away from the project. I mean how do we handle such scenario right. I know similar question was brought up earlier, relating to another project. So we considered that scenario for quite as well. My hand is up Arno. Yeah, please go ahead. I don't see. Okay, well I don't have the ability as I was. I get it. I want to like, I'm really pushing back on your assertion that there's no cost of caring. There's a huge cost, and that's, you know, just look at the greenhouse right. It's very confusing. And if we have a project that we know is not going to do anything for the next couple of quarters. There's a burden that puts an additional burden on staff to try to explain. Well yeah that's that shows up on the greenhouse but it's kind of asleep and and don't expect a lot out of it but maybe in a couple of like, I beg the TSC to find a way to, you know, help projects transition more to hibernation or something. I don't know what the word is, but it's not zero cost. Take your point I want to to point out, there is a work underway to revamp the greenhouse right and I can tell you, I mean, Ellen might say more but you know the discussion is so far has been going towards a much more dynamic view of the how we present projects that would show, you know, things in a different way so that we can surface things differently and that would give us more flexibility and maybe, you know, I think address this kind of issues you're raising, but beyond the greenhouse I mean in terms of resources. Do we have other costs with having a basically dormant project. I technically know a dead mailing list doesn't cost anything. I would defer to Brian. If there's a reputational hit from having them, I don't know Brian thoughts. I mean, it's not a problem until it's a problem and there hasn't been a problem with somebody saying, you know, quilt is broken there's, you know, no one has come up with say security holes. So there's, there's a, you know, perhaps a burden on a security and hyper legit or collectively if somebody reports a major bug in a project that there isn't somebody around to respond quickly to address that and respond that's that's where I would more worry more about the reputational risk, but I do agree that projects that are not active should not be as widely promoted and equally promoted as the ones that are and that that does open the broader question of reformatting the greenhouse into something more dynamic and landscape driven which is a longer term conversation but in the shorter term. I kind of see in the status update, you know justification to say quilt might not be dead but it might not deserve to be in the greenhouse right now. All right, so let's close on this I think you know the status quo is for now it stays in incubation we agree there is no, you know, obvious step we can take to move it to somewhere else right now. The alternative is somebody makes the effort to come up with a proposal on how we modify the project lifecycle. So, or maybe if you can come up with a new idea it's fine with me. Maybe there's a tag of some kind that we can say this is hibernated. That short of such a proposal that we'd have to be looked into develop proposed approved so that we can then use it. I guess for now we are stuck in this current situation we're in which clearly right doesn't like but that's how it is. I suppose right you could make a proposal with you. I don't know about that. That's okay I mean I don't mean to put you on the spot it's just like, you know, that's where we are any other thoughts. Otherwise I'd like to move with the other agenda. So, I don't see me. So, let's move on. Promoted release. So, in the process of implementing the resolution with regard to the change of name from active status to graduated. So, it, you know, I realized that the document we had the page that describe the project lifecycle made references to promoted release. And you may remember that at some point, well at least the older people like myself should remember that promoted release used to be called first major release. And there was this idea that, wow, when you make a first major release, you know, hyperledger goes all, all in and gets the, you know, press releases and a whole bunch of, you know, communication effort is put into it. And then we give it and there was also security audit and a bunch of things happening. And so we said, well, maybe not all projects in all states can claim to have the right to do this and long story short we say well that's not really a state. It's just one thing is promoted release because in fact, some, sometimes we do that, and it's not the first major release. So, we moved to from first major release to promoted release. And to me that you know we ended up with the documentation where the name was changed, and things were kind of left broken. And so, in the project lifecycle page, it referred to promoted release. And it kind of, it didn't define he said to have a promoted release, the project must be in active status, it was called. And so, you know, when we when actually Tracy have to be recreated when she reviewed the change I had made regarding the change of name of active from active to graduated. She noticed that there was all these texts about promoted release that didn't seem to make much sense, even refer to Sam there and a bunch of things that seem to be completely out of date. So, in the end, I decided to just get rid of the section on promoted releases which didn't quite belong to the project lifecycle anyway. But the only page we have left is this one that rise, you know, showing, which is the criteria for promoted release. There's no definition of, well, this tells you what you need to have to have a promoter release but it doesn't even say what a promoted release actually is. And so, I feel like we have a bit of a problem here in our documentation, there's a gap here. I figured, well, I'm going to bring it up and I know that our room for one was saying, well, this should be defined somewhere, which makes sense. So I said, okay, let's, let's take that on in the separately. So we have implemented the change from active to graduated. But now we have this problem of promoted releases. And so, I felt like, okay, I'll bring it up to the team and see what people are saying, people think we should do. And there's also the question about, you know, is that still accurate? Do we actually go through this? Because for one thing it says, prior to bringing a project to the TSE for a vote on granting a promoted releases. And I don't even know this is happening. Hey, so if I recall correctly, we used to have sort of a strong requirement for a promoted release and what that meant. But this sort of died because the marketing people just sort of decided what releases to promote and how to promote them without any input from the TSE really. So this came to be like a marketing thing rather than a TSE thing. Releases were being promoted without, you know, any sort of TSE thing. So the whole thing just kind of died. I think that's that's sort of what happened. So I don't know, given, you know, all the changes we've made if we even want to be in the business is a technical steering committee of handling promotion. Yes, I think that's a very well put it's kind of what, you know, I had in mind and made me feel like we need to bring this up to the TSE and have a discussion on this. Tracy. Yeah, I would say that we probably haven't had a project come to us for a promoted release because there hasn't been any. I mean, if you think about, we've had promoted releases for fabric when it hit 1.0 we had a promoted release for sawtooth when it hit 1.0. We haven't had any other promoted releases like official promoted releases. Obviously marketing has been doing a ton of marketing for any of the projects. You know, as they've moved through and the life cycle. I think the other piece about promoted releases per se that we had kind of tied into it but it wasn't really necessarily related to marketing was things like the. We were doing license scans every month, but then once it was going to go kind of active 1.0 we insured that there was no license concerns and we went through the legal committee to ensure that there were no issues there. And then there was also the security scans that we did that Hyperledger paid for to ensure that there were no security vulnerabilities for 1.0 type release. So I think there were some other pieces that were kind of tied to promotion. And when we went to this promoted release we kind of dropped the requirement for those sorts of things happening as far as license. Not dropped them completely, but we just didn't include them in the definition of what a promoted release was anymore. And it truly did become marketing focused. So I think in general, as long as all of those things are happening right the security scans when we do kind of a major release. The license scanning is still going on and that the legal committee is being. It's being talked to you discussed with when there's things that need exceptions, things like that I think are still important and need to happen, but they don't necessarily need to be tied to what this thing is, whatever we call it. And I mean marketing is doing their best to get the word out about all of the different projects regardless of what state they're in so. I agree with heart that like this piece around marketing isn't required but those other pieces are still required. They don't require TSC approval, but they are required processes that have to happen and I'm sure they're still happening. I think the, the license scanning happens once a quarter. I had to have to check in with Steve Winslow. We are doing security audits and kind of an ad hoc way deciding which, which projects get them in what order. You know there's some turbulence there because of the change in staff. Brian, do you have anything you want to add about the difference between where we were and where we are. Who is brief. And you should be brief coming from Brian. Wasn't sure there's anything that wasn't sure why I was being prompted. Well, just we're, we're going through right now, figuring out the security audit schedule. So that's, that's why I brought it up. Yeah, no, I mean we have capacity to continue to do security scans of projects that reach a useful milestone. I think there's some demand for us to do that for Aries and Ursa next. So there's some interest there but we have a capacity for other projects that are, you know, getting ready for their first promoted release to do that. I don't think the timing of that is awkward to try to do that before a 1.0 or before a first promoted release. I wouldn't make a requirement of release. Does it still make sense for the TSC to have a say in what can be a promoted release. I would say that for documentation, like the stuff about doing the license scans and all of that needs to live somewhere. I think the heart's earlier point. This is completely decoupled from any technical stuff. So I would just say, you know, remove this whole thing from the purview of the TSC and just document how it how it is done. So set guidance, give yours what good looks like kinds of things and trust the maintainers to follow that and ask for that in a status report perhaps and talk about that but not have not put the TSC in the position of having to approve the first release. Okay, so that's, that's, I think that's an important finding that I agree. I think it would be good to make that decision official and update the documentation according me. I agree with, you know, not throwing out all these texts because I think there's some good stuff in there. The fact that it seems to be under the purview of the TSC. When I looked into it as like really, I don't even know that we are actually, you know, that's not how we are operating today so for me when the documentation is that odd with how we do things is I think it's time to update the documentation. I'm willing to do the PR, if you're willing to get a second and do the vote. Well, I think we could have the vote now on, you know, agreeing that we are basically agreeing that the promoted release is no longer the governance of the TSC. Right, that's what I was saying. I was just going to say just to be clear what we're voting on is that we say that we're just sort of canceling the TSC procedure for a promoted release. That's why I was proposing. Yes, just remove all this verbiage and save it somewhere else releases as attached to the TSC. I'll second that proposal. And do we do we still have the requirement but graduated. I mean, who is in charge to enforce it. Or we just say, well, that's not our problem. Well, it hasn't been enforced marketing has been more than happy to promote non graduated projects. Okay. All right, so I'm happy with the proposal. Anybody wants to say on it. I think I already did. Okay. All right, we have more seconds than we need now third and fourth so let's try and get through this quickly. Is there any questions about the vote of the proposal. Does anybody want to object. Does anybody want to abstain. I actually have an objection to this process where we don't require people to make an affirmative action about on it. It just feels weird. I would prefer that we at least have a voice vote of everyone saying I or day. You do. Okay. Yes. We have problems with this in the stadium where passive action causes stuff to change and people say well I never voted on it. So that's my concern with it. That's fine. I mean, I appreciate that for me, it seemed to be more effective, but. All right, I don't think we need to do a roll call unless someone calls for it, but I don't like the silence confers success approach. Okay. That's fine. I can. I can totally accommodate your request. So anybody in favor says hi. Hi. Hi. All right. I don't have to redo the abstain and then objections right. All right so this is passing unanimously thank you. Thanks. All right so finally. I wanted us to have a look at the backlog of the decision log and see if we could do a little bit of cleanup. It's pretty clear if you look at it that there are issues that are still pending and that you can hope to get resolution on. And then there are things that just like I, you know, they either are superseded by other issues that we are working on, or we just never get to a closure so might as well accept it. So, the first one that DC O validation, I think this one is still pending. So we definitely keep that one. The project matter made majority matrix and badging is also pending experience experimentation and the automatic tools so we'll definitely keep that one. The restructuring the greenhouse to avoid confusion. I would say we can close it because we now have a task force that's dealing with this. And all of we this was about is, you know, let's make sure this happens. And I'm happy to say it is happening. The leadership of Helen who is present here and can tell you more if you care. But so I would propose to close it and call it. And we call that like we have delegated these to the task force led by Ellen as a sound reasonable grace. Just a quick question. Is it. I'm fine to update the status, but with the status being processed or I don't want to close it because I think we want to regroup on. What happens, but just not sure. But obviously propose doesn't necessarily make sense at this point. Well, so I see what you're saying. I mean, those might be the only two tags effect. I'm not sure. It doesn't cost me anything to make that text, say whatever. Yeah, we can. Yeah, it's free form. You can actually say whatever you want. Yeah, yeah. If everyone else agrees with that, but just so we don't, we do check up on it because I think it's important and we don't want it to just be closed because it's technically not closed, but it's definitely not proposed. Yeah, and it's kind of deferred to the separate effort. So, but okay, that sounds good. I really cool with that. All right, let's keep going down the list. Introduce a mechanism for regular review for project. So I would contend that the badging proposal is basically addressing this need, but because the badging proposal both as the, the badges and the project that the process and updating the projects. I don't know that anybody has come up with a better proposal or is intending to make one. So, to me, it's either somebody says no, no, we need a different mechanism to do that. And they need to work on a proposal, or they're satisfied with saying no, I'm happy to defer that to the badging mechanism. Of course, you could say, well, if the badging proposal doesn't get closed approved eventually after experimentation and whatnot, then maybe we should resurrect that then, but I don't know. Tracy. We already have a mechanism for regularly reviewing projects they're called project reports. Yes. I, I don't know, I see that you created this, I suggest that you withdraw it. Oh, that's easy. I can do that. Did I. I think I yeah okay I'll take the blame. The proof is right there so I can deny it as opposed. I do think yeah. So, again, I think yes withdrawing seems like a right thing to do. It doesn't anybody get offended with this. So we can actually all take out saying that this can be considered as part of project budget criteria and then market has done. The resolution is that we are considering this as I mean we have a update quarterly report. And then badging criteria keeps the project reports up to date about activities status. And we can close it. Okay, so that's a different proposal is you want to market resolve. Yeah. It's either related to one. I mean it's related to two activities so we can resolve it. So if you want to do that we need a we need a decision by everybody that you see. I want to have another vote on that. I mean, I think withdrawing it is probably the easiest but sure have another vote. Sounds like I really prefer that. I just feel that same way or otherwise I'm fine with withdrawing. I would vote for withdraw. Okay. That was going to be my comments as well. Okay, so there's a seems like anybody else wants to go through the process of resolving this rather than withdrawing it. Okay. Let's withdraw it. Good. Thank you. What's next. I think long-term agenda framing. The order change. No, there is what if a top level product does not meet its charter goal. I know I created that one too. And, but to my defense, I think it was based on some of the question that was raised earlier on. I think maybe by in some discussion we had, I think I wouldn't maybe have raised this. No, it was part of the rollover stuff. That's what it's about. Yeah, when we talked about rolling over, you know, that was the, that's, that's right now I'm remembering. So you remember when we talked about rolling over projects as sub projects to an existing top level project when there was a clear dependency, because a project. It was the grand goal of supporting different frameworks, but ended up never doing it. The idea was, well, let's simplify the number of projects top level products we deal with recognize the dependency, moving a project within another one that depend on, and then it was pushed back we decided okay let's not do that. The one question came up as part of this was, well, so we finally raises the one question which is, what if a project does not fulfill its charter. And we don't have a mechanism per se to catch that. And this is what this was about. Do we care. And if we do, how do we go at capture, you know, catching that situation. Sometimes he would also require knowing what to do if we decide okay they have not fulfilled their charter but so do people feel like this is still worth keeping on our decision log and something we should eventually work on. Do we just give up on it. That's basically the question. I'm asking. I don't know that we need a formal process on this I think it'll happen frequently enough that special action in the cases that it happens I think would be warranted. So, I'll be okay with the drawing it because formalizing it. I don't see the value about it. All right, thank you so we have a proposal to withdraw it. Anybody else either in favor or against withdrawing our room. I'm against withdrawing it because the whole point such a topic was brought up last time was because few of the members felt that particular project is being suppressed. So any kind of talk should not have come up. And if we leave it for case by case basis, then I'm sure such kind of thoughts will again come up. All right. Fair enough. Okay, so we'll leave it for now. You know, that's fine. Let's keep going we only have a few minutes left if we could keep going down the list, I think, and knock off a few more I think that'd be great. So, this is kind of like this, you know, big idea of like, okay, what is the big agenda for hyperledger, and can the TSC set a technical direction, a roadmap for hyperledger. It did, you know, it did lead to quite a bit of interesting discussion. I don't think, you know, we got anywhere specific and I don't know how we would, you know, close this person. So I don't know what to do with this. Yeah, I thought, you know, and Dan had opened it when he was a vice chair last year and also felt like kind of free space and you want to just close it but it seems like a mission impossible to close it properly with the resolution. So hot. This seems more like an abstract sort of long term goal rather than a concrete proposal. As you correctly point out I don't know that, you know, we could ever, we could ever do anything that sort of satisfied this goal this is sort of like an ongoing thing. That being said, I think it's absolutely something we should do. So, I'm not, I'm not sure exactly where it fits, I guess. Yeah, I agree with that. So maybe there's, maybe there's something that can be done that's different than keeping it there as an open issue. There should be something on the on the wiki somewhere as a page something to have and work on but not technically as an issue, I don't know. Any other ideas. I mean it's, it's you know it occurs to me that this thing has been sitting there for a long time and nothing is happening and I don't know that there is anything we're going to do to that would change that. I don't like just keeping it there for the sake of it. If we want to make sure we don't lose it some, that's maybe the best to do though, if, you know, until somebody can come up with a proposal on how to dispose of Arun. So it looks like this proposal is asking us to get back those discussions back into TSE maintenance and we lose Arun. Yeah, I think we lost him. Hello, can you guys hear me. Yeah, now we can hear you. Hey, sorry, I don't know it says my internet was unstable sorry about that. So I was saying, one place we are saying we don't require any reports from working groups and we say it. I mean it doesn't expect anything from working groups and at the same time we are saying architecture related discussion and discussions or decisions do happen in architecture working group calls and then similarly there is another working group for identity. So should we just bring back reporting to those working groups or maybe ask them to get the status once a month or probably once in two months to the TSE. Would that be a good start to answer these questions. Okay, that's an interesting question but I think it's, it's orthogonal to this long term agenda framing issue. Nathan, we're out of time so we're going to close after that. Okay, I guess I'm in favor of withdrawing or closing this proposal just because I don't see how it's not already part of our remit. I mean, we get to set our own agenda and this is the thing that's going to help us set technical direction for the project or help better support the underlying coding projects better than this is all what we ought to be doing. If any of these items on the list came up in our agenda. I would not be surprised at all and I would find them all probably fairly engaging. I don't think there's anyone in the architecture or identity working groups that are talking about that would be offended if we wanted to take up any of these topics and TSE meeting I think they'd actually be excited we were paying attention. All right, thank you. I, as you say that it occurred to me maybe one kind of middle ground is to try and, you know, capture some of the content there I mean there's questions that were raised I agree with you as kind of for mission to do. Maybe we just put some of this text on the main page of the TSE the main wiki page as things that the TSE, you know, text into account or as part of its mission. And then we can close this and say okay we are not going to lose it it's there we have, you know, restated that. That could be a reasonable way out so we don't lose it completely and we can dispose of it. All right. Let's leave it at this we're out of time. Thank you, I think we made some progress will keep doing this because there are a few more I think we should get through in a similar way to do a bit of house cleaning it's spring so it's good time to do cleaning. All right, thank you all for joining. We'll leave it at this for today. Talk again next week.