 Okie-dokie. Thank you. Welcome everybody. Where's my window? There it is. Okay, so on tap for today action items and workgroup updates and a lot of discussion about the action items. So first up would be the hackfest preparation and updates on the upcoming hackfests. And then we got Bill's proposal on the maturity of the software. I think Bill and Jeremy were going to go off and take a look at some of that. And then we have exit criteria so I know we're going to hopefully finish that up along with the update you've made to the project lifecycle for the naming taxonomy if you will. And then Brian did, it says zero dot one. Is this the one you sent before? Actually I should have looked at this last night. I think it's been updated to zero dot two. The link is accurate. I think it's just, yeah. Except that. Yeah, we'll get to it. And then we'll review Todd, the contributors that we've collected thus far and people can take a look at those. And I think what we should entertain at this point in time is we should probably discuss how we pull the list together and then get feedback from the DC as to whether or not they think we might have missed anything. And then there's a Hyperledger Explorer proposal out there but I haven't gotten feedback from Dan in part or so. I think we'll table that until the face-to-face maybe. And then we'll have the workgroup updates unless there's anything else anybody would like to bring forward. Chris, I just heard from Dan. He's interested in the Explorer. He said something about the scheduling being still a couple of weeks out. Yeah, I think I have the same problem in terms of actually getting the software out there. In terms of the proposal, maybe we could have it so that next week we could at least start finalizing it anyway. Okay, thanks. Thanks, Mike. I just came back from vacation so I'll start taking a look at the document you gave me. Oh, I was wondering why I didn't hear back from you. That's perfectly fine. So anyway, it's out there and we'll get to it quickly. All right, so Todd, Hackfest prep and the document. All right. So first quickly on the dates, the San Francisco Hackfest is next week. As everyone knows, if you haven't registered, please do so ASAP. The August Hackfest has been confirmed. It will be virtual August 24th and 25th. And the European Hackfest in fall, we are tentatively looking at October 3rd and 4th, which is a Monday and Tuesday following Cybos. It would be in Amsterdam. We will be firming that up likely today or at least in the next couple of days to have a final date for the TSC next week. In terms of the Hackfest for next week, we threw a couple topics into a draft agenda just from the discussion last week. I'm hoping that into the chat window right now. It's also in the agenda that went out. So if there are other topics that you'd like to see get slotted in or specific conversations or work groups happen at different times over those two days, either put a comment in the doc, send me a note so we can get those different components slotted in. And if there's any suggestions at this point of things people would like to see get added, please raise that at this point. This is Brian. We will have Rai Jones from the likes Foundation on-site. He's been talking with Chris and others about the transition to Garrett as well as to Jira. And I can walk through what the implications of that are and perhaps even do some training around that. But we'll have them there for both days so we should make the most of that. Awesome. Anything? Hey Todd, this is Hart. We've discussed possibly starting to put together a GitHub repository for some of the documentation stuff. And some people and I were looking at starting to set that up next week if that's all right. Excellent. We'll get that slotted in as an agenda item. And if there's a specific timeframe you'd like for that to happen there, let us know. Otherwise, we'll just run that non-conference format and pull a group together. And so Hart, just to make sure I understand, this is for sort of top level hyperledger non-specific to any given project documentation? Yeah, so like yesterday in the architecture workgroup we discussed starting to put together some of the architecture documentation. You know, I know the white paper working group is not quite ready to move to sort of a formal latech white paper, but we've discussed possibly doing that in the future and sort of having the infrastructure ready to do that when we potentially want to do that would be nice. Ah, okay. All right. Fair enough. Just want to make sure I understand. Thanks. This is Jeremy. I would second the need for that. As someone, for example, who has read-only access to the repositories, that means I can edit the wikis, but I can't actually upload any files. And so it would definitely be a help to be able to have some place to put things like that. Another topic, this is Brian, that I'd like to see added is I would like to see the two major projects and, I mean, explore if it's ready. But at least fabric and software like start to talk about with the rest of the developers. What the path is to a one-dotto, you know, using our guides, the documents we're coming up with now, but trying to get a sense for just what is the next, you know, what are the next couple of quarters look like and what stands between us and some sort of minimally viable release that we're happy to hang our hat on. I know there's a lot of variables at play, but those of us who talk a lot to the world about the state of things would love a guide to appropriately that expectations do. And it'd be great as a project just to have some targets, you know, and measure our progress against them. Any other topics before we move on? All right, sounds good. Chris, I think we can move on to the maturity of software discussion at this point. Yeah, so let's actually do this in reverse order just so we can get the exit criteria out of the way. So Arno, can you start and sort of catch us up on where we left off last week with the exit criteria, the updates you made, and hopefully we can get these approved? Yes, hi. So, well, I mean, the document itself hasn't changed much. The main change has been to rename mature state to active. And so I made that change to the project lifecycle document as well. I think everything is square. I moved out the material like background material and the material that Jeremy and Bill had contributed that I moved to a different document. So when it comes to the incubation exit criteria document, I think it's pretty much done. There is only, you know, I think one thing that was left is the towards the kind of, you know, more precise exit criteria that projects might want to set for themselves at the onset of the project. I had some examples and none of them are complete if anybody wants to suggest any, but these are just examples anyway. So it doesn't matter. I think for the crux of the document, I believe we are done. So I think it just needs to be approved and we can, you know, finalize it. So hold on. And of course, like we did for our other document, like the project lifecycle document, we just updated. We can always update that document, right? It's not cast in stone. If there are, you know, if anybody has any other suggestions, we just have to, you know, get an agreement on how to modify the document moving forward. But we can always update it and improve on it. Right. So let me just paste this in. So there's the link in the chat. So why don't we just sort of go around the room and take a roll to approve this. All right. So Chris, you want me to do a roll call vote? Yeah. All right. So to approve this. So running through the TSC members stand from CME group. Yes. All right. Yeah. All right. Hart. Yep. Chris. Yes, please. Mick. Yeah. Dave. Dave, you may be on mute. Sorry. Yes. All right. Great. Richard. I'm not so sure what I'm being asked to approve. Is it the project incubation exit criteria dog or is it something else? Yes, that is correct. Okay. So I'm happy with it from the sense that the conversations I've had, but I've not read it. And the one I'm looking at are the top two and big letters. This is a draft. So what am I actually approving here? This is the final version or this is on the right track. What's the actual question? This is the final until we commend this. Yeah. The whole point is to remove the draft. Right. Okay. Got you. Okay. So just for the sake of good order, because I've not read this much recent version, I'm going to abstain. Not because I disagree, but because in good conscience, I can't vote for something I've not read. So I don't object, but I haven't read it. So it's not safe. Sorry about that. All right. Thank you. Ajit. I love to abstain as well. So I think to read it before I can vote. Okay. And then finally, Andreas in for Stefan. Yes. All right. So with that, we have seven yes and two abstain. So that passes. Okay. Thanks. And then Arno, I think the other change was just to change, mature to active in the life cycle document. Is that correct? That's right. Then I looked around for any other references I couldn't find any. And I have to say, I didn't find it very easy to search our website, but that's a different topic altogether. I was trying to, you know, do a massive search throughout the whole hyperledger website for references to mature. And I couldn't really do that. There's like the GitHub search, it only searches the code pod, but not the wiki. And the wiki doesn't really have a search. I was like, hmm, not the best. So I don't know. But again, that's a different topic. The document, the important thing is the life cycle document itself has been updated. And this document now refers to the right name. So I guess we should probably approve this one too, just to get everybody on board. I don't know if you need to do that. There was an approval last week to change the name from mature to active. The document reflects the decision. That's right. So this is just making that real. Okay. Fair enough. So unless anybody has an objection, I think we should just move on. All right. Sounds good. Okay. Now we take on Bill and Jeremy. And I think I saw an updated proposal, although I haven't had a chance to dive into it. So I hope they're both on. Chris, if I may just one more thing on the executor document. I'll do like I did for the other documents like the project life cycle, where this is in Google Doc now. So I'll move that content to the Wiki. Okay. Thanks. So Jeremy or Bill, one of you guys want to... Here we go. Yeah, this has been Jeremy Severide. Per the discussion over the last couple of weeks, Bill Sparks and I had some offline conversations about some of what we've discussed around incubation and the software maturity. And we don't exactly land, I think, in either one of those. But where we did land was somewhere around risk management for the use of the software. And so we want to just briefly talk about that. So this is really sort of farther out there than a release 1.0 and the like. But it's about if the hyper-electro project succeeds, and the platform's used in production, what could go wrong? This is a good problem to have. This is something farther out. So for that reason, this may be something we want to table to a later time. But these are some of the examples of some of the things that have happened that conceivably could happen if someone's using the hyper-electro platform. So for example, smart contracts could get hacked. There could be an undetected disk failure. These are all just coming in. These, for examples, things like fraudulent payments being issued. These things have happened according to news reports recently. And these are things that could have some serious effect. And granted that there is an Apache disclaimer and limitation of liability, it's a question of whether or not this is something we should address at all. But that's the direction we're going in. What do we do about something like this? And some of it can even be for things that seem innocuous. So for example, Bill, do you want to talk about the example where the archives aren't destroyed on time? Yeah, can everybody hear me okay? Yeah, for example, one of the things we talked about was our application potentially was record retention. So in here you can see archives are not destroyed on time. It was discovered doing a routine audit. But that could go from bad to worse in a hurry in the event of some sort of a security breach and documents with personally identifiable information are compromised that shouldn't be there in the first place because they should have already been purged. So that exacerbates the problem. When you actually, if you want to take that to the asset size of a bank, for example, in addition to your promontory regulator being the FDIC or OCC, if the bank net assets are worth more than $10 billion, you could potentially have the Consumer Financial Protection Bureau added on at that point. So I think that's the kind of things we're looking at. He's going to get to it a little bit later. But identifying risk in some of these intended application usages that the maintainers and folks introduce into the hyperledger for incubation. So one of the standard ways to deal with this is to start doing things like risk assessment workshops or worksheets where you list out the risks, think about how often these things are likely to happen, think about how would you control for these, and then what's left over when you do that. And so as part of the exercises that we're going through is like the requirements working group and elsewhere, when we think about things like the illities about what do you have to do to make this thing robust, resilient, an approach like this could blend very well with that in terms of helping to understand not just what the edge case scenarios are, but what are the controls that people might need to put in place because in some cases those are things that could be in software, can be for example part of what the code, the configuration does, and some of those may be outside of the control of what the software can do. And in some cases, for example, with the smart contract hacking, the fact that they had to go to do a hard fork of the whole public chain is a fairly drastic step. And so it's something to just keep in mind that different challenges, different controls, but this stuff is already happening. And so it's something that we at least probably want to think about encouraging projects at least to think about, even if we decide to table something like this. And Bill, you want to talk about where folks are using this kind of analysis framework? Well, this particular risk assessment worksheet came, this is a Defense Department form that all branches of the military use and we've just kind of adapted it and there's many, many others out there, but they're all closely linked. But I think the point that Jeremy was trying to make, and I now agree with him, is that for each proposal for incubation, there should be a set of risks associated with, that we can basically put forth in a canned scenario. In other words, if you're doing a medical retentions, or medical records retention type of incubation, there should be risks associated with that that are somewhat off the shelf that you can pull in and do a lot of the work ahead of time. And then, of course, when you get to your mitigation control measures, mitigation and control measures, you can at that point assess what your residual risks are and go from there. And whether you agree or disagree with some of the FIPS 199 categories, that's something for the working group to put forth. But I do think that a lot of these risks can be identified ahead of time so that when something's pulled into incubation, there's almost like a database, if you will, of risks that they can pull from. And of course, they can add their own as they identify them in the development process. And of course, one of the things that we've already been doing in the discussions, whether it's in the architectural working group, identity working group protocol, we've started talking about features of the system that in effect are tied to SLAs and tied to risks that we know are out there. And so this, rather than sort of putting the cart before the horse, the saying, okay, let's at least list out some of the risks, categorize them, and then try and be explicit about tying them out to the requirements. So for example, we know that disc failures happen. We know that system availability is an issue. We know that some level of fault tolerance or resilience, some various mechanisms to cope with this are going to be necessary within the platform, which may be over and above the consensus mechanism. But this is just sort of trying to tie a lot of what we've talked about. And I think part of the challenge in the incubation discussion and the reason why it crossed over into the sort of software maturity was there are things that people know from past experience that we're going to have to deal with, whether it's performance, throughput, and the rest, that we need to get into some framework so that we at least know whether we're identifying it or we've chosen not to work on it. And part of the reason for this and part of the question about this is this originally came up in the identity working group where we had a discussion about concerns about people taking the hyperledger code once it's ready and doing something with it that goes awry and then that blowing back onto the whole effort and the whole project. So currently, as we understand it, something like the Apache 2.0 disclaimer warranty and limitation of liability is going to be in there. But the question is, is that sufficient? Now, maybe it is, but another way to tackle that would be to work through a risk approach like this, not to say that we're going to make a judgment about the risks, but to tell folks who are going to use this, not just we disclaim all warranty and limitation of liability and we made a reasonable effort to have the software perform the tasks and that there's a community behind it, but that if they're going to use this for the kinds of things we think they might, they really ought to do a risk assessment and hey, here's a bunch of risks that we think are maybe applicable. Here's a way to think about them and here I want to go fill something out. So at the very least, when somebody downloads this, there'll be something there that we can say, not only did we warn you that something might happen, we gave you a way to even think about it. So that's sort of the direction we thought might be interesting to go in, recognizing that this may be something that we want to table for a later point where we've got code up and running and out there, but we think in part given some of the nature of where we think this might get used and some of the high profile problems that have already surfaced, that this is at least something we ought to think about. Final slide is just a series of references and citations to some of the work that we've talked about in this forum and others as well as some of the places where we've pulled and assembled some of this from. And again, these are just examples and this may certainly be something we want to table for another time and some of the times totally understandable. Let me add on that, when you're looking at the references and citations, one that was just in the news this past week is the very last one on the list, which is the bottom right. This was a Citigroup thing that was, this was a program they've been running for about 15 years and some of you guys may be familiar with this, but what happened was there was a software code error that caused the problem and when Citigroup found out that it was in existence, it was not disclosed. So I think that's what got them in hot water, but they did end up paying a seven million dollar fine on this thing and so I think that it would be worthwhile to go to that link and read, it's a very short article, but read about it and that's the kind of thing exactly like we're talking about. We need to understand what the risks are. At least let people know, provide some references where they look for it. It's not all risk included, but just the ones that we can easily identify going into virtually any project and then as I say, as they develop and the thing becomes more complex, if the maintainers choose to do so, then they'll have to add some additional risk in there. I appreciate everybody's time on this and we put forth a good bit of effort in it and thank Jeremy very much for all his work. Thank you, Bill. Thank you both for this. I think this is very good. I think there's a couple of aspects to this I think that it's probably worth following on. The first would be we should probably explore so what does the Linux kernel do for this? I think there's probably similar types of liability and risk and so forth involved and so it would be interesting to sort of explore if there's anything that we can learn from that project. Then there's the, I mean, I think then there's just a couple of other things. Then is the, and I'm going to get it, is it core infrastructure? I apologize guys, but I can't keep track of every name. Is it the core infrastructure project? You mean Chris, you mean the core infrastructure initiative, the TII? Initiative, thank you. Yes. And so I think we've already sort of, we've talked about, we haven't think we've done an actual engagement with those guys and got a briefing and so forth, but I think that there's probably a good deal that we can learn and benefit from with, from that. And then just when we do actually get to the point of actually starting to put out releases that people are starting to use in anger, we will have to put in, and to this, I think to maybe the city point at the end, some sort of a vulnerability process in place so that people can report privately vulnerabilities, they can be explored and remediated or not, as the case might be. And then announced, obviously carefully, because we don't want to be in a position where we're not saying these things, but we probably do want to have a situation such that people that are delivering software offerings that are based on the Hyperledger project outputs that there's a vehicle to let them know first so that they can apply the remediation in their offerings before we actually tell the rest of the world so there's no zero-day exploits. So I think all those things, I think we need to sort of follow up on, but I think this is a good summary of the kinds of things we need to be aware of. As you grew that, Richard Brown here, just a couple of other thoughts. I thought that was really helpful, especially the links on the last page. A couple of reflections from some of the work we're doing with our members. One of the thought processes we've gone through and I think is relevant here as well is to ask ourselves what is different about this space. So there are similarities and I take Chris's point about the Linux kernel and elsewhere, but there's also some interesting thoughts that arise when you're asking what is different or what is special about blockchain. And one that stands out for me that I think has two implications for this space. One of the things that's different is that this is about building shared agreements, coming to shared consensus between mutually distrusting parties and in different legal entities. So it doesn't make sense to think about the deployment of the software by one firm leaving aside internal deployments. So we're necessarily in the world where multiple organizations and multiple people are agreeing to deploy an application or a solution running on top of the software at once. So immediately you're in the domain or you're immediately in the legal domain, what agreements have to be in place between those people. Essentially you're building a service whether you choose to look at it that way or not. So what are the agreements, whether they're master agreements or whether they need to be there. And then to what extent is the code expected to dominate or to what extent should its power to the extent it has any be delegated to it from a variety of legal agreements which then provides a place to put things like dispute resolution and escape clauses in so that we have a path not only to mitigate the risks or reduce the risks of technical problems, but there's a path for how we resolve them even when they inevitably occur. And then the final thing on maturity, one of the things we think it's important to think about is how the literature is used. So for any given use case, it seems unreasonable to assume it would be fully automated and fully authoritative for the facts on it on day one. Perhaps it would be a shadow or a data propagation let until we're more confident with it. So there's the maturity of the software but there's also the maturity of the uses for which it's put. So I thought that was it. So long story short, I thought that was a useful paper you took us through. Thank you. Hi, this is Ram Jagadeesan here. So this topic of security and risk came up in the architecture world group as well and wanted to bring it up here because we were trying to figure out whether some of these we should take on in the group or not within the architecture world group or not. And so I think our initial thinking was security functions like identity services, policy services would certainly need to address an architecture world group. But there's the second topic of what are the security reviews that need to happen on the Hyperledger implementations and that broke down into two levels. One was security review, security review by the security research community as well as the code audit for security purposes. So both of these I think need to be kind of addressed head on. Now which forum that needs to happen was something that I wanted to bring up here so we can have a discussion and figure out what is the appropriate way to deal with the security review for our implementation. As pointed out, these are very valid risks and given the importance of security in the application domains we are trying to address, I think it's very important for us to have a plan of how to go about doing that. Thanks, Ram. Anyone else? Yeah, so just for my own sake I think, you know, Ram I think it's probably worthwhile to sort of take on some aspects of those. I think the security review, we should probably also talk with Christopher, Alan and his team because I think that group is likely to have a lot of the expertise we're looking for. Yeah, I think Christopher, Alan was the one who brought up the topic in the architecture world group. Okay, there we go. Fair enough. Okay, all right, so Todd what was next? I'm trying to go from memory and I don't have the agenda in front of me. All right, the next thing up is the release taxonomy. Yeah, and for that last week what we talked about was that the semantic versioning standard was something that I felt at least captured better. I don't know what we could be doing then, but my attempt at least to try to restate it poorly. So I think what we were going to do is ask that people take a look at mver.org, I think it is, and come back here and see if that's something that we want to adopt. Maybe that wasn't as clear as an action item as it could have been. I don't know if anyone's had a chance to look at mver.org. I have certainly, I thought I had sent or written something up. I was essentially writing up a proposal that sort of took some and then mapped it to your taxonomy, Brian, in terms of the alpha, beta and so forth. I think that there's still a need to have some sort of tag indicating how ripe something is besides just a number. And so I think that having a taxonomy like that is important. So compliment. That's good. Semver itself. Yeah. Yeah, so there are expectations for alpha, beta means that sort of thing. Good point. Yeah, right. So it provides for there to be a sort of an appended alphanumeric kind of thing. You can do that with things like release candidate numbering and so forth when you're iterating through and finalizing something. And I thought I sent something, but I apologize. Or we could simply turn this existing taxonomy document around and say the version numbering is as defined by semver.org, but the textual descriptions for what each stage represents so hold. And I could create a version 0.3 that did that. I think that would be useful. Maybe we can review that at the face to face. Yeah, I did send out something in the email. Although it wasn't a formal, and I think I could make it a lot more formal. Okay, why don't I take it then as an action item to just make that a small set of mods there and then we can talk about this quickly at a review this at the face to face of the hack site. That sounds good. Okay, I'll do that. Thank you. All right, so next up is the preparing for the six months elections for the technical steering. And so one of the aspects that's in our charter, you know, six months get to know your period for the TSC during that period of time. The TSC members are appointed by the premier sponsors. But the following that there would be an expectation that we would have over that six months gotten to know each other a little bit and figured out who the community, those who contributed in some way, feel that they would like to see on the technical steering committee. And so in order to do that we have to assess so who's made a contribution? Who are the contributors to the Hyperledger project generally? And so we did what we did called the GitHub committers. So all the people that are listed as committers in the various projects are, they get a chip, if you will, they get a vote. And so we've got a list of those individuals by email. I think we may have to figure out who's who through that process. But anyway, we have those emails. I asked Todd to ask the chairs of the various working groups who's, you know, an active contributor to their efforts. For a couple of those groups it was pretty obvious because they had a list of the contributors where, so we actually, we took those lists. So that's the requirements and the white paper working group. And then we asked Ram and Christopher and Oleg to provide us with the people that had been active and helpful in contributing towards the requirements. And so we came up with this list. I think, Todd, do you want to paste that in there? Is that what you just pasted? No, that was the other. You just did not. So that's the spreadsheet with the list. I would encourage people to look through it. There seems to be some duplicated names. I think they're likely over. Yeah, so we'll go through and do some cleaning up of that, removing duplicates and also adding people's names next to the email just so there's a better view. We'll get that knocked out before the end of the week. And then continue to review this leading up to the August 11th election nomination phase at least. So if you are listed in here and we need an email, we're probably going to need an email from you. So like David and Frank and Ram and so forth, I think we need emails. And I can go through and do some manual work there and drop those in. We have some of them, it just hasn't happened yet. Alright, I wasn't sure about that. And then, well, anyway, so that's how we pulled together. So what I guess we should be asking is of the members of the TSC, do we think we're missing anybody? Not individuals, but in terms of have we overlooked any obvious means of contribution? I don't know, maybe we've already got these people. I wonder, I'm guessing there were people out there who are actively building on either STL or Hyperledge of Fabric who aren't necessarily contributing to the build of either of them but are using it in anger. I don't know how we'd identify them if we haven't already or who they are. But I wonder if, basically, as users, they'd have a useful voice. And I wonder whether we'd count constructive usage as contribution and if so, whether they should be encouraged to apply as well. That's a question I don't know the answer to. Yeah, I think that's a fair point. In other groups that I've worked with, the end users do get a voice, but there's a process for figuring out who they were. For instance, OpenStack went through this and it was a little bit awkward initially, trying to avoid the awkwardness. But they just sort of said anybody who thinks that they're a quote unquote member of this community can sign up and be a member of the community as an individual. It didn't cost you anything. There's no requirement to have a contributor or anything. I mean, you could just be a user and that sort of adds you to the membership. And they use that for some initial elections. The problem with that, of course, is that we saw people signing up and there was a bit of ballot box stuffing going on, unfortunately. I'm not going to name names, but there was some of that going on. It was a little bit unfortunate. And then they changed things a little bit. And so then the elections for things like the analog to the technical steering that they have at OpenStack were then restricted to somebody had to have literally landed a patch to get a vote in a given year. And then there was pushback that said, well, but what about the users? And then they created some sort of an end user community, but it was you had to be contributing in some meaningful way. So I guess what I'm saying, Richard, is I think that that's right. I just don't know that at this point in time with the early stage of the software that we have a vehicle to actually find those people legitimately. No, that makes sense. No, I wasn't aware of the OpenStack problem. So, yeah, because you avoid the same thing. It is a little awkward. I agree, though, very much with the point that we should find a way of giving end users a voice. I think the question becomes, how do we give them a voice? And to what types of decisions would they be included in? Any other thoughts from anybody in terms of obvious groups or obvious means of contribution that we may have overlooked? I didn't mention most chairs are all magically added as well. They've done quite a bit. We also got all the contributions. I don't know if there have been any, but contributions to the Wiki that may have been separate from commits and workgroup participation. I have to look at that. I'm not sure that I can. That's a good point. And I'll explore whether or not that you can actually figure out who made the contributions. I mean, with GitHub pull requests and issues, it's fairly simple to sort of use the GitHub APIs and figure out who the contributors are. I'm not so sure about the Wiki. I could look to see if there's an API to use. I'll take an action to do that, Todd, though. That would be great. Then maybe we do have the list. So are you inviting people to, on this document, start to mark out potential duplicates? Or is this something Todd will take on? I think I'm just going to go through... Yeah, I'll take action for that. I think some of the identification of individuals may be obvious, but then there are some others that are going to be less obvious. And I think with the IBM emails, I can probably find a name to match to the email. Gmail accounts are going to be a little bit harder. I think that's it. Then I think what's next is workgroup updates, which we haven't done in a bit, so... There's one more action out there about the Hyperledger Explorer proposal. Oh, we discussed that. I said... I'm sorry. I thought we'd cabled it until next week. Because there is actually a proposal that I had written, but Parta was out on vacation and he hasn't reviewed it, and Dan is also not on the call and he was unable to review it yet. So we'll bring that forward next week. Okay, workgroups. Oleg, are you on? Maybe not. Okay, let's move on to Rahm. Yes. So from the architecture workgroup, I'm happy to report that we finished our first work item. The only pending thing is to finish the documentation for it, but we completed our first iteration on the functionality breakup between the consensus layer and the business logic layer and the interface between them. So we still need to finish up the documentation. We hope to get started on it on the face-to-face next week. And we started discussions. The next major agenda topic is the security functions. And as I mentioned, there's a still an outstanding item to figure out where the security reviews should be dealt with, so we're not sure whether we should take that on yet. I wanted to bring that up here to get the TSC's input on the security reviews. We are planning to have a fairly long session on the face-to-face. I think we have about six to eight hours so that we'd like to have on parallel with the hack fest. So we're putting together an agenda for that and we'll do a doodle poll to kind of figure out which slots would work. So that's about it from my side. And we'd love to get input on how we want to go forward with the security review. I'm sure the code review aspects should be handled somewhere else in terms of getting the academic research community both and the industry research community to look at our crypto framework and bet it from a security perspective. Is there a more appropriate group than the architecture group to take that on? Do you think we should take it on so forth? We'd love to get your input on that. Any questions for Ron? Okay, Dave. Hi, yes. So the white paper working group, so I think we're actually making some pretty good progress. Now we had a meeting yesterday and unfortunately we didn't have enough members for quorum, myself included, and I got called away at the last minute, but we've got quite a bit of changes made since the last draft and they're mostly sitting in, we're using Google Docs, we're going through making suggestions. So we want to just have a quorum to go through, but if you see our new glossary, thank you, Nick, has been applied and heart's really been kind of stepping up as I haven't been able to participate as much as I'd like to in the last couple. So there's quite a bit of new suggestions that have been reviewed, they all look good, a lot of grammatical improvements, and so I think we might be able to be publishing our next draft and in fact we might even want to call this first one a 1.0 since it seems to have, I believe we are in agreement that we've addressed most of the input, if not all the input suggestions in this new version. So hopefully next week we'll have a quorum, we'll be able to accept all the suggested edits that have been put in there and unless there's a major something missing holding back, I would expect that we would be able to have a new version ready for publishing. Dave, any questions for Dave? Somebody's on another conversation. I don't think they're muted. Okay, next up I think was, lost my place here. Christopher, are you on? No. And then finally that would be me, the CI, so I actually made some really good progress, we have Jenkins is basically up and running for x86, I think certainly for the fabric we may be able to transition off of Travis pretty soon. Jenkins seems to be pretty stable for x86. For the X390, I'm sorry, we have a little bit of cross-compiling issues and things that are being worked out, but I'm hopeful that we can get to the point where that's an integral part of our build and our notifications. Right now we're just sort of ignoring that particular branch in terms of merges. And I think there's ongoing work to integrate open power. Again, if there's interest in adding additional architectures to this, please get in touch with myself or Rai and we'll look to integrate other architectures into the platform for builds. We've got Jira and Garrett are both up and running and ready to rock. Rai is out this week, I didn't realize he was going on vacation hoping that we could maybe affect the transition from GitHub to Garrett for the fabric projects on Monday, but since he's out and not back in the office technically until Tuesday, it looks like we may be doing that early in the hackathon to actually affect the transition. But that's good because as Brian noted, Rai will be at the hackathon and so if we have to have any remedial hand holding for people that are unfamiliar with Garrett or Jira, we should be able to accommodate that. We did start to pull in all the issues from GitHub into Jira and we found that what it did was it also pulled in all the pull requests, which is kind of weird. I guess maybe I'm not surprised because pull requests and issues are actually treated very much the same in the GitHub API. You have to actually filter them by the type. So I think we have to take a look at that import script and figure out what needs to be changed there, but hopefully we should be able to have the, certainly for the fabric projects, we should be able to be up and running on Garrett and Jira, certainly I think by next week. Any other questions for me? If not, then I think we're at end of job. So let's say anybody's got anything else. Thank you very much everybody and hopefully we'll see a number of you at the face-to-face. Actually I hope to see all of you at the face-to-face. Thanks Chris. Thanks guys. Bye bye.