 I lost my health and go to meeting there because it's too much. Thanks Todd. So we've got a fairly light agenda. I was just to sort of keep people informed. There is a another proposal working its way through the sausage grinder and I think one of the members is just looking to get through their internal clearances to contribute something and participate and so forth. So we just have an action item review, workgroup updates, and then I thought we would use the remainder of the time to discuss the exit criteria that we seem to have need for and not urgent but we need to start having that conversation so that we have it clearly understood as to what we all feel is the criteria to exit incubation stage and what that all means. So I think we might as well take advantage of it and use the remainder of the time for that discussion. Pardon me, unless anybody has any specific additional agenda items to add. Hi, this is Brian Billenberg, I just want to say hi and let folks know that I'm here and I'm following. I just had a message to technical discuss talking about my new role and most importantly I plan to stay out of your way as much as I can when it comes to technology issues. But I look forward to being a partner with you all and yeah, let's do this. Great Brian, thank you and welcome aboard, officially. This is good news. Yeah, I'm excited, really excited. Actually, I didn't know you were going to be on, but is there, would you like to say something or, because like I said, we do have the time. I didn't prepare anything, as I said in my email, I've been following the project on the periphery pretty closely and got into so many of you and also understand the I feel like there's a lot of amazing opportunity here, but it's also kind of on our shoulders and especially the TSE shoulders to shepherd this community and integrate the different contributions and drive us towards what every community needs, which is shipping products. And that's what I think the world needs from Hyperledger 2. So I won't be dictating what we build or where we go, but I will be nudging, certainly, and Chris and I have talked a bunch about this and I do want to establish a relationship with each of you. So I'll be reaching out, but also feel free to get in touch with me directly because we know this, not only there's potential here, but you know what the opportunity is. I also know it won't be realized until we really build a diverse, broad, productive, open-source software developer and contributor community around this, and so that's my goal and it's inspired largely by the Apache Software Foundation's premise of great communities focus on building great communities and good, high-quality software will emerge as a natural byproduct. So if there's any framing that I'm bringing to this, it's definitely that. Looking forward to working together. Great. Thanks, Brian. Okie doke. Ok, so action items. TSC representation policy drafts still need to do. My goodness. I'm such a bad boy. I promise I'll get that by next week's call. The paper draft and we can leave that Dave for the update since that's coming up right next. The next action item was for Bishop who reviewed a proposal last week to contribute his busy work to the fabric and he was going to work with Ben and Shane and Greg to get that integrated. And he told me this morning that the pull request is due to land later today. So that I think we can take care of. Doodle polls for the June virtual hackathon and the July hackathon on the west coast. Todd, do you want to have an update on those or? Yeah, so those went out. When you have a second, please, please compute your availability. If those are events you're planning to attend for the July hackathon, we're searching for space for that. I have a note out to a couple companies. Also, there's potential to host it at the Linux foundation facilities in San Francisco. So we'll just check what what dates people are most available and then see what space matches up with that and be back in touch with an update hopefully by next week. If not the week after, I know one of the requests was to plan these further out than we have been. And so we're definitely making strides on that front. Excellent. And just Todd, if we're having trouble, IBM could probably host. I mean, that would mean either South San Jose or Foster City. Those are two locations that we could potentially host it at. South Bay, but it's certainly something we might consider. It's just a little bit more travel for people that are in the city. And then finally, the exit criteria due to poll. And again, I think given Todd and I chatted yesterday and given that we have a fairly light agenda, we felt using the time here to do what we were trying to accomplish in getting some of the other TSE members together would be well served. So let's move on to the workgroup updates. So Oleg, are you on for the requirements? Yes, I'm here. I was on mute. Hi, good morning, everyone. In the requirements for a group we're concentrating on developing the use cases that we have in our catalog. I called for a better participation than the last meeting. We now record our progress on the dashboard page based in the chat. I'm myself concentrating on financial use cases. I just did the currency swap and I'll have interest rate swap and equity contracts by Monday, by next Monday where we meet and discuss. So that's about it from us. Great. Any questions for Oleg? All right, thank you. Ram, you're up. And you're on mute. Or maybe, if you're not. The architecture didn't meet this week. Identity met this week. We're basically alternating. Sorry, I just unmuted myself. So not much of an update since we meet bi-weekly and our meeting is next week, next Wednesday. So I'll give you an update in the next week's thing based on our proceedings in the next meeting. Okay, thanks, Ram. Next up is Dave. Dave Oll for the white paper. Yeah. Hi, Chris. Thanks. Yeah, so we did, and Ram did attend yesterday's meeting. So he was still working on the white paper working group. And we did, if you take a look at the wiki under the white paper working group, you'll see that we have updated the page to show that there is a white paper draft of version 0.1 that's been published. And there's a link for the feedback form that we put out there as well. So not everyone got to attend yesterday. A bunch of us were traveling. And so it looks like everyone is sort of in sync, but we might be doing one or two more tweaks. Well, we'll definitely be doing one or two more tweaks to this draft version 0.1, probably today or tomorrow, but just to update some figures and things like that and some last-minute tweaks. But the bulk of it is there. And we would like people to, especially the TSC members, to take a look at it, read through it and give us an opportunity to add any more edits before it goes in front of the board. So looking forward to getting some feedback through the feedback form there and let us know what you guys think. Yeah, and as I mentioned, if you look at it this morning, you'll see that a couple of the figures still need a little bit of updating. But we should have that straightened out in the next day or two. And that's it. Okay, great. Thanks, Dave. And thanks to the others on the team. This is good work. And so I would definitely encourage people to review and provide your comments. And then what we can do next week is we can schedule a little bit of time to discuss any feedback or any concerns and so forth on the call. But Dave, I really want to extend thanks to you and the team. Yeah, the team did most of the work. I'm just an editor. Cat herding is very important. Thanks. Okay, where did my screen go? Next up is Christopher Identity. You guys may answer that. Yeah, thank you. So I just posted a Google Doc link to the chat with sort of the minutes from the meeting. We had about 15 people show up. A number of people. The original plan was to talk about and get a presentation on IBM's membership services. But that's been postponed probably for June 1. But definitely by June 15th, which is our next two meetings, IBM will be presenting on the membership services team architecture for Fabric. So instead we ended up talking a lot about other topics among which are various kinds of key life cycles, credential life cycles, how they're different for nodes and federations versus participants, some things around separating identifiers from claims. We definitely felt like there needed to be more stuff in the requirements and in use cases around life cycles of identities. So we're going to be working on some documents to share with the requirements group and the architecture group around that in the areas of what happens with inheritance. There's a classic failure modes of revocation and things of that nature. But then there's certain kinds of things that need to be longer lasting. Inheritance is one proper extinction, whether it is of an individual group identity or a federation node. How are things handled in that fashion? A variety of different kinds of discussions about possible technologies that are being deployed elsewhere that have some real relevance. The one that I think people really got interested in and decided they would like to have a full session on is to dive deeper into selective disclosure and some of the different approaches to it. We closed mostly on the whole thing of is it possible, given that there are a lot of different choices in identity services and that not all use cases are sort of financial identity type of use cases that we may need to have different identity services. So how can we define what exactly are those APIs for being able to have different kinds of identity services and bindings and things of that nature? There was a little bit of a discussion around having a standard language around electronic features and I didn't at that meeting have a final draft of a paper that is now published. Let me quickly grab all the decks. There it is, decks. Okay, so we talked briefly about this but I didn't have the final version of the paper until today on an example of a smarter, smart signature technique that could be useful for a variety of different blockchain uses. So that's the beginning of that and that's based on some smart signature stuff that is going on this weekend. I'll close the identity discussion to say that tomorrow is the big UN conference on digital identity. There's still a couple of spots open in the design workshop on the weekend which is going to be at the Microsoft Building and if people are interested there's more information at www.webtrust.info if you're interested in participating and we're going to be talking about a lot of these types of things. Again, two weeks meeting on the first and then the one after that will be on the 15th. Chris, this is Jeremy Severi if I might add. We've come up with a list of a number of different potential use cases that we're going to be reaching out to Oleg to try and see how it maps in. But there's one of the things from the past two discussions has been as we get a better sense of what the different dimensions of say the layers of the system might be or the separation between say the participants and the financial instruments or other traded items in the discussions. It'll help to have a sort of a common language to, as you said, to separate out some of these things because I think in some of the discussions we end up merging some of them. So I think that'll be... Yeah, there's definitely conflation in a variety of different areas. I mean, some of it is different identity communities called key holders versus principals. There's consumers versus relying parties. And then there are other places where they actually use the same language but mean different things. So we've got to reconcile some of those. We need to have a better understanding of... I feel like there's a fundamental difference between financial business workflows versus supply chain business workflows that may have large differences in how confidentiality is handled in them. And that can have some big impact on the identity system. So we need to have just a general better understanding of these problems. I had a discussion this morning with Bloomberg, Eric Anderson, and he's sharing with the identity workshop this weekend a number of business cases that Bloomberg is willing to share. So hopefully we'll move some of those also over to the Hyperledger project if they're applicable. So we need to make some progress here. So thanks, Chris. I appreciate it. Just one bit of feedback here. I think it would be useful to be working along with the various use cases that are being developed to understand what the identity and various other... So that's why I've been reacting to the requirements group. And unfortunately, we just haven't had the critical mass in the requirements group. We haven't had the right people. And it just hasn't quite come together yet. I was at the Hyperledger meetup last night. There was a presentation that's listed eight particular use cases that IBM is using Fabric for. And a couple of those cases, they were able to say, here is IBM's financial global services. But we need to get somebody from that team to help us write up their use case because clearly you're talking about it there. I think there are also some use cases that are in the identity paper that we really need to get the principles. But the feedback I've gotten off-line is that the number of organizations are scared to participate in the requirements because they feel like they're under confidentiality with their clients and thus can't do it. And puts us in this catch. I hear you loud and clear. I agree and I've been sort of, to be honest, I'm trying to get those internal IBM use cases out if they need to be anonymized or whatever. That's fine. But yeah, I've been working that end. But I would definitely encourage people to at least help us shape use cases. Again, you can anonymize these things. You can make the discussion be about some other thing and maybe what you're exactly doing as long as it satisfies describing essentially what the requirements are. And I'm more than willing if it's something along the lines where if it's really clear that your company is working with X, you can... Chris Ferris and I and other people can work with you to make it anonymous. So please, if you've got some ability with that. I mean, I think if we have some more of those, we have a really good understanding of the fabric architecture for identity and Intel presents, helps us understand their different approach to identity for the sawtooth submission I think will be in good shape to proceed. It will make some real concrete useful suggestions. And again, in addition to Chris and myself, you can also leverage Todd or Philip or Brian from the Linux Foundation. I don't want to submit a use case without having any traceable origins. That's another approach that you could take and those guys obviously are not trying to compete here. We're just trying to get the project move forward. So I strongly encourage that. But thanks, Chris, for the update. Let's see. And then finally, we have the CI Working Group and we've made quite a bit of progress this week. Garrett has actually stood up. We have obviously we have to do a little bit more configuration and so forth and we have to, I think, do a little bit of training and then we have to do a planned migration over from GitHub to Garrett. But the services is up and running, so that's a good thing. Thank you, Roy, if you're on the call. And then I also understand that Jenkins is up, but it still needs a couple of last bit of configuration and the individual who is doing that is out on a personal day, the remainder of the week. So I think that, pardon me, I think that'll be finished on Monday if I'm not mistaken. So hopefully once certainly once we get Jenkins up and fully configured, then we can start the process of transitioning. For instance, the Sawtooth Lake team can start moving some of their own CI over to the Linux Foundation Jenkins servers and then we can start in the Fabric team. We can start the transition from Travis to Jenkins and would certainly welcome any of those of you who, the many of you who offered to help with the CI now that we've got the services up and running, I think that there will be plenty of opportunity for people to engage and contribute as we migrate the CI from Travis. For instance, there's some sort of rework of those scripts into the right format for Jenkins and then there will be plenty of work to integrate Jenkins with Slack and so forth, so should be a lot of fun. And that's it. I don't think anybody has any questions. Okay, hearing none. Let's move on. Is that me? I think that was an echo. Sorry, I heard something and I think it's just an echo of my voice. So let's move on to exit criteria discussion. So I just pasted in a link in the chat to the channel in Slack where we started the discussion around exit criteria almost a month ago and I think Chris and I and a couple of others had a little bit back and forth on some specific requirements and so I'm just reminding the people of that particular chat. But I figured we could just start by sort of reiterating some of these points and I appreciated if somebody could take notes. Can I get a volunteer for somebody just to take notes of this discussion? I mean Todd, you're taking notes obviously for the minutes but are you able to sort of get a little bit of a detailed... Yep, no problem. And we're recording the TSC call as well as always. Oh, that's right. Great. So that should be fine then. So let's just sort of do a recap of some of the things that I started to outline and Chris and a couple of others and I'll just sort of read them off and then we can discuss. So I'll read off a few just to start with. The first point that I noted was diversity of contribution of project must demonstrate that it has cultivated a broad set of contributors from multiple members and or non-members. So I think that diversity is probably one of the most important factors. We don't want to have, I think, I may be alone in this but I think we probably want to make sure that whatever we're doing it's the membership that's involved and not just one. Maybe be a little bit more clear. I'm hoping for diversity at a couple of different levels. It isn't just necessarily contributions but companies that are using it or servicing it at various levels of the architecture. So you're saying that it's not just contribution, it's also usage. Well we don't want to be in a situation where the only party who can actually deploy it is one party because there's some critical aspect of it that only one party can serve that. That's a slightly different... Yeah that's a different dimension though. So you're talking that it needs to be something that anybody can use. Is that what you're saying or deploy? I'm not sure that anybody is necessarily needs to be that high level but if somebody at DAH can deploy a fabric and somebody at IBM can deploy fabric that's a pretty good example of some diversity even though a small vendor might not be able to because fabric may have some fairly high requirements at various points that they wouldn't necessarily have to. Maybe we'll be able to do that. I'm not saying it does. I'm just saying that at least there be some diversity of companies that can deploy solutions is another form of diversity. Okay. Actually I'm just going to type it into the Slack here as well. Thanks. I think that makes sense. The next point that I had was test coverage. I said a project needs to demonstrate some threshold of test coverage to be considered mature. Again, I think then Chris, you had a comment. Some parts are more important than others. It's probably more important that you have real solid coverage around some of the crypto stuff and I think I agree with that. Of course it's not a... The question of how much test coverage do I need can always be answered by more. I think there needs to be some sort of a yard stick that we hold up. It probably needs a minimum again because I don't think... I think it's important that we understand when we talk about exit criteria from incubation into mature that that doesn't mean that it's done. It just means that it's not incubating anymore. It means that we think we have something that we can actually be proud of and ship and that people could go off and deploy and use in anger as they say. That doesn't mean that at its end it means it's really at its beginning because then you're going to add more tests, more function, more features and so forth. I don't know what people think in terms of what's a reasonable threshold of test coverage that needs to be 80% or something lower, something higher. It's so hard to say because it's so different at different levels. The security things, you want to be in the upper 90s whereas business logic... I think the typical error rates are in five lines per 1,000 in this industry. Ethereum has got errors in 15 or 20 per 1,000. I'm sorry, Ethereum's scripts have a much higher error rate. It all depends. Any other thoughts? Hey Chris, just a quick question. This is Mick. When I open up the Slack channel it says that there's a bunch of older messages that have been dropped because we are at our 10,000 message limit. That would be really bad because there's a bunch of other stuff on the other channels that we want archived. I see the beginning of the channel because I created it and I did the April 14th. Do you have back to April 14th? No, and the message I get is your team has more than 10,000 messages in the archive. So although there are older messages that are shown, you can't see them. Find out more about upgrading your team. Where is that? I'm opening the Slack channel. Which channel? Exit criteria. I saw that in another channel. I don't remember which one like yesterday and was wondering why we weren't upgraded to the highest level of the non-profit Slack choices. Strange. I see all of them. At least in all of it too, so I'm copying it. This is as much a question about Slack as it is about history. Slack is, we're getting it for free. I think, who was I chatting with? Was it Philip? This is Brian. I think there's a conversation we had about our mode of communication and collaboration and that's a conversation I'd like to lead on the technical discuss mailing list that actually got a draft of an email already that just talks about our use of Slack, email and conference calls. Didn't want to bring it up on this call because it's a longer conversation and I actually wanted to use email to have this discussion as a way to validate that mode. Part of it will be how we use Slack and that may influence decisions about do we decide to pay and go into that archive. I think there might even be a rationale is that no matter what we decide regarding our use of Slack, it's worth either having to pay or see if there's some exemption they may provide to us. I don't know if we qualify as a charitable nonprofit in their eyes but I'd have to ask, regardless of lots of other open source communities that had struggles with Slack, on for this reason, for reasons that it's not indexed by Google, that sort of thing. There's a longer conversation we had. Sorry to have not to provide clarity right now, but I think perhaps Todd and I can go off and research what it would take to remove that restriction while we have this conversation parallel. Thank you, Brian. Let me just see. Chris, thanks for copying that stuff back into it. Yeah, I'm almost done, I think. I just went to the exit criteria channel and I only see back going four or five days. Back to April 21st, April 20th before it says you can't just look any further. Your team has more than 10,000 messages, so although they're older messages and shunned with low, you can't see them, find more about upgrading your team. Right, we just went through that. I just copied everything, so it's all there today. I think. Thank you, sir. So, Nick, did you have something to add to the last discussion around readjusting? No, no, I was actually, I just had remembered that I had made some comments on the channel. I wasn't seeing them and I was just trying to make sure that I didn't put them someplace else. Oh. Yeah, my comments when we originally started the channel were on things like scalability and appropriateness requirements and things like that. Oh. You copied some of them in there. Everything from C-Mickey B. Oh, sorry. This is Jeremy Sever, I had a question. Given that running code wins, is there a risk in setting thresholds too high that something else out there works and thus this effort is, or some particular incubation effort is lost? I think, here's my, I mean, so I'm in this, you know, middle between kind of agile worlds and crypto worlds. And I think, you know, the programming practices of this, you know, the security world and in particular with crypto is very, you know, is very difficult to do in an agile fashion. That being said, there's some real value to agile for different aspects of things. So when it comes to some of the business logic and things of that nature, I don't know that we need to have, I mean, I think we can do better than Ethereum. Somebody just did a review of, you know, like the top 50, I don't remember the exact number, but you know, a number of Ethereum smart contracts and was finding on the order of 15 serious errors per thousand and then, you know, quoted, and I'm not an expert on this one around five, but whereas, you know, crypto work is at, you know, we're at like 99.5 with proofs with some of our codes. So clearly, different places, different levels. Right, but the contracts, you know, for instance, for chain code or whatever, those except for any samples are, it's not really part of what we're doing here, right? So obviously, I agree with that. I mean, like, you know, it's, I'm not sure that, you know, the, I'm fairly confident, for instance, that a lot of the identity stuff has to be strong. So, you know, we need to have, you know, IBM's proposing a new cryptographic technique. It's not radically new. It's not like a whole new crypto system or everything, but they're creating derivative keys in a new form and using them, you know, that hasn't been published yet. We need to, you know, to get some cryptographic review of that. You know, a few things like that we absolutely have to do, but I'm, I don't know that, you know, we have to have it all the way to the, that every layer of it needs to be to that extreme. It would be nice, but, you know, I do believe there are some specific spots we need to be very careful with. Okay. Hey Chris, this is Morali from DDCC. Hey, first, you know, we are new to this exit criteria discussion. Is there a document or some bullet points? I mean, we seem to be jumping, but is there a, is there a document that we can... There's no document, Morali. Just what we had been previously discussing in chat and in Slack, rather, and I've pasted it, the exit criteria. I've pasted all of the previous chat into today. So I'll just send a link into the Slack discussion for today. Yeah. I mean, if you go in the Slack, we can't see any history there, right? No, just because of that, Morali, it's... I just pasted everything today. You have to be able to see today. Okay, okay. Is it? Okay. Sorry about that, Chris. Okay. So let's, let's move on. So full reviews of security and cryptography was... Chris, I think that was your poll. I think we've pretty much beaten that horse to death. I think everybody agrees. You also had the comment, Christopher, of some form of real-world pilot. You want to elaborate on that a little bit? Sure. So I think there's a big difference between a proof of concept, you know, with play money and, you know, small scaling or whatever, versus some kind of pilot where, you know, there are real people using it that are, you know, outside your company or it's being used for some, you know, small purpose. So, you know, I, you know, and there's ranges in there. I mean, I think, I mean, I like what I heard from Interledger about, you know, they did this game prototype with the Interledger thing and all the lessons that they learned from, you know, having 3,000 people use it was valuable. But I consider that to be still a proof of concept. You know, that particular game is over them, the quasi-tokens that they exchanged and traded, you know, had no value nor, you know, real thing. Whereas, you know, a small supply chain or, you know, something that is real in some fashion is, I would like to see as a criteria for mature, which is why I had been suggesting there needed to be something between mature and incubation to start off with. Mature is a pretty strong... Well, I guess it depends on... I'm sorry, mature or production grade, GA, I mean, I think, you know, again, you know, from my perspective, incubation should be about getting the project to a cadence of maturity, you know, where they're doing testing. It's not like they've just omitted that completely. The CI process is in place, you know, the release process is in place. I agree that there need to be gradations, but I think that's a form of release. We can have a beta release or we can have, you know, a 1.0 or a 3.0, you know, a 3.0 means, you know, we're really sure this time, you know. But... I understand. I think you're reading into incubation a lot more than that really needs to be there or should be there. The signal of mature, though, is that somebody who maybe has a little bit less knowledge can begin to, you know, do a contract with somebody. And, you know, right? Isn't that, you know, isn't that in a statement that we've said, oh, it's mature enough that you can rely on it in some fashion? So we should... I think we're talking about... I think, Christopher, I think we're talking about different things. Because when I think of incubation and maturity, we're thinking more along the lines of, you know, Dewey, you know, have we agreed that this thing is something that we're going to continue to support and nurture and so forth? And from my perspective, nobody's going to go and use an incubating project in anger. You know, because they're going to say, well, it's still incubating. Right? I mean, what... And I'm going to let the technical steering committee and the board make some decisions about that aspect. So... I've said my piece. This is Mike Dolan. Normally our projects at the Foundation, when I think maybe the difference in what you're both saying is the anchor point in terms of what you're referencing to. Incubation and maturity usually references a project's participation or a module's use in a final release of the code base. Not in terms of maturity or use in production environments, many of which we may not even know about. Putting incubation on a module is like calling it beta. And nobody's going to deploy that anyways. But when you're talking about it in an open-source project in terms of graduation, it usually has this project or this module proven, capable of participating in releases. Does it have people watching for bug fixes and maintaining security patches and continuing active development of it? Or normally the criteria you're looking at when you move from something that's being incubated into a mature state, you can look at the Apache incubator for other examples of how other open-source foundations do this. But the Apache incubator does not at all require implementations or proof of production use that's getting into a very difficult place for a project to go. I can buy that, but I'm hoping that anybody who has anything that does at least what Sawtooth did, I don't know if Mix here, they learned a lot from a 3-month, 3,000-some-odd people, right, Mick? It wasn't that big. But we've had real deployments that are put out there which has been incredibly useful and sort of tickling out the... I'll say we come at this from kind of an academic that the real problems are consensus and chain code, they tend to not be the real problems. The real problems are, you know, does your code fit into whatever regulatory environment it's operating in? And just one observation on that. For systems like this that are related, that are very closely related to multi-organization deployment, whether or not there's a real application, I would suggest that it would be extremely useful to have something like running systems that we can all poke at. Would it be possible to incorporate into this process some notion of having test ledgers perpetually available that are running some particular branch out of the repository at some point in time? And that also becomes a less rigorous demonstration of maturity, but it does demonstrate a completeness and maturity. Yeah, but all open source projects go through a refinement period after there is a release, people do start to put it in production, people learn things about it, and that's why you want a project that moves from incubation to mature should have people already willing, able to work on that feedback from people who are putting into production. I don't think we're disagreeing with you. Yeah, okay. My question, Mike, is that this is not... these ledgers are not things that we can treat like a library or a separate service package, because one of their characteristics is one of the unique characteristics of this domain is that it's a cross-autonomous organization service. And so it does have some unique requirements that we have to consider. We can incubate DNS bind and understand how that operates as a package, but understanding how it operates in the entire DNS system is critical to really understanding how it works. So I think I agree with you, you know, if we're talking about something like an Apache server, it's a single stand-up entity that a single organization can run that way. These ledgers aren't, right? I mean, they go beyond that to multi-organization characteristics. And I feel like we're not addressed... And by the way, there's a big question mark at the end of this, which is how do we do this? I'm not specifically proposing an idea. I'm just throwing ideas out. I have worked on other projects that were federated services like this, and we had a continuously running open-source projects that had continuously running testbeds as a means of verifying cross-organization consistency. Yeah, and that's how our other projects who have a federated dependency model, that's how they do it. They do a testbed where they can just continuously running testing since it's the code base. So I was just suggesting that one level of one characteristic might be that it must work in whatever that sort of testbed criteria are, however we define that. And that is a common exit criteria. Yeah, that makes perfect sense. It's not a full-blown production system, but we do have some sort of minimal liveness that tests the cross-organization characteristics. Okay, maybe I misunderstood some of the comments earlier about the intention there in terms of... But that is very common. This is Jeremy Severed. I was going to suggest that others, because of the nature of the kinds of transactions they want to put on these blockchains, may need to know whether or not it's transaction-ready. So it may be valuable to say, has this been audited? Has this been blessed by the security crypto community? Has this been used and approved by a regulator if that's known? Just so there's at least enough disclaimers there that somebody doesn't go and say, oh, I thought this was ready for this. Hey, Chris, this is Morali. I think documentation-wise, I didn't see a mention of documentation. I think there should be sufficient documentation for anybody trying to apply or test any of these incubation projects or it should have enough documentation, which illustrates the test cases, which demonstrate from deployment to the testing of the various use cases. Okay. Thanks. Other thoughts? Just a process question on this. Are we going to capture all of these into a separate way of paper? Is that the antenna, Chris? Yeah, I'll use the notes that I'm taking in Slack as well as whatever Todd has recorded and I'll listen to the recording again and I'll put all of that into some sort of a Google Doc or something that we can bang on. And again, this might be a question from Mike and Todd. My understanding when, Chris, when you were describing your characteristics of maturity, it's maturity within the context of the hyperledger organization as opposed to code maturity relative to production quality. Did I understand you correctly? Yes. There were two things that weren't discussed that I find interesting. One of which there was no requirement that a mature release have any kind of pluggable architecture or support multiple consensus algorithms or multiple identity systems or whatever. I also didn't hear anything about that hyperledger would only have one code base and that future, you know, future nations moved into maturity had to reconcile with existing ones that were already in maturity. Are both those statements true or explicitly they're not part of the maturity criteria? So I would look at that as more of a function of, you know, you're talking specifically about an implementation set of capabilities. And it's not clear to me that that's, again, as, you know, Mick, I think, clearly teased out. You know, what I was referring to in talking about this is from a hyperledger perspective, is the project mature in terms of its, in terms of, you know, sorry, Mick, I'm, you know, is the project mature process perspective along the dimension of the project? Yes, that was the differentiation I was making. Thank you. So I just want to make sure we are kind of saying that, you know, whether or not, say, whether or not fabric is pluggable or not is not something we're really concerned about for it to get to mature and we're not really concerned about, say, Intel, let's say fabric goes mature first, that we also don't have a requirement that, you know, Intel also now has to, you know, be compatible with fabric in order for it to go mature. So those, in a sense, we're not holding either of those as gates. No, and again, you know, as I've said a number of times, I'm very keen on trying to figure out how we collectively as a community can, you know, get from a place where we are necessarily battling over one versus the other and think about this more as a whole. I mean, that's why I want a pluggable architecture, but that seems to be not where we're ready to talk about it. But I think, again, this is less of a, this is a less, you know, I think, again, when we talk about incubation, as Mike said, as Mick has, you know, sort of called out, this is much more of a function of are we behaving in the way that we hope from the rest of the project's perspective that, you know, we, you know, that we have a diversity of contributors that were writing test cases, that were writing documentation that, you know, we've got a release process in place and it's consistent with what the others are and so forth. I think that, you know, it'll take some time for us to do things like align on APIs and SPIs and so forth. That would be, you know, for me, that would be a wonderful thing if we could do that. If we are to have multiple implementations, you know, or, you know, if we're going to try and get to one and we can have pluggable componentry, that would also be fine. I mean, but I'm not trying to say. I'm expressly not trying to say, you know, but you need to figure out how we're going to achieve that. I think that's really what this discussion is about. I know we're coming up short on time and maybe this is another conversation to continue on the list, but I think this could be right for revisiting just because there may be a confusion between and acceptably so and beyond the people on this call on, you know, the maturity model we're going for here, you know, and what incubation means, both from a community perspective and from a code perspective, because I think there is a very useful function to being able to telegraph to the outside world when we think code is ready for production, when we think, you know, here's a set of APIs that are stable that you can build against or here's a protocol that, you know, you can depend, reliably depend on not messing up your federated network with. So I think we should also be focused on the long term, which is in the long term, there's a collection of projects underneath the Hyperledger banner at different stages of recommendation for production use. But ultimately, things that might start out as contributions from one vendor or contributions from one source. I know Ethereum is interested in talking about their C++ client as well. You know, rather than the thinking of these as contributions that they're like a collection of objects they are, they are instead, they are the seed for something that becomes a Hyperledger identity kind of product. And what do we want to put a 1.0 on? What do we want to label production quality and recommend it, right? I think these are larger conversations than we're likely to arrive at in the negative one minute that we have remaining. And so, but we could pun for the next call or have publicly, but I think we should be open to revisiting. We are at the top of the hour, but we do actually do have a half an hour of discussion, but I think, you know, maybe that we all have to sort of go back and think about this a little bit in light of the conversations we've been having and maybe, you know, having something actually written down would maybe give people a little bit more to chew on and to respond to. So, I'll take an action to, you know, once the minutes are published to synthesize that I'll read, I'll listen again to the discussion and see if anything was missed, but I'll try and pull together a Google Doc that starts to put something together that we can then all start working from. Unless there's any other issues, I guess we can get people some time back. I can check out in my hotel. Bill, if you've got notes from the discussion, that would be wonderful. You can send them to the Hyperledger TSC list. Alice, if you go to the hyperledger.org slash, what is it, community I think it is, all the link to the mailing list archives and so forth is there as well as to Slack and others. Well, thanks everyone and thanks, Brian, and congrats on the new role and look forward to working with you more. And we'll see you all next time. Thanks Chris, thanks everyone. Thanks a lot. Thanks Chris.