 Alright, thank you Ray. Welcome everyone. This is the weekly TSC call. It's open to everyone to join and participate in. There are two requirements to doing so that I must go through. The first is to be aware and live by the antitrust policy, the notice of which is currently displayed. And the other piece is the code of conduct that governs our participation in in hyperledger, which is linked from the agenda. So, speaking of the agenda. Before we get into the meeting proper, I saw somebody added a couple of items. And I'm sorry, I don't know the person. But do we have somebody to speak about this next step on decentralized access? Bobby, I know you're involved in this, I believe, but you didn't add that, did you? Are you involved in this? No. Yes, I am. Does anybody know Darwin? Okay. So unless that person shows up and can explain why this is on the agenda, I guess we'll have to ignore it somehow. And, you know, I always welcome input for the agenda, but this came up just an hour ago or so. And I was like, what is that about? I'm open to addition, but I still need to understand what this is about, at least, and how much time we need to allocate and so on. So it's not clear to me what to do with this at this point. And this is Zingela. I think this is someone from the telecom special interest group. So let's see if they show up. I'm not quite sure who that is. I haven't spoken to them. David Boswell on the team is the POC for that. But let's see if they show up. Okay. All right. Thank you, Daniel. All right. Is there any announcement from anyone? I don't know any. Since we had the meeting cancellations and you said that there was a possibility of having a uncancelling one of the meetings, are you going to wait on that decision or so we. Yeah, so in theory, this is the last call. No, we have one more call next week. So we have one more call next week. So we'll see if next week if we need one or feel like having another one. Otherwise, the assumption at this point is next week is the last call for the year. Cool. Okay. All right, so moving along. We had two quarterly reports posted. Grid just came up earlier so I don't suspect many people had a chance to look at it. I'm happy to carry it over for the next week. If there's any questions. The other one explorer was posted a while ago. So most people have reviewed it. And in either case, there was no prompt from the team to have anything specifically discussed by the TSE. But is there any questions or anything people want to discuss about either of those reports. If not, then we can leave it at this for now. And again, I mean, at least the grid which just came up, we can have it next week again so people will have another chance. And I mean, you're always welcome to say hey there was this report the other day I didn't have a chance but now I have a question right so this is not this is an active prompt prompt it's not meant to limit what people want to bring up by means. So then we can move along. The main agenda item is a follow up to the discussion we started on the last call where, you know, a room did some archaeological work in going back to, you know, all the different issues related to project lifecycle and evaluation reporting and so on. But he had put together the summary and RFC page which we looked at last week. But, you know, it was a bit of a mixed bag of different things. And we said okay there's some interesting stuff in there but we need to kind of divide this up into smaller chunks that we can tackle. So I had actually a separate chat with Arun and a few days ago and I, you know, I prompted him again saying hey, you have a chance to do this. And so he came up with this list, which I think is closer to what we can indeed look at. And he has now posted it as a comment to the summary page. So if you scroll down, right, it will show up. And my goal for today is not so much, you know, I saw there are several people here, namely three, I think, Dano, Hart and Tracy started responding to the some of the proposals that were there. And my goal is not so much to dive into any one of those points specifically now, as much as, you know, going over the list, and trying to decide what is it that we actually want to put officially on our agenda, you know, to to be tackled. So the process I'm suggesting is, you know, we go through this list, looking at a fairly high level, not so much about the solutions, but trying to understand if does that ask the right questions is really what I'm trying to get to right. We don't want to get too much into the answers, but it's like, what are the right questions we had that discussion, you know, that question raised several times when we're talking about the wall over proposal. Like, okay, what problem are we really trying to solve. And so this is another take at this. And I think there's general agreement that, you know, we can kind of, you know, separate ourselves from the the roll over project proposal or issue as such. It's more like, you know, let's step back from that and more generally speaking look at the situation we're in, and what are the problems we're seeing that we should tackle. So that's really my goal is to go over this today and see what we say now we're not going to tackle this. Oh, yes, we should add that to a list. And then for each of those, we should create a separate issue page under the decision log. And, and then we can start looking at the proposals to solve these problems. So does that sound all right everybody's on board with the plan. So if we are, then I suggest we start going down the list. So for instance, the first one, it was this question of, and Aaron, do you want to speak, I can do it, but I don't want to be the only person talking so You can talk about it. So, so this is the same list, which we discussed last time with the summary and RSE. I tried to break them questions to solve instead of directly giving the problems. And the way we can look into this is if we think this question is something we need to worry about, then we can take it up further. So this is just one of the proposed solution and depending on further feedback comments, we can improve on these things. And if we think this question is something not relevant for the TSE, then we can drop it at this time. Okay, so let's get through the first one because I think, you know, and I shared that with you privately when we are the chat is like, so the first one, you know, touches on the idea of, you know, projects, I think to start with lab in the labs, you know, and I think today, that's kind of our default answer when people come and say, Hey, maybe we should start a project on this. We say, Yeah, you're welcome to go create a lab for this. See how that plays out. But we specifically had a discussion on making this formal or not before, and I saw Tracy in one of our comments did the digging and brought up that a pointer to this, but we actually decided that actually we have a recording of resolution, not to require project to start with the lab. That's the third bullet there in Tracy's answer. Thank you, right. So I want to ask more generally, you know, so my inclination based on that is, I don't think we want to tackle this question again. But, you know, the rule of thumb that I've always heard and used in this kind of, you know, situation is, we only reopen issues, if there is new facts, or you know, the reason we should reopen that that you know something that might make us change our mind. Otherwise, you know, we we can just reopen issues all the time and they would not go anywhere. So I'm not convinced that the you know what what is the reason we should reopen this if there is any. And please, you know, anyone feel free to. And I understand some of this is also we have new people, not everybody has all the history. And that's really fine. And you know, there's nothing wrong with getting it helps us get on the same page if anything so Could somebody summarize the rationale of why that decision was made. So if you click on that link, right, see if we have that now because this, yeah, the minutes is a link to the minutes at least but does it go into the detail. So therefore issue five, which I highlighted a second ago. Yeah. So it begs the question, you know, what's the criteria of when somebody should start as a lab versus a project. Do we have that written down anywhere. I created a presentation when labs was first introduced to kind of talk about the differences between labs and projects. I will go find that link and put it in the TSE chat. Yeah, but you know labs was originally intended for experimentation proof of concepts things that people wanted to do but they weren't quite ready to introduce as projects and so, you know, I think the key here right is that we want to have labs be an easy entry place right versus maybe the challenge that it comes when introducing a brand new project into into hyper ledger under the umbrella right obviously there's a lot more that goes into that new project process, given that we've got the project proposal and things like that. The labs was intended to be kind of that easy entry to start, you know, building your idea experimenting with something, seeing if other people were interested in getting involved or or not. Yeah. And for projects I mean there's a there's a process and there is a form that you have to fill out what's called the hip hyper ledger improvement proposal I think it stands for. But so, and it kind of implies some criteria in there because it asks who is committed to this, you know, there's expectation there is more than one organization behind the proposal and so on. And so we have had the case where they were proposals that sounded interesting and we're worth investigating but didn't quite meet the bar that we expected to meet for projects. So that's how we came up. So we said no we're not going to create the projects for this, but we wanted to create an area where this work would still happen. That's why the labs were created so I don't know if we have a clear definition of what qualifies as project versus lab but that's Anyways, it makes sense to me I'm satisfied. Thank you. Thanks. Yeah, I just wanted to add one other thing that wasn't touched on, which was, we run a number of mentorships in the summer, and we have for years and part of the reason we wanted the labs was those mentorships sometimes produce outcomes that you wouldn't consider a project because they're narrow and scope. They've been worked on for three months there's really no intention to work on them anymore but we wanted to capture that work because it is useful and could potentially serve future work. So the labs are a perfect place for all the mentorship work that doesn't neatly fit under one of our existing projects. That's all. All right, thanks. Okay, so back to the question. Does anybody want to lobby for opening this question again of requiring project to start at the lab. And if so, so I don't hear anybody wanted to. So, if there's no advocate for it I guess we can skip it. I'm just screaming at me so I guess it's an agreement. I agree with skipping it next. So the next question then Aaron, please go ahead. Sure, so this was another thing which came up. And also, in some of the email this this was coming up. Hyperledger greenhouse is so confusing and then do we need a revamp on that we need to relook into it and see it differently. So these were some of the questions which were brought up I know in last meeting, many of us commented that this is something not in scope of TSE. We could however help out the marketing team in helping out in help them shape this little differently than how it is currently. So yeah, do we want to address this now that do we consider. Should we look at the greenhouse into something like, hey, we have library projects and some of those are focused on application developers, and maybe few of them are only for DLT developers. Maybe not all of them are interested in those projects. Is it better to call them out so that's where this question is all about. Yeah, thank you. So I saw Tracy also pointed that aspect that maybe this belongs more to the marketing team but Brian maybe can shine in on this one. What. Who's whose job is it to fix the greenhouse on the website. Whose job is it. It's an interesting question. It's something that we've typically owned somewhere between the staff and the TSE, you know, the last time we iterated upon it, you know, we had a couple rounds between, and we do have for folks who don't know a marketing committee comprised of representatives who we like to also have on board with how things get represented on the more public facing website, you know, the main hyper ledger.org, especially since this graphic goes into presentations and those sorts of things. So it's an it's not a well defined process for iterating this particular graphic but it we certainly if this community is unhappy with it would certainly continue to be happy to evolve it further. And then tying it into I think the next question on project metrics. I, you know, I think there's certainly the possibility of highlighting certain projects and over others based on based on those metrics but it's kind of nice to have a static image. Stay steady for about a year and I think it was about a year ago that we last revised this so happy to open that process but it's it this is one of those things it's kind of like a user interface to, you know, end user interface. To add to a software it's kind of hard to design it by committee right it kind of does take somebody inspired and with some skills to, to take a fresh look at it. But, but certainly open to feedback. So, I mean, this is what I'm trying to get these do is their value in saying yeah the TSE, you know, should have that on its agenda to solve this problem, or we just express the desire to you, the stuff to TSE could be more specific than just confusing. Then it would be something actionable something that we could try to address right and come back to the TSE with a different take. We have 16 projects right we're there's a certain amount of irreducible complexity to what we're trying to represent. It's not clear that there's there's a, an obviously different approach that reduces that confusion. Sometimes the confusion can be abetted by better explanation text before and after a graphic or or otherwise so perhaps one path is if people have examples of maps provided there are kinds of projects like hyper ledger that they feel do a better job of communicating what a family of related but still independent projects do then that might be another good starting point you know show us an example something that's less confusing on this front but represents the same degree of you know complexity to this kind of community. Thank you so I think that means to me that makes it worth having something to kind of, you know, to mark that we don't we actually want to spend a bit of time on if nothing else, gathering specific feedback on what we think is broken with the current greenhouse that would feed the work for the team to try to revamp it. And I understand the just saying it's confusing is not specific enough, but I also agree we do we don't want the whole TSE to design that page, that'd be horrible. So, I think I'm in favor of having that on our agenda but more in terms of better specifying the problem, rather than trying to solve it. What do others think. Perhaps a subcommittee could go off and look at it. Yeah, we've done that before we have task force sometimes we can definitely do that task forces, you know, we can see subgroup for those who are not familiar is just like, you know, whoever wants to volunteer. We can go offline and work on this, typically through the wiki page, and you just commit to working a bit more on this than anything else and making sure that we're making progress and then, once the subgroup is comfortable that they have actually hashed out enough of the problem, they can come back to the TSE. I think that's a good suggestions mark. Anyone else. I think we ought to have something happen anyway because this problem is we always been brought up several times so I don't want us to ignore it. I think I suggested this in chat but it might be useful to have some kind of diagram that is focused on applications or end users or end use cases that maybe focuses on some of the core platforms rather than the libraries or the tools. And this just might make it easier for business people are non developers to figure out what's going on. Yep. So, really silent so I propose to add this question. What is it. Yeah, to add it to our agenda, generally speaking, and then we can get into the, you know, not so much trying to propose a solution but better defining the problem that needs to be addressed to our agreement to go with this Tracy. Yeah, I, I go back to Mark's suggestion of a task force. Yeah, that would go off and do this work instead of having the initial discussion is directly in the TSE calls. You know, having the task force come up with something and then come back to the TSE. I agree. I am volunteering for the task force because this has been a problem I've been, I've been talking about for a while so I guess I ought to help out. Anybody else. I agree to that so, and I'm willing to volunteer to help out and sort this out. Okay, anybody else wants to volunteer now, Bobby. Yeah, I'll join that task force with you. Anyway, the door is not closed anybody can jump in anytime, feel free to just say so. All right, let's move along. What's the next one is about incubation and active forever. Right, I think Brian also touched upon this briefly, a while ago. I know I see you raised your hand probably I'll just complete and then let you speak about it. So, yeah, so over here, there was a concern or comment made in the previous meeting, like a project that can be an incubation or active forever. And there's no incentive for them to move from one state to others. And that's why we see many projects once they enter into a top level project. Not much happens around that. This is one of the area or one of the way through which we can keep them engaged or keep them seeing through what's happening. So I would suggest that this be part of a sub part of the badging proposal, which is already proposed a separate topic. We could consider this as one of the sub topic on that. Thank you. We had indeed a while ago already late, you know, identify this idea of project maturity metrics and that's why there is an existing page. Nobody really jumped on this to try to make progress but it has come up several times. I don't know that it specifically relates to the incubation versus active being forever. It's the way you put this it kind of seemed to imply, oh, this is a problem. Maybe we should revisit that and I don't think we necessarily want to do that. I think for now we should look at the project metrics and the badging idea. And then once we have a proposal on that front, we could then say, okay, what does it mean for those phases, the status we have. But this could be done as a second state. I know you've been raising your hand. So I think this is actually kind of the nexus of four separate problems, which is why it's hard to get a hold of the first one is the names I don't think are very good. When they come from an older model from, you know, early Apache days when things went through once and incubation, you weren't supposed to stay there forever but we're going to let you stay in incubation forever. Then that's the wrong name it's too comfortable it's not you're not growing something. If that's an acceptable final state for project before you know while it's in production. So the names I think is one issue the next issue is I think our current model is a one and done model you go to incubation you're done. You don't need to defend that or maintain that level of activity. You know you can go back to one maintainer once you're active and there's really no mechanism that TSC has short of deprecating it. There's been talk of people moving people back in the life cycle, but it's never been, you know, there's no, we have to invent new processes for that. There's also a little bit of lack of detail there's a lot of stuff to exit from incubation to active. And there's no way to tell which ones are you know, seven steps away which ones are just the final step away so the badging would solve that. And finally there's an issue of clarity and some of these standards in the exit from incubation active are kind of amorphous and is our experience in a row has experiences been dependent upon the whims of the TSC. There's a very explicit clarity and the badges would be that you know the badging definition would be very explicit, you know, follow these steps to get the badge. So I think those four nexus in the nexus of four problems is why, you know, everyone wants to judge one of them and it's really the interaction of all four of these that's created this problem or having in our life cycle it's not really serving serving us well anymore. Any reactions to this. I think what you're saying is reasonable I, you know, I saw the exchange and hot, you know, express the worry about, you know, reopening this, the like exit criteria and having to have to go through these several times is a bit scary and coming up with, you know, purely objective criteria is challenging. But I think, you know, the names is definitely a reasonable thing to say to to look at, I would be open to, you know, say, should we change the names. But in my opinion, you know, I feel like if we had a badging mechanism to already have a better sense and different way to express the status of the projects. I think we'd be better informed as to whether you know we need to have those other labels, which is the status today, and what those labels should be. So, I'm open to the questions are raising but I think these are good ones but I would say they should be looked at next. Once we have the project matrix slash badging. And, you know, under control. Tracy. I tend to agree with that. I don't know. I think the I think we could potentially in, you know, the future get rid of names right of incubation active whatever we're calling them right. I think, though, we cannot do that. And I don't even think we should change the names until we figure out how to do the measurement. And so I think, you know, you opened up that decision log entry and I think we should focus some time on figuring out what it is that we can provide to people to determine whether or not something is a project that they want to invest in and utilize. All right, thank you. And I remember hot the brought up this badging idea before project metric and the idea was like, you know, when you look at, for instance, what has project stuck in incubation usually is the diversity. So, you know, this is the criteria. And instead of, you know, just putting everything under this label of active status. You could say no, this project has all these different badges, it just missing the diversity batch. If you're more instructive, informative, then then just saying, oh, they're only incubation, and you don't know why they're still incubation could be just a new project that just started or previously been there for quite a while. It just doesn't have enough diversity to graduate to active status. Yeah, just to add back to that. I don't know, I think, you know, coming back to Dana was comment about the fact that the diversity may change, right after you become active it may actually go back to not be very diverse. You know, if you had that badge that could appear slash disappear as as the metrics changed and I think that that solves that question. Yeah. So, anybody opposed to having this like project matrix slash badging on our agenda to figure out. And then I don't mean to to dismiss your questions. I, we can raise them now officially or we can tab them to later. I think badging is the place to start once we get the badging I think you can move on to the names and the life cycle. And there's also another question that isn't quite on this list. What services does hyperledger provide projects based on their level, a lab doesn't get audits and incubation doesn't get audits but add active to do. So that's another thing that needs to be looked at, but I agree I think badging is where it needs to start there's a lot of seems like we're getting a consensus around building a set of badges to reflect what the exit criteria is, and applying those and maybe creating more badges on top of that. All right, thank you. Anybody objecting. If not, we can move on. Next one. So, one more concern or probably this is where I see a gap and current process is a mechanism to keep reviewing a project. I know we have a quarterly report through which we can go through what's happening in a particular project and understand different metrics associated with a particular project. And therefore what we lack is to, again, this ties back to knowing if a project is meeting all its charter goals or not. So when a project is maybe approved to be a top level project, it proposes certain charters, there will be certain goals associated with it. So this proposal or this question is to ask if we should bring in a review, which is stringent, just like what we would do otherwise for bringing in a new project. Yes. And I think it, you know, it's what this touches on is, you know, even if we have a badging system, I mean, how often do we update those badges. I mean, we, it touches on what Dana was talking about earlier where, you know, today we do, we have these gates, you pass them once and then you're off the hook. And the project might actually not meet the criteria anymore, but is still, you know, in the same status. There's no way to judge that because we never, we never reevaluate those. And there are pros and cons to going down there. I think hot. I saw a hot was saying, yeah, that's a scary thought. I think to go through this once he's painful enough to go again. It is not very appealing. I can appreciate that. But maybe, you know, it's worth considering. And by the way, there was also a point made in the comments about, you know, project deviating from their initial charter. I think, you know, and how it was saying, well, you know, that might be for good. They may not be doing what they were planning to do initially, but they may still be doing something useful. I don't think that's a real problem. It's not a matter of, you know, preventing people from doing something different as much as acknowledging that there is they are doing something different. I think there is, there is using, you know, it's useful to, to have a mechanism that detects deviations and say, okay, if that's the way it is, we should be aware and make that clear that they are no longer trying to pursue the initial charter. I mean, you know, I spend a lot of time in my life working on standards where you typically have a pretty tight charter that says what the scope of work is. And when the case like this, you go through a rechartering process. It's not disallowed. It's just, you know, it's not prohibited. It's just, you have to go through this process to make sure everybody understands that there has been a deviation. Anybody, any comments on any of this? I mean, I know this is Angelo. I must also for the badges, I had this feeling that, first of all, we should assess the cost and the benefits of doing, doing these things. Also about the social, I mean, getting badges in and out can produce also stress on projects. Are we really sure that these are good stress? So it depends on, again, I think the last time we had this discussion about what do we want from this project? We want them to solve problems, real problems, not just provide functions, just for fun. That's I guess we, I would see this entire effort to move the project in direction where we want to, where we want to go. And most of everything, if we decide I know this, I think we should have an assessment of the cost and the benefits of having these, these, these things. Right. Interesting point. I think that's a wise point to make. We shouldn't have too heavy a process that discourages people and distract people from doing real work. We should have the administrative fault and the overview from the TSE. So I think there are people have different inclination in this respect. I mean, Daniel, you seem to in your comments to be proponent of a system where we do more of an active review and change of status. You know, then we do today for sure. Yeah, my, my thought is we should move some of these administrative steps and tie them with the quarterly report is another thing to help that too. So when you talk about these badges and all these other review states. It's part of the quarterly review questioning. And it's considered then and only then you don't bring it up in the middle of a cycle. Okay. Tracy. Yeah, I think it comes back to why we introduced the quarterly reports in the first place, right? It was because we weren't able to see what was happening in the projects and this was an opportunity for us to, to get more familiar with what was happening inside of the project, whether or not it was progressing. And I think, you know, we should, we should use the quarterly report as a mechanism for, you know, determining the communication between the project and the TSE, so it starts that they don't become disconnected right from one another. All right. Thank you. Thanks. I just wanted to agree with Angelos point that, you know, we don't want the badge system to be cumbersome and we don't want, you know, projects to try to think, you know, oh no my quarterly report is coming up. I need to get these random, you know, five email addresses to make a trivial commit so that I can get my, you know, community diversity badge or whatever or something like that. So I think, you know, maybe it makes sense to not have sort of, you know, binary badges to have some kind of continuum and to do it in a sort of, you know, objective, but if possible non-gameable way that makes projects sort of not stress about, you know, not stress about badging or not try to game the badging system. Okay. Thank you. Mark. Yeah, I'm wondering how much of this is self inflicted we, you know, years ago the TSE said well we spend too much time doing, you know, on each project's report so let's just, you know, only bring up issues that we have with them and we got rid of the discussions that we'd have that would uncover things sometimes. And then we sort of said well working groups don't need to do reports so that got rid of about half the reports anyways maybe we need to go back to doing interactive project reports and that would solve a lot of these type of issues. I don't know. So I, we're not going as far as that, you know, we talked about inviting projects to come to present to the TSE every now and then. And I would hope this is an opportunity for the TSE to get deeper and into, you know, the situation of each project. Of course we didn't talk about making that mandatory but you know, I don't know if we need that. So I would just ask if we worry, but do you think that would, it seems like it's trying to find some kind of middle ground between the two approaches that I agree with you, just an agree we, we detach ourselves from the projects by doing everything offline, but then maybe lost the opportunity to, to ask more questions. All right. I don't see any other. I'll be raising their hands. So, hey, I know, I know I can't for this care. Hey, I know. Hey, I know it's Gary. Sorry, I can't read. I'm, I had to get up off my butt and walk around here but I'm sorry, I'm raising my hand virtually. Okay. You know, I think, I don't know. It's always sort of comes back right. Maybe we're trying to mix. Maybe we're trying to mix too many things. Right. So you would have a problem with quarterly reports. Right. If you get to a point where you have too many projects, quarterly reports just, you know, there's, you know, assuming we even if we met every week right in a quarter right that's you know 1212 or 13 meetings right you, if you, you know, expand past that right and you know, I don't know how many you can do per per meeting. Let's start looking at maybe, maybe part of the problem is a rede, I mean, I don't know, redefinition of hyperledger. I don't know. Right. Like, because, you know, badging is an interesting idea. Right. I mean, you'd have to kind of completely change the change, change what it change how people look at projects. Right. And have a definition of what sort of bad is actually me. Because essentially, again, I go back to like Apache. Right. You know, so Apache has tons of projects right obviously don't have a TSC. They have a top level thing but then it's you know, fundamentally everybody has their own, you know, the large projects all have their own, you know, committee right per per kind of project, but they, but essentially they have a set of criteria that you must meet such that right if I go in and use Apache code. You know, I'm, you know, I'm supposed to be able to say that Apache code met these things right everything's been licensed the IP is free blah blah blah. There's, you know, it's maintained or whatever. Clearly me I go check things like, because we're used to open source or some of the people are here I checked when the last main, you know, when the last commit was for something right to see if something's actually actively maintained or whatever, before I might choose to use it. You know, so we had that kind of in hyperledger right, we went further, because we had like an Apache doesn't go advertised. Right. Like you don't go to the Apache home site and go see, you know, here's our greenhouse or here's our 10 projects right there's like here's a list of projects. Here's the other incubator projects right and then they have a patch icon right where everybody gets to highlight their, their wares. Like, so we on the one side, we kind of want to be that because we're moving away from a single unified mission but on the other side we want to go back to what we want to sort of like stay where we were originally which was hey here's a set of components that we have vetted, you know, of that meet the criteria of blockchain for business. And here's a set of stuff. And here's these ones that that we're kind of promoting. So, I don't know if I'm really asking questions to make a statement of fact but it seems like we're trying to do something in between the two. And I'm not really sure that you can ever really do that. All right, thank you for working. Any reactions. Otherwise, I think we, you know, I don't know what to make of what you say I think you have an interesting point Gary, don't get me wrong. I just don't know. Yeah, well, I guess I guess where I'm going at it's like you mean that like for example badging right, you could move to like if you if you went with a model of badging right, instead of having like you know active whatever whatever maybe, and maybe to the point of, you know, when you earn your criteria for badges right, and a specific badge may get you, you know, additional additional benefits you're still kind of fighting for stuff but maybe those are the better ones. Right, like maybe that's maybe you have to get some level of bads before we'll do a security scan for your stuff or something like that right. I mean, maybe part of the bad system is, you know what services hyper ledger will provide for a project project beyond the fact of, you know we have the governance rules and whatever, and maybe that maybe that sort of starts the problem. I guess it's just, you know what I mean we had a hyper ledger. I don't know you can't have. Or we need to go to a model that just says you know we're going to stop. Like, you know, we have to really vet projects we have to go back to a real thing that's going to really vet projects and see what value these projects actually bring to our overall mission. And have a committee that isn't you know what I mean it's like those are the kind of two extremes to me, anything can come. But there's a status of how you earn criteria, and maybe you get some additional benefits, you know funded by hyper ledger for those that you know as you hit badges, and maybe that just keeps the whole game like doesn't matter whether you're active, whatever. Or on the other side, you know you kind of have this more stuff of we're actually more properly vetting what actually gets admitted, you know, into hyper ledger that fits under what we as a technical the elected technical leaders believe is the core mission. Okay. All right, thank you. So, the question that was raised by a run is whether, you know, should we should we look at this question of like, you know recurrent reviews whether we need to do something different than what we do today. To a certain extent, has been pointed out, you know, the quality reports are a form of review but they probably don't satisfy everyone. So, again, back to my goal for today. Two more questions. So there's one more after that. You know, should we take that as a as a question we really want to answer. And we say no, it's okay with everything else we have is good enough. I think based on the discussions we've been having we sort of should. Okay. Just, you know, and I think one one thing that's come clear is whatever solutions we come up with it's not you get to this level and you're good, you know it's, you must continue to meet the criteria to maintain that level, not just once you get there. You know, you're in this badge now you don't have to worry about it again now you're in this batch now you have to keep showing that you deserve the badge, or, you know, whatever the status is or however we come out. But I think that's one of the flaws in our current system is once you get there. It's hard to, you know, blow it away. So mark is in favor I'm also in favor of adding that question so anybody opposing this, otherwise we can just move on to the next one. There's one more. We touched on this a little bit. Yeah, I know just a few seconds to connect to what Gary said that if I understood it correctly because it was breaking a little bit and I found if it's that I found it very interesting because to me pointed to something more foundational. And what what hyper ledger wants to be which kind of philosophy is around the hyper ledger. If I got it correctly and to me this sounds more a question that we should answer before everything else. If that is, if that is what Gary was was was pointing to just this. I think this is actually you I could have just said one line. That's a good thing and I could have just said one line instead of my speed but you know I like to talk so yeah that's what I was saying. All right, but that's not the question that had the question at hand is, you know, whether we should introduce a mechanism for regular review of project. So Mark said, yeah, we should do that. And I agree and you know I was asking if anybody objects to it, but I guess I think it's a good idea. So let's move on. I'll put Gary's question aside, although I don't understand it's an interesting one. Let's try to tackle the last one which has to do with, you know, this question I was talking about the charter. Arun wants to talk to this. We have to go quick. This is one of the hard questions and difficult ones to bring up because of many things which happened on the chart. So this is about like how to what to do with current top level project does not miss this chart chart goes. So the proposal which would fit in which which would put in fit in here is that we agree that these rules are whatever we come up with new set of rules. The old projects they did not know probably we should give them some extra time or we should understand from them. Hey, if you did not meet your charter goes then what are those problems that made you not reach those. And yeah, this probably is to look at the current projects in special manner. That's all. So it seems to me that if we add, you know, if we had regular review mechanism as part of that makes sense to look at the charter, and then decide to do there's deviation, I do appreciate the bring this up because it was also embedded in some level in the roll over question that was raised before, where there's these ideas like well some projects said they would support multiple framework they end up not doing it what do we do about this. So I do think it's an interesting question. I don't know, you know, I don't know that it needs to be and or definitely, but it should be embedded at least in the review. Although it doesn't say what to do. Yeah, this one is more like what to do if. So yeah, I guess it's a good question. To speak up to this. So I'm keeping it. Yep, Mark. I was going to say we've talked around it a few times and different discussions so it sounds like it's something everyone's thinking of. And so, yeah, we should, you know, make sure it's included in the other discussions at least. Alright, thank you will add it to the list and you know there's no commitment to to we could down the line look at some of these issues and see you know what forget it and you know it just means that for a formal process we just add those to the to the decision log. So let's move forward and next calls, we look at them and hopefully offline as well between calls and try to make progress so that we can eventually get to formal resolution for everyone of those. And, you know, one resolution is it can be to drop it. So let's add it. I don't know what to do with Gary's point. I feel like this is a question for Brian but Yeah, probably probably with a longer conversation we have in the next couple of minutes. Yeah, definitely will take it off. Yeah, so my interpretation of Gary's point was sort of on, you know, and Gary, you know, correct me if I'm just way off base here which is entirely possible. It's about sort of how much we want to cultivate the garden right so Apache is is kind of like, you know, a wild meadow, if we want to use the analogy right you know sort of like a lot of things can grow. You know, and maybe there's not as much gardening. And I, you know, to continue the metaphor I guess it's a question of how much gardening, you know, we want to happen in hyper ledger. And this, you know, this question has existed since obviously the very beginning of the project. Right. Is that a correct understanding Gary. Yeah, I think so I think that's a good. I think it's really a good starting point right it's really do we go back to kind of that sort of mission right and I guess where I was really getting at is, there's a lot of suggestions here. And, but without a context or kind of, you know, mission statement to align them with it becomes very difficult right to make the kind of choices right because you could see a clear path. In my head I can see a clear path through some of the decisions, if they're tied to if they're rooted in in some core principle. And I think we're trying to deviate from our core principle sometimes and that's where the anyway that's that's the take yeah. That's the question about, you know, what's our core principles have they changed. We seem to, you know, we definitely I mean hyper ledger went through some evolution for sure, you know, and I don't know. All right, we're almost out of time. You know, just quickly going back to the agenda. I think we're done for the list of questions right. No, not with the questions but sorry to, I mean, I was just sorry to Bobby for not bringing that topic up. I know you wanted to present about learning working groups presentation and we should have put that as a first topic here. Thank you. No worries. But so let's be clear about this so we have invited all the groups and Tracy took the action to item to reach out to all the six and all to to invite them to the TSE. If anybody wants time, they should just let me know or add it to the agenda is better to communicate to me so I know what to expect. So Bobby, the invitation is open and let me know when you want to do it and we'll just schedule it. Great. Thank you. I will reach out. Thank you. So, I just wanted to point out the rest of the agenda so we didn't hear back from Darwin is not here. I don't know what those items where the other ones are mostly for me, you know, so I don't want them to fall off the face of Earth. And so I just want to keep those doesn't necessarily mean I expect us to discuss any of those other points. I think, you know, allowing new projects and the hyperledger is this question we've talked about, you know, do we have gaps? What do we do about them. And the other one is the working group responsibilities. I didn't know if actually we want, we still have to do more than we have done with the decision to invite working groups to come to the TSE and present. So, but this is what to me this is about. We can talk about this next week. We'll have a call next week and hopefully we have put there, you know, all these issues in shape and we can stop tackling them. Thank you very much for joining today. Have a good week. Talk to you next week.