 successful reminder of the Beijing hackathon. And then we have the top level versus sub-project discussion to resolve. And then there's the performance and scalability work group proposal that Mark has teed up that we reviewed at the HackFest, but not everybody was there. I guess we could get started with the recap. Okay, I'd be happy to try to jump in and give a recap of that and then if anyone else who was there wants to want to give that. So I had a productive two days of approximately 65 participants. I had about 80 registered and 15 those shows. Among that 65 is a nice mix of familiar faces and new faces. We spent much of the first day, I'm pulling up my agenda most year, much of the first day talking about kind of the path forward for fabric to get from here to one dot oh and talking a bit about a governance proposal. It's been right now this is the fabric level governance proposal that you know it's not a TSE-wide thing yet, but it's something we could think about down the road for module ownership to try to accelerate some of the pace of change through review and that sort of thing. And it's a hard it's a hard issue for sure. We also spent some time talking about the hyperlitter.org landing page kind of the way that we talk about our projects and kind of represent them and I'll bring that up actually in the top level versus subproject conversation later. But that was a presentation from Greg. He also talked a bit about what we're doing it at the Consensus Conference and others. Also had some great initial content presentations from some of our new projects from Borough. Just a really terrific deep kind of overview and as well as composer. And I know that the Sawtooth and Borough devs Dan and Ben spent a lot of time and Nick with each other looking at opportunities to to integrate the two and that was really great to see. There was also a conversation with a white paper moving that forward and and how we might represent that out to the world. So yeah so so conversations like this really a lot more conversations than hacking. I got positive feedback on that. I suspect there's probably negative sentiment that wasn't shared just because some people I think might have come expecting to open their laptops and start coding. But I think a lot of these issues were deep ones for us to really kind of churn on and especially with so many of the projects now. I mean it's not just fabric it's also Sawtooth and Iroha on this path to 1.0 on their own independent path that these conversations even if they were project specific I think ended up being pretty helpful to everyone else. And I should also mention there's a terrific presence there from the indie developer community and and Dipin as well kind of led a very meaningful conversation on how this will hopefully tie together some of the identity thinking across different projects. No decisions made of course that's not the point of the access but it was great to see everyone there. Any other thoughts or comments people wanted to share? No I mean I share the sentiment I thought it was very productive that was good. That was good to have a lot of activity from a number of the projects not all of them but it was rather diverse which is good. And we did have some meta conversations that I think were also valuable the whole discussion around the maintainer discussion and the the branching discussion I think others benefited from it wasn't just for the fabric team I think in terms of the various proposals and the merits discussion of the merits of the various approaches I think was good. Okay So I was just going to ask Todd to sort of catch us up on Beijing again remind us so what's going on and yep the planning and so forth for that. Yeah so there was just a discussion around whether the hackathon should be one day or two day we've been discussing with the community in China it sounds like for sure two day is the preference so we've been working through the day patterns. What we've decided and are recommending is that we would do Saturday Sunday which is the 17th and 18th for the hackathon that will feed into the hack fest which will run Monday Tuesday which is 19th and 20th. In addition we have a blockchain and hyperledger track at LinuxCon Beijing we've just finalized the sessions for that as of this morning so we're just going to confirm with all the speakers otherwise get that announced in the next day or two. But just main thing is calling for any objections to that date pattern otherwise we're ready to move forward with that and we can get the registration link out for the hack fest later today and then the hackathon shortly. So I'm curious to know you know we've had a lot of notice of this just I don't actually I don't know how many of the TSE is on the call do we have seven of eleven right now so we're one five four. I just be curious to get a sense from those that are on the call now then who's thinking of going me. I'll start it off. Brian I'll go for sure and we know that we'll have participation from the technical working group China I don't know Victor it looks like you're on the phone call do you plan to be able to make it okay Victor might not be able to speak. My my status probably depends on a number of things so if release one is out then probably a better possibility but otherwise it may be more difficult. I'm sorry Victor I mean you are able to. That was Ben. Oh that was Ben I'm sorry. Yes it's been. Hi Brian I notice you mentioned my name. I didn't hear the question very clear okay repeat did you plan to be at the hackathon in Beijing. Yes sure I will be there okay and I and I think in general you know the China community will be able to make it there and I think it's important to try to bring them together into into our other processes so I I realize that it won't necessarily be a critical mass of the technical steering committee or a quorum of the TSE which I think is okay what I would like to do since there is this admittedly ambitious notion that the hackathon is geared towards bringing in new contributors into our projects by having them focus on outstanding bugs and sample code and documentation and that sort of thing and then use the hackfest as a way to integrate those ideas into you know basically handle those those CRs and upstream them that if we have participants who know that they won't be able to make it but could contribute the time either in their own time zones during both of those events or or even you know later at night or early in the morning that would still be extremely valuable and I think one thing we might try to do is make sure that we we be as virtual about this and as we as we can be that might be one way to also help bridge this but I really do appreciate the fact that Chris is traveling there that looks like our know is also planning to go and I I I think this is important to to Hyperledger as a global project I just keep making that pitch any questions for Todd or Brian okay if not let's move on so the next pardon for me the the next part of the this of the discussion is actually something that I think we need to start coming to conclusion on and making some decisions and whether that is just directing to go off and and you know refine some of the TSC material that talks about life cycle and so forth to clarify project and sub-project but I think we were sort of growing consensus but I didn't sense that we were quite there yet and on on the sorry Brian let me finish the the summary here so people can catch up that that hard head you know proposed of essentially you know essentially establishing some sort of a dependency graph amongst the various projects for when a project is brought forward to be presented for incubation that rather than having things called projects or sub-projects or what have you that we from a technical side of things from the TSC perspective that we simply establish that there are certain interdependencies amongst the projects and that if there is a if there is an established interdependency between projects when something's brought forward that the maintainers of that dependent project I'm sorry depended project would weigh in on the proposal and its merits and so forth as an input to the TSC making a decision because obviously they would be in a better position more informed and so forth to to decide on the merits and so forth of a proposal that said then there's the marketing side of things which is that you know how the Hyperledger organization how Brian and his staff Jessica and Greg and so forth go off and essentially market the notion of an umbrella organization that has a number of different projects and how do we how do we you know how do we market that how do we present that to the rest of the world without creating confusion about and or angst about whether or not one or more projects because there's more sub-projects has greater weight or whatever so that's sort of where we're at I think Brian you were the one that had some concerns about the dependency so I guess I know you wanted to speak so I guess I'll turn over to you next. So first of all I think we had somewhat of a consensus or at least an idea at the hackfest that I thought would help clarify at least on the marketing side that there seem to be support for the idea that when we when we provide our list of projects to the outside world you know as people land at hyperledger.org that doesn't that list of projects doesn't necessarily need to reflect the organizational view one that has for example some of the SDK projects as independent units that report in the TSC that instead we can present a product-oriented view so you know fabric SDKs would live within the pages associated with fabric rather than presented at that kind of you know front end level you know that would slightly slim down the list of projects today from nine to seven but I think I would still characterize these as independent projects with independent maintainerships etc. The I'm sensitive to the concerns of the TSC being able to adequately reevaluate the technical merits of projects as they come in and if they if they seem you know if there's if there's a high volume of them and certainly I think we don't want you know 300 projects under hyperledger this year or we want to do want some rate limiter of some sort my concern about the dependency graph is let's say somebody does want to start a you know electronic healthcare records project I know that's getting a little more ambitious than we've talked about or sector specific than we've talked about it but go with me here and that's dependent upon fabric and indie at least at least at launch without necessarily you know committing to porting to the other frameworks or anything like that I'm just not sure that I didn't want that those sub-projects had to approve that addition of a project so they can certainly weigh in they can certainly inform and that would help the TSC and its judgment I think the TSC's focus should be primarily on scope primarily on appropriateness is this a worthy and valuable addition to the portfolio and and that's challenged obviously when it's something like the SDKs but I think it's also ultimately a governance question too do we have the right processes to adequately oversee you know not the seven project nine projects or 15 and the final point I want to raise on that is you know there are structures such as Apaches adopted in terms of regular reporting to the TSC in a structured way on you know developer diversity on releases that sort of thing and I think if we were to introduce something like that so that the TSC calls once a month we review report outs in the structured form some different projects it'll feel like a more manageable answer so I just wanted to add that bit to the discussion here I don't I I think there's a little bit closer versions on on many of these issues don't know that there's a proposal for voting on yet but I just wanted to hear others thoughts on that and then maybe we could advance this this week so Brian are you suggesting that at least part of this becomes a reflection of the reporting structure as well so the fabric related SDKs would be part of the fabric report is that what I heard you say what you heard me say was that when we when we talk about how we market these projects then then you know the outputs from the fabric SDK projects would be part of the fabric pages but from an organizational TSC oversight perspective what we voted on improved were these projects as independent partnerships reporting to the TSC a separate project now this is a bit of a yeah and you know and this is this is a bit of a complexity right because it's simpler when you say a project is a project and that's how we present it to the public and how we manage it internally but uh but I think I'm sensitive to the notion of you know if some of these are so specific to to you know if they're paired I think I prefer the term paired than dependency because you could have a fishery supply chain project that's probably way too specific but a fishery supply chain project specific to sawtooth but uh you know they're not paired in the same way that SDKs for sawtooth or SDKs for fabrics might be I understand your difference but I guess the question would be like a SDK in a specific language for a project is different than an actual implementation using one of the projects right and I think that's sort of what you're trying to make sure you differentiate hey Chris we're hearing you're typing in the background oh I apologize would you be able to mute well why are you so angry today here is if I'm unmuted unfortunately so yeah my biggest concern is I want to make sure that governance of the projects is direct between you know the project leadership and the TSE and isn't filtered through another project the because that's an easy way for those you know we've used the term sub projects and I kind of don't like that term those are discouraged in Apache even if there are instances where that term is used over there if you have too many layers of of indirection that feels like bureaucracy and it's an easy way for those projects to feel like redheaded stepchildren and forgot about and and so as long as we recognize that we need that direct reporting relationship between the maintainers on those projects and the TSE then how we present it to the outside world we can have flexibility around it yeah so I just I just said in the comments I think there are kind of two separate issues here that we are discussing one is the kind of the the project governance structure and I think at least on the email list there was wide consensus for maintaining a flat project structure so that that seems to be fine as is the other kind of sub issue I think here was the project proposal document and that a lot of people were concerned that it was becoming just an enormous amount of work for the TSE to review you know all these new projects as they came in and it might not be feasible to do so if the projects keep coming on at a steady rate in the future and the solution that seems to be most popular on the email list was to require project proposers to have kind of experts or or related developers you know sign off on the project in the project proposal so you know if I was proposing a Fortran SDK for Sawtooth Lake I could say you know hey Mick hey Dan you guys are Sawtooth Lake guys you know here's my proposal take a quick look at it and they do and they say oh yes that's that's great we have a demonstrated need for for more Fortran code so we're gonna do it and this way like Chris and Ben and all the fabric guys don't have to take as deep of a dive into the project so so I think those are the two issues here and I think the first one we can just kind of leave as is but it might be nice to change the project proposal text to require some some kind of expert sign off that's all and I and I think in you know we could yes and you know many processes like this like in Apache do require kind of a mentor for projects and incubation to have been previously involved in other Apache projects something like that at least from a process and an incubation point of view could also be helpful and ensuring that you know in helping increase the confidence of the TSE that the project will come in and grow in the right direction so I think I think we could add you know expert review or endorsements to the project template for sure I totally agree with this one, it's just really the best practice in the state and that provides extra credibility to the high assigned qualities that you have to be to the eyes of the gods and tees crossed and all that stuff in terms of technology understanding and the reasons therefore it makes the challenge so it makes it so easy for TSE and any others to endorse and sign off right Leonard that was pretty challenging I think for most people to hear but it sounds like you were supporting the idea of endorsements and sign-offs absolutely god yes I have an application this morning sorry but yes you're right terrific thanks I think we can wrap up this point for now and there's some instruction here for myself and I think others to kind of come back the next TSE with a more specific proposal so if everyone's okay or if there are any last words on this before we get to the working group proposal okay Chris should we move on Chris might have forgotten to undo himself um so uh mark do you want to talk about this tool is just and just infuriating sorry all tools suck it's just all every single god yeah tell us how you really feel Chris well you could but you can't just sort of bring the thing to the floor it has to hide and oh god anyway um so yes I was saying next up and I think Todd you said we were at Corm yes correct yeah we are awesome okay so mark you're up and I know we presented your proposal at the the hackfest and I think it was well received but I think there was a few from the TSE who weren't present and so for their benefit if you wouldn't mind sort of um reprising your your pitch sure um well thank you for the time first off um I in the performance and scale team at red hat so this is an area of great interest to me anyways um but you know the discussion we had um I had floated a proposal out to the TSE um hoping everyone had had a chance to read it but basically um you know I tried to keep that somewhat you know more as a guideline to start the discussions um and going off with some notes that Tracy had here to cover sort of what we discussed um you know we had a good discussion if this should be a working group or just come in as a project and I think we you know my personal feeling was I proposed it as a working group so um we could go and work you know the structure of a working group would allow us to better work across other working groups um and my expectation has always been that there'll be at least one project that comes out of this um and the fact that it starts as a working group you know I think the concern is we don't want to study this to death we want to get rolling and and start on uh some code and I think you know I don't see this being a working group as stopping that um you know from what I've observed in Hyperledger you don't say I want to start a project and then start with code start coding you you start with code and and come in and say we'd like to submit this as a project so I think we'll be able to do that um the notes here were that we thought you know people from each project would would have the ability to sit in um and of course this is going to be open to anyone who wants to contribute and and there are people I've received several emails from people that weren't able to be in DC that want to want to work with this as well um it seems like there'll be some companies that will be able to donate some existing code potentially um and one of the things we want to do with this is is not have a single metric but define you know what metrics we think are are important um and be able to provide a guide eventually that um you know as Hyperledger versus oh god sorry it was a long day as Fabric versus Sawtooth um you know they're they're not intended for the same same use cases per se um and you know even bring in Ethereum based stuff and be able to say look if you want this particular performance characteristic this is the project you should go with um so I think that's more or less the highlights I guess is there anything I I I missed that people wanted to bring up uh one one thing I would say is that um this is great uh so you know I've been looking for a way to uh kind of like establish some benchmark or something from the performance point of view so um it's kudos to you for initiating this and get it going um the thing that I'd like to see is perhaps not necessarily recommending you know which project to use or based on the performance characteristic but but more because you know um our base project you know Sawtooth Lake or Yoroh or or Fabric each of them um has various different configurations right it's it's very rich in configuration and because of that certain configurations would meet some uh requirements um so maybe somehow we establish a base benchmark and from that we work out different configurations and you know the performance characteristics of each configuration would be different and would meet some uh requirements um and certainly you know we can we can compare between different projects but I think different configurations would be more important just my point of view have been suggesting we use it as a way of comparing configurations within a project rather than using it as a means compared between projects right right which is to have um you know multiple different configurations in each project so so the onus of creating the benchmark applications goes back to each of the platforms so um I know we've we have some internal packages and I don't know what the current status is but Dan could perform that more but we have some packages that we use for doing benchmarking of our own code um are you suggesting that we provide those through the working group I mean I see one role of this working group being something similar to what the architecture group is doing and that there's sort of a there's a little bit of consistency checking to make sure that it when it's appropriate we compare apples to apples but there's but there's a lot more call it sanity checking in that role of making sure that the benchmarks are that we propose from each project are reflected right yeah no I think it's a good point to be able to compare configurations and and that's one of the things I do as part of my you know normal day job is you take the benchmarks and you know you try different configurations to see what gives better performance things like that um and we tend to focus when we talk mostly on performance but scalability is also a big part of this you know what happens when you need to add 10 more servers or you know 100 more x um you know I think in most of the blockchain cases performance goes down you know your total throughput will go down as things have to compare so um you know I want to make sure we don't overlook the scalability aspect of this as well because that will become a go ahead now just saying I told you that last weekend also we have control of scalability in the cloud and I have to say just to say this is from DDCC is there a hey so do you do you envision that we'll take up a business use case and that's how we'll evaluate across a business use case that works across these various platforms and then do the performance and scalability or these are very technological use cases for you to evaluate the performance and scalability um well that was one of the side discussions we had afterwards was you know we need to make sure that the benchmarks would come up with a representative so I could see different benchmarks for different use cases and I think that's part of the goal of the of the working group is to go through and identify those which you know and that that will evolve over time too as new use cases come up or something like that so we're talking about a business use case not like a technical use case well I'm thinking like you know an IOT versus financial transactions is that what you mean or do you mean very specific business cases right like in financial world you know we'll apply this business use case across these various platforms which has enough complexity that I guess which has enough characteristics for us to measure the performance and throughput or scalability right but that's going to be not so much a business case as much as it the business case informs the configuration that needs to be satisfied and then there's some you know common computation that needs to be done from a smart contract perspective at the various scales and then you come up with numbers I don't think that it necessarily is a solution you know is this fit for a particular solution I think again it needs to come down to because again it's not just about finance or fintech or IoT or you know it's it's all of the above and you know I think you know when we think about you know like cloud benchmarks it's back and so forth they are those things are not business domain kind of problems they're scale problems how many be enclosed in a minute you know yeah I'm glad to be there I'm glad it's like we've conclusively proved that Java as a server side language is appropriate for running a pet store and and that's quite like a service level agreement indicates that interaction of that agreement and all that uh warranty between the business customer and the technology there is that as a territory but as far as performance goes we need to show that technology and solution in place um it's satisfactory performance satisfactory in any environment and therefore it scales to provide that performance in any environment by the way I'm also very excited at the prospect of this working group including people and and thinking from BLT's outside of hyper ledgers there are commercial BLT's out there and you know coming up with a vocabulary and for describing you know how to even characterize performance in a BLT setting or something I don't think anyone's really tackled yet so that's where there's some pioneering work to do here and and I think why leading it with conversation and making it a working group rather than leading it with code first and making it a project is the better way to go right although I I do tend to think that you know the sooner we can get and I think mark I think this is your intention as well sooner we can get to starting to write code have a project that's informed by and and sort of joined at the hip with the working group is this really and mark cornered your proposal um the the focus is in the written proposal is on coming up with metrics um and and that's I mean that would be a precursor to to benchmarks and things like that but I think coming up with definitions of those to which each one of us could write our own set of benchmarks and the first step is a really good idea okay yeah that's a good suggestion thank you in addition to that there are lots of industry benchmarks and benchmarks out there already actually so we can start with those things fine and they need to be customized further so blocking that's one first Chris I suggest we might be ready for a vote yep I think so too Todd all right sounds good uh walking through quickly Arno yes Ben yes Chris we Greg yep part yes Mick yes Morali yes Tamash yes all right that's approved unanimously all right awesome mark you're all set um you should be able to create a wiki page and um we'll get a mailing list set up for this into and uh we should have what I think once every two weeks phone calls is what folks talked about at the hacks us if that makes sense yes makes sense and we should probably bootstrap well well we can keep this a conversational working official you know maintainers or official members of that work yet but uh might be worth formalizing that later down the road but for now let's just keep it a conversational working group and see what it produces sounds good thank you everybody any Chris any other comments or agenda no I think um that was all we had teed up so if there are no other agenda items people can have time back on their cast awesome all right thanks everyone and thanks again for a great hackfest and uh and uh you know mark if you have anything you need just let us know we'll do thank you all right thanks everyone bye everyone thanks bye