 Sounds good. All right. Do you want me to go through the first two? It looks like mixed on now, we are at Quorum. Okay, so in terms of the first few, Dave had sent out a note prior to break just around releasing the Hyperlegger Fabric 1.0 security audit report. All the votes came in, that's been unanimously approved, so Dave will get that taken care of. That's really just in FYI. The second one in terms of hackfest planning, we are trying to get these mapped out for 2018. For the next one, it looks like we are converging on February 20th to 22nd in LA. That would include a day zero on that first day. Essentially, that would just be more of an intro to help newbies come up the learning curve, get familiar with the code and whatnot so they can better participate in the two full days of the hackfest. It doesn't get as fragmented that way. With folks being out for the past two weeks, it's been a little slow to get that confirmed. We picked that thread up yesterday and hope to get this confirmed in the next couple of days and get the rest mapped out for the remainder of the year based on the calendar we sent out early December. As always, if anyone on this call has space at their companies, get in touch with me ASAP, otherwise we'll keep you updated as we have more. With that, I think we're on to project reporting. I think if Silas is on Hyperledge or Burrow, the report came in in December, but I think they're just catching up to do readouts on that. Yeah, no. I'm finally on at the same time as everyone else now, so ready to give that update. Would you like me to go ahead with that? Yeah. I've just got it up in front of me. Do people have the text version of this that's been up there for a while? I guess if I work through the different sections and maybe embellish a bit with what's happened since then. In terms of project health, I'm describing burrows being a kind of transitionary period and ramping up, and that transition is really related to it being divorced from the somewhat divorced anyway from the previous Monax tooling that brought in a lot of dependencies on things like Docker really to sensibly run burrow, as well as an upgraded underlying consensus mechanism to the latest tendermen. So that's causing some issues in that we have documentation linked to Monax that is becoming a little bit out of date, but we're able to talk to people on the Hyperledge chat and then deal with that. On the positives we've got from Tata Consulting Services. There's three developers joining us from India who are new to go. They're not new to burrow. They've done work with our previous tooling, so they've got some knowledge there. They need a bit of hand-holding in terms of development environment and stuff, but it does mean there's three full-time people working on burrow. There's a roadmap linked for Q1, some of which may be a little ambitious, some maybe not ambitious enough, but I'll split that up so that I can give you that work up between three new people. I'm saying yeah, from the Hyperledge summit, seeing that there's quite a lot of interest, which was nice. The community having not been sure quite of the future of burrow, I think there's definitely a desire to use it. It's also being integrated into Fabric and Sawtooth, and at the Hackfest I was able to get Adanudvik of Bitwise to start helping me out on reviewing my rather large pull request, which is this hypermarmot refactor, which is still in progress. I'm actually looking for a bit of a race position at the moment. Issues, right, so two key issues are we need to provide a Web3 compatible API. Some positive news on that is that the Fabric IBM team, Sretha and Jin, J, sorry, have a early prototype of this, probably using a similar web framework that we'd want to use on the burrow side, which is Gorilla. We have a plan to try and build that API on a common abstraction layer that would allow us to share RPC code between a burrow, which probably still wants its own Web3 RPC. The point of having Web3 RPC for people on the call, maybe not familiar with Ethereum, is this is the main interface that is expected by Ethereum libraries, client libraries and other tooling, and opens you up to the ecosystem of Ethereum tooling, whereas what burrow has currently is a kind of due to kind of co-evolution at the time, a slightly incompatible but rather similar API to Web3 in a lot of ways. So that's the big ticket item for Q1. Actually, I'm trying to provide something on the burrow side from the end of January. And then the other issue is around tooling. Since I wrote this update, I've pushed a Mono repo to Monax called Bos Marmot, which condenses and simplifies the necessary Monax tooling to run and interact with a burrow chain. Well, burrow will now run on its own without any need for Docker anyway, but you still need our package tooling to deploy contracts. Really, I say you need, you could write against RIPCs, but it's a soft dependency. So it packages our key signing demon, which incidentally, I did mention HACFIS, I see some value there in agreeing a common interface and method names for a key signing interface, but we have a version that that's put into there and a compiler service. So that's been stripped down in the sense it's had Docker dependency removed from it and had various other things taken out that our previous tooling did. That's in a slightly less cleaned up state than burrow itself, but that will be where I'll be pointing people to get a kind of out of the box experience with burrow going forward. Releases, yeah, so it was a while ago since the 18-0 was released, but it was in the previous quarter, so it belongs in this review. That was our previously supported release by Monax. There are some bugs that are known in there, but it does basically work and it works with all the existing tooling and by and large existing tutorials. This release will be replaced by a the release that comes off this refactored code base, which will kind of set the tone for the future of what burrow will be, which is this lean, tandem-based blockchain and also a library that exposes some interfaces for integrators like Sawtooth and Fabric. Overactivity, so I'm the only active developer on burrow or I had been certainly in that past quarter really, but there's been a lot of code written by me on this refactor. I mean too much for a single request, but I'm having a miracle upon that and a lot of it is stuff that's been outstanding for a long time. I think I had some discussions with individuals about my reasoning there and there's more justification if you follow the links. So current plans, yeah, I could briefly just go through the buckets that exist in the roadmap and this relates as well to what I'd like to get some of the title consulting people to work on. So one bucket is Hyperledia and that's about going through doing a full audit of issues and trying to get some more contributions from general Hyperledia people and I'd like one of the TCS developers to kind of take a lead on that. Boz Mama, I've mentioned now, so this is certainly for us and I know for some others in the near term we're still relying on our tooling and our JavaScript libraries. This is going to be a mono repo that has a single release rather than they were all of these projects were in separate repos and a kind of minimal maintenance thing that may exist after we have Web3 but it may not. Web3 is the third bucket so we're looking to collaborate on that but I've got a common interface to implement that against and then I put a fourth bucket of project work so just admin around getting CI set up on Boz Mama and getting make sure this refactor has gone through with a proper review. It needs to be slightly restructured now that there is a willing reviewer at least in the form of Adam. Let me just go back to the update I think I'm nearly done. Say on the B point, the Boz Marmont, are you collapsing those together in the sense that you're going to pull those in as binary dependencies or you're actually collapsing the code into a single repo? The code is in a single repo you can actually see that on Monax slash Boz Mama. So what were top level projects are now packages in a single go repo and where they had dependencies between each other they now just depend internally there. The biggest stripping out really so the command line interface and much of the code is identical for our package management tool that's probably the thing that's most likely to survive because it may actually have a niche and there is some interest but what I've got rid of is we had a lot of a kind of ansible like configuration files that allow you to run different services like IPFS you could run and that could depend on something else and a lot of that was orchestration so we didn't want to keep that but what has stayed is the package management so it's what was Monax packages do has stayed in so that allows you to run importantly allows us to run our complete test suite which is contained in the Boz Marmont now as well which is a whole set of stability contracts and kind of integration test assertions which I've run incidentally actually since I wrote that I've now run them successfully I've got this race condition which I found which is possibly intended. Cool thanks for that and then a question on the web three stuff when we were all in Lisbon you had mentioned you were thinking about some of the trade-offs between having that interface as a separate process like we did with Seth versus having it as a single process again you kind of went towards the latter. Yeah so my reasoning was and this has also changed a bit by the fact that we have in the fabric project those guys working on a web three interface in go in probably a library want to use so it seems like this that lends itself more to sort of bothering having a separate web three interface in borough. My reasoning was that it is this niche of borough standalone mode being this single process tenement harness because you know we're using we're not even using tenement over a socket like tenement kind of it encourages the sort of encourages people to do so it's if that's the use case and it seems a bit ugly to have an out-of-process RPC in that case I don't think it's an ugly design decision and also it kind of puts into the territory of what say sawtooth is doing so yeah I didn't really want to take on those extra moving parts and it and it sort of depends I don't think that the other thing we have is that our existing so I our two RPC layers we have one's called Vnaught one's called TM one's used by gyro script one's used by package management tool the Vnaught one at least is or both really are not that far away from web three in fact they're closer to web three than than what had to be done for the sawtooth integration so I don't think it'll be to get the basics I don't think it'll be actually a huge piece of work and if we if we can share code with fabric I think it's worth having that on base borough so that was my reasoning with not jumping in with with Adam's rust implementation yeah okay thanks right I'll just finish off connectivity maintainer diversity yeah maintainer diversity is bad right now it's me and Casey really so Ben our former employee he is technically a maintainer but I haven't re-heard from him for a while and what I think I'd like to do is try and approach someone from both the sawtooth and fabric teams if they're interested to become maintainers particularly and I think some of that might be contingent about how much work we end up get managing to do together over the next quarter but yeah I don't think we need to set a huge bar I mean I certainly I've worked with both Sretha J and Adam and I'm sure they're all and would be capable maintainers if they're interested really so that would be a plan for getting someone else on then also since Tata has made quite this quite significant offer of help it would certainly be nice to get someone Tata in currently like these are I guess fairly junior developers and I wouldn't be comfortable with them at this stage being maintainers but possibly some of the technical leads are supervising them or someone from Tata it would be nice to get them on so so perhaps that puts us through to having better diversity in terms of we might have three maintainers from three different companies and so if we can swing that and I'm sure Tata would be would like to to have someone act as a maintainer from them so yeah hopefully that will improve and there's another guy who's been around for a long time actually that I could approach so for the next update I should be quizzed on what progress I've made on getting these maintainers on board oh additional information yeah so this this is the idea of having someone a new contributor to act as a as a right I think contributed not maintainer as like a hyper legion liaison person so this might be the person somebody from Tata consulting who is interested in working with the open source community and I think can just probably spend a little bit more of their time really reading like every what you know most emails on the mailing list and it's not to say that I wouldn't be available myself but could I've got other stuff to do as well and it'd be good I think they could kind of increase the contributions from people who maybe had like a few hours a week it would be interested but maybe the the setup is is is a bit too much of a pain so someone who could just be on the hyper ledger chat but yeah like I said I think the Tata people would do that but if if anyone else from hyper ledger wants to to help us like a liaison that would be cool and that's all that was great thanks for for that download yep that was very very nice pardon me okay thanks Alice so who's doing the explorer update hi Chris this is part of the I'm on from can we can we do the update next week oh I see it hasn't been submitted okay I wasn't sure yeah that's fine okay we will upload to the wiki and then we'll do the update next week okay yeah I think satish actually I think satish actually put out the update I think it's available now so I just don't know if everybody's had a chance to look at it yet I don't have a link so so Tracy I just wanted to know a few things in that update and then we'll repost that one okay thank you cool and then Chris just heads up we'll do a hyper ledger fabric next week as well yep so is our know on I didn't see him earlier he's not Tracy do you want to drive the the lab's proposal I know there's been some discussion and some updates and comments in the margin I think our know is probably closest to it but maybe we could just have a discussion about sort of where things stand and what issues people still have I think there's still a little bit of how should we say concern about you know sort of what types of projects and so forth I seem to recall yeah so I mean if you look at I think what honors done is he's quit some bold issues in the actual document itself things that I think maybe discuss as a group so maybe we just go through those it looks like five separate issues and maybe just have discussions on those points and see if we can come to any sort of conclusions on them okay that sounds like a good plan you want to drive okay great sure I'll drive so the first issue that I see is under the governance section there's a question around what's the decision process and and do we do a vote so basically this is around understanding I think which projects actually come into the is this that one or this is actually who the maintainers are it looks like so how do we decide who these maintainers are and and then also the the next question is around the actual committers to is it committers to existing projects that can be the maintainers which is what the Apache software foundation does for their lives projects or you know could we open up the maintainer and committed list to other folks as well so those those I think are kind of a combination of two issues that we should talk about so another thing that I think is an important issue is this will kind of be one of the first projects where we have kind of two types of maintainers for the project where it looks like we have some kind of higher level labs maintainers and then we have some people who are actually maintainers of the code right so if I want to submit a project to labs then I get lab maintainer approval but then I might be still maintainer of that the code underneath these lab maintainers so we almost need a completely you know a you know a complete new governance model so what so so hard just let's be clear I think and maybe you know maybe we just need another name the maintainers for the labs org do not serve as maintainers for any of the projects right doers if anything else right of the organization making sure that they're the ones that sort of are the gatekeepers for what goes in and responsible for you know pruning the garden periodically and archiving things that are no longer relevant or being supported and so forth um yes when you know when you add a project to the labs then that's your project and you get to decide how it's governed it's you know it's not really uh I mean I think aside from you know periodically getting a report from the let's call them stewards of the org on the health and you know well being of the various projects inside uh the labs org I think the intention is that nobody gets you know the the stewards don't get involved in the maintenance aspects of the various projects that's again it's whoever submitted it that's their that's their thing right and with what we've done even at this level right when you know monax contributed borough well you know they get to choose who the initial maintainers are and they get to choose the process for adding new ones and so forth and we haven't really you know gone to the point of insisting on absolute consistency across all the different projects about how they make those choices um and I think that's I think that's okay I don't really have I don't see a need why we have to sort of be dictatorial about things I think you know it's best to sort of let the projects work their way through and and manage themselves as they see fit and and again I think I see the same thing in in what is being proposed for the labs I wouldn't expect that the maintainers for lab project X to be maintainers of the labs org and I think that's a different set of people so if we want to call them something other than maintainers we're going to call them stewards I would be hung I would be fine with that okay yeah that's I mean I had I think we're talking about the exact same thing here I just was hoping for a little more um maybe information about what happens if the say lab stewards and the lab maintainers disagree about something like if the lab stewards want to like deprecate or end a lab project and the like lab maintainer of the project is not just things like that um these kind of corner cases that's all I was wondering about I think the lab steward is a great name um and I kind of had the same structure in mind as you did as you mentioned okay um so I think go ahead Tracy no go ahead Chris that's fine I so I was just going to say that so basically in heart what you're really looking for is a little bit more uh definition around the criteria for adding things in and printing them out over time sounds like exactly having a a little bit more specificity around that I think would eliminate the possibility for there to be conflict like you're describing if you have objective criteria that you can use to make those decisions is that yeah I I agree so then it seems like we have some pieces that it looks like our know has probably added since we last reviewed this that I'm highlighting now which are you know things that must be true before this can be considered for a lab but I don't um I don't think we have anything except for um timing as far as like how long this hasn't been touched uh as far as when we would deprecate something um so you know I think you know what we're talking about then is just this concept of a little bit more around deprecation of projects and when they would be deprecated and then maybe even uh a little more specificity around um this decision process right is it all all stewards have to agree that this should be a labs project is it you know two-thirds what what is that um that vote that would happen that would cause something to be either accepted or rejected in the lab does that sound right then yeah so I also had the question of whether you're expecting the stewards to do any kind of technical review of the projects being proposed for labs and if so how much of a technical review I would think not yeah I agree I think yeah I would agree that there's a certain amount of evaluation up front does it meet the mission and so forth but I don't necessarily consider that to be uh from a technical perspective it's not good or whatever I think I mean so the the issue with just completely no technical review that I have is that if I write up a Caesar cipher it will meet the mission and be faster than everyone's you know crypto code right or things like this right I if I have um if I just if I try to do something that extensively meets the goal but my like proposed technical solution is just totally wrong it sounds like yeah I'm thinking about these is this is a sandbox and people can do crazy things in a sandbox and you shouldn't go grab something out of the sandbox to go put into production somewhere because I want to go figure out something between um uh hyper ledger explorer and and uh burrow and yeah I'm going to connect them somehow with a Caesar cipher and maybe just a little proof of concept to make sure that the integration is is feasible but nobody should grab that and use it until such time as I say all right this is a this should be a real project and then I try to promote it into the regular project pipeline yeah I totally agree with you Dan and I think that maybe for deprecating uh projects we should say that if there is a in general if there is a disagreement between maintainers and stewards technical steering committee maybe is the the body that decides actually pretty related so if you remember like how we came up with the whole hyper ledger labs kind of initiative right we were worried about the brand right and then there are a few comments there about the endorsements right like whether we want to have hyper ledger endorsing labs project and at what stage is the labs project and we don't know how much it is right so like we're done right that we shouldn't even recommend or we actually we should recommend people not to use a labs project that is even pre incubation and driving production but what we do give people I think in the hyper ledger labs versus just putting it in github or in any other kind of repository is that maybe they will be exposed to more of the community right there because hyper ledger has a world community so more people are going to look at it so even if the stewards are not going to be that technical they will be able to to get some feedback because the minute there is a hyper ledger labs project one would assume that more people will look at it and if it's like a super fast cipher that is not secure or why are we reinventing the wheel other people in the community might say something which is much different than me putting something in github or github or just giving to people sometimes so I think that you know because hyper ledger is growing in popularity and visibility we will get a lot more feedback I'm not I'm a bit worried about kind of people not seeing it I think it's really improving visibility and maybe yeah maybe maybe the stewards should be more kind of the maintainers in in the sense of the operations right like the management of things and if there are conflicts yes you can yeah like the mother says yeah we can bring them up but you know it's like I don't know where is the where is the kind of break even kind of point between over managing and kind of over controlling all being too free and then again the concern that we are devaluing the brand every two people are going to check in some project hey this is hyper ledger labs project so we need to strike the balance right I don't know maybe we'll see what time as well I don't know if we know everything now but I think that we will get a lot more feedback from people if it's a hyper ledger labs project compared to like something in git and then people fighting over ready whether it's an expert or not yeah I would like to think I mean I I'm I tend to agree Jonathan I think that you know we want to be careful that we don't make this too much over the top because otherwise then what's the difference between what we have now right you know yeah we need some freedom right yeah yeah so one of the one of the comments that Dan had made about you know five different people and you know maybe two or one and I was thinking maybe the thing that we want is you know for for going in anyway is some sort of a mentor approach like the patchy software foundation uses for new incubated projects we may even want to think about that for incubation but you know or maybe we could have like you know to get into the you know there's certainly the stewardship aspect but maybe part of that is working with a mentor who's maybe a TSE member or maybe a maintainer for one of the other active projects for instance um uh help them with their proposal and and essentially sponsor their their entrance and and that you know part of that could be you know just helping them make sure that they have people interested in what they're doing and so forth thoughts on that I'd like to sponsorship Chris I um I want to make sure that we ensure to have diversity of our labs projects right the same way that we want diversity of our projects and maintainers so we need to be just careful and aware of that right that we're not falling into any sort of um you know case where it's like oh well I don't like that person or I know we wouldn't do that but you know what I mean is like how do we ensure that we um kind of keep an open mind with these labs projects good point but I do I do like the sponsorship I think that's a great idea right I think um it helps kind of I think the whole point of of the resource right is uh having the ability to have that mentor help you kind of understand kind of the the rules of the game and how things work and um really helping you see like how the best way is to contribute right and and I think we need to do that even more than we do today plus one the the only downside that comes to mind with a mentor is it it seems to pull things closer to the existing projects so if if I've got some idea from out in the left field I need to go develop a relationship with somebody who has an existing project that's really not a bad thing is it down I'm not sure um it is I think it's okay unless the sponsorship is a requirement um but otherwise you might end up in a bit of a sort of like self-reinforcing thing I also think that from the um I think the stewards from what Hart was saying um I think stewards should be like newspaper proprietors like they should have a nuclear option of firing the editor but they shouldn't have any editorial control so you know is it like and I think that would put a nice like if there's I think it's a good idea not to have ambiguity about where the stewards should be having an opinion on code because that's almost more likely to make conflict but you know if someone's putting out stuff because I mean clearly there is some tacit endorsement by hyperledger of labs projects that's kind of the point um but yeah so at some point it must be possible to to kick out something that's really low quality but you you probably will be more likely to sled it with a rather than do that yeah I think that should do for me that yeah less technical so the reason I like the sponsorship idea largely because it provides two things one is a little bit of resistance um so that you you know you do have to build a relationship with the hyperledger organization if you're going to bring a project in the labs um and the second thing is the um sort of technical sanity check um I agree that we don't want to be in a censorship role um but it does make sense to have at least some um well sanity check on on the kind of projects that were accepted okay well a related concept is uh like the third issue note there about in Apache they require you to be an existing committer or an existing contributor so would we want to put up a requirement that if you're going to create a lab project you have to have at least one commit into some other hyperledger project yeah that would be nice I wonder if that's an even I mean it certainly could be nice but I wonder if that's even a stronger um reinforcement thing they're just having to find a sponsor who was willing to think it was a good idea um I don't know or you just have I think it's a wicked project right you need to like work with some projects show that you've tried to I don't know compile build run change even if you change documentation know at least you try to to get some people to look at what you do and then you also get you know people will get familiar with you right so you know Joe Smith comes in and basically send something to some project we see the reaction it's it you know it's at least something more than nothing that's of like how we I don't know I use this point defense you know like code review suggestions and stuff it's it's it's another data point but I don't know let's hear all the people that's my view I said this in chat but I'll say it again I think that within this organization we have a lot of different people with many very different interests across blockchain and if no one uh in the organization is really interested in a proposed lab project that's probably not a good sign yeah I think we're gonna have a similar problem that the enterprise theory of reliance has right everybody's pulling in different directions we should be careful of that right otherwise nothing will take off well we we don't have this problem because we have a core that is really strong but I'm just worried about it like really side side projects that are remote and two people just doing it just for the branding or to raise money for an ICO we're really concerned about that kind of behavior right there is some risk there yeah and I agree with it we want to be careful about that risk but I also think that when we say sponsorship we're not trying to say something as strong as what we're saying in say the project proposals for the incubating projects that are coming before the TSC we're trying to say we're trying to get something someone to vouch for this is somebody who's who wants to do this for the right reasons and that that the person sponsoring is has looked at it and said yeah this has some relation to what hyper ledger is such that it's something that should be in the lab as opposed to maybe the TSC as a whole when you evaluated an incubating project where all of us make that determination in the labs we're after something maybe a little bit more casual but we're still after some somebody looked at it and someone said yeah this belongs in hyper ledger for for some reason yes I'm not hearing any disagreement on on sponsorship so would we want as a secondary threshold also this criteria that they must have at least participated in some way on one of the projects even if it's you know a single commit isn't that a stronger requirement than currently proposing a project to TSC for incubation because we don't require that for incubation so that's an interesting thought Dan um and I think you know Marta has a point there but maybe not necessarily just participation but use of might be a criteria right if you uh or if you're you know extending in some way an existing project maybe that's yeah so what I read from the Apache governance page was that they're using that commit as a very simple social filter that this is at least somebody who's who's been willing to participate in a healthy way at least once uh and there's that aspect and then we could I'm not sure how I feel about it one way or the other but the other justification there is maybe twofold one is you've at least exposed yourself to something else in hyper ledger so you aren't trying to create uh something that you should at least have the right context for for proposing whatever lab idea you have and then secondarily you've you've had some sort of proof of work if if you'll excuse the the analogy there that you know you've you've gone to some level of effort before you've you had some costs uh in addition to developing that sponsorship I've got an outstanding poll request that's been languishing for months is that proof of elapsed time then um uh does it have to be an accepted poll request or does it just have to be that they've actually participated I think one motivation we might see from someone doing the lab is that they're doing something that really can't be merged and their motivation was to engage in a project but then they realized you know this is too riskier to experimental so let's can I have a lab for it instead yeah that's actually not a bad thought it sounds like maybe the way to approach this rather than weakening the idea of having a commit which I quite like in some circumstances um you know it's just being participation or whatever like maybe we could have a different types of evidence that would be acceptable so for example yeah an accepted commit uh like maybe an open poll request that couldn't be merged in in the circumstance just mentioned perhaps as well in another case would be you know if you've got a project on github that clearly has traction um then it would maybe seem a little bit odd to be having people jump through hoops if it's if it really is you know relevant I guess there needs to be some way to prove that it's that relevant type alleged but um you know something that's got many thousands of clones and it's starred by people you know like that that seems to have already passed that filter so maybe you could have multiple ways of establishing traction or whatever we want to call it so I think out of this discussion I'm hearing a couple of different things the sponsor idea well three things actually so call of stewards not maintainers so we don't have confusion around roles and so forth the second point was um sponsorship thought should be um fleshed out and then the third would be the um engagement aspect so restricting access um to the labs to um contributors committers of an existing project is there any disagreement on those three points I mean again I think they need to be fleshed out but I'm not hearing anything press okay um so the the the other issue then I think you know down below pertains to so who are the stewards right and how are they chosen or how are they anointed I think you know the proposal there seems to be volunteers with the approval of the TSC I don't I don't have a problem with that necessarily um I think obviously the staff you know the community architects I think are automatic unless anybody disagrees with that and then having volunteers with approval from the TSC seems reasonable I don't know that we need that many and the only other thing I might think about would be you know maybe it's is that maybe it's a role of you know that if actively fulfilled sort of grant somebody access even if they're not necessarily a regular contributor or a committer to one of the projects to satisfying the criteria for actively participating in in hyper ledger thoughts on that absolutely if someone is a steward they should be counted as a active participant yeah as I said in chat I'd prefer if the proposal names names for initial maintainers so if the proposers wouldn't mind doing that that would be amazing I assume it will be you know Tracy, Marta, Arno and maybe some others but I think if you know those should probably be named in the proposal I think that's actually required that we name the initial maintainers well at least just for incubation anyway true because if it's approved what do we do on day zero right yeah I agree it's going to be good to start with unknown sets I agree huh so we need to make Arno volunteering I think Arno actually volunteered in his previous call so I think that's okay yeah okay so any other issues oh this one we're down here seek to some sort of agreement as part of a lab creation process I think to me it's you know I was wondering as we were talking right and this one kind of brings that to mind is you know we have a proposal new project proposal template that we fill out for projects going into incubation and guessing that Arno is asking should we have a similar sort of thing for the lab's projects and is that like an agreement right that you will do XYZ as part of being a lab yeah I think I think you know what we discussed a little bit earlier was refining the criteria that there was a fourth the thing I forgot refining the criteria for you know deprecating and so forth needs to be added I think if we had you know similar to what we have for Reader projects had a life cycle proposal you know or a life cycle document for the labs that that covered captured this I think that would be good I guess it could be part of this proposal itself keep things a little bit simple and it seems to me that that would be the criteria or the agreement if you will they're agreeing to abide by you know the criteria that we established if they dump and run and you know after some period of time the stewards find that nobody's answering issues or questions in chat or anything like that then you know the project is deprecated and eventually archived or do we do we think we because we we don't have an agreement for instance for you know the the top level projects there is a proposal yes but I don't think anybody's necessarily signing some agreement other than the IP aspects of things where they you know put the appropriate license and so forth but that that's already part of this as well I think it's a nice idea to have some kind of a charter that is maybe not too involved and then it's the stewards job to make sure that the lab projects are following the charter whatever the charter means okay so it sounds like there's no strong in favor of having some sort of agreement or anything it's more this is our proposal for hyper ledger labs and we expect that you would follow kind of the the ideas that are presented here is that really kind of what I'm hearing then right where this is this proposal is kind of considered to be that charter or we would end up putting together a separate charter then yeah I think you'd best get all that criteria into this proposal okay yeah and I guess it could be organized that you know here are the criteria for you know remaining a labs project boom boom boom if you fail to meet that then you get deprecated and then archived okay yeah I think you definitely need there needs to be some definition of active but even if it's only one person who's bothering with it yep okay all right so did we catch the and then uh yeah just one last chat I see in the thing um so boz as uh volunteered to be a steward I know that boz had reached out to me in the email when we originally sent the labs out on boz's from the blockchain tech deep diving uh in the last minute I'm sorry in the Netherlands um so I don't know all you know how we want to handle that one um well pardon me I think um two I think it was either Dan or Silas was suggesting that we um have the list of proposed the initial list of proposed stewards and as part of this thing and then when they agree to it that's the initial set all right okay um although yeah I think I think that should be fine um he may want to introduce himself a little bit more to the tsc but yeah and I recall boz from some early contributions that that he made to sawtooth so certainly in favor of uh his continuous contributions here well we have one minute and I think we're pretty much um good with this again you know please feel free to chime in in the margins um I'll catch up with Arno and we'll see if we can't close this up next week all right thanks everyone thanks guys thanks everyone all right bye let's bye thanks thanks everybody bye