 Great. It's Matt. Yeah. Okay. Let's draw a joint. So okay, the recording has started. Hello, everyone. Welcome to the TSC call. So this is a public call. Everybody's welcome to join and contribute. There's two requirements to doing so. The first one is to be aware and live by the antitrust policy notice or the antitrust policy, the notice of which is currently displayed if you're online. This is to keep us out of trouble. And then the other piece is the code of conduct, which you should all know and live by, which basically requires we all live like decent human beings and don't yell at each other. I'm joking, but it's not. We had to have those in place because obviously some people couldn't behave. So I assume everybody is aware and we can proceed. So first, I wanted to start with highlighting something that went through the mailing list, maybe a bit quickly. And just so that everybody is on par and okay with the plan, the current plan is to not have calls starting from December 17th to January 7th included. Okay. And to be honest, this December 17, I was, you know, I could imagine we have one. It's still early enough. We'll see if we need one. As you've seen, I literally cancel those calls anyway when we don't have, when I feel like we don't have enough material to make it worthwhile for everybody to dedicate a whole hour. And so this is the way we've been functioning for operating for over a year and it seemed to work well. And so I will continue doing so. If there was really something important, I could imagine we say, hey, let's meet on December 17th anyway. But if not, well, we'll cancel it. And quickly the first week of January has been spending time on the holidays and there's not much to talk about. So it's good to give people some time to get back to work before we start meeting again. So I assume everybody's okay with that. If anybody has really a problem over this, let me know. But I would think it's reasonable. So Rai was the first one to bring it up and I agree. And so he went ahead and canceled the call. But I want to make sure everybody understands the kind of the background. Is there any other announcements anyone wants to make? We should probably also note that we're not meeting next week. Yes. Yeah, that's correct. I did cancel that meeting. What should have sent an email to the TOC list? But you're right. No, you're absolutely right, Tracy. I meant to highlight that too. It's Thanksgiving in the US and a lot of people are taking the week off or at least a few days. So we'll definitely not meet next week. But to me, it's kind of like you might see we almost meet every other week. So I felt like, well, this is kind of a natural base anyway. So shouldn't be too disrupting. Anything else? Thank you, Tracy, for bringing that up. Okay, if nothing, then let's move to the quarterly reports. We had three reports submitted. And I have to apologize again to the indie folks who had submitted the report. And somehow I didn't normally I get like notification. I catch those pretty early on. I'm always on the lookout for those reports. But somehow I missed that one. And I complained about not having it on the mailing list, which is, you know, embarrassingly enough, I realized just after I send the email, but here's the report. So we had indie transact and cello. For both transact and cello, there were some questions asked that have not been addressed on the page. So I hope if there's anybody from transact on the call, I know Andrea is not on, but it'd be nice to get some answers. And there is the thing that, you know, we decided last week to have the reports highlight insights information from the dashboards. And while we, I mean, we can't expect the project to start doing it right away, but I pointed it out to transact with people. And I saw Ryan went ahead and did the same for cello. And so this is something we'll have to keep asking explicitly for the projects to do. I, you know, I know that, you know, most people just copy the previous report and they did it. But the problem is, you don't, you know, so we need to make sure they insert it at least once. And then we can hope that they will carry it on forward from then on. But so is there, I mean, I didn't see anything in the reports that call for attention or discussion from any action from the TSE, but is there anything from the TSE members, you know, that you guys want to bring up or ask about regarding those reports, right? We have a quite crude today. So I take it that no, that's good. If you haven't reviewed them yet, please do so. I saw there are a few names that have not checked their box yet. So that tells me they have another chance to get there. But please do that when you can. All right. So let's move on to the discussion part of the agenda then. First, I wanted to talk about a topic that kind of came up last week when the, oh, the week before the last call, I should say, when we were talking about the working groups and getting them closer to the TSE, increasing relationships so that we would have more insight about what's going on in the working groups. And then that discussion eventually led to the idea that maybe we could invite projects to come and present to the TSE beyond just doing those quarterly reports, they could be given the opportunity. I don't think we've talked about requiring projects to do that, but we could provide that as an opportunity for the projects to come and present, you know, at some, I mean, it doesn't have to be on a regular basis or anything. It's when they feel it would be interesting to highlight what's going on in their projects. And then we could therefore in the TSE be a bit more knowledgeable about some of the deeper insights into what's going on in the projects. Quite frankly, you know, we used to have Hackfest at the very beginning of Hyperledger, we had them like it seemed like every other month. And then once a quarter, and then they eventually kind of disappeared. And of course, the COVID that basically impossible. And so I always feel like we missed a lot in having those disappear because they were a time when I, for one, you know, was able to catch up on what was going on in some of the other projects. And to an extent even the project that I focused most on. And so I see this as a possibility to kind of, you know, compensate for this lack of opportunity to network with the other projects. And so the Hackfest project jumped on to the opportunity and quickly said, hey, we'd be interested in presenting the TSE. And we have tentatively schedule for the beginning of January. So that would be January 14th. Let's remember correctly. And so, you know, we talked about doing this. So, and then there was the governing board actually met on Monday this week. And at the end of which we talked about the SIGs. And Mark actually, I like the way he described it, is like, you know, the SIGs is kind of interesting. It's a bit like the family on the other side of town you don't really know. And he was pointing out that the relationship with the TSE is very weak. And, you know, for different reasons, we don't have to go back into the SIGs are not reporting to the TSE. They're reporting directly to the governing board. And because of that, we don't have much relationship with them. And so he was saying, maybe we could also have the SIGs kind of, you know, come to the TSE and kind of organize some cross collaboration, at least in information sharing. So we would have a better understanding of what's going on in the SIG. So all of this brought me to these ideas like, well, okay, so it all comes down to this idea that maybe we should invite all these different groups, the projects, the working groups, and therefore the SIGs to have this opportunity to come at their leisure to the TSE and give some kind of presentation of what's going on in their world. So I wanted to, you know, that's the introduction. And I wanted to get a sense of where people feel about this. Hi Arno, it's Bobby. Excuse me. I think it's, I really appreciate that idea, because a lot of the working groups and special interest groups, when they acquire great community resources and presentations, I know they would love to share them. But since we used to have it on a calendar and no longer do, they don't feel like anyone, they don't have a venue for it. So I think the idea of maybe putting out a calendar with blank spots for five minute presentations at the TSE calls and sending it out to the community might be a great idea. And you'd be surprised how many people sign up. So I mean, you say five minutes, to be honest, it's shorter than I would expect. But you know, I think that could also be, you know, the leisure of the group to decide how much time they want to, you know, they need to present what's going on. I could talk about the learning materials working group for hours. Okay, but maybe there's a middle ground that's reasonable. No, but seriously, though, you know, for me at least, and again, I'd be happy to hear from the others, you know, I feel like when it comes to the projects in particular, you know, I want to know a little bit more of the details. And we already get some high level reports from the recorded report. And I want to go a bit beyond that, right? So I think that would require a bit more than five minutes, maybe 20 minutes or so. Daniela has her hand raised. Sure. So just a little bit more details around the conversation that we did have at the board level, just to share with everyone. We do staff produces monthly reports of the special interest groups, highlighting presentations that we think is valuable for the community, highlighting opportunities for our member community to get involved in the special interest groups, and also highlighting the actual code work. There is some good, you know, work that is has moved into labs out from within the SIGs, as well as, you know, and more work wants to come from the SIGs to labs and to projects, etc. So one of the things I recommended as part of that discussion to Mark and Arnaud was to, you know, to, we have a quarterly call with the chairs, and we would like somebody from the TSC to come in and talk to them. The each individual SIGs writes reports. They do two reports, bi-annual reports a year about the work that they're doing and what they plan on doing for next year. So, you know, having the TSC read through those would be valuable as well. I know we're all very busy. And then, you know, to the same point of the working groups, you know, having the chairs of the SIGs would love to come and present the work and what they're seeing in the market and bring to the projects and the working groups opportunities for the devs to work on SIG-related content. So, you know, I think I don't know if that's required to emotion or whatever it is, but I think you will get support. But I would recommend or I would like to request that somebody from the TSC come and speak to the chairs and kick that off. All right. Thank you. So Tracy, you're next. Yeah. So, I was just going to say, I think sharing those reports with the TSC would be great, Daniela. And I'd also be willing to maybe add a responsibility to the vice chair role of the TSC to, you know, be a conduit, if you will, to the SIGs and join you in your meetings, Daniela. Oh, I hear you volunteering for the job. You heard me volunteering, yes. Very good. Works for me. Yeah, works for us too. Thank you, Tracy. No, just let me know. Hopefully it's in the calendar. We'll see what the recurring schedule looks like. Okay, but I wanted to hear also from the other members of the TSC with the, you know, I mean, how they feel about this whole idea and, you know, do they think that would be a waste of bandwidth for the TSC or do they think this would be valuable? Maybe nobody wants to say this is a bad idea. Grace, or Arun first, sorry. Hey, Arun. This is a great idea. I definitely don't think it's a waste of time. In fact, I was waiting for these kind of discussions to kickstart and the TSC meetings. So I would be very happy to welcome such presentation happening in TSC. So maybe we can, I don't know, if we leave it to the project presenters, then I just worry that it may never happen or for a few of the projects, if not all of them. So do we need to just bring in some structure around saying that, hey, if we release something, do we want to bring them in to this TSC meeting and then speak about those releases or some structure around it, if not release? Yeah, I'm a bit, you know, I'm not too sure I want to go as far as mandating something like this, but I do think, you know, we can in the background definitely go and nudge them and then kind of, you know, try to lobby for them to come if their projects we feel, you know, under the radar and we probably would, you know, benefit from having them come. So I think, at least as a first step, I'm happy to make that on a voluntary basis and then see how that goes. If that's okay with you. Okay, sounds good. Grace? Yeah, good morning. First of all, thanks Tracy for volunteering. I think that's a great idea. I think it's a great idea overall. I definitely think it's great to leverage whatever we have. So we're not asking too much of the sags and that they're, you know, what they're producing for the board or other reports can be leveraged to us. And I think that's a great idea. The one thing that I would maybe challenge us to do as a part of it is not just have them come and present us and and us give them feedback, but then also just give us feedback. So if it's, you know, Q&A at the end of each session or or a follow up or or a form or I'm not sure, I think that would be a really valuable use of time to be able to kind of get their thoughts and feedback and and what they want out of us too. If, you know, they come back in six months, you know, what would be kind of a better way for us to do it or or, you know, what they're looking for guidance from us. All right, thank you. Nathan? There's a few things that I think are important when we try to get people to come to present to TSC meeting. This is one of our best chances for convincing people in other projects who don't hear about our requirements or hear about what's most important to, you know, the next release of our particular coding effort to understand where we're coming from and what's different about how we see the world. And that's a good chance for us to kind of get some common culture and common direction amongst all the different projects at Hyperledger. So emphasizing, you know, what are the problems you're trying to solve and how how should other projects at Hyperledger be thinking about or how could they help with these problems? I think it's part of what we want to emphasize here. In the past, we've had some presentations that were really focused on a particular commercial solution or a particular, you know, kind of I'm in the middle of these particular type of RFP that weren't as applicable to all the projects. And the more we can get the technical steering committee to focus on kind of technical challenges or what's cool that's next that we should all be, you know, putting on our reading list, I think the better off and the better the debate will be because we really want to make these an opportunity for all the maintainers to say, you know, I really wish I was at that call. Maybe I should go find the recording. And if we can do that, that I will hopefully raise the bar for participating at TSC meetings and encourage more cross project collaboration. Yes, well said. I agree completely with that. And I think, you know, some of these I feel like can relate to another agenda item, which, you know, I don't know if we'll get to today, but there was this discussion last week, last call, about, you know, what are the projects we're missing? What are the gaps in the stacks we have? And obviously, I think presentation from groups like the six could help us identify some of those gaps and, you know, inform us on what the challenges are. And maybe then we will be more, you know, informed and equipped to kind of highlight areas where we would welcome new projects. But I agree with you that those things need to be not appropriately based on any of this like commercial oriented. That's a bit scary. Mark. Hi. So I'm obviously, you know, a big fan of trying to work as peers with the SIGs and would almost, you know, challenge members of the TSC in the community to go, you know, see what SIGs are out there and maybe attend a call, see what they're doing. But I think, you know, in order to grow Hyperledger, we we need to, you know, work more with them. Also a big fan of, since we don't have the HackFest and things like that right now, trying to get more cross-project things going. So again, that could be having projects come and present at the TSC or a maintainer's call or something. I'm not a maintainer, so I don't know if we have regular maintainer calls across all projects. No, we don't. You know, I don't know if that would be something that would be worth trying to get going to. Just to try to build more cross-project, cross-hyperledger things. But so I think if we if we go there, we could definitely advertise those calls to, you know, a broader community, including the maintainers and like as Nick and said earlier, right? If this becomes interesting to the maintainers, they feel like, okay, I'm getting something interesting out of this beyond, you know, the typical stuff we talk about, like TSC election rules and whatnot, which I'm sure does not interest them much. You know, I think there's an opportunity for the TSC calls to become more broadly attended. So I think we would benefit from all of that. All right. Anybody else? We didn't need to have a recount or anything this year. So I think, you know, the election rules might be set. Oh, I wouldn't say that. Wait for next year, you'll see. Hey, next year should be even smoother. Daniel. So one thought that crossed my mind, how much of this lack of cross-project communication is happening because we're not meeting in conferences anymore? Because we'd have a maintainer conference, we would have a the hyperledger summit and the hyperledger global forum. Those all look to be not in person again this year. Was a lot of this stuff usually happening in those venues? Well, we did have the hackfest before, which was the primary venue for these kind of conversations to go on. And then they kind of disappeared. And we had other types of events. And then eventually we had one was it contributors, maintainers meeting. That's two years ago, I think, which was very good. But you know, and that was it. Then we had COVID. That stopped everything. Yeah, we had three hackfests, which we're really more about trying to recruit new developers in. Those are the ones we did in Hong Kong and Brazil and Moscow. And then that was last year, we would have looked to do them this year, but COVID put the kibosh on that. And then the maintainer summit, I'm pretty sure was early 2019. And we thought we'd do another one this year, but that was the stuff. Yeah, I do think Dana's point is solid that not seeing each other at conferences means we have to be more structured in how we do these kind of sharing. So yeah, this is certainly a great venue for that at the TSE. I'll answer Dana's question. I'll say yes, that sort of both Ursa and Cactus were started as a result of conversations or work at these hyperledger collaboration events. Ursa notably in the famous or infamous Portugal school bus. Angelo. Yeah, thank you. Actually, I must admit, I was thinking about this. In hyperledger, there are different blockchains that to some extent are also competitors. They are backed by different companies. They do different things. I was more wondering, shall we foster a more tough competition between these blockchain systems? We want the best of all. Do we care that we have so many blockchain systems? Or is just important the number? Or do we want the good one? And then fostering maybe competition would be better, because I'm not sure also what it means exactly that we make this collaboration between different blockchain projects. I can understand the libraries like Ursa, and then we might push to say maybe more projects should embrace Ursa, which is also not so easy to push, but I would prefer more a tougher competition. So make them fight more. I mean, the show that you are the best of all, I don't know how to say. All right, thank you. Daniel is back on. Yeah, I don't think focusing on the DLT is necessarily whether thinning or growing the ranks is where we need to worry about growth. I think we need to move further at the stack and talk about dev tooling and talk about libraries that will help end users who aren't necessarily blockchain mavens create applications that will adapt to whatever blockchain is on the back. I mean, if we consider this to be databases, how many people write straight SQL into the database? Not too many. Some of them still do. But a lot of the stuff that gets the most important tooling is stuff that builds on top of it. I mean, if we're talking about how do we get the new projects, I think if we are meeting together, I think there'd be a lot more interest in getting these layer two and these developer tooling type projects together because I think that's really, if we're going to be a technical steering committee, my opinion is that's where the real growth and where the real onboarding can happen and getting new people into the area rather than having us fight amongst ourselves. Interesting point. Thank you. Angelo, you need to put your hand down. Gary. Hey, so I think, so I agree mostly with, I will agree with at least half of what Dana said, but not that I don't disagree with the other half. I think, yeah, I think you would agree, right? Partially, a ship is sailed in terms of like, you know, the platforms that are out there. But I think, and again, I don't know if I've ever said on this call, but I think that it's crazy if anybody believes that one technology will ever solve every distributed budget technology problem out there. People can agree or disagree with that, but it's a fact. You can't have your cake and eat it too. I think it'd be interesting to look at, I'll still reflect back on maybe we talked about this one time before is what's always been missing and maybe because it comes in to the products or whatever is we don't seem to have this thing of people coming in with, again, like use cases, identifying gaps. And then maybe partially to Angelo's point, like maybe each platform can compete to, I don't know, to see who implements it best or respond to it or whatever. But like, what are gaps that people see, like that are that are constituents in the community? See, right? I, you know, people maybe filed defects against the product, maybe actually feed it for a project or whatever. But we've just never, like even the architectural working groups, no offense to that, like just never really seen a set of like requirements or what's next or what's missing. Like, and maybe we've never asked for some people or maybe we've never, we don't have a place for people to put them. I'm not sure, but I don't know if I'm making sense. But that like seems to me, right? So sort of on the lines of what Dana was saying to a degree of like, what's new stuff? What's missing? What can facilitate and make things easier for people? Or what advanced idea is somebody looking for? Which again, might, might help and say, Hey, you know what, we all want to solve this XYZ problem. We believe that at a base level, it's crypto. So let's get some of the base crypto in Ursa. And then it's up to other people on how they consume it. But we don't kind of have that trickle in from what's the external needs of our community. Very interesting. Thank you, Mark. Yeah, I just spammed everybody's TSC inbox. Hopefully it's not spam, but the telecom say get about an hour and a half is going to have a talk on using fabric for 5G network. I know I'm interested in it. I thought maybe other people would since we're talking about SIGS, it may be a good chance to just hop on a SIG call and see what they're doing. Yeah, but I don't know, just quickly to say that I agree with what Gary said, we need more challenges and we don't need to tell ourselves how beautiful we are. I mean, I really show that you have to, I want to say this to all the projects, all the blockchains projects show that you can do something that others cannot, cannot, cannot do even aggressively. I mean, we are here, you are here to show that you have capabilities, that this blockchain system can do something that can cover things that have not been covered before. So that's for me, without saying, I mean, without saying this as personally, but I mean, the point of hyper ledger again to the root, we want to make this blockchain for enterprise something real that really is solving problems. So not just for fun. We are serious people, we don't do things just for fun, right? Anyway, thank you. I for one, do actually like to, you know, talk to, tell myself how beautiful I am. So, but I just throw that out there. Again, you have beautiful, if you want, I can tell you. There are exceptions to every rule. That's right. All right. So I think that's good guys. And, you know, so trying to get back to the agenda, I mean, so I want to close the, I think we kind of touch on two points at the same time, which is fine. It's, I may have led to this because I did talk about, you know, this notion of identifying new projects and so on. And so I think a lot of the comments that have been made are very much in that line. And so it seems like there is general agreement that will benefit from more of those discussions anyway. So back to the first point, I only hear people agreeing to this idea of having, you know, inviting groups of all kinds to come and talk to the TSE present. I don't think we need to have a formal approval for this. If anybody feels that we do, please let me know. I think for now, I take it that there is agreement that, you know, we welcome this kind of presentations. And then we have Tracy who already volunteered to go ahead and sync up with the SIGs. And so I think we can start from there and, you know, I'll work with her on the scheduling and make sure that we can keep things. I don't think, you know, we don't want to overwhelm the calls with a whole bunch of presentation either. But as the, you know, we can kind of fill up the calendars in the months to come with, you know, a few presentations here and there. So I think that would be a good thing. So if everybody's okay with that, that would be my plan. Arun? Hey, quick question. So do we get a report from SIGs just like the projects or even if it is not for the CSE or a place where TSE can look into, but I would like to subscribe to those things as well. So that's what Daniela was talking about. There are reports being made by the staff to the governing board. And I think the idea is they will share that with us so we can see those. That is correct. And there's also the bi-annual reports are on the wiki. If you just go to the special interest group page and then go to bi-annual reports, you'll see them backed through Q1 of 2019. Thank you. So if you need help finding this, we can help you reach out to her. I'll put it on the chat. Yeah, thank you. All right. So if we have an agreement on that plan, then I think we can move forward. There is actually just one more item that I wanted to really spend a bit of time on, which is the next one on the agenda. It has to do with this rollover projects issue. So for those who may not remember when we started on the previous TSC, so an issue came up. The idea was, well, we have this umbrella, the greenhouse with all these different projects. And the reality is, so I think there were two problems that got highlighted. The greenhouse is confusing to at least newcomers because there are projects that are all presented on the same level when they are not. There are dependencies between the projects that do not get surfaced and that are not necessarily easy to find. And we often hear from the community at large that it's hard to figure out what's doing what, what projects relate to what. And so there is this problem. And the other was, well, when we look at some of the projects that aimed, I mean, one of the reasons that some of the projects got approved as top level projects was in the premise of a charter they put together and presented to the TSC that said, we will be platform neutral and support different platforms, like frameworks. And then when we look a few years later, and the period of time doesn't really matter, it's like some time later, but there's a fairly significant amount of time as passed by. And we look back and we say, but wait, you never really jumped the gap of going from being based on a single framework to being really platform neutral and supporting several platforms. And so some people felt, well, we should revisit those projects after a while. And so we should, if it's appropriate, recognize those projects didn't live up to the expectation. And it's, I don't mean that in a negative way because it's not necessarily anybody's fault. And we've seen this with Composer, for instance, at the very beginning, for those who don't know we have this project that's now archived and retired. But it meant all the people involved meant really well and they wanted to support several frameworks. It just never happened. And they were fabric based and that was it. And so in that light, we would have said, okay, maybe Composer, we should just admit it's a fabric related project should be part of fabric and stop pretending it's a top level project that is platform neutral. And so those two ideas led us to look into this idea of possibly cleaning up the greenhouse by saying some projects that are currently at the top level should be rolled over into other projects with which they have a strong dependency. And there are pros and cons, and there was a lot of debate already, but you know, some people felt this was an attack against some of the top level projects. And but at the same time, when I asked every time, should we kill this issue? Should we bring it, keep working on it, try to find an answer? There was enough people saying, yes, this is an important issue, we should definitely work on it, that we have kept it alive. And so now we have the new TSE, and our room for one was, you know, interested in this issue, and said, I'm happy to look into it and try to recap on where we are and make a proposal on how we could possibly move forward. So that's kind of the intro and background. So there is the initial, so from the agenda, you have two links. The first one is the initial issue as it was raised, and I had put a proposal together, which didn't really fly. We never really got to vote on it anything, we just had a few discussions. And then, and then there's the summary and RFC, which Arul put together, and I will let him talk about this, but go ahead, Arul, forward yours. Thanks Arun. So I felt this topic was interesting, and it's important for TSE to close it as soon as possible, because this I saw that there was an email chain, which Arun was talking about, which was not very pleasant. And as that email thread is being watched over by multiple people, not just by people who are interested right now, maybe the people who may see those email threads in future. And another thing is, if those kind of questions are coming up, then there's definitely some gap which we have missed earlier, maybe because we overlooked into those aspects, or we did not anticipate those things to happen early on in the stages. So before I start on talking about this proposal or this summary and RFC, I'd like to quickly thank all the previous TSE members on the idea of putting together everything in a text format. All the information which I wanted were just a search away, the keyword search away on the conference. So talking about this, I saw that there was a proposal from a working group, which was approved by the TSE. And right now the document can be found in the archives. That's about the project lifecycle. Or there we can find that the decision were made for any project to be in one of these stages. And I have included two extra stages, looking into some of the other discussions happening within the TSE meetings. And those two are lab and inactive, even though they are not formally proposed, I'm just putting them over there. So that's about that first thing. Now, one thing which was probably lacking over here, or which was kind of confusing is that any project could be under incubation or active forever. And this is also one of the questions which Hart had, has commented on this page, asking what if a project is always an incubation. They get the benefits of being a top-level project within Hyperledger umbrella. They get to promote their project, speak about their project, they get their own. I don't really know what exact list of benefits each project get, but I'm assuming these are the kind of benefits which they all get. So he also brought up the topic that what if they stay in incubation forever and then never try to be an active project. So that's an open. I have put together two opens which I found were open, but this also is an interesting fact that we need projects to push themselves to become more active and get more user base or do develop features which would benefit community at a large. And if we can scroll down a bit, now, having seen those things, the two open which we had, one was so there was a proposal, as I said, which was on having the project lifecycle over there. One of the topic was if we should have sub-projects and fewer top-level projects, and that decision was abandoned. And thanks, Arnaud, I saw your reply. So it was abandoned because of a specific reason, right? Can you? Yeah, so we had quite a bit of back and forth on this issue of the overall structure of the projects with the notion that we would have officially recognized projects that are under some other projects. So there's like this hierarchy of projects. But, you know, we eventually always end up saying, no, let's not do this too complicated. So there are projects like Fabric where you have different sub-projects within them, but from the TSC point of view, there is only Fabric. The rest is left to the Fabric project to deal with. And so it's true for all the other projects. So, and from that point of view, if we were to roll over, you know, a project into another one, effectively it would disappear from the TSC point of view because it wouldn't be on the greenhouse at the top level, and it would become consumed in a way by the other projects. So we only have one level of projects recognized with the TSC what it is. Got it. Thanks. So this was one of the conflicting thought of why the rollover of project is now, again, reappearing as a separate proposal. Ideally, so I would, okay, I may start telling about this. I would ideally consider this rollover of project to be one of the amendments to the project lifecycle proposal, which already occurred. And if we have to look into doing anything with the current set of projects, I think we should not try to do that, rather try to fix up these missing points from the earlier decision log or probably the proposals. And then, I mean, based on those device rules, we should then apply them to the current projects. Now, there are challenges with current projects as I'm not already summarized them very well. I'll not again speak about them to save the time. Other open question, which was kind of conflicting and why that email thread expanded to that was because probably there were some topics about like getting benefits. I guess I touched upon this briefly. Now, when it comes to security audits, even though that project is part of like another project, even if we roll over a project into another project, that will still continue to happen by the hyperledger. So I don't consider that to be an additional effort, which is happening. Now, the thing which is happening in addition to like without roll over is the confusion part or how do we help community understand what projects are meant to be doing what things. So this is where there is one proposal of restructuring how we look into this the hyperledger umbrella of projects. Do we do we continue the way we are looking at currently? Do we do we consider a project, for example, in under tool section, a separate from the one which is put under the core protocol develop section? Do we consider a library separate from the tools? So that's one question which needs to be discussed, which is still an open in this proposal, but we can come in and discuss on those on that topic as well. Not how do you want me to talk about this because I had put like elaborative five proposals. Do we pick one proposal at a time discuss? No, but so I obviously we would take too much time to go through every proposal. But what I was hoping you just kind of give an introduction to what's there. And obviously we're not going to discuss every one of them. What I want to make sure is that by the end of this call we have 10 minutes left, you know, everybody understand what we're trying to do and what's there so that they can do their homework and go into the details offline. And we already had some comments that I think we can discuss as to whether this is, you know, indeed addressing the problem. Well, I want to say Tracy pointed out what is exactly the problem. I'd like to say that as well. It's hard to look at these proposals without knowing what is the outcome that we're trying to get to. If it's simply about confusion, if it's simply about confusion, then like talking about rollover, I don't know is an appropriate starting point for this discussion. First, we should just understand what is the what would the outcome actually look like based on the current projects that are in the screen house. So maybe if we if we knew what it should look like as a result, then we can understand what proposals would get us there. Yeah, one question I had for you, Arun, is when you have this list of proposals, do you mean that these are alternatives or are they complementary? I wasn't sure about that. So again, let me rephrase the way I look into this. So I look into this proposal as a missing part to our overall objective of a project lifecycle. Even the projects which are, let's say, have their own charter and then they propose their initial objectives and then they were made as top level projects. But do we have already a mechanism to measure if they are following that charter for for us to make any decisions? I don't see anything, any process currently defined for that. So that's an open if we make an if we make a decision right now for any of the project, irrespective of whether there's when we make a decision or not, that that would be incomplete for for us, right? We need to have a process defined, we should not be saying, okay, so in 2020, we discussed about the specific project. And when we took this decision. So now in 2021, I see similar thing happening for some other project. And let's bring it up to TAC, let's see some other alternative for this project. I don't want those things to happen. Since we identified that, I mean, if the reason that this topic is being discussed is showing that there's a gap. So I want to fill in that gap before we make any before we take any actions. Alright, thank you. And I want to make everybody at ease. I mean, the you know, this is attached to the rollover issue. This is how it first came up. I'm happy for us to, you know, kill this, close it, morph it into whatever is makes sense, right? So at this point, everything is on the table. I can't hear you. Sorry, it was clicking for the mute button. So I think one of the things that this discussion has brought up is that people think the greenhouse diagram is confusing. Could one potential solution that maybe doesn't solve all our problems but makes something better as if we asked the marketing committee to try to help us create more intuitive greenhouse diagram. That seems like something very simple to do in relatively low effort that might solve some of our messaging issues. Alright, thank you. Tracy. Yeah, so I agree, Hart. I think if we're talking about just removing confusion, then this is probably something that we shouldn't be taking any further. But then, you know, you made the other comment in the document about kind of moving projects through the lifecycle. So what is the incentive for making things move from incubation to active and the major challenges that exist in doing that? And I feel like, you know, we originally started this conversation around moving projects from incubation slash active to deprecated and or combining projects. Right? So I feel like we've got now three different things that we have to decide what it is that we're going to solve and each of those three different things that we're talking about will be solved in different ways, right? So if it's the reduced confusion, then it's probably a marketing committee sort of issue to deal with, right? If it's about moving things to deprecated or combining projects, I personally say drop that because that is seems to be a very short fuse there in the discussions that we've seen already. And if it's moving things from incubation to active, then let's have that discussion of what the best path is to making that happen. All right. Thank you, Tracy. Now to say, I mean, Tracy has been pretty consistent about the fact that, you know, she felt the problem was not well stated. And, you know, when I've asked is in the past, how the TSC felt about this issue and whether we should keep trying to address it, she has pretty much expressed that problem that she felt it wasn't so clear what the goal was. So I give you credit for consistency. And so, you know, I want to restate. I mean, I think it's a very good conversation. I think there is no disagreement that there are some issues. And I don't want us to be cornered by the way it was initially framed with this notion of roll over. I'm happy to step back and say, okay, forget that. What are the problems we feel like are worth for the TSC to tackle? Arun, go ahead. Yes. So that was a good point that we we are looking at multiple issues through this one proposal. But that was my intention as well that we close those gaps which are being shown up because of this discussion. Maybe this proposal itself needs to be dropped. But the topics which we are bringing up through this should be fixed. For example, that in moving from incubation to active, I guess one way is one way to look at that one one proposal would be also to combine that with I know we have been talking about project maturity matrix. So associate some benefits on having those, let's say we bring in badges. And when the project is in incubation, it should have attained, let's say XYZ badges, those three, then we call the project to be in incubation. And for it to move to active status, we expect that project to gain further badges. And this badging criteria again, this is a separate proposal, but I'm just giving you a possible idea. So this can be brought up to TSC upon every major release. And then we can re review or re look into the status of those projects at those major releases to know if the project still meets the badging criteria. So that time we then come up with, okay, this project initially agreed for doing something that according to what it's put in the charter, but they're not currently following because their badging criteria is number of badges, which they have is reducing. They don't meet these criteria. I think that's where again, this would come up. Until then, just this as a topic would not stand on its own. So if you haven't already read, then I would request you to read through those five proposals. I think that's mixing multiple aspects into it. Yeah. So I think this is going to be, I agree, people should be familiar with the points you're touching on. But I think our next step should really try to be to tease those out and try to figure out the different issues we're facing in this so that we can address them independently. At this point, I'm tempted to say, let's withdraw the rollover project idea and say, okay, let's do restart. And by the way, there is one issue that you talked about which rang a bell to me because if you look at the rollover project proposal, there's a comment from Dan Middleton who is no longer on the TSE but was there and even was cheering for a while. And his comment was, well, if there's a problem with the charter that projects are deviating or not beating the charter, maybe instead of looking at one particular aspect, which is like dependency, we should look at that. And you touched on that as well, Arun, about this notion of, should we have a mechanism where we can review projects against their charter? And with that, prejudging what the outcome might be, because in some case we might say, yeah, it has deviated, but that's the right thing to do. And then it would be more like an acknowledgement of the deviation and rechartering some sort of activity. But it seems to me it would be a good healthy exercise to have this kind of introspection for the projects. But that would be independent from the status and all that. So I think that could be an issue independently from the others we could get out of there and say, okay, how do we do charter reviews kind of thing? Any other comments? We're out of time, but I'm happy with where we landed for now. We will continue the discussion, obviously. If anybody has an urge to say anything more or disagreeing widely with what I said. All right, if not, we are out of time. So thank you all for joining. Have a happy Thanksgiving for those of you who are in the U.S.