 Sounds good. All right. So I see Alha, Chris, Dan, Hart, and Nathan. Any of the other TSC members joined yet? Hi, Todd. This is Greg. Can you hear me? Hey, Greg. Welcome. Hi, sir. I was struggling with the new mute. No worries. And it looks like mix here now as well. So we are at quorum. Awesome. Okay. Morning, everybody. Good afternoon. Good evening, wherever you are. Okay, so for today's agenda, we have our usual discussion of the upcoming hack fest. Hopefully that can be brief. A reminder about the internship program. Actually, can we, we will move the discussion of leaving incubation to the end. Okay. So we have some inquiry updates from requirements, and then from cello. We have project proposal renewal from caliper as recommended from the out of the performance and scaling working group. So we can finalize our discussion about whether or not you need to be out of incubate, pardon me, out of incubation before you hit 1.0. So any other items for the agenda, it looks pretty packed. Okay. So just very briefly in terms of the hack fest planning, I think there's a question about whether or not we want to have a hack fest pride at Amsterdam and I just don't see how we can squeeze one in at this point. Todd, do we have any even any offers. No, before we did that, I think we wanted to see if there was a hunger for it. Yeah. I just think quarterly, you know, this is sort of the direction we were heading in there. And we had our first quarter and technically June is still second quarter so I think we should stick with that. Okay. And then just a reminder again the registration is up for June in Amsterdam hosted by our friends at ABNN row. And a draft agenda and I think again the thinking is we'd like to, you know, really sort of get the agenda fleshed out beforehand so people know what they're doing so I think we'll spend some cycles in May to try and lock that down. The internship program is up and accepting applications so you know we've got some really good proposals out there so if you know of any student interns that would like to work with us this summer please get those up and get them to register. Okay. Quarterly update so requirements. What do we have on to do the requirements work group? Should be Clive I believe right Tracy. That's right. Okay so I'm not hearing anything so let's do then cellos. I think Tong is on. Let's do cello first and give Clive if he comes on. Thanks Chris. Yeah, I assume you guys have the link right you can open up should I share my screen instead. The link is in the rocket chat. Right right I mean everybody else can just go ahead click on that link and so you can see the cello project update page. I'll go over this very quickly. So cello project is very the community is very active. Things mostly happen on the rocket chat cello channel. We normally have a lot of questions. Ask how to use the project. Sometimes we have some generic questions regarding fabric as well. I think the maintainers normally respond to those questions very quickly. So that's that's good thing. We also use the channel to discuss new ideas features. So that we can gather some of the requirements or new work items for the project. So we started to have this weekly Friday meeting last week. We feel that it's important to have the cello channel on rocket chat. Also important to actually have, you know, voice conversation. So maintainers and whoever interested in cello can get on the Friday weekly call. So we can hear each other's voice and discuss stuff for the project. Most of the patch set gets reviewed within 24 hours. So we responded to those parts that quickly. That's a good thing. So in terms of issues, we don't have any urgent issues from the project point of view. We are planning to have some kind of like a test test net for the fabric. If the foundation can provide some machines for us. That would be nice. We can set up an older system than other parties can join. So this is more like the playground. So people can start sort of see how things work. New features can be presented. So that's what I'm thinking. If Linux foundation can provide some public facing machines, that would be very nice. So that's sort of like a request. If you want to do that, just use the info channel. And Ryan, Jessica and others will help out. Okay. I'll try that. Thanks. We had the two releases already. We're planning to do the 0.8.0. As soon as fabric get released, we'll release our own as well. Overall activities, I think I pretty much addressed that already. Current plan, ensure the release of 0.8.0. So after this release, we'll plan to integrate fabric composer to a cello. So the idea is that after you run the command, you set up the fabric network. You also have the composer ready to go. So user can basically use the browser to hit the composer start to develop their own business networks. So that's the idea. So we sort of provide like an end to end, you know, as everything set up, you immediately start doing your own business network. So that probably a pretty big item for cello. We also wanted to create some video to help users to understand the project. So we plan to have a little mini series from the like a very basic idea what cello does to some advanced features. We also wanted to update some document so the user can get a user, have a user time to start using the project. We have currently three maintainers to from IBM one from Oracle. So we can cover both North America and either specific areas. We basically practice the common, you know, rules for the open source community. The people contribute most will be nominated as maintainer answer most of the questions we review most of the past set will get nominated. Currently we have 25 contributors. We in the last from last December, I think we have total of 62% merged. That's, I mean I consider that pretty active. So, a lot of cello developers also participate in the local meetup and other events such as a hack fast to promote the project. And help people to use fabric. So, yeah, I think that's the updates I wanted to give to you guys questions. Thanks Tom. Any questions for Tom comments concerns. Yeah, this is Brian Bellendorf. It's great to hear that there were 25 other contributors that you could point to. What do you think we could do to encourage them to be even more active in the project. Well, I think if you users have have more interest in the fabric product, the ego probably come to the channel more often. We have more features we want to add. I think people will contribute. Well, Brian, this is about I think you have a purpose though very well question and it also suitable for all the projects. And from my opinion, there are several things we can improve to encourage more developers. The first one, I guess we need to improve the quality of the documentation to help those new beginners and take and set up the project quickly. And for the second one, I guess we can try to help those very active and active and core developers to help to recognize their contributions. Like in our local meetups, we usually invited those who were active in the code developer to be a speaker in the meetup and to help give tutorials to others. And also certainly I would like to hear people's that's now this question. Yeah, I would echo that. That's the part of reason why I think in the current plan section, we wanted to create some more videos and update documents. That's the area that we wanted to put a bit more focus on to help people to get on the project easily. I think it really applies, you know, sort of to a lot of the tools, I think Brian, getting other people to contribute is largely going to be a function of people that are using it and having it scratch right. And so I think some of it is awareness. Some of it is documentation. Some of it is, you know, we're still sort of early days with some of these things. I think the more people started opting and using these things in an anger, as they say, then they start finding things that they want to improve or fix. And they start getting involved. I wonder if there's a way to widen the audience. Is it still an objective for cello to expand out of fabric and and provide capabilities for the other infrastructure projects and hyper ledger This question for quite a while. Okay. Yeah, exactly. As we have discussed in the hyper ledger summit, I guess cello from its scope is always open to all the hyper ledger blockchain frameworks. Besides fabric, we do have a plan to support like a sawtooth and your heart and we have created the GRI issue. However, I had to, I had to admit that we do not have too much resources on the on the support and your heart projects. But I certainly I would like to see if you can give any advice on that. I will be appreciate Actually, I have much more expertise in fabric. So in a cello just I miss muggling things means try to learning those things. If I will be become a expert on those things then definitely I will contribute. And apart from that, my this is my research area hyper ledger. It will be very helpful for me if we will get any internship program online or offline. So any any means I'm able to come China also. So if you if you would like you would like my work definitely because from Institute to be getting a stipend. So there is no issue regarding means money. So just we want to learn and to work on this hyper ledger product, this cello project. Okay, thanks, our mate. And we are very glad that we can hear from users like you, a new beginner have learned a lot that you think that cello is helpful. And certainly, yeah, we would like to hear more that you want to channel to have improved. Yeah, thanks. Yeah. Okay. Any other comments, questions, suggestions. If not, is, is Clive on for requirements. Okay, I'm not hearing anything. I think then we should move on to the proposal for caliber. Yeah. Yeah, hi, Mark Wagner here. I wanted to say that the caliber folks have been working with the performance scale working group hand in hand, contributing a lot to our efforts as well. And that, you know, we've passed the rough consensus there are no objections to the last two calls to us coming forward with caliber and getting it in as a project. Awesome. So they have the recommendation from the performance and scale working group. And I think the caliber folks will drive you through that work. Now. And I actually have to drop because I have to go to a doctor's appointment, but I think Dan and vipin can handle WG questions. And the caliber folks can handle the caliber work. Super. Thanks. Thanks, Mark. This is Victor on Chris. Victor is not online, but we have a very important developer for categories. How Jun, how Jun should be online. Super. Okay. How Jun are you there. Yeah, yeah, yeah, I'm here. Okay. Also, I want to introduce different who is also from Huawei. He can help to introduce category for the current progress. If you have any technical questions, I can help to answer the question. Steven, are you here. I don't want to hear him, but how'd you want, why don't you just go ahead and, and. Oh, sorry. Sorry. Hello. Can you hear me now? Yes, we can. Thank you. Thank you. Great. Fumble there. Yeah. So thanks. Thanks to Mark for the, for the intro. As, as he said, caliber has spent the last while support. Well, two things. You know, we took the feedback from TSC the last time. And to go work with PSWG on some of the metrics definition. That's, that's produced some good results. And I think there were a couple of other comments. One was on representation and just to try to build some diversity in the community. And we think we've been pretty successful at that. So at the moment, wow way IBM folks from Sora Mitsu, then also the University of Budapest have all been pretty actively involved in caliber. And as always, we'd sort of encourage and welcome as many people as possible to join it. And we did post the latest updated caliber proposal document. I think both in the invite and in rocket chat, if people want to browse through that, the various teams are listed there for representation. And then the other comment that we'd received was just some concerns maybe about the focus of caliber or that people would take it to being in some sense a assessment tool. If you like, or in some way would be used to sort of, you know, bash different projects and say, my block chain is better than your block chain. And I suppose from, from, from our standpoint, certainly for, for a while away and more generally for, for the caliber team, we're not interested in that. It's not our intention that caliber be used as an authoritative tool to benchmark or to provide comparison between different hyperledger projects. We kind of see two users for caliber one, obviously the hyperlaborative projects, framework projects themselves, those dev teams would find caliber useful in their ongoing work for internal uses to, to get relative benchmarks as they're, as they're working through their own road maps and performance improvements. And to some extent for, for other companies or individuals to use it to evaluate the tools. But I think as, as we all appreciate performance is only one aspect of a decision. It depends if your use case needs those performance or if it's public or a private chain. And there's, there's just many reasons why you would choose one, one tool set over another. So we just wanted to be really clear about that and again, put that kind of as the intention and the start of the caliber paper that we're not trying to provide authority of results on behalf of, of hyperledger and publish results of the benchmarking. And the rest of the document just brings it up to date. Progress reports through. Sorry, is there a question? No, I think somebody just needs to go on you. Yep. So then the progress reports just to catch up clarified some of that and brought fabric up to 105. So we've got sawtooth support up to zero point date. And the latest developer release of a row. And there's specific questions on those. As I've just said, we can, we can take some questions on that. We've then folded in the, the output from the PSWG. So the results and the reports that caliber produces now, you know, correspond to the terminology and the definitions from the metrics document of PSWG. And then we have a little bit of a roadmap ahead because this will definitely be a, you know, work in progress on an ongoing project. And we want to build in more of the PSWG definitions. See, are there other. Hyperledger projects, either frameworks or tools that we could use. And we've, we've kind of an obvious eye on. Cello is that would be, that'll be really interesting to find ways to support that and use Cello to orchestrate some of the deployments when people are running caliber tests against tools. And just try to support the kind of cross-pollination of those, those tools. So I'll stop there and just see if there's, if there's any questions that, clearly there's, there's more to do on caliber. But, you know, we've kind of done our best to clarify the scope, broaden the team. And we'd appreciate the support from TSC to, to move forward with that as a project. Thanks, Stephen. Any questions for Stephen and how we're going to move forward with that? Thank you. Thank you. Thank you. Thank you. Any questions for Stephen and how Jim. So I'd just like to hear from Dan and Vipin about the engagement between caliber and working group. I know that was one of the issues originally. Yeah, this is Dan. So when, when caliber was coming for proposal that turned out the first time to be a little bit awkward timing with having just launched performance working group. Our objective there was to try to at least get to common verbiage or common metrics on what we meant by performance and what's relevant in this space versus other spaces. So we wanted to make sure that if, if there was a performance harness out there that it, it wasn't sending conflicting messages or wasn't producing something in conflict with the direction of that working group. So we wanted originally was for that working group to quickly produce metrics and then kind of get out of the way of caliber or other projects. As I imagine the architecture working group can relate to maybe some of the other working groups is it's a fairly lengthy process to get all the thinking in place and then get the document organized. So what we decided a few weeks back in, in one of these working group meetings was it might be more efficient all around to let caliber evolve alongside these metrics definitions. So I think we are close to definitions in, in the working group, but one of the way to check to make sure if, if we're creating metrics that are measurable, that are useful is to have caliber see if it's feasible to be implemented within that tool. So it's, it's going to, I think evolve at this point to be a bit of a back and forth between caliber and the working group where, where both of those efforts are enhanced by the other's activity. That sounds like a really positive relationship. Good. So this is on Ohio guys. I totally agree with this. And, you know, I would feel very bad if we were to push back again on caliber because they clearly have done what we asked them to do, which was to establish this working relationship with the performance working group. And the, you know, on a practical level, I, it would be good to highlight the link. I mean, in the hip document, there's like a text that refers to the performance working group. Is there a document that could be linked to that kind of shows that, you know, this is an implementation of the outcome of the working group. I think it would be good to kind of formalize that and, and put a reference link so that I can follow and see where those metrics are defined. And, you know, can probably search for it on the site, but it'd be convenient if there was a link. But other than that, I think this is, this sounds like great, very healthy work going on there. So, I would like to add something. Actually, I have a partner. So they have a, you know, resources. They have given a red book related to blockchain, whatever they implemented. So very well documented and very well, very good manner. They prepared a video means how they implement, how it's actually work. This is their hyper laser in fabric with their scenario. So in this manner, is it possible for you to give some video lecture related to this project so that for, and the user for a new developer, they are able to understand what they, what you are supposed to do, exactly looking for using this project. So such type of things I'm looking for. Am I right? Or is there anything you have to add something? Hello. Yes. I cannot believe. Sorry. Are you asking as a question or? Yeah. I'm asking a question means in a, means in IBM blockchain, whatever they implemented using fabric. Oh, so very well documented and they prepared a tutorial means how this, their fabric is actually working real scenario with four notes. They are taking four notes and making a hyper laser communication using their environment. In the same manner, we are go for this project caliber. So is it possible to see their working in a tutorial fashion? So such type of things I'm looking for because this, this project caliper project, little bit confusing. I mean, it might be in a wrong direction. I don't know. So such type of things I'm actually looking for. Yeah. So I think, I mean, you know, absolutely all of the projects could use better. More documentation. And then actually Brian to your earlier point, you know, how can more people get involved? Or how do we, you know, documentation is equally as important as code. And sometimes it's also one of the easier ways to start engaging in a project because you are basically writing down and sharing with others what you're learning as you're learning about the project through the documentation. So it's a good way to sort of get, get rolling. I wouldn't necessarily expect that or make it a prerequisite for a project to have, you know, fully, you know, sort of product production level documentation for its production. And I do, I do tend to agree with what our, our know was saying a little bit earlier about, you know, they've, they've stepped up and they've done exactly what we've asked them to do, if not more. And I, you know, I think that, you know, certainly the, the partnership with the working group has been productive and a positive one, I think is Dan and Mark both suggested. So I think it's, it's probably time that we take a vote. Yeah. If anybody has further concerns or questions. I would like to add some one, one, one thing. If you teach me miss how your project actually work. So I will make a production ready tutorial for other guys so that they may be easily for them to contribute on those, but on this particular project like a fabric or sort of such type of things. I'm able to contribute. If you teach me how this project actually work and what should be means with code and they're running example so that I can make my own production related to this project. So such type of condition I'm willing to give for this project. Well, I don't see any objection. So we can go ahead with the vote and yes, I mean, you can contact the developers and yeah. Yeah. Okay, so. Whoops. Yeah, sure thing. So let's just do a quick vote. So for the nine TSE members that are on all in favor, please say aye. Aye. Aye. Aye. Aye. Aye. Aye. All right. Any abstaining. Any opposed. All right. That passes unanimously. Great. Thank you very much. And congratulations to the caliper team on becoming the newest. Project. And I think the next steps then would be for, you know, Steven and, and, and how John and Victor to contact rye and he can. Help get you on boarded from a get hub Garrett. You're a great Chris. Thanks. Thanks for that. Thanks to everyone for the support. Yeah. Yeah. Look, look forward to, to this. Awesome. Great. Thanks a lot. Okay. Go ahead and send out information to you on how to get. Started getting that into the gate hub of hyper ledger. Yeah. Great. Great. Tracy. Thanks. I'll follow up with you. Great. Okay. Last call for Clive and the requirements working. Okay. Todd, I guess we'll have to defer that for next week. Yeah. I emailed him and didn't get anything back. So I think that he just missed it. Okay. Thank you. Okay. So we're back to the discussion about. Leaving incubation before a 1.0 or, you know, whether it's a prerequisite or, or a strong suggestion or. Or not a requirement at all. So. I think we, you know. And again, I don't want to, you know, necessarily put words in people's mouths, but I think that the. You know, that there are arguments on both sides, as they say, to be made for, you know, the fact that. I think they're likely to be projects that maybe don't necessarily. You know, have as broad a. A community around them as others. And that will always be the case. And we shouldn't necessarily penalize a project. That has value and that is, you know, the value of the project. And that's, you know, the fact that a community wants to sort of establish. That in fact, there's some relevance here. And you know, they'd like to sort of make that 1.0 statement. About, you know, the, the, the, the. The quality and the. You know, the completeness of a project. You know, oftentimes, you know, being at a zero dot something. You know, you know, you can sort of be an inhibitor to people sort of picking it up and kicking the tires even. Because they're waiting for it to be a little bit more mature. So. So, you know, and again, there's a bit of a chicken and egg. The tween. People using something and then turning back and contributing as. You know, that aspect of the question. And then there's also the, well, but if you put in the effort to, you know, to satisfy the criteria for exiting incubation. And shouldn't teams be required to do that? We wouldn't necessarily want hyper ledger to be. Abused as a community for, you know, going to 1.0. Without necessarily really engaging. And, and, and attempting to embrace the community. That we have here. So. And essentially just using the name. To brand some. Largely proprietary project. So. I, you know, again, I think there's, there's, there's. There's. There's arguments on both sides. And I don't know, you know, others can, can weigh in here. You know, we have another 15 or so minutes. But I would hope that we could maybe wrap up this conversation and. And make a decision. And if we do decide one way or the other, then I think we should. Then leverage that to update our. You know, make a specific update in the project lifecycle. To either, you know, make it a criteria for. I should say to make, to update the project lifecycle document to say that exiting incubation is a prerequisite or not. Just so that it's clear. And then if it is. Then we should. Well, anyway, we, we, we should just update our, our documentation to, to, to accommodate that. So I think the, you know, there is general agreement that in the application exit criteria, there's a set of criteria that really, you know, pertain to organizational aspect of the project that we all feel like, yeah, this, you know, to qualify for one zero release, you ought to have all of that taken care of things like the CEI, the test, all this stuff. And then there was this other aspect that seemed to be the real problem is, you know, this diversity, you know, how broad a community do you, do you have? And so it seems like there, the options we have, you know, to address this problem is either we agree that people can get to one zero with that getting out of incubation because they don't have this community aspect that can care of, but they're everything else. Or we, well, there are three options, I guess, either we, that, or we, we say, sorry, you have to get out of incubation. Otherwise you don't qualify to issue one zero. Or the third option is we water down the criteria to get out of incubation to say, well, in some cases even if you don't have a very broad community, you might still get out of incubation. And therefore you'd be allowed to get to active and qualify to one zero. I made a proposal on the TSC channel email, I guess, as well, that maybe there's a middle ground which is we allow people to, if you're an active status, you automatically qualify to, you know, for one zero release. But if you don't enact, if you're not an active status, then you can essentially it's almost like an appeal to the TSC to still, you know, be able to release a one zero. So the, if you're not an active status, it would, the one zero release would be at the discretion of the TSC. And the TSC would then do an evaluation, make sure everything else is taken care of. And on that basis could possibly say, yeah, okay, fine. We understand you can't build a big community, but you have all the other things taken care of. Therefore you can go ahead and release a one zero project. Is the problem the size of the community, or do we not want to vote for every project? Is that a concern? So that you go to the TSC and appeal and say, Hey guys, you know, my friends are on vacation, I still want to go one zero. Is it something like that? No, no, it was really more the diversity of the community in the executory. We have this notion that you have built up a community and there's not like one entity in full control and the only one contributors, right? Yeah. So that would have been like, you know, hyperledger fabric initially, it was all IBMers for the most part, they were a couple of people from TSC. But that's, you know, pretty much all IBMers and we had to grow the community and get people from other organizations on board. So effectively with this, since becoming an active project requires a vote from the TSC anyway, effectively what this does, it just gives the TSC a chance to review anything that goes to a one oh, at least, I mean that effectively is what we're, what we're saying, right? Yeah, I think that's a good simplification of that. Yeah. Yeah, but you apply for different outcome though, right? In one case today, you only apply to get out of incubation move to active. In this case, you would have to the option to apply to reduce the one zero even if you're not moving to active. Yeah, I understand. I don't know. I'm just suggesting that what this does is it gives the TSC at least some visibility into the project and an opportunity to review its maturity, whether we review that maturity as a transition from incubation to active or review that maturity as a transition to one point or release at least gives us a chance to be on board with where the project is. And that's the part I like about this mostly. Yeah, so Nick, actually that may be the, maybe that's just the ticket here is that we just sort of say, you know, there are going to one that oh, or exiting incubation requires passing through and review by the TSC. And that sort of covers because then essentially it makes it a decision, a subjective decision essentially by the TSC as to whether or not they felt that either the maturity of the code or the community is, you know, is suitable enough for for reaching that particular milestone, whether it's exiting incubation or not. And we can choose, you know, to maybe handle both at the same time or to you know, to say, well, but we still think you need to work on XYZ, right? I'm just judging by how much hard time we gave the caliper guys back in the day. Remember, like with Mark when he was trying, he said, no, we want the requirements in and this and that, and actually it did work well. So I'm happy to have some authority, right, as the TSC and actually, and we're all happy to vote them in, we're all proud of the work that was done. And so I think it's not bad to approach the TSC from a time to time. Just my view. Because it allows us to also guide people, right, so they don't waste time or actually what exactly do we want from them? And then we see we cannot be proud saying, hey, look, this is exactly what you wanted. Thank you very much. Go ahead. Good luck. You know, and we all endorse it. Yeah, the vote for 1.0 seems like a totally reasonable thing. Right? Yeah, that's what I'm thinking. Dan? Yeah, I totally agree. I'm not hearing any disagreement from anybody. Maybe there's a knit we'll have to work out with the phrasing of 1.0 versus some other sort of the GA terminology. Okay, Greg? Sorry, bubble boot. I have no objections. Okay. Ben has been on. I think Ben is out this week. Okay. All right. Well, I guess then I guess I'm not hearing any objections. So maybe that's what we do. We just sort of say that 1.0 and exiting incubation require TSC approval, you know, review and approval and maybe that that. And we can update the life cycle document accordingly. So unless there's any objection, I think I'll take the action to do that, you know, and present the update at the next call. Chris, can I just ask a clarifying question because I've heard two different things and I want to make sure that we're all on the same page. So is 1.0 regardless of whether you're active or incubation? I think it sounded to me like the last thing that 1.0 regardless of what status you're in. What do people think? I would think yes, but I want to make sure I'm not. I agree with that, but I think that generally we would expect projects to become active as it hits 1.0 or sometime within the same time frame. There are exceptions to that. And I think the thing I like about this is it allows us to handle that with, you know, a review of the TSC without having to make the rules too stringent or too cookie cutter where there is variation between projects and what each project needs. Okay, so I think the answer then is yes. I'll update the document and we can vote on the update. The answer is yes to what? Because Tracy, you're asking all questions you're answering by yes. I'm sorry. Yes. Yes, I know. Yes. Yes, the answer is both. Yes, it's either A or B. Yes. So I took that to be yes. Anything that's going to 1.0 has to have a vote from here. It has to have a review. Yeah, that's probably the easiest way to phrase it. And then I don't know if we want to make things harder on ourselves, but figuring out do we want to at the same time enforce this semver kind of labeling so that something that's claiming to be production ready is defined as 1.0. I thought we did that. I thought we had agreed that projects here in hyper leisure would use some semantic versioning. Yeah, we did that. We did that a long time ago, but it seems that when projects have come in, they've at times had their own versioning sequence. And so I think this was maybe the case for Indy. Oh, okay. Yeah, that's correct. Indy went to 1.0 right as we were entering right before we entered hyper leisure. Kick him out. Can we rescind to the project approval? That's right. Okay. I'll look at adding some reinforcement there and for that. Sound good? Well, would that mean that Indy, if this applies to any other projects, we'd need to reversion. And then if that's the case, can folks on Indy think about how bad that is? If it's bad. I think our strategy here would just be to hurry up and exit incubation rather than try to reversion. Yeah, that might be easier. I can see that. Who wants to change the version number backwards? I wouldn't necessarily say that you have to go backwards, but you should be using semantic versioning. If you were using bananas as your version number, then maybe you need to rethink that. Yeah, but that's not what I'm hearing. If they use 1.0, that's the problem, right? Yeah, but that precedes this decision. Yes, no, I totally understand. That was exactly one of the difficulties on our team is that we did that 1.0 because we reached the first phase and featured completeness and we hit the milestone where we can't break user space anymore. How about we do this? Because I think the criteria is going to be the first major release of a project under the Hyperledger umbrella requires TSC approval. Does that make sense? What does it mean, major release? Well, it means the one that you want to have the press release from Hyperledger. Nice try. I think it means the one that you want to have the big, you know, the horns blaring, you know, pinching on pins, heads, and all the things. It's not release. You don't want to get only one bonus in your lifestyle. You have to give it. Yeah. Does that make sense to people as opposed to 1.0 since we may have, like, Indy, have a project that's already passed that threshold? Yeah, I think that's reasonable. We can deal with the, you know, the lack of precision. You could say, and which is like, you know, IE10 for the project that follows some verb and, you know, and then aside from that, we say new project need to follow this and then we would avoid the... Right, but I don't think we necessarily need to have people reset to 1.0. No, but I agree. Right, okay. So I will update and I will share it via email and people can comment on the mailing list and then we'll review and... So just from my understanding, so we allow people to go 1.0 while they're in incubation or not? Is that... Yes. Yes, if we decide yes. In other words, it's a decision. Let's see, it's not... We're not saying that we are. You need to bring your proposal to the TSC. We will review it and we'll make a decision. Right, but we are allowing that as a possibility. That's the difference. No, because I'm reading the TSC channel and I'm just making sure. I want to do a PowerGravity, not this way. But again, it would also then encourage you, you could maybe do this and say, okay, we think the code is ready and we're also pretty comfortable with where we are from a community perspective and all the Garrett, JIRA, all the other things are in place and so therefore we think we're good. So, okay, I'll update the document. I think I have a good sense of where we are and I don't hear anybody objecting generally to this course. You can always email the diff, right? Yeah, sure. So that's a deal. Given that, I think we're at the end of the job. Thanks everyone and talk to you all next week, hopefully. And we'll see you soon. Oh, and congrats to Caliper. Thank you. Yes, of course. Congrats, Caliper. Welcome to the club. Thanks. Thanks again, guys. Talk to you soon. Bye.