 So we have I think two agenda items the first is you know after the TSC meeting last week at the close of the of the hackathon of face-to-face posted by two for more than chase I promised the other proposal to write up exactly what I was trying to explain on the previous TSC so that everybody understood what we were deciding and then we'll follow the discussion of that and hopefully approval of that proposal with a discussion from a tooling perspective and insight from the the foundation's infrastructure staff that manage a lot of the other projects as to what you know what the best configuration will be for a percent or a lot so can everybody hear me I can hear you hello oh you can okay it sounded like the Bluetooth speaker was cutting out it's good so any other business any other agenda items people want to bring up if we have time I suppose we could actually talk about the project lifecycle and and the template proposals that are still out there and and some of the comments in the in the proposal sort of suggests that maybe we should conclude that piece of business but but let's see you know where we get I guess okay all right so so is everybody have a cop or a link to the proposal hopefully what we can do is we can go through the proposal and we can also go through some of the comments that that people had made and I tried to address them so essentially what we're proposing here is to you know formally incubate the merged code base that emerged out of the hackathon last week and formally evaluate that through the incubation process you know maturing and get into a point where we know builds and we can follow a release with it the project is sponsored by myself and Tomas from digital assets and again the proposal is that we create this merge repository of the IBM and digital assets contributions based on the the output of the hackathon evaluation by the technical steering upon a request for graduation from from incubation so again you from a context perspective you know we agree just you know to try and experiment you know based on the joint proposal that IBM and digital assets had proposed back at the February 25th test skill steering we agreed that we would you know move that forward with the hackathon and so forth and we did that and and we were able to successfully get if you will approve of concept out of that hackathon have links there to the to the details of what the team was able to achieve actually it was teams because there was really two teams that came together to do this and a number of individuals from a number of different companies and a copy of the merged code bases linked as well and so again the motivation is that you know following the hackathon there was I think a lot of energy in the room keep going and so the team had proposed a number of idle next steps they're articulated there in the proposal and then along with another set of steps that are another set of tasks that are necessary to get us to the point where we have a mature implementation that we could you know bring forward for evaluation again this is proposed as an incubation project I think there was a question from Patrick in slack about you know whether or not other projects could be put forward and proposed for incubation and the answer that is absolutely yes this is not exclusive this is inclusive if others have proposals then I think we should bring forward and consider them technical steering in terms of the resources IBM and digital assets are both committing full-time resources to this effort and we're proposing that Ben Tamash Robert and Sheehan be the initial set of maintainers and in those those guys again per the governance they'll be the ones that are tasked with reviewing patches before they're merged and you know over time hopefully bringing on additional committers that can that can join and help in that process again you know in those process projects everybody can review and and comments make suggestions on poll requests that are made but the maintainers are the ones initially that will have the review the ability to actually merge the code and they can also bring others on board to the project to join them as reviewers and people that have the authority to authorize a merge how we go about doing this we would establish a single repository under the hyperledric GitHub org with the merge code base that we created at the face-to-face clearly label to read me that it's an incubation project project and then that would essentially allow us to move forward and we could also you know start working on things like the continuous integration we'll talk about that with Steven a little bit later so before I get into the comments in the margin any questions comments concerns yes Stefan here and Chris would you see that as an effort driven by DH and IBM or would you rather see a more of the community participating in this initial effort I don't see this as being an IBM and digital assets project I see this as being a hyperledic project if it's so and we just try to install the code as well and we also found what we found last week that's not easy to do and last week we said should be 101 on how to basically install the whole code right also if you want to bring on more people could we establish a set of documentation or a set of guidelines that people understand the code who are not part of the core team prior to kicking off this this project so that we can pull in more people from the outside well I think we can certainly put that as a priority for the first steps but I wouldn't want to necessarily make it a prerequisite to getting going because we mean we have to bring the code in and put it under the the governance and and you know rate the various tools and so forth for continuous integration to happen so I definitely agree with that Stefan that we need to to clean that up make it a lot more accessible and that definitely should be a priority for me that's a prerequisite of getting more people on board who are not part of the core team and it depends on how quickly we want to achieve that the priority of documentation and this how-to guide has to be said all right so we could add initial next steps to do that your first project for the first task for the project all right let me just edit the oops hey hey hey Chris this is Morali from DDCC I think along with that along with the along with what was suggested I think what would be good is to have a current architecture of you know both these tags I think we have seen a high-level architecture but more a more a deep level you know a more detailed design of both these tags and what are we shooting for when we merge it together the you know that in terms of the future stack how it's going to look like and also the functional you know what are the two functional aspects from a functional perspective what does OBC bring in what does you know what what does you know what does the other party bring in and you know how do they complement each other that'll also help us for somebody new to both the stacks yep I agree with that thanks Morali this is this is Chris for Al and I brought up some comments in the chat box if you're whenever you want to talk about that yeah we will go through yeah we will go through the margins I said I just wanted to sort of ask you to invite others to to comment that hadn't already done so in the market we definitely go through those did you clarify the number of stages that are involved so you mentioned this this project going to an incubation status and then presumably downstream from there right so we we had previously discussed a project lifecycle that starts with a proposal to incubate a project and then you know that's followed by a period of maturation once the the project is what did I say in the markets actually there was a comment in the margin that sort of articulated my response to that yeah so there's a Chris Chris Allen had had put in a comment what exactly does incubation really mean and I linked the the wiki where the the project lifecycle document is posted and again that that process involves you know this incubation stage where you know again the project is ensured and when the the team feels confident that they want to request that the project be graduated from incubation that you know they need to have a fully functional code base it needs to have test coverage commensurate with other projects again we'll have to decide what you know efficient test coverage is for the initial one have an active and diverse community developer so again we want to let this be a project of the hyper ledger project itself not of any one or any two vendors and we want to have a history of releases that demonstrate that the team knows how to go through and and do a release of that project and that may be you know that they're they're integrated with the release if you read if you take a look at the the lifecycle document you'll see that you know there there's you know somebody's proposing a wholly wholly new component that may need to be independent until such time we can we can merge it if you're just adding a smaller feature than you would that that you would do it with feature flags and so forth that could be disabled so so again you know that the intention here is we go through that process eventually graduated to a mature project and then finally you know there's sort of an end of life process where we would go through when we may deprecate a project if we deem that it's no longer relevant and and go through a period of deprecation and then that would be followed by end of life so that's that's roughly what the process lifecycle is and again that's been proposed I you know when we had the initial discussion of the lifecycle document there didn't seem to be a whole lot of disagreement with that in fact I don't recall any all right let's let's let's actually go through so we covered that comment let's go through the margin then see your so the first one is see your comment about hacks below it's also in the chat room on the side um in both places oh and I'm sorry I'm not looking at that Chris is putting stuff in the chat as well okay thanks the Slack or the Google chat okay no they go to a meeting chat oh they've got a meeting chat yeah and so the joint of having multiple tools yeah and I apologize and I can move my comments to the appropriate place I mean just in summary you know I feel like we were invited to a hackathon I love hackathons I've been running for just hackathons for you know 20 years uh they're great for you know information sharing they're great for you know trying different ideas lots of freedom to fail uh you know proving some concepts and whatever um my problem is is is this word incubation and and looking at the life cycle document about the the uh you know calling this hack a something that is a baby that we're that the next step is to make it mature after this one and it just feels uh premature premature it's it's really not architected to allow easy contribution by others there's a lot of architecture things in regards to like um membership services from top to bottom that you know a lot of engineers we were talking to were kind of going yeah you know some of these ideas of having a different architecture that allows for um you know say uh um the uh uh jim working uh uh contribution to to be at the top but use idms at the at the bottom a lot of those types of things are not easily I mean they're they're really kind of heart baked into this uh into this proposal and I was you know looking at the life cycle document and it says you know proposals really need to be uh you know vendor neutral and I'm you know this this was a hack it was great let's let's move it to the github let's uh you know continue to experiment with it turn it into a real proposal but but it doesn't have it doesn't meet the it has to be a proposal first before you can incubate it um we're looking at proposal Chris I'm struggling to understand what you think it is if it doesn't go in incubation almost every open source group that I'm familiar with has the first step is an incubation and it could start with nothing more than a blueprint that's what they do at opensack they start with essentially an outline of what they want to do yeah and also also the proposal started in February this proposal was uh presented to the community in February it's been six weeks now so you know Chris I I don't know way I don't know how long I think the proposal was for the hackathon not for the the topic exactly for a very different thing yeah fair fair enough but I mean again I guess I'm struggling with exactly what we would call it and how we would it's a proposal it's a it's a proposal and I would like I also think that the proposal Stefan I think you're cutting out or I don't know for how much cutting out of it there was a body in the section of the document and the code code so I don't know what I would call proposal if that wasn't a proposal and now moved on and worked on this proposal during the hackathon to create something that I would call is something that is incubating so I don't see the point this is Mike Dolan can you guys hear me yep hi Mike hi so at the LF we host over 40 projects incubation state is very common in our projects it is a very low barrier for people to get code into the repo start working on it on a proposal that fits the scope of the project and this should not be something where we're gating and throwing a whole bunch of barriers up for people to contribute and create ideas and start working on it together right now we have this weird state where people are trying to work on these off the normal uh you know github in these extra repos where you can't just you can't just transfer this stuff over later and so you know this is this is different from a standards effort which is what I think some of these comments are sounding like as though this is some sort of standardization effort and that's not what we're doing here um you know and others are free to bring proposals to it this isn't this is a very odd discussion for you know what we normally do in all of our other projects and I it's not just linux foundation projects open stack any any major open source project I'm aware of this is this is going in a very different direction so I think this is mostly a matter of semantics can I come back this is uh hold on uh heart was just talking yeah maybe we need to try this sorry I think this is just a matter of semantics I agree with chris that we should make an effort to make the code easier to use and easier to to work on and that we shouldn't be necessarily wedded to a particular architecture you know there may have to be big architectural changes if we discover that you know something something doesn't work with what we want for the vision of the project but I think uh I guess most of this is just semantics you know what's you know we I think we all agree on what we need to do it's just we're arguing about so let me just express a couple of my concerns about it one is and I think this has been addressed in the in the one comment that you have in the proposed section of the proposal which is this is not the code base we're proposing this is a code base that will be evaluated formally at some point in time that's correct I'll be adopted as a basis okay that that's that's number one and I'm real happy to understand that that that there will be an evaluation process leading to that though I would feel a lot more comfortable understanding a little bit more about what that evaluation will entail and ensure that we've got a parallel effort that is equally aggressively being pushed to establish the evaluation criteria for what we're doing I think the third thing and this is one one I'm going to come back and and I know what I heard Chris saying a couple of minutes ago is it it feels like the proposal is code as code without an understanding of exactly what it is is being proposed the architectural specifications are given is extremely high level especially on some things like the membership services which is where I have my greatest heartburnism at area right now and I would like to understand more about what and how those components are going to be deployed made available who runs them what the expectations are on that so there are there are some questions about exactly what it is I think that that is being proposed architecturally and as I have said multiple times I'm all in favor of in parallel making code work so you know there's nothing quite like having the code as a way of making concrete discussions yes I'm just I'm really uncomfortable about growing code without having some idea of what it is I'm actually coding right so we have a parallel piece of work to do to gather the use cases and requirements there were a number that were you know part of what we had initially proposed the sort of the combination of the what IBM had proposed with a combination of the paper and so forth to articulate some of that clearly there is more needed to be done in that space I totally agree with that Mick and and to your point on you know sort of we should aggressively work on you know evaluation criteria and so forth I'm I fully agree with that I'm and in fact you know we can we can make that part of the you know you know part of the bargain if you will part of but you know I again as Mike said you know the point is that you know we need to get code into the hyperledger project that we can all start collaborating on I realize that you know it may be a little bit awkward to get it up and running initially we have to work on that absolutely you know it that's I think the nature of open source is you have to make it accessible to others to contribute and collaborate and that's I think what we intend here this is not again it's not a foregone conclusion that you know if somebody else has a better idea or wants to make another competing proposal that we would incubate side by side I'm happy to do that as well can I go ahead hi this is a Stanley Berman see me given the I guess part of the question is what are we accepting and maybe as an option we can look at accepting parts of the architecture and maybe break it up into separate projects because right now what we're talking about is accepting the basically the entire obc architecture as the hyperledger architecture no well as a proposal as a proposed implementation no but I mean again it's an incubator it's a place to start from it's not the end result right but part of the yes concern is what are we accepting so maybe accepting portions of the architecture so for example the membership services just in this example maybe that can be broken broken out into a separate project I don't know how feasible that is from the technical side but maybe it could be accepted into incubation piecemeal versus the entirety so Richard here from our three so I've been listening it's interesting a couple of thoughts of crystallize listening in particular to to Mick and then Christopher so Chris Rowland speaking I've been uncomfortable for for some weeks now and not not quite been able to put my finger on why and I think part of it is because I've been struggling to to understand how to contribute to this process and as I hear the discussion I think the the thing that's becoming clear to me is I think I need far more clarity and maybe this was discussed last week and apologies I couldn't be there but more clarity on what we think the an end state could be I've argued for some time that I disagree fundamentally with the idea that there will ever be one correct code base for distributed ledgers or for blockchains there will be different appropriate architectures for different requirements that's just self-evident after any amount of requirements analysis so I've been uncomfortable and I made this clear at the you know the initial kickoff that the idea of Linux foundation effort trying to select one code base regardless of what it is would only make sense if we had a really clear view of what problem it was we were trying to solve so almost like the first and the only thing we should do is say right this is the problem I'm going to solve let's let's let's figure it out so just finish that off just so so if if the vision or the intention is at some point we get to a single code base then the the utmost priority is is to agree as a tsc in a broader community about what is the problem we think we're trying to solve independent even of detailed requirements or or any architectures or if the if the vision is we actually think there will be several you know sister projects all under the hyper ledger banner each addressing different needs then that's also a plausible outcome it's probably one I'd favor although I don't have a strong view on it but if that's the case then when we talk about things like you know evaluation processes we need to be clear about that upfront because the outcome then isn't which code base or which code bases get merged and selected it's of the universe of possible code bases which ones plural do we think are most appropriate for the different use cases we've identified but they're two very two very different questions and that unless it was resolved last week I think it's something to address soon otherwise I struggle to I struggle to engage meaningfully with the code because I don't know what problem it's trying to solve so so Richard let me let me clarify something because I think there's and again I think to heart's point earlier I think we have a problem of semantics and we're talking a little bit past each other here we are not selecting a code base we're collectively a community that is coming together to develop we're going to develop a hyper ledger you know whatever that you know whatever we decide that it needs to be right with requirements and use cases that will that will shape what we built it's useful to sometimes start with a lump of clay that you can evolve into what we want to build we are not selecting a code base we are not selecting an answer we're just at this point we're just trying to start a process of getting people collaborating working together to actually develop something we're not looking to evaluate the answer to something at this point we just need to get started doing open source development so I think you know for you know if there's concern that we're somehow or other pre-anointing what the end state is we're not not at all but we are trying to get to a point I think to Mike's it's Mike Dolan's discussion where we actually have something we can work with piece of clay then we can start working so I don't disagree with any of that and I'm not and I totally agree with the need to to make progress you know it's it's very easy and I am I want to make sure I'm not guilty of this of being the person who sits there sniping rather than contributing so I'm very I'm very conscious of that but the reason I raise it is a perfectly valid alternative and maybe superior or again I don't have a strong view on this is to say well actually you know what let's let's take OBC and a bit to prove because they're the the two code bases in the discussion they're both fine pieces of code both I think solve designed to solve or address different problems it's not obvious to me why we're trying to to merge them when actually they could both as they stand be perfectly valid code bases that both independently form the basis of of of sister projects under the high college of banner so one with the UTXO model Bitcoin aligned one that's you know Ethereum inspired it's not obvious to me so there could be could be code working on in parallel with both of them and the effort could be to you know to it to improve them and understand them it's not obvious to me why we think we need to merge them maybe we do but that point has to be an anapologies if I've missed it that point has to be argued yeah hey Chris this is Morali just as a suggestion you know again this is just a suggestion I'm in favor of merging the code bases but maybe this will help right maybe if you come up with a target architecture you know for the hyper lecture and then identify the different components and as part of this proposal you say that you know this proposal is bringing up you know these components from the OBC and these components from hyper ledger so that'll set a template for any other anybody else proposing it they will have to identify what components of that target end state you know are we are we proposing there will that help just a suggestion so if I understood you correctly I mean I think that's exactly how we work going forward that's you know other people are going to come forward with an idea about improving the membership services or having a better membership services and they want to bring a proposal forward with maybe some code or maybe just an idea and incubate a project to do that that's why that that's that's exactly what we want to do and so I mean again I think it's important to sort of to to think about this not as that this is the answer but that it's just a lump of clay that we can evolve to be what we think it needs to be if I can add to some of the other Linux foundation projects manage a couple others the look if you have another idea put another project proposal up and put it forward this is this is that this is all about at the end of the day if that's right more people to come over to your project and your project will grow faster and that's how we get innovation right just people trying things out we see this I see this on a lot of the projects that I'm involved in you get competing ideas which isn't bad people try them out experiment compare sometimes they merge sometimes they die off right I mean you take a look at you know some of the ways that this happens certainly you know if I think about open stack you know if somebody has a better idea for how they want to you know maybe refactor some component or add in a new feature they take a fork they start working on it they get others to collaborate with them you know they keep it current with the base you know with the trunk and then when they get to a point that they're ready to share that they you know either request to be incubated or if they've already done that they're requested to be merged and with the the base code that's that's really what this is all about so you know I mean again it's you know I think if there's concern that somehow rather this is only IBM and digital assets then I think we have to dispel that right away that's not what this is about I think something that would help in that vein is looking at it less as this is a lot this is the single lump of of clay that innovation emerges from and this is one of several different lumps of clay so I think just in the verbiage of the proposal if it's clear that you know this is one project being moved into incubation but it's not intended to be the foundation that's right so we can bring in other base blockchains to work with sure absolutely I think I mean again and I think you know to Phil's point you know that you have to vote you know somebody's actually got to make another proposal and at least today I don't think that's happened I mean there has been you know other you know there was you know initial code bases that were brought forward and you know I think they need to be you know if that's truly something we want to do and they want to apply for incubation then we should do that absolutely from Deutsche Börse we fully agree with your energy of the piece of clay but what we would like is us and others to help us and others to easily understand that initial piece of clay for example for what who runs our development efforts took a day now or so to get the IDN code running and he also could provide like the the 101 description how to do that and this kind of stuff I think would help everybody to put the whole thing on a broader development base by documentation and some pieces which help people to get going yep so I totally agree with that Stefan and I'd add that to the to the first you know it's the first step yeah that's all I wanted to basically all right hi this is David Vole um yeah I mean it sounds I think I agree with well I think everyone is is agreeing it sounds like there's a lot of violent agreement going on right now and that um you know moving this project that a lot of this is semantics and I don't see you know how moving this project to incubation status you know would conflict with anyone's points that they were raising about what should happen next and what has to happen going forward and what happens if someone else wants to suggest something different or you know in order to meet some additional requirement so I mean again it sounds like everyone is in a state of violent agreement right now and and that you know the proposal to move this project into incubation status isn't in conflict with anyone's points so that's just my two cents yeah and I I would like to add this assurance from IBM that there were some really fantastic ideas right at the hackathon last week that you know we were trying to encourage people to come forward with proposals to either integrate with the code base you know or to just bring it forward so you know I think there's a lot of opportunity here for integration or for other code bases to come forward I also like to address what Richard raised uh why we did this much well be as uh who know the individual code bases on IBM side and and on the digital SSI we both recognize that there are advantages and this much um because these uh the implementation on all side is a very specific implementation um coming from Bitcoin angle whereas their implementation is a very generic implementation for that it will be accommodating for alternate approaches of consensus for alternate languages of smart contracts and so on so we thought that this is a very pragmatic and and very valuable merge that gives us an API that is accommodating to order the business cases that we already understand but certainly we need to do more research about other use cases and I think that this this is running in parallel and this moving this this merge project into an incubating phase I would also say I don't see how to endanger any other progress. Chris can I just ask a question um what is the so you have uh the the current merge code base does any get is any get have a repo of its own right now right I mean where was the development taking place I thought I remember the comments that it was that it was it was but I think right now it's actually still back in the IBM code base for a number oh okay okay he got it uh so really the incubation status and and I'm just trying to be precise about what the the you know what does accepting the proposal mean um as I understand it it means number one we give it a label that it is a hyperledger project that's an incubation status two we give it a repo on the hyper we give it a spot on the hyperledger um banner uh in github what else um is it is there another additional set of trackings what what actually change so if we accept this what changes um well we we bring it sort of under the hyperledger umbrella what changes then is we can put it under the governance of the project um you know to to be honest right you know what what they did for the hack was often a in a private repository not a private everybody in this public but um in an independent repository there is no uh you know there's there's there's nothing in that that sort of identifies this uh and and puts on it you know a set of governance in terms of having the review code putting it under again we're going to talk about this with Steven uh in in a few moments you know putting it under Garrett so that we enforce a review process around any changes to the code base that all the code is reviewed that we can start you know engaging and accepting contributions from others um and and run it through continuous integration delivery pipeline that is managed by Travis or Jenkins or whatever you know Steven and his team recommend um uh what it what it does is start down that path of actually building something again if others want to bring forward proposals that are operating in parallel or uh you know that augment or improve upon what we start with we we should be doing that aggressively right I'm not disagreeing with that I'm just trying to to be clear on so um process wise that the real difference is that this comes under the hyperledger label it comes under the set of guidelines for uh for such a code review and commitment uh both in terms of licensing and um uh kind of community contribution and the rest of the things that go along with with you know what we all signed up for when we signed up for this um I mean the process of the Jenkins the other things you know we all have our own repos that have all of those in that that's you know you just move it from the IBM version of that to the Linux foundation version of that but but really the critical difference here is the labeling that it becomes a hyperledger project and uh and the licensing and the review process that is that fair I think that's that's fair it's also again it's a process of growing uh you know a community you know part of part of what we you know and I think that we were successful at with the hackathon was actually getting people from different companies to collaborate on you know various various you know it's we have an elf in the room and we're all you know filling it up and we all feel different parts of it right and and but it was getting collaboration from many different members of the community around that now again there can be other proposals um but the the important thing that we do is we start engaging and collaborating as a community and building an understanding about what it is we're building through the requirements in the use cases working group and working on refining you know the messaging around what it is that we're building and then working towards actually getting code whether it's this code or another piece of code or this code other pieces of code or you know what have you that address the you know the the requirements and use cases that we all have in mind you know we may find indeed you know to Richard's point that it makes a lot more sense to have you know smaller things that are specifically answering or addressing a particular flavor of use capes that may indeed be so right and there may be better ways of delivering that than you know what we have today there's no doubt about that in fact part of the discussion that we had at the hackathon was about how we would actually you know go about building and delivering the actual running code depending on what you put in as sort of you're sorry I want to use GTXO with this kind of chain code and you run a build and it spits out a piece of code that does that so we had those conversations but we have to have them as a community and not as you know individuals or you know individual companies or even pairwise companies going off and working in seclusion we need to do this as a community and we need to learn how to do that as a community that's part of this this initial step. Chris this is Chris for Alan you know what I said in the in the give-to-meeting chat box and for those people are logging in other ways how about I'm willing to accept this proposal you know from the proposal stage into incubation but I would really like to see in this repo the some really you know in this initial repo some clarity around that a we're hoping for further proposals and incubation projects that b just because this is the first one it isn't a base at this time and that c you know that as the first you know we kind of have an incomplete understanding of the goal end states and are waiving the requirements of the life cycle process that we have a you know a well-defined scope and a well the you know whatever other things there because we want to get started but you know if that's in the document so that it's clear that somebody goes straight to that thing you know does the read me and goes yeah this is you know something that's being you know thrown out there for for people to look at I'm much more willing it just there was an element this is the first incubation and and the language and you know things that kind of again you know unlike other Linux foundation projects that have a base to start with where everything is you know often you know a fork of the of a base that everybody has agreement with this isn't so we want to be very clear and be very concrete that that you know this is not a base yet maybe it will be I'd like to interject here I think I have a proposal that would address Christoph first point here I think we're suffering as it's been said before by lack of common understanding of what it implies to be an incubation and we have Chris Chris and I have started developing a proposal on defining the project life cycle for the hyperledger project and it's unfortunate we haven't finished this work and it occurs to me that a lot of this discussion could have been you know easier by having a proposal that has been accepted and it's you know based on the discussion I heard it seems like this document needs more work because there are questions that have been raised through this discussion that are not being answered by the document and but so I think you know rather than having this whole explanation about what the incubation is in each the incubation project what we need is when the project enters the hyperledger github there should be a clear you know in the read me status section that says this project is incubation and there should be a link to the project life cycle definition of what incubation is what it means and so what I think we need to do is finalize the work on the hyperledger project life cycle document publish that on the on the website and then as I said put a link to it when we when we put the documents thanks Arno I think that's right so so Chris to your point um on you know sort of clearly calling out exactly what we're trying to do here I I can fully appreciate that you know there's an awful lot of focus on this project I mean holy crap the coin desk was the phone with my doll and I think two minutes after we closed the call last Friday wanting to have clarity on on some things that happen and um and so I fully can appreciate that we don't want to send a signal somehow rather prematurely that you know the answer to life the universe and everything is what we're proposing to incubate here and so Chris you know and I think you know Mick I think you're you have some similar concerns and I and I can appreciate them here's what I'd like to suggest that maybe you too can collaborate on writing what you think the read me should say um share it in the mailing list or Slack whichever is most expedient so we can get this done quickly as to exactly how we would want to characterize this is that that makes sense I'll be glad I'm happy to work yeah I'm happy to work with Chris on this Chris this is Mike Dolan from Linux Foundation again if I could just make a comment you know you guys need to think of this in the long term there's a balance between putting up a lot of gates at the very front end of community members who want to propose projects and being able to you know make there's something available for them to start working on and engaging on to work through some of these issues that are being raised and I think you really need to look at the next stage of you know what does it take to get out of incubation and focus there because on the long term side of healthy projects they have a very healthy ecosystem and making it easy to contribute and get started on an idea is typically at the forefront of all of the ones that you know succeed over the long term because you have to have healthy debate and in order to have healthy debate you need to be able to start working on something and generate interest from others who might be able to want to interest in working on the same thing and experimenting on the same thing and if you have no experimentation because the gates are too high to get started it's a very it's a very systemic long term issue if you started off that way so I would really encourage this community to focus on you know making it for projects not just this one but you know any others you know somebody wants to come along with a competing project tomorrow and they have a pretty you know decent understanding of what they're doing and if it's in the scope of the project why not let them work on it and try to see if they if it's a worthy experiment that should move forward and that's really the way you need to start looking at this I think. So Michael that's a really good point and I guess it's I guess it makes the read me really important because the long term is important but we need short term clarity and I think maybe this read me and associated messaging and this goes I guess for all parties who are making messaging is important because coming into this call the question and listening to the comments the question is asking myself is if we as a TSC as a broader group were creating the impression that this code base or whichever one was in there was the first piece of clay from which everything else would would follow I can't explain that or justify that to my darkness if as I think I'm hearing we're saying no it's just one proposal either for the long-term code base or as I would prefer a long-term code base because I continued to make my point that I think there will be several correct architectures or different use cases if and this is what proposal for one of them if that's the the point we're making and therefore that that barrier because the people don't want to think they have to choose one or the other but that barrier is gone and actually people understand that there are multiple plausible architectures and this is just one of many naming will be important there especially the name of that that subproject will be critical if that's the case then I think that's I think that's a good outcome yeah and the other thing Richard is that sometimes these incubation projects you know as people start working on it it becomes you know obvious to the community well maybe we should split this up into multiple projects somebody mentioned it earlier you know you may you know take a code base and start putting it into multiple projects because there may be some sort of base level components that are you know more consistently reusable or you want to you know actually use them as the one component that everybody is working off of but experiment in in other in other places and so you sometimes you see a componentization of the various code bases that are being incubated but you know that takes something where you have a code base that you can work on you have a workflow you have an IP policy and people are contributing under the terms of the IP policy that was set up and in order to do that you have to start somewhere and that's that's what incubation is really about is just giving people an opportunity to start somewhere Mike this is Premier speaking I do have a question so when I came into this call I looked at the Hyperledge website and to my understanding we do have a few proposals you've got Ripple of course of IBM DAH and you've got the Blockstream one now what I don't understand is why now we've got the OBC the IBM and DAH which are called the incubator or an incubator what do we need to do then for Ripple or the elements projects to become a project do we need to do a hackathon do they need to just put up documentation is it just a question of the read me why are those not projects as well why are they still proposals then well I'm not aware of anybody proposing you know those were initial you know statements of you know willingness to contribute those co-basers and everybody's looking at I think even Blockstream's been working with IBM and DAH I don't think it's just them you know and if Ripple wants to you know put forward a proposal for the technical steering committee to consider I hope you you know make it easy for them to you know suggest something that they could incubate and work on and hack on and see if you know that you know fits into the ultimate elements of this and the other thing is you know you guys have a requirements committee and others who are working on you know looking at you know what does this need to address and you know when you look at these cases and requirements you know you should be evaluating you know what goes forward based on whether you know it does you know a healthy job of meeting the needs of what this community wants to address and so there's multiple things that are going to go on in in various stages and you know I should hope that you be open to evaluating other proposals even if you know they are competing and making it easy for you know others to contribute if the Linux kernel community just you know said here's the one direction we're going in and we're not going to accept patches that compete or even experiment on patches that compete that would be a really damaging situation for the long-term success of that project. I don't think that for my problem in any case it's not the competition it's of course that the projects will need to compete you'll have different algorithms will have different effects but this isn't just a question of project algorithm I can't figure out the website actually says proposals so as far as I'm concerned these are in the initial stage of this life cycle they're all proposals and I can't figure out how they've gone from proposal to incubator I don't know if we need to work on the website then we can do that you know at the the read me I think was written by each of the organizations who uh wanted to propose code I took their I took their um you know language and put it into the read me I didn't draft that myself so you know that's something where over time we need to you know evolve away from a read me as the you know source and have a code base that people can start playing around with and interact with and you know there's a lot of things that the community proposing this it sounds like have to do in order to make this easy for people to engage and that's got to be job number one for them is they can't figure that out then it's never going to advance beyond incubation so the the way this works in some of the other projects and I thought Chris that we had showed this several TSC meetings ago was showing a workflow of how you propose how things come in the life cycle it's in the comments as well we talked about that a little earlier so you know the I think the short answer to the question is put forward a proposal to the TSC like this group did and that gets it into the life cycle it goes from a comment to an official piece of item running through the life cycle is that Chris said I think that's fair yeah I mean you know again I think you know part of this as Hart said a little bit earlier is semantics the proposals were you know we you know essentially there was sort of a call for who's got who's got some ideas who's got some code that they might want to contribute and and that brought forth a number of different things you know IBM and digital assets got together because we saw some complementary things in our respective code and we felt that it would be worthwhile to explore how we could start collaborating as opposed to trying to compete on whose co-base is better to get to something that might be a little bit more acceptable to multiples to demonstrate that it's possible to actually get to a point where we can start working together on a thing but that doesn't preclude that there are not other things that we might want to work on in the context of the hyperledger project as Mike said a little bit earlier these things are typically called incubations and it's it's pretty clearly understood in the links foundation and open stack and cloud foundry and other places that an incubating project is something that's undergoing all kinds of engineering and development it's part of the whole life cycle of producing something and it gets to a point where people think that it's ready to be birthed and then there's a discussion about whether or not it's it's soup yet um we you know collectively have to get to the point where we're starting to work on some things it can be one thing it can be many things ultimately we are going to have to choose that this is where we're going to go forward with going forward you know going forward but you know somebody may come along with a better mousetrap we may decide well you know what maybe that's what we should do and you know I think collectively we should all be we should all be looking for that better mousetrap but in the interim we need to get actually collaborating that's the most important part and and so that's what we're really proposing here is that we can start collaborating if this thing turns into something completely different but that we're all happy with I would be happy I hope everybody in this and this call would be happy um we need to make this what we think it should be collectively you know this this again I think you know if there are other proposals then we should indeed bring them forward documented using this template that vipin had pulled together for us thank you and and um and and and let's have another discussion like this hopefully a little bit less you know contentious and and let's bring things into incubation and we can collaborate side by side and we can get comfortable and familiar with them and we can find where things seem to make sense and maybe we can actually start thinking about bringing things together as opposed to trying to be competing that that's my hope and my vision for this is that you know more important that you know we get to the point where we're on a path and that can serve real value for our various constituencies so that's I guess you know I guess I'm hearing pretty much that we're okay but maybe we're just a little bit stuck on some of the semantics but it's eight o'clock so we have a half an hour left and I'd like to I guess put it to the TSC whether or not they agree with this and and so Todd or Phil what do you guys want to drive a roll Chris um this is Ram um I think one of the things that would help us to have a better understanding of the longer term track you know we are at the use cases and requirements space if you will but it'll be good to have an architectural track going so that we can kind of try to collaboratively and have a well-known group to kind of address some of those architectural options versus the requirements so maybe you know having some kind of agreement of what that longer term track looks like and what process we will take from any of the starting points and this and you know the current proposal is a great starting one and the only one we have right now really and how we would evolve that towards meeting that ideal end state assuming that we can come up with that end state in the architectural looking group if you will I think that might help a lot and kind of making sure that everybody's on board with this um I don't I think that's a great idea you um you want to leave it sure I can do that okay awesome I'm happy this is hard here I'm happy to help look over architecture documents if you like as well so you've got some others I mean I think Subram I want to thank you for for offering to to lead it and you know just we did with Patrick and with David's work groups what I think we should do is have you circulate a note on the mailing list and anybody that's interested in collaborating with Ram and and Hart on on the architecture part of this and how does the architecture meet satisfy the requirements I think that would be really awesome so Todd all right so just running through the TSC members on the call uh Stan do you agree uh just so that we're clear exactly what are we what yeah Chris do you want to just run through that summary quick yeah so so again so we we I went through their proposal we've had discussion I did modify it to add the feedback from Stefan that you know the initial focus should be making it accessible and easy for people to stand up and and to make contributions and engage the project improve the documentation and so forth the other point was that I added was from Mick that the TSC will aggressively work in parallel on the incubation graduation evaluation criteria I think that's a great idea and and and that Mick and Christopher will collectively collaborate and again we can do this in the mailing list and others can contribute as well to have a clear section in the read me that that describes what this is that this is one of potentially multiple incubation projects and so forth and and so other than that the proposal is as I originally articulated that's an that's an I thank you all right Tomas yes I'm certainly supporting because proposing all right thank you Stefan yes part of yeah I agree with the proposal especially I agree with the fact that you know we should have a little bit more documentation so that the rest of the community feel more welcome to make the contributions because I think the community feels that they may be at a disadvantage because of the lack of documentation yes all right Chris yes Mick yeah all right Dave yes Richard a contingent on the um the read me which I say is critical then then yes okay great uh and then Oshima san or Emmanuel if you're on the call I don't think they're here so that's uh Chris that's nine in favor zero abstaining zero opposed awesome thank you very much everyone okay so we'll we'll move forward as we described and so the next topic of discussion is Steve Merlin as has joined us thank you very much for getting up very early and and so I think we should transition to a discussion around you know so we you know we talked about you and I had a chat yesterday about tooling for this and previously two TSE calls ago we had a discussion around some of the tools that the Linux Foundation can help us with in terms of you know doing code reviews and so forth I thought that and again we had a um uh you know we had a good conversation around you know the the need for um very very well managed review process I think is is really um for for whatever it is we're building whether it's this code base or another um that you know the rock solid um we get a lot of eyes on everything that many eyes makes fewer bugs obviously um and and one of the tools that you brought up was Garrett I think um so um I think it'd be worthwhile to have a conversation about you know can we get Garrett made as part of this um activation project proposal so that we have that front-ending the the actual repository so there's essentially a lockdown right and then we start with the initial set of maintainers going through review process others can collaborate and review code patches and so forth but maybe could describe for us what you know the recommendation would be to set that up yeah the um just building on the conversation we had last time um the the project that you have here is obviously got lots of people lots of contributors lots of folks in the code one way to manage that certainly in very large projects you know android chrome you know things like that out in the ecosystem they use Garrett to to control that and and not not controlled in a bad way control it as far as a uh maintaining your sanity way of making sure there's there's a stop point where everybody gets to see the same thing at the same time comment on it review it and that there's a once that review has been done go ahead and hit the go button where it's included in the code base and is part of the build and part of the build out configuration or or if there's further review that needs to happen all the contents all the communication that's associated with that goes back to the contributor so that they can take a look at it and and adjust accordingly um since we're coming from um I got to see the the keynote that described some of the components that you guys did the hackathon and and part of the conversation we had yesterday is I don't often get projects that have so many different code bases uh that that will be interesting in itself um what I uh suggested and I would suggest to you folks is I think is a general direction um you know Garrett would be the right way to do uh control uh and code management and you know code review um I would also suggest that as part uh kind of parallel to what you're doing with your uh initiation the proposal you just did that we have a working session on infrastructure uh some of my people I think some people volunteered at the hackathon that said hey we do these bills for these components now we know what they look like we know what they smell like we know what keeps us up at night that would all be really great input in with uh some of my release engineering team to to build out a chart a straw man if you will of how we'd like to manage and get the continuous bills going on a regular basis including the the code review so uh that's you know my input my suggestion you you guys are at TSA we take direction from you so we modify it accordingly based on your wishes so if I so so I think the recommendation then we use Garrett as the review process flow and that's pretty standard right um way of locking things down um I think you're offering to have so I think there's actually probably two two parts to that right one is um we need to have sort of people that are focused on the release engineering side of things right of actually you know getting the bill um working integrating with continuous integration integrating the test um you know the testing you know the unit testing the smoke text and so forth and then I think separately probably to have a workshop right to get people familiar with how to use Garrett how to use these other tools um is that so I think that's what your those are the two pieces so maybe a little face to face of people that are interested in helping flush out how how this project generally not just the sinker better but all of them would would be managed so it will set that once again I think of it as as setting a straw man uh to work from uh that was we learn what what's effective what's not effective uh we always find out uh you you guys do this for a living too you know how this works there's the set of requirements you know and then there's a set of requirements you don't know so that straw man usually ferrets out any issues associated with well gee we do need this extra component or we do need I'm trying to think of one of them one of the fuzzy code code checks um you know sonar you know if there's any other requirements that are needed is part of the process so um part of what I'm going to do is an action item out of out of this week I'm going to go back and get my release engineering resources lined up that that is part of the budget your budget's approved I think directly uh no we haven't actually done a budget yet right we have we have certain oh we do yeah okay so so part of that will have you know there'll be a release engineering block in there that that's what that person will do we'll get that um I do have some samples I know there were some comments in the previous conversation about documentation uh part of what that release engineer does produce uh is you know those FAQs those initial start points um this is the way you get your code checked in this is the way it gets reviewed uh they are by no means technical writers so don't get your hopes up that's going to be the best documentation on God's creating earth but it's typically very useful for for the existing folks all have a common understanding and also for new folks that are coming in uh it's not unusual to have one of my release engineers work with uh under the direction of work with new folks that are coming on board to kind of get them jump started and in the pipeline excellent you talked about that yesterday about calling the meetings and or the contributing indeed right absolutely and and yeah so we we can uh I think that'd be a great addition um that'll help also I think address Stefan's aspect uh attended to that though you know and and I think you know we had some of these conversations at the hackathon um of people who may be not totally familiar with the you know what was being proposed and and then we heard a lot of discussion around some of that didn't really quite understand the membership services and so forth but some of the things that I think a lot and easy does sort of wrap our heads around is just how do you do creation right so how do you do a maven build or whatever we choose to use right you know you know it doesn't matter what your building they're they're very similar and um a number of people came up to me and said that they'd love to get involved but they weren't sure how but one way to do that would be to have you know to help collaborate on on things like uh testing uh you know coming up with the build process uh working with the release engineer from the links foundation to that uh running as a well-oiled machine I continuously improving it well exactly and I I uh I've been through enough of these projects this project has enough moving parts to where I think it's a a really good thing to get that strongman built that that flow of what the integration play is going to look like as early as we can um you know I've I've been through a couple recently where we found uh G open stack doesn't work that way uh well an architectural flaw that's not what I wanted to find and see island uh so the earlier we can identify that um you know the better awful big and just streamline the process okay so I'm I'm going to do a couple things my punch list looks like this I'm going to sign a release engineer to represent you guys I'm assuming budget budget will come through so well I'll be I'll be happy campers on that I won't be out of bounds uh secondly if if you could collect the names from you guys of the people who volunteer to work on ci from the hackathon hopefully you wrote them down or recorded them on video so you they can't deny me they are and we'll we'll team those folks up we'll we'll come with some sample sets we have some very large projects with some very large moving parts still can attest to uh so we'll have some sample sets to say here the way the pictures look for everybody else you know what's different what we can do so we'll have working samples to to work uh and that will not only help uh stabilize what everybody's conception stabilize the terms that we're all talking about but also set that strong answer for common discussion and collaboration as we find in exactly how we want to proceed with the ci portions to some extent it'll help set you know your expectations on on what a release cycle because it will give you that face great okay so I'll put out a call um and um and we'll once we get a small team together we'll arrange to have a face to face and um I guess in the interim we can also just start planning for the um I don't see what I'll work through Todd I'll work through Todd to to you know set some milestones up and once we uh have a candidate slash victim for the release engineering component we'll get that set up and set those meetings excellent anybody have any thoughts there was some chat going on I was taking some notes from Steve but anybody have any thoughts or comments on the um the tool discussion I guess a infrastructure discussion right not hearing anything um is there anybody on the call that's interested in and working on that aspect of things helping out with um you know working with the release engineer building out the the pipeline integrating the tools improving the contributing mv and so forth and I'll step up at once okay I'll send that to the list um but if people you know I mean again as I mentioned this is one um really effective way of getting involved and it's an important it's it's as important as the code frankly in many regards is more important I I you know whenever I start a new project the first thing I focus on is with continuous interface this is Chris this is part of uh will be interested in um you know working on this part aspect of the project oh excellent excellent all right so I'll send out a a request to the list and if you've got some names please please add them to the list and and we'll we'll get things scheduled I think I've got somebody from from the background here too um awesome um any other comments thoughts questions concerns um I think um so the other I guess the other that's really we're sort of putting together a release work group if you will um the other thing I think we have to start working aggressively towards it we just agreed previously is the whole sort of exit criteria evaluation criteria whatever you want to call it um I'd be interested in somebody stepping forward and helping to lead that effort of pulling that together this process I took a look so one of the things that I added to the proposal was that the TSC would aggressively you know per per per MIX request basically aggressively start working on clearly identifying what is our evaluation criteria for advancing something from incubation to mature release um and I think that's a good thing to do I'd just like somebody to help lead that I would have didn't expect that I'm sorry Mick was that you all right I yeah this is Mick sorry I was gonna say I would expect that to come out of at least part of that the substantial part of that to come out of the requirements group so I can talk to Pat Holmes about um about what it would take to at least um ensure that that piece of that deliverable was not from there okay all right um I put out a call on the mailing list and also at the at the last at the end of the of the meeting in New York about an identity subgroup and I got about eight or nine members that were interested in it and all we really wanted to do for now was I'm not sure if it's a bot for a working group or if we even know what the difference is but um there was enough interest in it that it's I think it's worthy of a mailing list and um you know moving forward on that because it's it's related but it may be a different you know it's it may feed into architecture it may feed into a variety of different places so or or Mike if you're still on um what I mean because right now we haven't really started doing that right we're trying to sort of keep it all in the technical um mailing list um and I think the initial thought was we would do that until people started to say uncle in terms of the volume of stuff in their inbox there are various strategies that we can uh you know obviously you know we can use tagging in the subject line for people to write filters if they want to filter out what they think of uh spam um I'd be interested just to you know from Phil or Mike or or Todd you know what's what's the bar for for starting a new list because I guess my concern would be we would start getting over two fragments too soon right and we're still trying to come together um you know would it make more sense just to have a set of tags that we could use in the in the subject to identify this is identity this is requirements this is one of my other topics as they choose is a fine-grained mailing list process yeah where where where top topics get mailing lists kind of big top areas get mailing lists there are a lot of mail lists and you probably have 20 mail lists yeah easy yes we're free so for me it's complicated because I now follow 20 mail lists and on the other side it's easy because they're threaded and you can enter them and go back to catch up so I think that's really more a matter of how this community wants to be one of the other projects I'm on has a single mail list so what would be people's preferences so let's just sort of have a real quick five minute discussion on do we want to have a fine-grained mail list or one because I think setting up a mailing list is not a big deal right this is Christopher Allen I I'm quite open to setting some bar for subgroups you know whether or not it's there's you know 10 people who want to be involved or what you say it needs to be 20 or or whatever or you know like you said you know it gets noisy in the list I just know in particular on you know identity and architecture discussions that you know both of those are the kinds of things that can kind of go a little bit more further afield and you know may not be the best thing for the main technical discussion but you know they both have different audiences thank you other thoughts just one comment this is Arno I think too many least the problem is people copy all the least or several least we already have two and most messages are sent to both lists that's a good point yeah um and of course we do have slack and so everybody and again I think somebody asked me I can remember who it was can I set up a slack channel anybody can set up a slack channel and please do you know just don't make it private make them public that's right obviously you can have private chats with another individual but we should keep all of the if you will the broader conversations at fully transparent public but so that there is that as well how many of the people here can't go slack because I know some companies want to let you will not let you use slack some companies won't let you use slack how many is that a problem for block stream or no it's not a problem for block stream yeah I haven't run into we've got quite a few on quite a problem actually now I haven't run into that problem with slack but if if you've got someone that has let me know yeah because that always you know tip of the iceberg kind of thing well we've talked about this and I think actually you know one of the things we may want to explore as well is just the integration of slack with IRC and so forth and you know if you can't get slack people can just do IRC and we can merge the two it just goes a little bit more complicated because you can only really bridge you know sort of channel by channel but we can certainly look at that as well if it does become a problem um so Chris or Steve I'm not sure that was just speaking but this is Mike again I think we also have the IT team working on slack and mailing list integration so maybe you can confirm if that's there is a project there is a project active looking looking at doing that that's correct yeah well Chris I don't have a problem then of setting it up and it'd be a worthwhile experiment it's at an identity mailing list yeah okay Chris can you um Chris can you just I'll sync with you offline to get the details of all of our participants all right I guess that's it there are no other topics I guess we can be adjourned and I want to thank everybody um especially those of you who got up early this morning to to flip down to the to the conference room it was good to see everybody in here um and so uh that's that's adjourned and then we'll talk to you all next week if not before thanks Chris yeah thanks Chris thanks thanks bye