 We can get going then. Morning everyone, or afternoon, or evening, or whatever it is, wherever you are. So the first item on the agenda is action item reviews that will be followed by the working updates. PMOS has a request for a repository that I think we should discuss. And exit criteria, again we, one of the action items was to start a discussion on exit criteria, which I did do, but it sort of petered out and I think we need to figure out how we're going to move forward on that. And then, actually, maybe we should move this first, the TSC representation policy. And Mike Donner, you wanted to call, I think I saw you on the list. Yes, I'm on. Yeah, so, and again, I think Patrick is on behalf of MEC, but something that we didn't, there wasn't written into the bylaws, the governance was any notion of a proxy for the purposes of representing somebody either on the board or on the TSC. And Mike, you want to sort of go into some of the history and essentially how we handle this in other groups. I know that many people who may have participated in standards organizations are accustomed to having the ability to sort of proxy or have somebody come in and serve as an alternate. But we haven't been doing that in the Blemings Foundation and Mike, maybe you could just sort of give a little history and background. Yeah, it's not typical for us to have alternates in terms of voting alternates if there's something that's up for vote. So that's why a lot of times our TSCs actually use email for voting just in case somebody can't make it. And so that's one way to resolve the issue of the alternates, because anybody can join this call. So it's not, it's not like it's just open to TSC members. And so anybody can join in, call in, talk, participate. Obviously, if you've been on calls prior to this week, it's pretty wide open in terms of getting everybody to chime in. In terms of voting, though, that's usually where they do like to have the person at the meeting where it becomes more of an issue. So in this first initial startup phase, the first six months that's in the charter, it's by representation of the premier member. So from that perspective, you know, if the TSC wants, I think the key thing is just for the TSC to agree on how you want to handle this instead of because Todd came to me and asked me, you know, hey, how do we hand alternates on this project for this? And you know, this is where it's up to the TSC, if you guys can just, you know, come together on agreement on how you're going to handle alternates. And I would look at it in two phases both in the startup phase, the first six months and then going on after, because in an open source project, you know, here's where the issue comes up. So somebody is, say, the lead of a project or elected to the TSC because of their leadership on a particular project. You know, what happens if they can't make it? Should they be allowed to just send somebody else from their company? Or should it be something where an alternate comes from the project that they're involved with? You know, that becomes the issue. In a standards body, it's typical to send an alternate from your company as a proxy because you're basically signing up as a company for votes. And that's how it works. In an open source project, that is not the norm. The norm is that if somebody can't make it, then it should be somebody else from the project is the norm of what we usually see. And so we're in this weird six-month phase, or it is more like a, probably more like a standards body, but after that six months, I think you don't want to have the same expectation going forward. And it would be good for the TSC to clarify this before we get to that six-month window. Yeah. So, anyway, that was just kind of a phrase. Right. Yeah, so thanks, Mike, I appreciate that. Basically what I wanted to have a discussion of here and maybe even get an agreement. From my perspective, I think that this first six months is definitely sort of an outlier. We set it up so that each of the Premier members would have a seat on the TSC for the first six months. And after that, we're looking for people who have been contributing into the community and they would be nominated and potentially elected into the TSC. And that's based on their individual merit. And so just as you would get a commit bit based on your individual merit, I think the same applies to the TSC. It's an individual. If we have, one of the functions of the TSC is going to be that a project lead would be automatically represented on the TSC, but then there would be others that are elected. So I think, as Mike suggests, that it's probably wise if we come up with a formal representation policy and then take a vote on that. I'm not suggesting that we do that right now and today, but just get people to sort of weigh in on whether they agree with roughly what was outlined, which is that we would permit it at least for this first six months, which is actually we only have about two months and a four months left, but and then after that, after we have the election and we have a duly elected TSC that we would, from that point on, it would be, if you're on the TSC, you either have to be in the meeting order and if we don't reach core, we can't take any kind of votes and so forth and we'll have to take it to mailing list as Mike suggested. Any comments or thoughts on that? TSC membership from the contributors be evaluated, meaning if, let's say that you have 11 members or 12 members or more from the contributors, the project leads, the maintainers and so on. If one or more of them do not show up for a considerable number of meetings, let's say three or four in a row, then what happens? I mean, in other words, for whatever reason, you know, I can't pick up many, many reasons why people will not show up. So then, does the business of the TSC go on in spite of lack of quorum or does it continue? Well, it depends on how. If it becomes a firm issue, you can only discuss it. I should have also said that many of our TSCs don't have any alternate option available. So their expectation is that, you know, we're scheduling around, you know, a ten or so people, and, you know, they should make every effort to be there, and if they can't be there, you know, the agenda, you know, they should generally know what's on the agenda and weigh in ahead of time, and typically, we do take votes offline via email anyway, so it's not usually that big of a deal to, you know, miss one meeting, but, you know, it does get disruptive if somebody is not showing up to any meeting, and certainly they can, you know, evaluate, you know, what policy, how do you want to handle that, you know. So Chris was asking, Chris Rowan was asking in chat whether we are always going to have weekly meetings. I doubt it. I think once things settle down, it'll probably be every other week or something like that. You know, whatever seems natural, but in the bootstrap mode, obviously, there's an awful lot that we have, you know, to recover, and so I think for a while, at least, we'll be going with weekly. And then, you know, to your point, I know a number of Senor's bodies also have some sort of a policy, you know, three strikes and you're out kind of thing and you lose your voting privileges, and that's, you know, that's typically when it's representation by a company, and there's also an opportunity for an alternate, and so in that kind of a situation, it's actually much more egregious, right. But you know, since we can do things like, yeah, exactly, OASIS allows for leave of absence of W3C does as well, and, you know, typically what happens is, you know, the chair will, you know, reach out and say, hey, you haven't shown up for a while, what's the deal? Give them, you know, a chance to get back on track, and if they don't, then, you know, oftentimes, you know, the best way is just to coach somebody to say, hey, if you really can't do it because you have too much on your plate and your day job or whatever, then maybe you could step aside and somebody else could be elected, and I think that's probably the best way to handle it, because you go to dinner or somebody from Winx can coach somebody to get back into participation or, you know, gracefully step aside. So, I guess what I could do is I could take an action to draft up a policy that we could use for the first, you know, for the remainder of the first six months while we were by members at the premier level, and then we would basically have it be, you know, that there would be no alternate except for projects, but there wouldn't be an alternate on an individual basis because they're representing themselves. That makes sense? Anybody disagree with that course of action? Okay, I'll take an action then, Todd, if you wouldn't mind recording that, and I'll draft up a policy you can cover it next week. Bring it up to vote rather. Okay, action item review. So, Todd, the first one is the tooling meeting, which is going to be held right after this, and I'm bad because I forgot to spin the list again. Yep, the call-in details were sent out with the agenda that went out yesterday, and you can just surf to the week you won't get held for the exact dial-in details. So, anybody who's interested will be having a meeting with the infrastructure team, and we'll be discussing, you know, getting Garrett stood up, getting Travis integrated, and so forth, and various other things that need to be done to get us fully up and running from an infrastructure perspective. And so, I'll be immediately following this call unless we end early, in which case it'll be at 8.30 a.m. Pacific. And then the next update, Todd, would be the technical face-to-face. I think we have results from the doodle poll. Yeah, so in terms of dates, looking at the Thursday and Friday right after consensus at the beginning of May is looking like the best. I'm chatting with a few companies right now that can potentially host space for us. I'm hoping to close on a answer by end of day today so we can get that move forward, just waiting to hear back there. All right, and we'll be able to sort of close it up then on the mailing list and select so that we can get our registrations up going soon. Yep, exactly. Okay. All right, thank you. Next up was Dave Vole to finalize the wording of the white paper draft 01 or 0.1 rather to get in front of the board. How's that going, Dave? Yeah, so it's probably going to be a couple more weeks before we have our first draft done, to be honest. So, you know, we discussed in our working group meeting yesterday that we want to be able to devote a full session to having, you know, here it is, let's go through it one more time, make sure that we're ready to, you know, generate that PDF off of the Google Doc and post it on the site. So, you know, basically that first draft is what we want to be able to put out there and then, you know, there's going to be that one section that talks about public versus private that we just wanted to highlight. So, you can see the first draft, I'll be able to zoom in on that one, that's the only thing that we had actually identified that we just want to make sure that we're all on the same page on and that's likely going to be, you know, a couple more weeks before that's ready. Okay, all right, so then let's, Todd, let's just amend this to skip a week and then it'll be due to the 28th, I guess. Yeah, well, no, no, what's today? You were right. Yeah, right. Okay, Cheryl, I can't, for crying out loud, here. Where was I? Oh, next up is Patrick to set up the STL repository. Patrick, what's the ETA on that? So, we'll have that done by the next meeting. Okay, and is Patrick, is somebody going to be able to attend the infrastructure meeting that we have next? Because I think, you know, it's important that we at least, you know, have somebody from Intel there to understand what we're going to be doing. I will be attending as much as I can. Okay, awesome, thank you. And the last one was for me to start a discussion on exit criteria, which I did. I created a Slack channel and there was some discussion, but we need more. And we need to start getting a little bit more serious because I think people are going to want to start pushing for things. But if we don't have any exit criteria, it's going to be hard to evaluate graduations. There's somebody on a phone that's full of background noise. Could they go on mute, please? Chris, I'm just going to mute all lines and then you want to come off mute. Okay, thanks, Todd. Okay, work group updates. Patrick, you're up first. Okay, we all held our first regular meeting on Monday and Primrose so walked us through the counterfeit drug use case. In that process, we recognized several improvements that could be made to the use case template, and I've made those. The next meeting is Monday where we're going to walk through the requirements section. We didn't even get to the requirements section. We just got to the use case description and in some other areas, the upper part of the document. So this week we're going to walk through, not on the counterfeit drugs use case, but just in general, what are the requirements we're collecting for any use case. If you know people with skills in writing use cases and requirements, please send them to us. And that's it. Except I'm on mute again. All right, thanks Patrick. Ron, you're up next. We need to come off mute. Hi guys, sorry, just came off mute. So we had our initial kickoff meeting the previous Friday. So we had a very decent participation and we decided that we would have regular meetings biweekly starting next Wednesday at 9 a.m. Pacific. And so we had a discussion about the tools that we're going to use and we decided to use Slack as the primary communication channel. Also, one of the things was the list of issues that we wanted to discuss. We had about seven or eight topics that we could get started on while we wait for the requirements group to kind of come through with the requirements track. So we're going to get started with some of those starting to discuss those. And so we had a good kickoff other than some WebEx problems. But we managed to get through that. So that's where we are. And thanks to Chris Allen for helping me with that. That's about it. And again, I'm mute. Awesome. Thank you very much, Ron. Next up is Dave. And I guess Dave, you basically gave your status, but anything you didn't already cover? Well, yeah. I'd say, you know, most of the meeting we had yesterday, we were reviewing Renat's proposal for feedback. And so we were able to put together the right process procedure forms. And we all agree that that's the right process. So it was all accepted. And thank you, Renat, for all that. Basically, what we're going to do is, when we do post our first draft, we're going to include the link to, we're going to be using a form, Google Forms. And Google Forms has, so there's a form that people will fill out. They provide an editor's view, so we'll be able to have a list of all the people that have provided feedback on our drafts as we publish them. And then a portion of our weekly working group meeting is going to be dedicated to reviewing the feedback for updates into the white paper. So that was an accomplishment. We got all that figured out. And then just proceeded with additional reviews and edits to the to the white paper. So that's pretty much what we did yesterday. Alright, thanks, Dave. Chris, Chris Allen, Identity. Yes, so we had our kickoff meeting on, you know, last week we did have a discussion about, well, first off, we had 32 people show up during the meeting, so it was very well attended. Fairly lively intro with a lot of thoughts about, you know, where does identity fit into things. We did decide that we had some independent goals, then just having it be part of the architecture or requirements working groups, that there were some things very specific to identity that people always wanted to be able to articulate and be able to, you know, move the specifications forward and such and contribute to requirements and architecture and other groups. There is some live notes of the first session, which I posted in the chat. We are planning on meeting bi-weekly on, you know, alternative weeks from the architecture meeting, so there bi-weekly, we will be bi-weekly. We also will be primarily using Slack. I guess the final, you know, sort of an open question after that meeting was, you know, our, you know, one of the days we were talking about for meeting is the same day as the face-to-face. So we were kind of wanting to know how the face-to-face agenda might work and is it possible for us to have the identity, you know, meeting during that with some kind of call support. That's it. Thanks, Chris. Let's see. And finally me, the continuous integration working group, we're meeting in about an hour and we'll give you an update next week. Not much to talk about yet. Okay, and I don't know if I'll be leading it, but I'm cat herding it for now. Next up is Tomas. Tomas, you had sent out a request for repository and some naming. Maybe you could review some of that and the motivation, the rationale behind it. And then we can get into a discussion on that. I'd like to create a GitHub repository within the hyperlature. This would contain a subset of digital assets proposed code base so that we can build the joint proposal that we created on the cap alone on the last face-to-face just by using hyperlature repositories. The code I would move there is defines a generic data access interface, the blockchain, it influence key generation, transaction composition, account level integration of UTXOs. And this code, this is the code that we actually connected to OPC. The code repository would build a Java artifact, a Java jar, that would be then included into the build of the fabric to build a joint proposal. This repository, this piece of the digital asset code is also a piece that we use in our own internal development in creating solutions for our clients. So we know that API is helpful, probably helpful for others. And that is why I suggested to name this repository API and move that code. This is basically the suggestion that I'm waiting for comments. Hi, Tomas. This is Dave Vahl. I sort of thought this was a natural output from the agreement on the code base anyway. Is this a change in plan versus on how that your code would be represented in the that was originally discussed and being represented in the repo? It does not change the discussion. I think it is a natural way to implement it. The wording of the original proposal was not explicit about this and I thought that it would be better to bring this up so there is no confusion or it doesn't nobody feels hard by the kind of setup and setting up another repository. So I'd like to ask, this is Patrick, I'd like to ask the same question in a different way. Does the fabric repo that's in hyperledger today include this code? No, it doesn't. The purpose of fabric was to incubate the code that had been developed in the face-to-face which included the digital assets. No, the face-to-face did not actually create a repo that would have included both code bases. On the face-to-face we were building from two distinct repositories and we were connecting the resulting services with each other. Okay. Tomas, this is Stefan. How would that code interact with the code that's currently in the known as fabric via the interface or would you code it indirectly? This code would be connected to the fabric through the implementation of a GRPC connection between the two because they are two distinct technologies. So this would be a connection between services, yes, the same day as we had in the output line. As it's your blockchain, could that be seen as an interaction between two independent blockchains or how is that to be understood then? No, the code that we contribute here in this repository is not an implementation of a blockchain. It is an implementation of an application development API and utility functions to use a blockchain. Okay. It's your client layer then as you called it in the face-to-face. Yes. Okay. Thanks. Richard here. So that seems sensible. My only request would be it's just as fabric is unhelpful as a top-level project here and maybe we need to get on to the readme which I've not been paying attention to but it should I think actually maybe Chris Freiland saying the same point in the chat. It shouldn't be called API at the top level. It's associated with one of the projects under incubation that should be scoped accordingly. So and you know again my concern was I guess there's sort of two-fold. One is the sort of the generic name and the second is just the complexity of the build increase is because now you've got to deal with sub-modules bumping and you know when you submit a pull request to one it doesn't test the other and so forth. It just it makes for a much more difficult CI pipeline to manage when we start having multiple things that need to be assembled from multiple repositories. But I think to us if it correct me if I'm wrong but I thought that we also were going to sort of start with this approach but then gradually merge into the fabric repository so that we could have a single repository to build and test against. Is that still? There are different technical motivations for how wide this setup is as I'm just suggesting. For one these are really distinct technologies so creating common build script even if we would move them into same repository they would probably use the entire different build mechanisms and it would still build two distinct artifacts that are connected as individual services. So it might look optically more related but the actual technical process would not change at all. The second reason is that this is certainly a work in progress and this code this piece of code is part of our current stack and our internal stack that we're working on and it is this is the the simplest way to separate and enable us to be able to maintain both code bases and at least until the Hyperlogel Foundation's J creates a solution that is that allows us to replace or with your internal effort. We hope that this will this will happen quickly and as soon as we are converging and as soon as it looks like we are near to it there is no problem in moving this code into into that target repository but at this very moment having this code inside another build with other build scripts would pose a significant effort on our side to merge code back and forth between the two supported stacks of digital asset and this would not only be a bigger effort on our side but I think that this would also not be beneficial for the community because it would mean that all capabilities of moving code between the two would be limited by resources and probably it wouldn't be as vital and living repository then if we managed to run the two in parallel with the shared repository. Did this explain the motivation and I heard that there are concerns about the generic name API. I could also imagine that we call it by the technology as Java API or we call it by the currently proposed fabric connection, fabric API. I don't know what people would prefer. So is it that is it at this point that it will only work with the the fabric repository or do you feel like this is going to be something that would be useful if sawtooth lake moves forward or a third incubation thing moves forward? Well we currently aim to support the joint proposal. This library however contains useful functions. It defines a very generic on the same time use-proven access to your blockchain. It is an open source project. People are free to do with it what they think it's suitable for. I think it has utility functions that might be interesting and maybe it helps to speed up other developments too but it's currently a focus. Hi I would say it should be renamed as DAH underscore whatever that Java API because for clients some of our interfaces could be you know something else other than a Java interface. They could be a JavaScript node.js or JSON interface as opposed to a the proposed DAH Java API interface. So this right currently as it is only talks to the the what was tested from IBM the OPC from IBM but then somebody needs to also look at the Intel API right and how to access them. So this is just my my two cents. Could be DAH slide Java that API. Thank you. This is Mike Dolphins explanation. I don't care what you guys call it but do not use company names or trademarks on the repo names please. Just not not a good practice. Sorry. I agree I agree that API yeah that's one The test for me is when somebody who's not part of these calls or part of the project comes and lands on the top level get repo and looks at it we we know we have to think about how we communicate what's going on and how things relate to each other so as long as it's clear from its name that at least now it is scoped to or works only with the the the the BOP OPC converged code-based incubation project and we don't yet know or we maybe know it doesn't work with STL or anything else that comes along then fine. So so whether it's scoped it's well mental down or it's got no fabric at the beginning of whatever and I don't remind but but it can't be something generic is already fabric is generic and I worry that's going to confuse. Yeah that's Richard. Chris here. This is a question for you Chris you know in regards to the CI working group and maybe the tooling working group or whatever there's going to be a variety of people who are going to want to submit things that aren't really technically incubations that are useful tidbits for this and that maybe used by multiple incubations. I don't know I mean you don't do is there's what do you guys want do you know do you absolutely want these types of things to be integrated you know are there some technical reasons why it can't that you guys might be able to solve. I'm just wondering if this shouldn't be pushed into an action item of another group. Yeah so so Chris you raise a good point and actually you know there was some some conversations in Slack and elsewhere I think on the mailing list about you know people with code that they were developing and they had their private repository. I think somebody who was the guy that goes by Joe Quant handle had built sort of a docker you know a vagrant list if you will procedure for standing up all the various docker containers and you know something like that I think is fairly useful you know it remains to be seen yet whether it's somebody something that somebody wants to formally incubate or and again it's related just to one of the currently incubating things I tend to agree you know it's like where does that fit if it's often somebody's private repository and somebody wants to contribute to it that can create you know some well it potentially can create some problems depending on how people license it as to whether or not they're able to contribute certainly I know I know that from an IBM perspective we have to go through all the sausage grinding of getting approval to even submit a bug fix to something small like that and but if it were under the hyperledger project in some capacity formally and you know the governance of you know the IP and everything else was therefore you know part and parcel of that particular contribution then you know if we had something some place where people could post things that you know they wanted to sort of let people kick the tires on that that might be useful but I think I think we need to sort of take a step back and think about this long and hard because if we have something where anybody can post you know well then it's a free-for-all and we don't necessarily want the hyperledger project to be seen as endorsing something that's you know not up to par so to speak and then you know conversely we would have to have some sort of a process to ensure that the licensing and so forth was commensurate with what we were expecting so it would have to be some sort of a vetted environment and I don't know maybe the TSC has to approve you know it's not a formal incubation proposal but it's a formal proposal to share something under the IP terms of the hyperledger project for instance I don't know I don't know Mike if you've got any insights from other projects and how they deal with I don't know they might want to that they might want to call them you know community projects or I mean I know Cloud Foundry has a Cloud Foundry community but that's not really formally under the the CFF it's it's completely independent it's just sort of their open stack has stacked a let it that's like a stack forage which isn't formally under the open stack governance but it's basically a bunch of satellite projects and but it's a free-for-all essentially just like the Cloud Foundry one so I don't know Mike if you've got any insights well I mean normally if the code is sizable enough that it's you know its own project or some of our projects have sub projects as well so like you know you can have different sub projects for instance if there is a project just working on like build tools for a project like what do you guys have fabric and then you have fabric build tools or something as a sub project of fabric you know some of them structure that way where you have projects and then sub projects and then the only ask of the community is that they align you know to at least some higher order project when they create a sub project you know some do that some do the free-for-all model you just described where they they park at all and you know some you know community working group or something repo I'm not a particular fan of that just because it is the Wild West and people start doing that then instead of going to the TSC and you know going through a review and proposal and discussion like you're doing here there tends to be a lot of sidestepping that and people just go and create stuff over there because it's just easier and quicker which isn't necessarily a bad thing but you know there is some value I think to having a community discussion around projects and things that everybody's going to work on and try to get others to start working on things together instead of having single group projects out in some third-party repo or community repo and you know some some projects you know they just forfeit force fit everything under various projects and so if you're doing a build script tooling project then you just do it under you know whichever one is most closely aligned or whatever so I don't know I have an answer for you guys and I'm not sure what you guys are envisioning either so I guess it's without it it's a little hard for me to right well in the context of what Tomas is proposing that's actually part and parcel of what we had originally proposed so it's not a separate thing it's not a new incubation it's not a not incubation it is the same thing it's just it's a part it just happens to have a separate repository Chris Allen asked a really good question actually STL has a number of different repos I'm curious Patrick is the plan to move over you know that collection of repositories no that was actually covered last last week we felt that it didn't make sense to use more than one repository within hyper ledger so that's basically an appoint to another organization where we're going to put all of the repositories okay now I'm confused it's not so let's say we have five repositories we didn't think that you would want us to create five repositories within hyper ledger organization given that fabric is a single one we didn't think it makes sense to create five for sawtooth lake so we're creating it we have another organization it's actually github.com slash sawtooth lake where we had put all of our repositories and then point to them from from hyper ledger okay somehow or other I missed that subtlety from last week and would then would would you be transferring the I guess I'm just not sure how that would work from a Linux Foundation perspective would you transfer the ownership of that word to the Linux Foundation and just what I guess I'm confused and just leave it with a pointer in the idea was we would create a repo in hyper ledger but it wouldn't have much more than a readme file the points points people elsewhere to sawtooth lake Patrick maybe we can work fine with you I can get right from our to work with you guys to figure out how to get this work in the right way I'm not sure that that's going to be a good long-term solution and I don't want to get to a point where people want to start working on things in that right and then we're in a weird spot so Todd let's take an action item for to hook up rye and Patrick and whoever on his team and we can get a solution worked out there is that right Patrick yes thanks Mike yeah Chris Allen just in chat the basic problem is the lack of really good ways to organize repositories that is so true sub modules basically suck I mean yeah I mean I think we probably need to take this offline because we're spending a bit of time on it but would I mean this is the larger problem of you know multiple repositories how do we deal with non incubated projects or you know sort of side side projects if you will or community projects whatever you want to call them I guess we'll have to take that one and think about a little bit more but in terms of the ask from Tomas he's looking to have a separate repository and there's a number of reasons that he cited and so I guess the the I saw in the chat a couple of people suggesting fabric dash API I'm curious Tomas is that something that you could live with and then for everyone else on the call is that something that others could live with as well at least temporarily until we figure out a way of doing the full integration I can leave the debts if there are no objections then we could end this discussion with that just a question you know last last week when I brought sawtooth lake to here I used the formal hyper ledger improvement process document are we going to do that on request like this well this is this isn't a new incubation proposal it's just it's really more of a naming problem and an organization problem right we had talked about doing a merge it's still it's still emerge it's just that the code bases aren't fully merged they they are built independently and they and they compose and they and they complement each other right I think that's the distinction okay it's not really a different proposal though it's just a how do you build it and how you how do you manage the repository I mean we could update the proposal to incorporate this if that seems to make sense but this is Stefan here isn't this like one of the original proposal which we put together before we start we went to the face-to-face no not quite because it doesn't again what what we the the proposal that we articulated was it a month ago I guess now and and approved had in included in it I think there was a diagram you know an architecture diagram that showed the the various pieces from the digital asset proposed contribution integrated into the OBC right and how you know how they interacted with one another that isn't changing and so it's the it's the subset of the original DAH what was it called DAH proposal or something like that I can't remember now exactly repo it was a subset of that that we defined in that experiment and that's what Tomas is going to be including in this repository not the other bits that we shaded out so to speak well with whatever subgroup is going to be doing this I think you also need to be thinking a little bit about things like you know if we have a hackathon next week you know how do people do you know things like that you know how to how do people who wish to contribute you know you know bits of code you know what's the what's their process you know you know somebody's got a great you know XYZ but you know it that will apply to five different incubations someday yeah how was that done that would be done through the same process I come up with a proposal I ask it to be incubated I prove it's worth I graduated I mean I don't know maybe I understood standing something I'm saying things that aren't say I is it true that anything that incubated should be able to graduate to mature as opposed to something that that is you know a submission that says hey this would be useful for something great for you so I don't know the answer to that Christopher I I just don't and I'm not going to say what I think the answer should be I think that's really for us to decide that's why we're all here so but getting back to the original question Tomas is asking for a repository and I guess the suggested name is fabric dash API at this point is supposed to just API are people okay with that or no I'm okay with that and as Stefan I think as we mentioned before this no we're not carving anything in stone here you know if we want to change something a little bit later we can certainly do so so if it helps you know if it's easier for Tomas to keep those the co-basers in sync and we can still build off of it you know it seems fine by me I mean names because it seems like what I had at least I heard another comment that you know somebody else wants to have a job based API I mean just saying fabric API because this completely Java code you might want to call it a Java API well just public dash Java API yeah and it implies that the API could only be used with with fabric which may or may not be the case I don't know I'd like to I'd like to draw in a drop in some other consideration in our joint proposal we also said that we would integrate block stream block streams script script interpreter for the UTXL code now once at the current on a hackathon we did not we also just took the binary artifacts there but we did not actually created a copied this this code into the into our repositories either the the code in question is actually a derived code out of the Bitcoin projects which is an open source project I think that the code has a very has a very good security properties because it is maintained by the Bitcoin community and who guard their few billion dollars of tokens and now therefore it makes sense to keep the link of this code with the Bitcoin code base so we can benefit of any security enhancements on any reviews that happens there and this if we would want to do this the way that GitHub suggests to do it that would also imply that we would have to actually fork the Bitcoin repository into the hyper ledger to be able to link that code I know that this is this would be something similar than I'm proposing here and probably spikes us even more discussion but it's a technical but technically this would be the right way to do it so my question to the community how do we deal with this composed projects and how do we deal with creating repositories now that's probably a discussion for the next meeting but you know again it's going to need a sub module link at the very least that we bump whenever it's updated and I think it's a slippery slope because once you start if you know if you if you go down the path the cloud foundry for instance is done where they have literally hundreds of repositories over 100 anyway and they require a team of 10 people to manage the release integration step because you just there's no way to just automate a build every time somebody does a pull request to one of them and so basically they require the whole process of doing release integration which means that you typically are dealing with multiple commits not single commits when you do tests and then you don't really know where in the code cause the bill to fail blah blah blah okay I'll have to sort of okay I didn't want to hijack the conversation I just want to point out I mean so we're sort of actually stuck here because until we get your code actually in under hydro ledger we don't have a merge proposal right now which is unfortunate and you know the sort of we can get that the better again it's not my preference that we have a separate repository but if that's the way we have to do this initially then I suggest that we try to do that and with something that Richard was suggesting which is to make sure that it's scoped by virtue with editing David will also that it's scoped by virtue of its name so that it's clear what this is about and so maybe fabric dash Java API or something maybe that's that's the right thing okay let's keep it simple let's make it fabric API and if any objections fabric API fine by me and let's copy into the read me something similar to or identical to the other one so that it's so people know what fabric is the same as it won't get firmly so there's still the the subject of yeah there may be another API Chris I guess that's that's potentially true but we only have one and again my goal would be that once we get that repository established that we'd be looking at figuring out how we actually can merge that back into the fabric repository so that we have one one build potentially multiple artifacts that get built out of it including you know a jar file for the Java API part that would be my my hope that we could work towards all right so let's let's do that then I think I'm not hearing any objections and so we'll use fabric API and we'll make sure that the read me is appropriately annotated so action to to moss to make that so thank you thanks where did the exit criteria so we've been talking about this sort of obliquely but again I you know we tried you know taking it to slack and having some discussion and there was some actually some good discussion by a few people but I think we need to start making this a little bit more real and actually getting concrete discussion on exit criteria I'm not suggesting we do that now but I'm going to reiterate a call that we have at least some subset of the members of the TSC willing to and anyone else who would like to get together at least once to go through and have a coherent discussion about exit criteria and put together at least the beginnings of a proposal that could be fleshed out maybe over slack and email but I do think a call is in order because I don't think we're getting the right level of engagement to get this moving without a call so I'd like to propose it Todd could we get a doodle poll to just find an hour to get the members of the TSC and anyone else who'd like to join to together to have this discussion okay thanks and with that I think I don't think there's anything left on the agenda unless anyone has something they'd like to bring up Todd gave an update Todd you want to repeat that maybe for there was a couple people that asked about that in chat yeah it's looking like the Thursday and Friday in the first week of May right after the consensus conference we're just trying to finalize on space right now I'm chatting with a few companies to see if someone's able to host it and I'm hoping to close on that by end of day today and provide an update to the mailing list thanks Todd Chris would like to join the next continuous integration the tooling meeting I'm not sure if I didn't see any meeting in white or anything like that if you don't mind you know it's just it's in the agenda and it's in the it's in the agenda here and then there's also I think in Slack and on the mailing list it was published okay okay thanks all right if then Todd just pasted it in the chat so we can all share in that all right so then if there's nothing else I'll join the call thanks everyone