 On today's agenda, we've got our usual hackfest planning session, an update on the internship program, which is now in the phase of getting some interns. We don't have any quarterly updates for the working groups yet. This week, I should say, but we do have one for borough, and I believe that's ready to go. Yes, it is. Okay. And then we have the continued discussion of going to 1.0 before exiting incubation. So any other topics for today's discussion? Okay. No. Talag, do you want to kick it off? Sure thing. All right. So for the hackfest, I think two things we wanted to discuss today. Let's maybe tackle the easier one first, which is Dubai. This came up at the hackfest in LA as well as on the call last week. The sense we're getting is that with the holiday in Europe and just kind of general travel availability, it's sounding like many of the folks from the more seasoned community are not able to travel for this. So it's sounding as though we may just want to turn this into a meetup as opposed to a formal hackfest, but certainly want to close that discussion off with those on this call. Get any further input or thoughts on that? Doesn't sound like it. So maybe we should just have a vote. Quick. I guess, are there any objections if we just turn that into a meetup at the end of April for those that are in town, as opposed to doing a formal hackfest? Give the answer. All right. Sounds good. And then the second part of the discussion is just kind of around the format of the event. If anyone had further thoughts there, I think a couple of people made the good point that it sounds like there's really two parallel things happening. One is more focused on bringing new devs up their learning curve, and the other one is really having the more seasoned community focused on cross-project collaboration, hacking, et cetera. It may make sense to keep the format doing it consecutively, or it may make sense to put this off entirely into two unique events. So curious if there's been any more thoughts from those on the call related to that. I think what we probably need to do is, I mean, because I think that having some sort of a road show and maybe have a few key individuals join that, and maybe it's a regional kind of a thing with hitting up a few cities and doing a meet up a night or something like that for three consecutive nights or something like that, that that might be the approach to take, and they can be planned in advance, and maybe we have one of those a quarter, I don't know, or maybe twice a year we do that. And then, and then just have quarterly access. It seems to be the right thing. I just don't know, I mean, it doesn't sound to me like we would be doing the planning. I think that's more of a marketing thing, probably. Is that what the thinking is? Probably a combination of a few different functions. Yeah. Yeah. I agree with Chris here, you know, it's hard for the new people to really catch on and do any meaningful work at a lot of these hackfests. And when we host them in places we haven't been before, we tend to get a lot fewer, say, developers who really know what they're doing. So it might be best to do, I mean, I really, in agreement with Chris here, that maybe we do, we do some core hackfests in places where we have a lot of developers quarterly. And I think I've suggested earlier like one in East Asia, one in San Francisco, one in New York, and then one in like Amsterdam or London. So if we do that quarterly, we hit most of our developers. And then we can do, you know, more roadshow type stuff if we want to do, you know, kind of, if we want to satisfy evangelism, then like Todd, you guys in the marketing committee can say, hey, can you give us, you know, these four technical people for a week to come, you know, talk and do evangelism. All right. And it's not to say that we couldn't do a meetup in the city that we're in for a hackfest. I mean, I think actually that might be a good idea, but, you know, keep it separate. Keep the functions separate. So kind of like what we did in, I guess that was Chicago, right, where we had the meetup. Yep. So in the case of Amsterdam, since we already have that one announced and people registering, does it make sense to still keep a training day, but make it very clear that the training day is a one day event. And, you know, we just leveraged some of the people that are traveling in anyway and focus on that and really make it clear that the following two days are the more advanced hackfest cross-project collaboration, hacking, and have a bit more structured of an agenda there. And while, although it's three days in a row, we really treat them as two separate events, or does it make sense to just chop off one day? Yeah. I mean, if everyone's going to be there already, it makes sense to, you know, to have whoever would need to have come early and talk about evangelism. Yeah. You know, Amsterdam, we've been there before. It's actually pretty active from a hyperledger perspective already, you know, with ABN Amro and some others, you know, really sort of taking a large role there. I wonder how, you know, how necessary a day zero is really going to be. I wonder if we could just maybe reach out to some of the, if you will, the locals to get a sense for whether they would think that's a needed function or whether we could just do a meetup. Okay. So in general, I mean, I'm a bit concerned with this idea of splitting the events entirely for the reason that, so first, I don't know that we'll be able to attract really people to come to a separate event just for evangelization, or if it's any different from all the other things we already do, we have meetups and stuff like this going on. And then, you know, it just falls into that program. And the other part is, I mean, the reason we came up with this day zero idea was because we couldn't stop people from coming during our hack fest, right? And then we felt this was disruptive to the primary goal of the hack fest. And we say, okay, let's have a separate day just for that. And now, yeah, just because we say, okay, we want to have it, are we going to stop people from showing up and having this kind of expectation we're going to introduce them to all the technology? I don't know. So, you know, I understand, you know, it's not like I'm especially in favor of keeping three days per se. I just don't know that we are not falling back into what we had before. And then we haven't solved anything. So, I mean, I actually think three days is good. But I do get your, I do, I do take your point. I think, though, that by making a little bit clearer what we're trying to achieve, you know, and, you know, if you're going to have a day zero and it's a completely different thing. And then we make it very clear that the hack fest or the face to face or whatever we wanted to call it was really intended for those that are already immersed and, you know, project conversations or project to project conversations that are probably going to be above a lot of new people's heads that, you know, that we, just by being a little bit clear about how we advertise and market this thing, we may sort of, you know, do ourselves a favor, you know, the challenges have been in the past that we just have a hack fest and we have an introduction. And then you have somebody asking everybody else a lot of questions. And so that can be a little bit of distraction from actually having the kind of conversations and work that we, I know we all want to do. The other thing for keeping three days is I think that then we would have more opportunity to actually put the working groups in and we could, instead of doing tracks, we could actually have, you know, identity and architecture and, you know, white paper or something like that where others could participate and we wouldn't have to pick and choose. It just gives us a little bit more time to have those kinds of conversations. And I think that for many in the community that are participating primarily through the working groups that that would be good and I think it would also be good for the people that are primarily working on writing code to also participate in those. So I'm actually in favor of keeping three days but making it a little bit more whole in terms of with the whole of what we're all doing, you know, so having, you know, actual working group meetings where, you know, others can participate having the, you know, and then having enough time for the conversations and cross-project collaborations. That sounds good to me. The other thing is, you know, we only had one instance of a three-day meeting so far and, you know, granted there was a fairly low attendance but that was across the whole meeting, right? And if anything, the day zero I couldn't attend it but it sounded like it was reasonably successful. Right, day zero was packed. So, you know, okay, so. Right, we had the high school students and we had a bunch of college students that showed up for the initial training who then didn't show up for day two and three. And I don't know if that's because they thought it was bad but I think it was mostly because of scheduling they had to go back to class. Right, so that's my point. I, you know, I don't think we should necessarily question the whole premise of the three-day meeting just because in the LA for some reason we didn't have too many people showing up especially for day two or one and two, so. So, this is the thing, this is the thing, Alec, can I just add something? Because when I speak to new members, I do spend a lot of time telling them about the hack fest and we all do and we tell them that day one is really a great onboarding for their dev teams and that they, you know, they don't need to participate in day two and three. I don't know how to say it, you know, day two and three gets much deeper. So, yeah, just, that is the way and maybe it goes back to Chris's comment. Maybe we need to market it better as we, you know, on the web page and when we talk to people about it but that's how I've been introducing it to folks. Yeah, I'm not sure how much long-term traction we get out of the day zero type visitors. I think that I'm interested in more of this deeper collaboration and working group progress that we get if we show up with a structured schedule of this is what we're going to get done and we don't stop people or discourage people from showing up but at least it's clear from the agenda that there's topics here that require context. So, there's probably some investment that needs to be made beforehand if you're going to show up to one of these. You know, the other thing that we could do, Dan, on that point is we could actually, I mean this is a little bit extra work but whoever it is that normally that would be, maybe doing a day zero presentation of the projects could just record a short video and we could have those posted the week prior, advertise them around the registration, for instance. Here's a set of introductory videos that you can go through and, you know, on your own time to give people some of that context and then allowing us to have the full time for our own conversations. Just a thought. So, I suggested this in chat but I think maybe if we had a separate registration process for the day zero and the actual hack fest it might serve as, you know, an effective filter. Yeah. Well, like I said, I thought I would go back to Tim and some of the other guys there and I'm sure I don't know who you're working with. Yeah, Yuri, Tim and a few others. Yeah. And then I would just get their thoughts. Okay. We have enough time to plan it. All right, sounds good. And then one other quick question and then I think let's wrap this up just because we have other topics. In terms of a quarterly cadence, you know, with Dubai not happening, is there a hunger to try to get either a US-based hack fest or more likely an Asia-based hack fest slotted in sometime from now until the end of June when we're in Amsterdam? It's common. I didn't catch that, Chris. Well, because I'm assuming that a lot of people are going to be in that consensus. Maybe I'm wrong. So, Chris, I think we lost most of what you said. We heard it's common. Yeah. All of you guys, I'm in a hotel and I, right, I'll put it in the chat but basically I'm suggesting we might want to do maybe one day around consensus. Yeah, we heard that. All right, if there's no other thoughts on this, we can take it off an email thread. Otherwise, I know we've got some other stuff to get through today. Yep. Okay, so let's jump to borough, I guess. Oh, no, internship program. Sorry. Yeah, just really quickly on the internship program, 12 projects. We're accepting applications from students now. Please help us promote that in the agenda that went out. There's a link to the blog with more details as well as some links. If you want to click to tweet and promote to your communities. All right. Super. And so next up would be borough Silas on. Hi, sorry, I managed to get into a pen drawing mode. Hi, everyone. This is Silas. So I've posted the update. If you want to be able to follow this as I go. There's also other couple of documents I've done. One being a roadmap post Morton. Which I might refer to of the Q1 roadmap that I did for the last update. And the other being a draft roadmap for Q2 that I'll work through the updates as it stands. So, yeah, in terms of project health, my feeling is that borough has been gaining momentum in terms of useful contributions on the Hyperledger chat in particular. Few users that I'll mention later who have done some useful stuff, including building a truffle like package for borough package manager facility code. The refactor was fairly big undertaking. It meant refactoring not only the borough code, but also getting all of our tooling into a into a mono repo called Boz Mama. But in the process, a lot of existing bugs were dealt with, including a lot of panics, a lot of type safety issues. But still, not huge progress on actual features, which was expected, but I kind of hope to close it off a bit quicker. So the main issues that we have, and some of these have a good chance of being closed off in what remains of Q1. So one is EVM compatibility. So I got a developer who's now up to speed from started consulting, who's been working on these EVM issues and has an implementation waiting in the wings for the revert op code. But there's a number of new op codes. And we're now in a good position to implement them. What I'm also doing at the moment is integrating the Ethereum has some table-based JSON tests available to all Ethereum clients, some of which can be translated to borough. So I wanted to integrate those to help us assert the correctness of the upgrades we do have. So for example, I found a bug with the help of one of the users who came on the Hyperledger chat in our sign extension, which basically meant that using types narrower than 256 bits that were positive was actually broken on this sign extension. It didn't set the sign bit correctly, which is kind of a fundamental thing to find, kind of strengthens the case for needing this level of testing. Another issue we've had quite a bit of, which pulls me in multiple directions is the lack of decent up-to-date documentation. We have some kind of extensive tutorials from the previous iteration of Monax, the company, which I point people towards. But there's a lot of that as atrophied where it sits, or there's just a lack of sort of basic information about how is our permission system defined. It's not complicated if you read the code, but I actually did add some comments on that. To that end, there are three more junior developers from TCS who have worked on a package of documentation, which due to some kind of arcane legal processes, I haven't actually been able to see. But hopefully that will give a, I spent several hours presenting burrow to them and asked them to put that into an overall kind of architecture piece of documentation. We also have a former employee from Monax who was deep in the tooling for years, who is working on consolidating a lot of our documentation. So I hope that will help it, but on the other hand, it's something that I could certainly do with help with because there are certain Monax priorities that involve burrow that are kind of trumping, spending time on documenting what's already there. And the other big one, and this relates to what I bring up in the Q1 post-mortem would be Web3 support. Partly, we internally re-prioritize that. We are taking burrow into production using our existing JavaScript APIs. There's also some issues with, we had been hoping to collaborate with people from Fabric EVM on a Go-based Web3 RPC, but they've decided to take a different approach. So that's something that hasn't happened, that was planned for community, then I think having Web3 support is quite a big deal for adoption, but like I say, for my day job, it wasn't really in the high priority set of things to work on with burrow, but for Hyperledger, it would be really useful if we could get some movement on that within burrow. There is a prototype or more than a prototype, I guess an alpha or beta Web3 implementation on Seth Sawtooth with burrow, but that's written in Rust and we wanted one in Go. So there hasn't been a release yet. There's quite likely since the last update, there's quite likely to be one this month, I would say, we're closing in on it, largely that's been down to the refactor, as I already mentioned, we had 0, 18, 0 would be the release, even though really it preserves a major point release, we're reserving at one because of the semantics that might be a wrongly have become attached to that. The other thing I'd like to start doing once that point release is out is integrating both in Fabric EVM and Sawtooth, the new changes, which are numerous and worth having, particularly in terms of EVM compatibility, that allows us to use the latest Solidity compiler, 0, 4, 2, 1. So activity, so this big refactor named Harkamama, that successfully completed, introduced a lot of safety, removed a lot of panics, mostly just really needed doing for sanity and maintainability. What ended up, I ended up doing in a, probably to a higher level than I had expected, but also took a bit more time was the establishment of this Mono repo, so in reality, to be able to test, borrow, and successfully, and to use it, all of our tooling that we would, we had slightly optimistically thought we could deprecate, has had to stick around. So we now have a Mono repo that has our compiler service, our key signing theme, and our JavaScript libraries, and our package manager, and integration tests in it, and there is now a sort of, kind of, dependency between borough and Bosmarmot, which is the name of this Mono repo for testing. So they both run a, quite a full set of integration level tests on any pool request, so that certainly gives a bit more certainty. The upgrade to 10-minutes, zero, 15-zero, that has loads and loads of improvements. There's actually a zero, 16, bit of a moving target with 10-minutes, but they're moving towards their 1.0 release for their Cosmos network, and we should be able to track them fairly quickly. We've also pushed various changes to 10-minutes around signing, because we run 10-minutes within a single process, and we need a bit more control over how we configure the node. Yeah, removal of fairly large 10s of different panics, it's a bit of a panic happy code base in some places. And the event system to synchronize 10-minutes was replaced in areas where there were blocking on events and so on was removed. So really heavily code quality improvements with some feature level things around. There's now a query language for events and logging, all of which were needed for debugging. So I'm just going to flick over to the post mortem just to see if there's anything to mention there. Yeah, I think I can leave that offline. So the current plans, and these are being driven as well by our use of borough for our product, which will be going into production Q2, Q3 this year. So a governance transaction, which will be, initially it will be something of a pointy stick that will allow you to redistribute validator voting power relating to the consensus mechanism and the native token across all accounts. Ultimately, we will want this under control of a governance, autonomous governance contract, but it will be building towards that. And that will also be reintroducing validator set changes, which have been commented out in an earlier form of validator bonding for a while. We have another team member joining who has a lot of database experience and will be working on upgrading our Merkle tree to something that Tenement have been working on and providing their SDK, but needs a little bit of work, but has some very interesting types of range proofs and other Merkle tree based proofs that it can provide, which we're going to want for running borough in this sort of multiple chain universe. State history, so that will be linked. We'll be able to have a queryable EVM history at any block, which should be a nice feature, something that Go Ethereum won't have in quite the same form. The event fire hose, this is the ability to get a catch or consumer for both consensus events and EVM events, which are defined at the contract level and are the way that Solidity drives a lot of external processes. Currently, you subscribe to that over WebSocket, but if you lose an event, there's no easy way to look back at previous ones. So this can give an experience that maybe feels a bit more like Kafka or something like that. The queryability events there. Validator bonding, it's linked, so we need a way of changing validator sets. And then a serialization of state and restoring that state. So being able to ship our state back ends around to different ephemeral nodes and Kubernetes is kind of what that's about, but also just giving an upgrade path. So if we can have a reasonably stable state store that we can dump to, we'd upgrade that to a chain that could read that in. On maintainer diversity, so Tyler Jackson from Monax, one of the founders of Monax has been getting more involved and I would consider him a maintainer now of Burrow. Me and Casey are still going. We have this new team member joining Sean, who will most likely be a maintainer and then there's another Sean from TCS who is keen to become a maintainer and they're kind of spinning up. I don't know, perhaps I could have some guidance on what level of confidence with the code base we should be waiting for before calling someone a maintainer. I'm fairly relaxed on how we do that, but perhaps wanted to give people a bit more time to get up to speed. In terms of contributors, and I'd like to think some of these people will be potential maintainers as well. Sean Blocker from TCS already mentioned. Amad Pulazade has done something quite interesting called SNAP, which is similar to Serium Truffle, but using our JavaScript APIs. He just came on to the chat and had this thing, so I've been trying to get his interest in perhaps maintaining our JavaScript libraries as part of Bosmama, whether they end up being an interim thing or turn into their own, stick around as an interface to grow that's so useful, I'm not sure, if Web 3 is around. Robert D. Bills has been building Kubernetes integrations. Early on, Adam Ludwig from Sawtooth helped me merge the large hypermarmor refactor, helped me review it. Some other stuff I think I mentioned there. The final thing to say is that we will be putting our own product into production on top of Borrow, which is our legal agreements network in Q2 and Q3. This both ups the ante for us in terms of testing around certain things like EVM compatibility and correctness of things like validator set changes and so on. But it also means that the focus is really there for us and things like documentation, possibly things like what we had hoped to prioritize around Web 3. They matter less for us now. I'm very interested in getting people from the community to work on that stuff. But that's just, I guess, the way the priorities lie with Monax. So yeah, I think that's all. Any questions from anyone on the Borrow update? Yeah, because I think your line is dropping out. Any questions from anyone on the call for Silas around the Hyperledger Borrow update? Hey Silas, this is Dan. That's a really thorough update. I appreciate you getting in such detail there. I was curious, did you make a giant merge to make that 666? Yeah, I noticed that. I didn't. It was not an earthly hand that did that. I guess Borrow already has a subterranean feel. That's what you will. More substantive question. So it's not like you've got one external repository that you're relying on for your testing. Everything else though is in the Borrow repo. Yeah, so we had certainly flirted with dropping all of our stuff, much of which we could Apache license into Borrow. There are two reasons, one hard reason and one softer reason that we haven't done it. The harder reason is that we still haven't done it. So what was Monax packages do, which is part of the Monax tool, I've stripped all of the docker dependencies and a lot of the kind of incidental complexity of that out and I've just kept the package manager. The package manager is a bit more than that. It reads these EPM.yaml files which can deploy contracts, it can call functions, and various things. It's what we use for integration tests, it's what we use to push contracts. That relies on Go Ethereum's ABI. It would be a non-trivial but not particularly excessive piece of work to get an Apache licensed ABI, but I am not familiar with them. So the ABI is the application binary interface for the EVM, you can call a function and you want to know how to pack the bytes for a particular function call and you want to know how to derive the dispatch hash for that function and all that sort of stuff, it's in the ABI. It would be nice to have an Apache licensed ABI. So that keeps part of what's in BOSMAM up there. I've actually dropped some GPL dependencies on things like Monax keys, which I think there is a lot of work to be done, particularly as Burrow takes on the ability to be a delegate for other keys that are within this Monax keys container. That may well move to Burrow. But the main idea was to get all of this stuff that you still essentially need to use Burrow into a single repo and to have it maintained. So we lost our person who had been working on it and we lost various people working on compilers and so on. So I am taking on maintaining that and BOSMAM up is a package that is sort of maintainable size and I feel like I can kind of iterate on. It's not entirely clear at this stage what it will become, but it's kind of essential really for someone getting into Burrow right now as we transition to the new code base. Okay, thanks. And then I imagine Adam probably has a good idea what's involved since he did review your big refactor. But I know we're all interested in getting all the benefits of that refactor integrated into Seth properly so we're not working off of that fork. So any guidance that you can suggest to Adam and probably defer first to Adam to see what we need to understand. We're looking forward to. So I think the thing with that will be probably to I need to get out of this 0180 release just to give a little bit of a rubber stamp to the there and then it would be best if we had Seth depend on Burrow as an actual dependency. And I'd note that if we use Go's depth tool, which is the first dependency management to go that actually seems to work, it will strip out unnecessary files. So you should be able to take just the Burrow components and they're all encapsulated in a bit of a better way now as well. But there are some critical bug fixes in there. So you guys will want it. Great. Any other questions, comments for Silas. Thank you. Got a lot of background noise might want to go please. Okay, so up next is continuing the discussion on whether a project can go to 1.0 before it leaves incubation or what are the implications of that. I think where we had left it off and can somebody paste in that link there. So we had continuing discussion. I think Dan, your point was that you think it is required. You seemed to be sort of required. I don't know if anybody else had any thoughts. Personally, I tend to think that when you're talking about 1.0, the code is either mature or it's not. But I think I can't remember who it was, maybe it was Hart was talking about, are we disadvantaging some of the non-core platforms, if they have a small community, if they have a robust and mature code base. Is that any less robust and mature? Obviously from a, you know, building a community, getting other, you know, getting committed diversity, getting maintainer diversity. Some of those other things may be harder to achieve with a smaller project. And I don't know if you can see where a project could say, well, we think we're at 1.0, but from a hyperlinked foundation, you know, supporting marketing, supporting with the, you know, security scan and, and both bounty and all the other things that go with it, including press releases and so forth, that that wouldn't necessarily be as, you know, if that were the case, but, you know, again, I'm, I'm just sort of coming at it from the perspective that says, you know, I think that we definitely want to encourage people to get out of incubation quickly. But that can be hard. And I think we all are aware that you know, we need to all do better. I think on growing that diversity and looking down some of the, you know, the closer roles around our various project. That's it's clearly something we need to be focusing on. But I don't know if that necessarily means we penalize the project. Silas again, actually, I mean, this is something that I didn't actually directly bring up. It's kind of, it's something I spoke into Casey, our CEO about and would have a perspective on. So if you take, perhaps take borrower as a case study. So we have some of the the majority of the best practice is bad. That's actually one thing that the last quarter as well. And in terms of our code base age, having our first commits back in like, I think December 2014, we're actually older than than all of the, well, possibly all certainly sort of fabric projects. So in pure age, which is not I think quite what is meant by maturity. We're older, but we've also gone through some, some gymnastics and I wouldn't with the stuff that I've worked on recently want to put burrow into 1.0 yet. However, I may want to do that a bit sooner. And with us still being an incubation, I guess I actually wasn't even aware that that was potentially impediment. So I guess it depends how hard it is to get out of incubation. But certainly I would at some point feel like I'd want to give the signaling of a 1.0. I mean, I also would just like to just get on to a rapid release schedule and actually use major releases in the sort of semantic versioning. Meaning in which case, I mean, I nearly did this six months ago, to be honest, to get on to you know, if it was a major release, breaking changes as a lot of the releases are to just do it. That's a perspective from burrow. So Chris, I mean, you mentioned, there's like this seems like there is no clear there's no clarity on whether the current status of things is whether there is any requirement or not. I would claim there isn't any requirement as of today that those two things are separated and there's nothing in our documentation anywhere that says otherwise. If anybody believes that's not the case, I'd be interested to hear where there is a mention of any kind of requirement. Now, this is not to say that we shouldn't have one but I think it's important to agree on what the status quo is because otherwise, I mean, we have a bigger problem if we don't even agree on where we are. Yeah, so I don't think we define the policy, right? I think why we took it really pushing for a 1-0 because it was a signal to the market, we felt that a few features are mature enough and you know, all the antennas were happy to sign it off. So we said, okay, can you hear me? Can you hear me? Yeah, I can hear all of you guys but Jonathan's coming in really not a very crisp sound. Okay, then I'm not going to say anything. Fine, I don't know what to do. I'm in a loud place, maybe I'll move. I can try to say it like maybe in a short version, I think we wanted to keep it open. Who is you in that sentence? Jonathan. No, I just looked at how we did 1-0. We had an agreement on okay, let's go to 1-0. The beginning we were thinking about March 30th, we communicated like April, so more or less then we added some more features related to the challenge and then everybody said okay, let's get it out of the door. People really wanted 1-0 in fabric, right? But we didn't want to force it. I never had, like even when I was always listening to the TSC I never had the policy kind of either encouraging or discouraging people from going to a 1-0 release. So I feel I believe all the time that we wanted to keep it flexible. That was kind of my assumption. But if you want to define a policy then maybe we should, if people think that we should discuss that because there are pros and cons, right? There are pros and cons to encouraging people to go 1-0 and it's harder to go 1-0. Just to get out of the incubation, right? However we called it that step. What I said last week, I think it is a big step. I think it is a game changing event. It's not like 0.92 is not the same as 1.0.1. If you see what I mean, right? It does the release cycle. As a signal to the market, there's how much money because of auditing and all the other things that come. And the good things that come along with the 1-0 release cycle and getting out of incubation. The question is, do we want to encourage you or do we want to make it this strict process? I don't know how people feel, but I'm open to suggestions. And I'll mute myself now, sorry. Yeah, so I think to the earlier point, we do not have a policy on it but what we're discussing is, do we want to create a policy? And I think it makes sense that if we're going to put some sort of marketing and backing behind things, or just even the notion that hyperledger supports the concept that is particular project is production ready, that it has to have some level of maturity behind it. And so it makes sense to me that a project be in an active state at the point that they're declaring a 1-0. Or the opposite of that is it seems like it would be odd for something to claim that it's production worthy when it's still being incubated. So I'll just sort of go back to the conversations that we had around incubation and maturity of the project itself from a code. And we made a clear distinction that they're unrelated. Exiting from incubation doesn't mean the code is mature. It means that the community is mature. It doesn't necessarily mean the code is production ready. It means that the community has met the criteria that we outlined in the project lifecycle. We didn't talk about, you know, releases in that context, but you could, I think, make an argument to say that code maturity is not a requirement for exiting incubation and then why should exiting incubation be a prerequisite for community or project community maturity? And again, I think that these are independent contexts. Again, I think I can appreciate that we wouldn't necessarily want to be in a situation where somebody comes in and is not putting in, you know, immediately after they incubate the project, they go to 1.0 and expect all the marketing and so forth. I think that's probably something we want to try and avoid. And, you know, I think there needs to be a certain expectation that there's active efforts on going to improve the community maturity around the project. But again, I'm just mindful of the fact that we made a clear distinction between code and community when we made the decision around whether or not the code had to be at, you know, sort of production grade before you could exit incubation. And I guess I'm saying why would we have that a different discussion in the other direction? I think I would just point out that when the project goes to 1.0, that it does send a certain signal to people who are using that product that it will be, that it will exist, right? It continues to exist and be something that can be used, right? And so this is the only reason that I think, Chris, I completely agree with the fact that we've written that incubation and code level kind of don't go hand in hand, right? But I think on the other end, you have to think about the people who are using the project and thinking, oh, this is 1.0, this community is going to continue to exist and I can go ahead and base my product on this and work from here, right? So I think that's the only thing that I would bring up as a possible concern with the other way around, right? Not being active for 1.0. And well, the counterpoint is that a project just could be small, right? Like if I, if, you know, say Mick and I write some small little library that's like 300 lines of code and doesn't need much maintenance or something, but a lot of people use it. Well, you know, maybe we don't have a large number of contributors just because we don't need it. And if we were to go away, then someone else would just pick it up because it was simple. Yeah, I think we shouldn't get too focused on the number of contributors. Diversity is important in ensuring that the project remains if one participant or one company goes away. But I think the other things we look for in an active project are maturity in the processes. So you've got the CIA things covered. You've got sort of, you know, build integration, unit test coverage. Your licenses are checked out. And all these things are, are part of a picture of maturity that seemed to me as precursors for declaring production level maturity. Dan, I completely agree with that, but that if the code is mature, this process is going to go very fast, but there's still a process to be followed and a bunch of gates that we've put in place that, that trigger actions, both in that, you know, both as a sort of reflection of code, but also trigger actions on the working groups part from security audits to marketing pieces of it as well. A 1.0 in an arbitrary release is fine, but a 1.0 coming from Hyperledric contains at least some stamp of blessing that we should be able to address. I would like to suggest that we may have a look at what, what happened in other communities, like the Omistak and Apache. So in my opinion. So I think we lost your audio, Bawa. It looks like you may have gone back on mute. So I may encode in the chat later. Okay. Sorry with my microphone. Yeah. So I don't think we're necessarily ready to completely close this off. I was like, I think there's, you know, there's good points on both sides. Right. I suggest we continue on the mailing list and pick it up again next week and hopefully I will have better audio. Any other discussion topics? If not, I can give people a couple minutes. Right. Thanks. Thanks everyone. Thanks all.