 Update on the hackathons. So the July hackathon has been finalized. That will be July 26th and 27th It'll be in San Francisco. The registration link is now live So if you plan on attending that, please register as soon as possible For the upcoming hackathons, we have two doodle polls out right now August We're trying to hone in on a couple dates for a virtual hackathon and then during the September and October time frame We're going to host a European hackathon. So please indicate your availability if that's something that you plan on attending Any questions on the upcoming hackathons? Just one quick so Clarifying because there was a poll about whether it was going to be South Bay or San Francisco So it has been decided to be in San Francisco, right? Correct. Yeah, the overwhelming majority seem to prefer the San Francisco location That's fine, but Just wanted to make sure that's what I understood was correct Perfect. Can I ask you a question regarding how the hackathon is going to be organized and the setup itself? Is that being worked on? Typically in others feel free to chime in as well. Typically what we do is largely run it in unconference format Although be one main room With clusters of tables power strips, etc Typically it gets kicked off with about 30 minutes to an hour overview with general objectives directions or some different topics that people may want to dive into and then a variety of groups then meet around specific topics or specific things that they want to work on over the next Day and a half during that time will also have a breakout room if people want to dive into more presentation style stuff And as it gets closer, we will Firm up an agenda and different topics that people would like to get slotted in All right, thanks Any other questions before we move on? All right. Um, the next thing is the TSC meeting next week We've already heard from a few people that they're gonna be out of office It sounds like people will be going away at least in the US preparing for the fourth of July holiday I know Chris is gonna be out. I know Brian will be away in China And wanted to gauge from the rest on this group if it makes sense to keep the TSC call next week in which case we'll need to Find one of the other TSC members to run the call and collect the agenda, etc otherwise potentially next week Back up after the holiday Richard here it suits me if we if we skip next week as well More alternatively because ahead I won't be able to be on it, but in that way All right. I see in the chat window another another vote for cancel Other thoughts from the group. Does anyone feel strongly about keeping the call in the calendar next week? All right. So let's put it this way any objections to canceling next week All right, hearing no objections and seeing quite a few Cancel notifications in the chat window. We'll go ahead and cancel next week's call and Pick up on I believe July 7th All right, and then at this point I am going to hand it over to Arno Arno, I'll make you present her in just a second here to walk through the exit criteria discussion All right, thank you Hello everyone. So yeah, so following up Last week's call and discussion I took another pass at the document There were two main driving forces if you will to behind the changes that I've made the first one is, you know, I look closely at the set of criteria that were defined by the Apache software foundation, which has the same kind of concept of projects like cycle with an incubation stage They start from and then they match they graduate from incubation So I looked at this and trying to see, you know feeling some of the gas we had tried I mean some of these, you know, obviously are very Apache software foundation specific and not applicable But they were several of them that I thought were quite relevant and I tried to adopt For our project. The other thing, you know, the other dimension to the changes I would say is that So we have a discussion between, you know, are we talking about the project maturation, you know, mature state or or the product and We did clarify last week that it's more about the project itself But, you know, it seemed like a lot of people we also talked about maybe having some kind of criteria They were more like some kind of goals to be met and this could be defined as part of the Proposal from the beginning when people enter incubation You might want to say, you know, we are trying to achieve these goals And then these might be more in terms of, you know, applicable to the product that the project wants to produce And so I tried to separate the two and, you know I can't claim that I got it this way all right, but You know, I tried to separate the two in those two lists with the first one since, you know This is more about project life cycle and small but whether the project is organized well enough, you know, generally speaking to to to graduate from incubation or Or in, you know, so this is more like Everybody it should be applicable to everybody and so I think we could define this set of minimum Criteria that needs to be met and then there's the other set is more like, you know The applicable maybe to the product and these are goals that will depend much more, you know broadly to depending on the project, right and so There were some items rather than, you know, because I didn't want to throw anything away either And so that was also part of the motivation There were things they were not directly applicable to the project life cycle per se But I thought it'd be shame to just throw that out and we did have quite a bit of discussion as to, you know Things like security review and that kind of stuff Scalability that people feel like these are important Criteria that should be looked at and so I put those into the second list that I call additional Requirements with this idea that so the minimum requirements is things that should be applicable to all projects And then the other words is something that is more open-ended that can be defined on a pair on a pair project base So I saw that there's so people made some comments, and I thank you all for your feedback Obviously, it's even him my place So I haven't had time to go through everything carefully yet I will try to do that today and and and you know, but I would be happy to hear if there are people want to Discuss or if there's any reaction that anybody wants to raise now or discuss. I think that'd be great There was one comment I made since then there was a I think Chris Fairies pointed out the actual name. I had called maturation incubation and maturation seems to be Accent to me. So that's what I wrote. But in fact the life cycle project The project life cycle document talks about mature state. So I made that change So if you looked at this last night or earlier today And you and look at it now. There's been that one change made already to the document, but that's very pretty editorial Hey, this is Brian. I I have a few I have a few thoughts and I and I will and get them into the document, but I wanted to air them here first The first is on the on the second page you use HIP Even though it's I think it's defined earlier And I'm sure you're borrowing from the VIPs and EIPs from other communities, right? But on these other communities that you know, that stands for improvement proposal, right? and they tend to be about specific features or specific pull requests or You know, almost more of a standards kind of thing than they do to speak about proposals or Projects basically Which I think I think you're intending here is is that it's a code base and a community that goes from being proposed for incubation To being actually in incubation to being mature to deprecated tend of life and so I'm wondering if we can come up with a different term and reserve HIP for Things that are more specifically within each project about technology change Okay, so let me clarify the so the part that I did it is only the first two pages which ends at acknowledgement The what I think you're talking about is a table that Jeremy Actually added to the document as an attempt to try to show the different dimensions that are you know at stake here And so this has not been really reviewed by the group. We discussed it a little bit last week We're trying to figure out how this plays out with the rest and so do you want to do you want to focus this week on? Just the first two pages and then next week on the third page Yeah, I mean Then okay Then pulling back To just the first two. I have a slight sense that the term mature may I understand the value of that in terms of communicating That you know, this is a project that that has actually met a number of different criteria And it's something that we can recommend and it's safe to use But I also wonder if it can come across as a signal that innovation has ended in the project I don't know about you, but if I were to be described as mature by a friend of mine I would I would interpret it to mean that I was no longer a fun guy to be around I'm wondering. I mean Apache calls them top-level projects, which is awkward as well It kind of almost doesn't matter. I'm just it early on is kind of where you get the one chance to set the right terminology And so I'm just wondering if there's a better word than mature Yeah, I mean I Released I don't have a strong So if I don't have a strong opinion we do I mean we have a proud project life cycle document that we reviewed and approved that calls that mature But it you know if we have a better name. We could definitely call it something different and make the change throughout But right now I'm only referring to terms that I use, you know defined elsewhere Right, right Okay, well, I guess I would just open the floor then to people to consider Whether whether there's a better term Live is is good or If I see hard This is Jeremy separate, I think I think the mature term is is problematic and I think the the term project may also confuse because the degree to which that means that means I Don't take that word to mean the same thing as the word Brian that used last week community And so I think I think the terminology is a Concern because I don't think We want anybody to Anyone to assume that just because of the TSC has spawned an approved sub project That it's necessarily ready for production I'm sorry go ahead. No good I was gonna say you're right that was my my second point Which is we should get the project or sub project or you know hyper ledger project is comprised of a set of communities and code bases that produce, you know that sort of thing like We should get the taxonomy down for that I'm willing to be somewhat benevolent dictator II about that if people would prefer I But but it feels like the other the just getting a hierarchy naming thing It almost doesn't really matter as long as we're consistent and I've been inconsistent. I've been trying to find code base community happy to take proposals for consistency and then maybe we approve that in two weeks at our next meeting for or happy just to declare something and So just so you know, I mean the I you know, I'm personally completely open to changing terminology I Do want to point out that you know the the more we develop documentation obviously the more the changes will be you know, we'll have to to be Made throughout the documentation so for instance, we also have a proposal template and it's You know, it refers to these terms to it calls it, you know, a proposal template for a hyper ledger improvement project So if we want to change the term project, we'll have to make those changes throughout is all I'm saying but I'm not personally, you know fond of the current names either so It's I think this is kind of things where you know, we're kind of stuck with whatever somebody had came up with and nobody had Better idea that could be convincing enough that we changed but if you want to try I'm sure you're welcome to do that Well, when we do this if people want to put together a proposal for that, you know Address this kind of naming and taxonomy questions posted to the TSC list You know, I just wanted to move on just because it's probably in some ways the least important thing to talk to About with the doc, but in some ways, you know, it's important to get right at the beginning or right enough, you know And these things are always organic. It's just like language. It evolves over time but it It's fine. It's just pick one and go so Close to TSC and then either we'll talk about it in two weeks or or I'll just say that one clearly is the winner and Plus one other people's proposals to I see I like the suggestion of stable when it comes to describing and as an alternative to mature All right, so is there any other comments? This is very useful. So please This is Jeremy. I think the splitting out that you've done of sort of the base Versus the additional requirements is a fine one and I think There's consent it's I assume that there's some consensus around the distinction between the the project life cycle and the Product life cycle. So I think so I think this is fine to move ahead with I Guess my question would be is Where do we want to put things do we want to put much most of this stuff than in the requirements? About sort of the what the scalability requirements are what the security requirements are if so, that's fine But I think it comes out of this next Yeah, so I think the answer to that is you know, if you look like for instance It talks about in the first place we talk about sufficient test coverage And maybe they should be changed to something slightly different But it's mostly it says hey test coverage is important. You should you know if you want to to claim that you know, you see you You can graduate from incubation you should have your test coverage Basically under control it doesn't mean that you have achieved a certain You know certain level when comes to test coverage and I think for scalability test. It's the same thing I think and somebody actually added this piece about you know additional performance and scale test Capability is desirable. So this doesn't say you know, this is the level of you know Performance of scalability that you must achieve to graduate, but it says this is an aspect that needs to be taken care of So I think this is where the nuances in the second least a specific project might say we want to achieve You know a certain level of performance or certain levels can be in some dimension And that might be much more specific in having some kind of number But so I think this is the difference that's that the document is trying to to have to carry In a way, it's almost like making sure that the community that is formed here prioritizes and and you know has a demonstrable kind of aptitude for Things like test coverage and user documentation, right? It's there's probably separate criteria We can have around release criteria like the the taxonomy I proposed But you want to make sure before a community graduates from the incubator That if they at least demonstrate that you know those are those are principles that they believe are important As they're building this code, you know that they able to at least be able to characterize the performance be able to have a framework for testing and Care about onboarding new users new developers into their project and that's and and That's still a subjective criteria criteria, but it's worth it could be worth having You know in called out specifically That's indeed that's the spirit of what I'm trying to get to there That makes sense. Well, perhaps the thing I would imagine One could add in that sort of goal as opposed to requirements vain would be something around an Appreciation for how this stuff might be used. So for example If you saw in the news somebody lost fifty three million dollars on an ethereum smart contract that got hacked and Similar a conversation I had with somebody From another one of the open source foundations, you know in an on an IOT project for example That's control that might be used to control say like a generator or something like that. There's a there's just a higher level of Robustness and care that may need to be taken simply because of the way it might be used and so if if if With something that has the potential of the I think we all hope that Hyperledger and DLT has it might be good just to at least suggest that somebody ought to be thinking about things like that Without it any sort of language that implies liability on our part Clearly yeah, but I agree with the idea Yeah, in general any attestation as to the suitability of software for use is normally avoided Meaning, you know, nobody is going to legally stand behind stuff Even even software that is not open source Will not you know like Microsoft, you know, Excel if you if you buy it. It doesn't mean that you can Rely, you know, you can sue Microsoft if you lose money because of bugs You actually I mean there are product liability Laws out there and they do apply to software And you know we can disclaim in the Apache license, you know, all of this is use at your own risk, etc And so far that's been good enough for the world So but the software is now being used in more and more critical environments and and the health care industry is Starting to face this with open-source software as well where they can't just point the finger at those crazy open-source developers whose code broke So Yeah, anyways, I think I agree with everything people said I didn't get into paranoia into conversation. It was more Just making it an ethic that of you know, what we're building is aimed at production Applications and when we say something is Stable when we say it's production recommended for production use that we have a high bar by what we mean by that Yeah But so I think there's part of this could also be addressed when we talk about user documentation Maybe I could add to the the sentence there, you know that The documentation should provide, you know some kind of information about what this project is about obviously and what you would you know What the applications people are expected to be able to use it for with that kind of Yeah, I think so Yeah, I think the the the point is that There is somewhere a fine point between exhaustive legal ease that covers everything and You know, basically some kind of a normative approach which Tell people to you know, these are the best practices and if the the more of them that you address in your software and in your public release notes and your Documentation the more people will will be inclined to use it under the Parameters that you specify like for example, if you say it's scalable to 10,000 nodes and this is the performance we notice then somebody who wants to use in 10,000 nodes would be able to You know at least Check or trust that that metric that you have published in a user documentation or somewhere else But the exit criteria document itself should be You know quiet slim It cannot possibly take care of all future, you know problems or Or cannot be exhaustive in a legal sense Right Is there anything else? I think we're making progress. So that's good So I take it that I've heard support for the tool least I haven't heard anybody object today. So I take it as a Sign that we should continue in that direction Is there anything else? I think you know, then it's just a matter of keeping on hammering on the different items in each list and Fine-tuning what it says and we should be able to get there very quickly I agree. This is this is a really great progress and art or not And I think emphasizing at the top that this is intended to apply to projects and is separate from the criteria for labeling and making releases of products, you know Code of actual code is important right And then when it comes to the taxonomy, we'll wait for Brian to tell us what to do I mean, that's a fairly simple change. Obviously, whenever we get the better taxonomy we can align all the documentation that's Simple query replace type of thing. So All right, so if there isn't any more comments now, I think we can move on with the next agenda item. Thank you And obviously, you know the the communication channel remains open feel free to comment in the document or The mailing list or contact media is like whatever works for you. Thank you. All right, so Todd I'm just marking. I'm moving to the next agenda item Perfect. Yeah, I was gonna pass that over to you Brian just to to give a quick walkthrough of the exit criteria Or sorry, they tax on taxonomy that you sent out earlier to the TSC list Right, right So this is definitely a Developer preview of the taxonomy to be a recursive here This was an attempt to try to figure out just how how we might consistently reflect to to new users and between projects with date of maturity of our code bases In attempts to set subjective criteria at each level with enough finesse To allow some wiggle room, but but enough clear points as well and to describe intent As well and and really it suggests that there are four phases To a major release cycle Although the very first one is only used when the project is still really getting off the ground, you know It's kind of both fabric and sawtooth lake are right now But but but that over time as you go to a 1.0 or a 1.x or a 2.x or a 3.x release stream You know alpha beta and production will apply and And so so just a quick run through the idea that alpha was something for which you know where your feature For everything that you've committed to in the production release Those can be at various stages of you know readiness, but but let's just say there's at least the clear in code attempt to Implement the features that the community feels are important. It's ready for proof of concept level deployment That may be an ambitious statement, but I think it's what a lot of people are doing today with fabric And sounds like may start doing a sawtooth lake as well. So I think that that matches performance You know is at least Describable it's something where it's it's predictable that you're not when you're doing a demo for somebody You're not going to end up waiting surprisingly, you know two minutes for a garbage collection to happen in the background Or at least that's documented if that happens any API's that it exposes are Documented and start to be solidified because that's that's I think an important thing to communicate to other projects really What what's your contract that you're going to form with them? There's some first attempts that a user documentation and developer docs are further advanced from from the developer preview I'm sorry, I'm skips kind of reading through developer preview Developer previews basically everything before that point, right? In both alpha and developer preview when you make a release you try to make sure that any any issue that you could characterize It's the highest priority issue, which is different in different bug databases But you know generally any any security flaw not just theoretical, you know any You know doesn't compile or or seg fault kind of kind of bugs You don't really want to release anything if if those with that kind of you know dangling turd is still there and And and in alpha, you know The idea was that you'd have a naming convention that generally would follow like a zero dot eight or a one dot eight or whatever And if you wanted to do iterations on that release stream You do zero eight one zero eight two zero eight three, etc beta further along is Intended to be feature complete again just like with alpha You could also have an opening for additional optional features, you know to make those core features Easier to use that sort of thing It's ready for pilot level engagement Performance could be very well characterized, you know, it's not just this won't fall down at a demo But it's something where you know where you know the active orders of magnitude required and how things scale of whatever is is understood And and people are actively focusing on asking how can we crank the transactions per second and that sort of thing With some sort of sense of a target for a production release And here I'd expand from no highest priority or high priority bug left unclosed when you when you do a release And and developer documentation should be for for that, you know to start bringing on the the final kind of wave of testers and Other developers is mostly complete and and user docs, you know are trending towards them And that's where it's a zero dot nine dot one zero dot nine dot two And then finally a production release is intended to be basically an exact copy of the last iteration of the data cycle So that you're not introducing any possibility for regression from things that have been well tested That you want to give some reasonable length of time and that could vary a week or two, you know Longer if you feel like you'd need it for convergence, but during which no higher higher priority bugs are discovered Docs are complete and basically where the community the developers are willing to you know, put their name on a press release If we do a press release and and I that's about where I would do a press release Ready to say it's ready for production level engagement. And again, that's around certain the performance Characterizations that sort of thing and that's where you get to call it 1.0 or 2.0 Or potentially 1.0.1 1.0.2 1.0.3 or if you're adding a Minor improvement, then you create a new branch 1.1 1.2 I'm not as attached to the naming convention. I know there's You know plenty of other room for opinion on that important things to be consistent and if people feel comfortable putting a's or b's after Or DP for developer preview after after release numbers, and that's fine. I Tend to find that I it's easier to miss those and I think Linux did benefit from an Alternating approach, which was that the odd numbered point releases 4.1 4.3 4.5 were considered You know more alpha and more unstable and then the 4.2 the 4.4 4.6 kernel branches were considered the okay. This is recommended for production use I had intended to get this into a Wiki document and If Todd is my hero. He's done that for me. If not, I'll go and try to do that later today So that or start out as a Google doc Eventually, I want to get into the wiki because I think it's having it on the wiki is a good thing. Certainly eventually But I would love to take kind of first stab feedback and then and then iterate it for the next call Thoughts. That's good. Yeah, so so I this is uh, Sean so I've been doing The release stuff for sawtooth like and a lot of that's been kind of internal At Intel for internal releases But yeah, I have a lot of thoughts about this. I don't know if We can take up this this meeting's time to kind of delve into all of the detail but a couple Observation, I think we're Combining a couple things here at at a top level One we're combining this concept of kind of production ready with The major version number and there might be other reasons to have Have that version increment. All right, so for we start to Do semantic versioning where we want to make an API change, but that's not really a statement about The production readiness as much as the fact that we are making big changes in the project. This would kind of deter that type of versioning change But So so that's one observation just kind of I guess status of of how it should be used with with you know in conflict with semantic versioning, which is kind of What we've been thinking Also, it seems very Focused around major releases that we would take you know have six month releases and that's And I realize that this is more around major releases But I think that maybe we should call that out that this is around that the major release Cycle and and probably a lot of it is is more around how we branch and think about maintaining our branches So something like the developer preview, for example, what I've had in mind for such is like is at some point in the very near future starting to do very a very regular cadence of releases and so When I say that I mean point releases essentially we call them patch releases releases in here But they're not really patch releases. They're just releases of the development branch but instead of having one there would be maybe one a week for example and the motivation behind that would be One around packaging starting to get you know stuff released into Pip and you know Debian and Sent to us and like getting the getting the software packaged up and we have to have a regular cadence to do that But but we're not really necessarily making statements around Other other than it's checkpoints right where we're trying to release stuff that's not broken But we're not making a big announcement about it it's really just the development branch and That's a lot different than the developer preview Idea here, which seems more focused on on an announcement of a major version Are you thinking not going mechanics? Just just to test this are you thinking you may want an alpha and beta cycle for say a 1.1 or a 1.0.1 Yeah, so for example, so the current version is how to like is 1.1 and For us that we achieved that when we open sourced it Although the versions prior to that were were closed source and so we put a big effort into You know, this is a march into preparing that for us that that release so in this in this sense of That was a developer preview for us. We didn't call it that at the time. We just it's part of our open source process And the thinking Especially after this recent hackathon where we we got a lot of participation You know, my thought is it seems like we're ready to start doing More release activities. So it's very timely for us And that would be basically on our our master branch, which is currently 1.1 Just starting to do point releases, right? Which essentially means we're going to take it and Build it for the community and try to get away from, you know kind Right now we're we're assuming everybody has developer level skills and is going to kind of do our developer setup activity and So, you know those ongoing point releases of the development branch would would be basically saying you know feedbacks valuable regardless of Whether or not you have the skill to Actively set up our development environment But we'd like feedback even on the development branch if the level of expertise is a Linux to submit that can And install it using app get for example, so a lot of so so I think You know at a high level like thinking about branching differently is the biggest thing for me here separate from the status of the branch So and you know when we if we Got to a point where we're we're doing like a production level release We might bump up that major version number For us, maybe that's three We're at one one now the production one, you know, we might have some other reason to do a version two if we Change fundamentally something about the software But we might have a version three that is production level and it seems More logical to me to describe that version number then to encode it in our And how we select that number And maybe the shift there is talking about stable versus, you know, if we use the word stable instead of production here to describe this branch then Then I think this makes a lot more sense to me because it removes, you know, whether or not it's production ready You know the intent is that it's stable and people can work with it, which is different than The definition of our current branch where we are breaking APIs between repositories and stuff like that You know, it's often said that if you're not embarrassed by your first release or, you know, the 1.0 release, you waited too long to release it So you may have a point there that you know requiring everything to be recommended for production systems and it is 1.0 So maybe a high bar when I think I think Bitcoin is still officially in beta as an entire But Ethereum is, I forget which, but anyway, yeah, it opens up production for who? Right, so I think production within some clear criteria, you know, which is on this kind of test rig This is the kind of TPS you can expect I, you know, that, I don't know, it's kind of For one degree, you know, we could be dog-fooding us, you know We could be running our own test instances and you know, there's been some discussion about public chain, you know If we wanted to adopt some, you know, social benefit public chains as partial demo, but partial production as well And and they, you know, in the same degree that the Apache web server team didn't call something a production release until It was running on Apache.org, right, because that would be pretty embarrassing if it wasn't You know, there was some way of introducing dog-fooding here, you know To help attest to that confidence in the production quality of what we're building that would be, that could be helpful The other thought that we had was adopting kind of Even odd Numbering approach, you know, we haven't, we haven't done a stable branch yet But our 1.1 is You know, basically our development branch, and so if we wanted to do kind of the stable Development-slash-stable model of alternating releases I think that's at least where my head that Given my experience with like Gimp and GTK and stuff like Those community projects and how we did it many years ago I guess is the model that I'm most accustomed to But we did the rest of this around like alpha-beta that all makes sense, but I think we should be clear that that's for each major version It's not a one-time thing, right? Like You kind of have that it's a cycle of writing to that that stable release Right. It is it is repeated for each major release was my was my intent and and I maybe I could make that clear So so it sounds like There's two there's two schools apart here one is Different ways of doing release naming the other is asking whether we wanted to attach these criteria to To the to the traditional, you know 1.0 1.1 1.2 kind of thing or make them simply attributes of a release You might say this thing actually isn't production quality until it hit 3.1 as Windows famously was, right? Or and that's boss it's point to two or something whatever But I feel like that would miss something of an opportunity Well, anyway, it seems like Some of the commentary might also be is there a fresher approach to this what I would it suggest is If people wanted to propose alternative numbering schemes within this definition That you know that could be done on when we set this up as a Google Doc that could be done as you know extensions below that Google Doc if others really wanted to propose a different framework for this document overall then let me know and You know, maybe well, maybe what we do is provide the space for a completely different write-up and then two weeks from now we try to have more of a Apple the apples apples comparison between between the two different approaches and go for it Do that make sense? Yeah, that makes sense. I think we could also continue I had some discussion on the mailing list to that's Throw some ideas back and forth Maybe before before writing up an alternative proposal Okay, so my action item will be get this on a Google Doc and and start integrating other people's comments or others For hopefully more something closer to ratification in two weeks. We move on the Yeah, the next item is going to be to talk about the TSC composition moving from the startup phase into steady state six months out Brian, did you want to kick that off or do you want me to give a quick overview? Yeah. Yeah, I'm happy to do that and Todd Tell me where I get this wrong. So the original charter called for the TSC to be bootstrapped with representatives from the premier members of the organization, which is a reasonable way to bootstrap but over the and it bootstrapped and said that'll it'll be that way for the first six months and then I I from there it'll evolve to be a group that is elected by the contributors to the project and That I And kind of leaves it at that and the intent there is to make sure that you know This doesn't become seen as a stark and star council, you know Comprised of you know people who paid to participate but it instead reflects actually the the meritocracy In inherent in the community And that Rollover date is August 11th. If we take February 11th as the first TSC meeting and so On the plate is figuring out How do we want to conduct an election for the next set of the net for the next TSC and for the chair of the TSC? And and probably that comes from deciding who counts as a contributor to the project You know Chris Is putting together a list that he simply pulled from github of people whose code has ended up in Any of the code bases that have been contributed to date, which I think is is very fair and he's Suggested also adding to that names from People who are in the working groups Which I think has been another form of contribution that should be recognized I I think this community this call might want to say are there other ways of defining who the electorate is and And once we define that You know some some process for and choosing among them the you know the 11 people say who form the members in the TSC and 11 is what we have in the charter That's a nice odd number I Does not include me. I have no votes in the TSC And the TSC is intended to be hyper ledger-wide So I'm tended to apply to these projects and as well as others as they come in so So anyways, I just wanted to put that on the table And maybe the first thing for people to be thinking about over the next two weeks is What the definition of contributor should be you know who and to recognize? You know the the value of contributing to the project and keeping it very individual focused rather than vendor focused And then secondly You know what is what is a reasonable process that isn't over politicized or ends up looking too much like the American electoral process? And and then finally, you know who wants to volunteer for for the role. It is a very critical role And and it's been performed adverbally by by all of you And I think people won't be shouldn't be too hard to find other volunteers But I just want to emphasize that it's it's critical to the health of the project that would have this Technical leadership and that's what what this this council represents and I think I personally think that Chris has been doing a fantastic job and and if you wanted to Remain the chair of the TSC. He'd be welcome And I you know, but I but I think he also I think it also is fair to have that the position as well that is Usually that's actually elected by the TSC. Let me check the Charter I'll do that offline rather than right now, but anyways just wanted to plant the seed have an initial conversation about this No, no need to converge on something right now But if anyone had thought they wanted to share on the call, I'd open it up for that Okay Feel free to post the TSC mailing list some thoughts otherwise in two weeks. I'll come back with with Chris with a specific proposal then And feel free to even communicate privately if you there's thoughts you want to share privately So we can we can move on to the next topic Ben are you on the call? Hi, this is she and Ben is not able to make their call today. So I'm gonna substitute for him All right. Yes. I just wanted to discuss the fabric V zero dot five developer preview release So our main intended goals of this were to Stabilize the set of capabilities that we have out there So the developers can try it out and then really Just exercise the release process. I think there's been a ton of good info on this call from especially Brian and Shawn And so I think we'll learn as we go in our future releases So what we've done is we've created two wiki pages under the fabric project There's a release process page and that page kind of gives an overview of How we're handling the release process. So we've created a separate branch with the same developer preview name and We'll Keep that branch there. We've tagged it And so I think ideally we'd move some of this info Into a kind of higher level document and hyper ledger if the projects are able to kind of standardize on the way They do this And then keep anything that's you know more specific to the fabric project on this page One of the other Set of instructions on this page kind of describes You know, how do we handle picking? Bugs that should go into the developer preview branch, you know, how do we select them? How do we vote on them? kind of what's the timeline there so that's something that Again like to kind of see the community Discuss and try to standardize on In terms of what's in the release itself There the primary new feature there would be the client SDK Written in Node.js. So we've tried to standardize that and the the REST API and the command line interface there are a number of a Known Issues listed on that page that we're still looking at and some of those may be moved into the developer preview branch is needed So I guess I'd encourage people to go look out at those Wiki pages. Sorry, I'll post the links into the chat here and Give us feedback and then I think we'll Participate in the discussion on the mailing list that and started so we can help standardize the process So are there any questions? I think somewhere in the release process. There should be some opportunity for The for a low threshold consensus to emerge amongst the developers you know very similar to the Improvement kind of proposal for you know, three plus ones and no veto Something along those lines should also be done when cutting a release And and if at some point in the future, I mean Apache does this the developers sign the releases with their PGP key And you know this community may not be as active PGP users of the patch it was but With the useful thing to be able to attest to the integrity of the release tar ball I want to download it and that would be something good to add eventually to the standard release process Yeah, completely agree especially with the voting threshold. I'd like to see that Have we established a location to kind of put up artifacts like that? The tar files and you know if we had you know depth files that we had built that we were we're publishing our RPMs Just give have provided a place to do that So get hub provides a release or tags pages that has that information Right, but not not to easily download the release image, right? Um, there's a yeah, it's just like a zip of yeah, what's a zip of the code that you can download It's probably that's more geared around like source releases, but yes Plus them further by signing them If that's something you want My team to pick up on as a as an infrastructural kind of kind of thing to have a downloads server of some sort Are there any other? Typically Releases at other projects also have a changes file that kind of describes at a high level release to release what And I see you have a place for release note I guess the release notes intended to be kind of the tweet tweet size kind of updates on each PR that was integrated into a given Yeah, I think it was kind of difficult because this was the first Attempted a release, but but yeah, I think yeah, yeah for the next week at least yeah I'll give a much more descriptive change of exactly what changed between the two Yeah, okay. Now I see it Yeah, it's something that yeah gets updated with each word perfect And I guess it doesn't have to be included in the tar ball that can be kept on the web page Yeah, I don't know and I wouldn't be opposed to including it in the tar ball also That made more sense. I'm just so if you downloaded it, you didn't have to go look somewhere else also To see what was in it? And then it would also be find I guess Are there any other questions about the release? Okay, well, I think that's that's all I have. Thank you So next we'll move into the workgroup updates starting with the requirements workgroup Oleg are you on the call? Yes, I'm on the call. Good morning, everyone in the past two weeks we've been Further developing use cases into requirements. We worked on and discussed delivery versus payment by Jeremy Severee asset depository We have a quite a long discussion on the identity requirements and data protection And for the next week, we'll be we'll be moving into a little bit outside of the financial use cases I'd like to try a peer-to-peer insurance use case see what the requirements we can get from that case That's it for now. Thanks Excellent. Thank you Architecture workgroup. I know rom is not able to to join the call. He sent a few updates by email Essentially, it was at the architectural group met last Friday during the virtual hackathon They'll continue with a regular cadence on Wednesday next week that he said they seem to be converging on a common functional definition of the consensus and smart contract layers Which is going to allow them to have truly pluggable consensus layer that accommodates different consensus algorithms From there. He says as they develop the common definition both the new fabric consensus Proposal and the proof-of-laps time teams are testing bottom-up to see if their designs can fit or can be evolved to meet the common framework and They are also looking to have another off-cycle meeting next week to see if they can reach a definitive point on the topic Any other questions, please direct them to ROM or to the mailing list or the slack channel and with that on to Dave all regarding the white paper worker. I I Yes, so if you check out the white paper working group wiki page you'll see that we have a new version of the white paper draft published and basically, you know, we've Revamped the vision the background section why a new fab blockchain fabric. No, sorry. Why a new blockchain? We've actually Removed the term fabric throughout the white paper. So you shouldn't see that showing up anywhere and And so yes, I'm just encouraging everyone to please take a look Give us your feedback the links are right there for Submitting feedback and you can also view what has been submitted today on our on our wiki page You know, we're working on it on the glossary We've got a first version of it But it just wasn't quite ready for that to make it into into this draft release that we put out yesterday and we're also in the other area that we're expecting some Changes in the next version is around the architecture section. We want to make sure that we're reflecting the ongoing learnings from the architecture group, you know, be able to give a high-level summary of that captured into the white paper That's about it for me Excellent, thanks any questions for Dave? All right onward from there identity work group is Christopher Allen on the call All right, we'll get an update by email from him. And then the last one is the CI work group Chris Paris is not on the call. So I suspect that'll come by email as well There's one thing I wanted to just mention that's related to CI Which is we have I mentioned this on the technical discuss mailing list. I think We at the Linux Foundation have access to a 1000 node cluster for one of our other projects the cloud native computing Federation foundation and we have the ability to Deploy jobs to it We there's a form to fill out But and the idea is that it might help us With testing it could even be something we might wire into some sort of Maybe not continuous process, but at least a regular process Is something that you know, we become kind of a guinea pig for another project too So I'm cautious at first, but what I'd love to do would be to turn performance testing into something that we do for all of our projects and we You know find some way to standardize or share those practices when it comes to to instrumenting and and building a real science around around doing this so What would be great is if there was somebody out there who for whom performance testing was was a thing that they enjoyed doing Who was interested in taking on the task of figuring out how to to set up with conjunction with CI or some other process a performance testing Process and cross-project Kind of thing so so if you're interested in that kind of right to Chris and I Or or volunteer publicly on the TFC list and and we can start that conversation That's just that And that brings us to the end of the agenda for today So for those on the call any other topics that you'd like to discuss Otherwise, we're happy to give 20 minutes back to your days Sounds like no other topics. So with that we will finish a little bit early today and get minutes out later this afternoon Thank you, everyone. Thank you. Thanks Todd