 Okay, so on the agenda today we have Action Item Review, we have, I guess Todd, you're going to do an update on the election? Yep. Yep. All right. And then we've got two proposals, one for the explorer. And either part or Dan or myself will present that. And then we have another proposal that I'd like to have Bawa introduce. We don't have to, we don't have to approve it because this is the first time we're all seeing it and there's haven't been a lot of opportunity for people to review it, but certainly we can let Bawa do the introduction and then we can pick it up again next week. And then we'll have work group updates unless there's anything else that we should cover. Okay. I think that's it. So Action Item Review, so updates on the hackathon, Todd, the preparations for the August and then the October? Yep. So a couple things for the August hackathon that'll be the 24th and 25th, that's about two weeks from right now. In the chat window I'm pasting a doc where we can start building out some agenda topics. If work groups are interested in holding a dedicated session during those two days as part of the virtual hack fest, please get in touch with me and let me know what time you're looking to do that just so we can get everything slotted in over the two days, call in details, et cetera. I think one thing that will be helpful that the group noted from last time was having a more defined set of topics that people want to walk through and be a bit more focused from that front. So I think if we can just take a quick minute now to maybe brainstorm some of the things people would like to accomplish during this time, whether it's from the projects or whether it's from the technical community, that will help us start to build out a better agenda for it. Okay. Well, so from a fabric perspective, I think we want to do a repeat of what we tried to do the last time and that is to encourage people to come and build an app or build some chain code and then we can have some of the fabric experts available to help either with remote pairing or screen sharing and so forth to get people off the ground. So I think one of the things that we didn't have the last time was possibly enough of a socialization of that, but I would like it to be focused on building stuff with the fabric. I think it's in a position where with the developer release that people can actually start writing code, whether it's chain code or working with the SDK and so forth and I think that's where we'd like to focus. Great. We'll get that noted and slotted in. First from the community or from Sawtooth or any of the work groups? Yeah, on the Sawtooth side, I think we probably have, we set up a similar objective to facilitate getting people up and running with Sawtooth and maybe making a simple transaction family kind of like we did on the prior virtual hack fest. And then we're also planning on doing some restructuring, I don't recall if we've actually sent anything to the mail-in list, but there's been some discussions on Slack where we're going to be doing some repo consolidation and package renaming. So if we don't get to that before the hack fest timing, then that might be part of the collaboration that takes place during that. So it sounds like we're in very similar, I wonder, Todd, I don't know if Brian is on or not, but maybe we could somehow or other leverage the LF social media outreach to raise awareness. Yep, sure thing. Hi, this is Vipin. We had mentioned something about actually building a use case which was the DVP, but unfortunately the small group that got together for this purpose, most of the people are not available for the August hack fest, but we will continue to work on it otherwise and then try to spark interest in the community by putting it out there in the demo and other groups so that we can build some kind of momentum around it because we feel that we need to actually build use cases that make sense, at least to us, to the financial community. Maybe there are other use cases out there that people can work on, but we would ideally try to work on it on one of the variants under the umbrella, which would be, the first thing would be fabric, then we would also like to try to do it on once we get it to try to do it on Sartout Lake, but this is the general idea, but obviously since we won't be available during this particular hackathon, we just want to put it out there that we want to do this. That's all. It's Richard here, that triggers a couple of thoughts in my mind, so I haven't been involved in the DVP discussions here, but if you could loop me in or tell me where to go, I'm happy to add some comments there, it's obviously something that we've been looking at very closely as you'd imagine and I guess as you know, we do foot in both camps as part of our work. It'd be great if we could inject some of that into this as an aside, not directly related to DVP, but to requirements more generally to serve ones aware. One of the working groups within the R3 consortium is getting close to finalising our paper on interoperability and given that it talks to DVP, but obviously it also talks to what we're trying to do here. I'm currently going to do the process of figuring out what's IP, what's IP, I have to jump through to see if it's something that we can contribute to this server, not directly related to that, although it's surfacing now whilst I've been in my time. Thanks. Well, the question is, you know, DVP could be, well, without, I mean, your definition of interoperability is, you know, not meaning, you know, there's sort of, let's say, debate about what exactly interoperability means, but in the beginning, it would be just DVP on a single chain. There is a write-up. Oh, indeed. Actually, sorry. Yeah, you're absolutely right. I completed two things there. I was just, for efficiency, I was covering two topics whilst I had the microphone. So yeah, very old news, confused. Interoperability was, I was raising that as a separate topic and not saying that was related to DVP. Sorry for the confusion. Okay. So as far as DVP is concerned, Jeremy has a use case. Jeremy Dritton, quite a bit of, Jeremy and the use case team, I believe, have quite a bit of work on it and they already have something on the requirements of a work group already put together this DVP use case to some detail. Of course, you know, it may not be complete. There may, you know, we may need to do some more work on it. But in the end, the point is that we want to build something that is relevant to the business. I mean, it's great to have technical background like, for example, the explorers, the various languages, the hardening of the consensus, separation of consensus and smart contracts and so on. And identity, of course. But, you know, we might not be able to do it completely because of one of our stumping blocks, but then we'll take that to the various other working groups and say, look, you know, we're not able to do this because this particular aspect is overlooked or not complete or maybe there's a way to do it and you guys can tell us how to do it, you know, those kind of things. So I think it is more of an exercising of all of the parts in order to come up with some use case. That's what we're talking about. Anyway, I don't want to hold up a discussion on the HackFest because this is not directly relevant to this particular HackFest because none of us can really participate because we are on holiday during that period. Thank you. One additional HackFest note I wanted to add, this is Brian. So we're, as I think Todd mentioned, we're hosting a hackathon with A.B. and M.R.O. on the two days prior over the weekend and it's intended to be promoted fairly widely locally and it will be an actual competition with teams and actually some prizes and it will be focused on Hyperledger. So what we're hoping is that at that hackathon we can pull people who seem to be even more interested than usual and more in depth, the most in depth of the people that we meet there. Hopefully we can pull them over to the HackFest the next few days. I also would extend this as an invite to anyone attending the HackFest to also feel free to either participate in the hackathon or simply come in and observe and participate that way. Todd, I don't know if there's anything else to add on that. No, I don't think so. So the one thing that was expressed in the chat, Satoshi was asking whether or not there would be potentially opportunity for people to get together at the LF if they were in town for the HackFest at the LF. So I think Oshima-san's question was about LinuxCon that's happening in Toronto as opposed to Linux Office in San Francisco. Oh, I must have misunderstood, okay. We can check with the Linux Foundation Events team if there's space at LinuxCon. It's late, they're likely isn't, but we'll certainly ask. Any other questions, comments on the HackFest and Hackathon? Okay, I think the next topic was the release taxonomy. Brian? And could somebody paste a link to that in the chat? Yeah, and again, it's waiting on me. I've not yet updated that document yet to reflect. Oh, okay. So easy to pass, a little on from that. It's still waiting on me. If anyone else would like to volunteer to help with that, it probably isn't that hard. It's just a little bit of time reconciling what is the SimVar standard with what's been proposed in that doc. But otherwise, it is still on my tool. It's just not with the crisis date and other stuff we've had. Okay, that's fine. Any volunteers for that? I could maybe take a little bit of time to noodle on it. All right, I guess it'll be me. All right, so why don't you add me to the action and Brian and I'll try and at least bat it back and forth once before next week. Sounds good. Next up is the election. All right. So for the election, I think we've talked about this the past few weeks. But just to remind everyone, let me paste this into the chat window. One second. So from a timeline standpoint, shortly after this call will open the nomination phase for the steady state TSC that will be open for about one week. All the information will be included in email. After one week, we will move to the voting phase, which will be open for about one week as well. And then we'll announce the results of the steady state TSC from there. We'll move into the TSC chair election with a similar timeframe and process. The only other thing is, and I'm going to paste it into the window here as well. We have pulled together a list of everyone that's eligible to nominate themselves and run in this election. We've shared that on the TSC call for the last four weeks. I believe it's also been sent out to the TSC technical discuss list as well as posted on Slack. Please be sure to go in and review. If you do not show up in this list, but should be, please send me a note immediately so we can get you added and make sure that you should be on that list. There's a couple emails that popped up at the end that we didn't have names for. And we just wanted to make sure that anyone that should be in this nomination election process are included. So for those reach out to me as well. Otherwise, about 30 minutes after the TSC call ends, we will use this as the official list to kick off the nomination phase. So just checking with the TSC. Are there any objections to moving forward with this as the list and getting the nomination started shortly after this call? Okay, I mean, I think a couple of those are Intel and I don't know if Dan or Mick can figure out who that is. I suspect some of those highlighted in blue at the bottom are just duplicates of someone's actual corporate email. But please do double check. Otherwise it doesn't sound like there are any objections to moving forward with this as the official list. So we will get this kicked off shortly after the TSC call. And Todd, if you're on the list, can you nominate other people from the list for the election? Typically we do self-nomination. I don't think that that's explicitly stated in the charter, but I will go have a quick look now. But other projects, it's always typically self-nomination. If this group wants to consider something else, the TSC can decide that. I personally would probably not nominate someone before talking with them, but I do find it's a good way to indicate to give people some confidence that they should consider it. There are certainly people out there in the community that aren't on the TSC yet that I will be approaching to see if they are open to it. And I just would encourage others to put their name in even if they're on the fence just because it's a core part of how this process works and how this community works. And it's a really valuable thing to do. So no need to change it. I hope that the folks feel encouraged to go for it. Excellent. We'll get this kicked off shortly after this call wraps up. I think next up is the Explorer Proposal. Parta, Dan, or Chris, I'm not sure if one of you wants to take over the presenter role and share anything, or if you'll just be speaking to this. I mean, I don't think there's any presentation at least, but the proposal is available. Dan and Chris, if you want, I can just stop for a few minutes to the proposal. Yeah, please do, thanks. Yes, thank you. All right. So the proposal is it's written and co-sponsored by Dan, Chris, and myself. This was initially discussed a couple of weeks back and we had a question from TSC to give a presentation about what this is developed. The idea is I think quite simple and obvious. We need some kind of explorer to get insight into what activities are going on in the network, what transactions are taking place, and the data available as well as the chain codes and transaction families that are deployed to the network, and the network status itself. And we could think of more functionality, but this is the initial functionality that we have included in the abstract. And this will be a web application initially with the king of developing as a Node.js application that will be useful for everybody. And IBM and Intel and GTCC all three independently developed explorers. The idea is to basically unify them and in all the efforts and work towards one single explorer that can work with any backend blockchains of it. So it's fabric or Intel for the click. So as part of this project, we are proposing to create a new basically blockchain explorer project and contribute all the source code that's available. And start the development basically by unifying it and making a professional look and feel of the application. GTCC, IBM and Intel all three companies are committing full time resources to ensure the success of this project. And we also basically welcome participation and contribution from the rest of the community. Yesterday I sent out the proposal in the email as well as Dan posted the proposal to the wiki. So I hope the community had time to look at the proposal. Dan and Kristi, do you guys want to add anything to it? No, that was well done. Thanks. Dan? No, nothing further. Okay. I mean, certainly from my perspective, I think this is a really important and good opportunity for us to start working on something that isn't just sawtooth or just fabric, but that is valuable to both. And I think it's sort of the start of how we start bringing more collaboration, which I think is a very positive step. We have a little bit of T-crossing and eye dotting over on the IBM side to get the code ready to come across, but we're pretty close. Yeah, I agree with all those points. I think it's going to be pretty straightforward for the very common set of APIs for querying things like blocks and transactions. But the interesting parts of this project are going to be when we start exploring what do we do at the point that you've got more unique capabilities in one platform or the other. So I think that'll be a nice place for seeing how we address that and how that can be put into a unified explorer. Anybody have any questions for either part of Dan or myself? This is Mike. I do have one question. Is your intention, is the focus going to be, is your intention to focus on the kind of interface or by that I mean user interface? Or is there an intention to use this as kind of an excuse to start standardizing APIs, external APIs that we could use? I think it's a little bit of both, Mick. At least my personal perspective on this would be that we focus on enabling a single tool that can introspect on the respective blockchains inside the STL and or fabric and potentially other things through a pluggable way, but that we can also look at that and explore, okay, so what would it take for us to start standardizing what the API should be or could be and thinking about implementing that in sawtooth or fabric and or whatever. I don't think it's a requirement, but I do think it's a, as you point out, it's sort of an opportunity for a bit of an excuse to go off and start working. I mean I can imagine a few different approaches. One is sort of a back-end plug-in thing which allows each one to go off on its own and the other would be to really encourage commonality and those and trying to push towards at least thinking, at least using this as a way to explore opportunities to unify those interface systems like a really good thing and it will be a useful tool. Well I think that I think what is likely to be the case is that as we start down the path of providing sort of a pluggable back-end to get the information that there's even differences on the front-end potentially and so then I think that's an opportunity for us to sort of step back and think about where this is heading. Yeah, I have a question. This is Wipin. I mean just to contribute to this particular discussion. Is this the first tool that is sort of integrating an approach to looking at the multiple variants that we have currently to, of course, but is this the first tool that is in that vein? Well the change tool is, I don't know, I may come up further. You've gotten with Greg in thinking about adapting a change tool to the Sawtooth transaction families. But I think, you know, when we were talking with Greg about the Saver chain tool, I think the stated intention would be that there's potential that it could be more generally useful, although that wasn't its initial design point. Sure, but to bring it back to what, again, bring it back to what Mick was saying, basically this gives us an opportunity to standardize at least the read-only interface and the beginnings of what Richard was talking about before, which is the interoperability situation. Because, you know, like in several instances we've had any kind of relay tool like a BTC relay from Bitcoin to Ethereum for other kinds of interoperability. The reading is the first part and then once the read is accomplished from one or the other, then we would need to write into the, you know, suppose you're in fabric and you read from Sawtooth Lake, then you could actually do something to write, to transform that read into a write into the Sawtooth Lake, read from fabric right to Sawtooth Lake. I think that would be a function of more of an SDK than just a blockchain explorer that's really much more of a way of visualizing what's going on inside as opposed to something that's actually interacting. Yeah, but it all starts with the read, which is the explorer, what I'm saying. I'm not suggesting the explorer is going to write, but the beginnings of an interoperability tool would start with the read. Anyway, I think it's a great effort if it lays over both systems and it can also bring together a synthesis of, you know, in terms of the interface as Mick was mentioning, if it makes it more, you know, common somehow, the interface in terms of the read, listening to blocks, listening to transactions, get blocks, you know, these kind of things. Anyway, that's all. Thank you. Okay, any other? Just a comment from me, not directly related to the things. I don't have anything to contribute to the blockchain explorer, but I think it's a really useful piece of work and thinking about both Sawtooth and fabric at the same time will be the right way to go. Just as an anecdote, we're doing a lot of thinking about user interface requirements on the core site and exactly the same discussions are coming up. Essentially, you end up getting down to effectively traditional requirements gathering user stories, what are the different constituencies. And for me, a blockchain explorer might be the gateway to many other scenarios, but the story of show me what's happening in my node or show me what's happening in the network, allow me to reason about what's happening. It's not business related, it's not business orientated, there's no business in quotes value there, but it's absolutely critical one to developing the platform, allowing developers to use it and giving people confidence is what you think. So it's clearly necessary. Any other thoughts? If none, Todd, can we put it to the question? So we'll do a quick vote, just walking through the list here. So first, Stan from CME Group. So voting for the unified API or just to initiate the project? Just to start the project. Definitely, yes. Stefan? Yes. Parda? Yes. Hart? Yes. Oshima-san? Yes. Chris? Yes. Mick? Yes. Dave? Yes. Richard? Yes. Yeah. Haji? Yes, definitely. Alright, so that passes unanimously. Thank you. Awesome. Okay. I'll work with Ray to set the repo up and then part, I guess, you probably have the first code drop and the IBM one. And I guess Dan will work on getting the Intel ones. Yeah. Yeah. Peter in corporate process solicited no as a maintainer in that doc and he's got access to all the code that we need. Okay. Super. I have to switch headsets because my headset is dying. Okay. Can we hear me? Yeah, we can. Yeah. Okay. Sorry about that. Okay. Next up is Bawa who's got a proposal for a Python SDK for the fabric. Okay. This is Bawa. I'm glad to be here. And can you see my screen? Yes, I can. Oh, great. The proposal is about Python SDK for the hybrid fabric. So why I want to have the proposal. Currently, if we want to interact with hybrid fabric, there are several methods including using the CLI tools, the commands and REST for API. But both neither way is flexible for programming. So, and on the other hand, we know Python is a very popular language. It's ranking top file within the top file in both GitHub and table index. And currently, we have the SDK written with no GS. And it's also will be cool if we can have a Python one. Okay. And this is what it may look like. We use several simple codes. Then we can do some operations like to connect with the hybrid fabric. And we can get the information from our blog. And we can list the existing chain. And we can also do the operations with the chain codes like typically the deployment and the invoke and also the query. So actually the project is started in several months ago. It's April this year. And it has been verified and used in several real web services. So the main functionality is basically we have finished that. But there are also several to-do tasks including authentication and also the registration. If this proposal is accepted, we will be glad to follow the existing SDK style. And maybe we can also let it to support the Google RPC framework. Okay. Welcome for any comments. So my understanding then is that this is working against the REST API presently. Is that correct? Yeah. Currently it's only for REST API. Okay. All right. Because that is actually technically it's deprecated. There's discussion about essentially removing the REST API capability from the peer, but relocating it into a node interface that then uses GRPC to interact directly with the peer node. And of course that hasn't begun, but that's the stated intent. So the other question I had is actually one that was raised by Keith. I don't know if he's on the call. I think he's in a workshop today. Which was that I think he was hoping that potentially the Python SDK could basically mirror what the Node SDK is doing. Obviously with Python idioms and so forth, but I think at least from my perspective anyway, I think it would be useful if we could at least align them. Yeah. Any thoughts on that? Is that your intention, is my question? Yes. I guess your concern is to support the GRPC, right? Yes. Well, number one support for GRPC and number two, because that's where we're sort of focusing our attention going forward. And then the second point is in having a sort of consistency between the Node SDK and the Python SDK, at least as sort of an exit criteria from incubation. Yeah, yeah, we can follow the style. We can support the GRPC. Actually, I'll put it on the to-do list. Okay. Okay, thanks. Any other comments, thoughts, questions for Bella? Okay, I think, and again, there's a few people missing from the fabric projects like Greg and Sheehan and others. But I think what we should do is, the proposal is out there. I'll send a note to the list to remind people to please review it and add any comments and so forth. And we'll take it up again next week. Okay? Thanks, Baja. Oh, sure. Okay. What's up next? I think it was actually work group reviews, rather. Oleg, are you on? Yes, I'm here. Good morning, everyone. So, requirements for the group. We continue working on use cases. I'm working on a global QIC database. There's work going on for, we came back to the e-voting use case as well. There was a good presentation of art option demo that turned into a good use case document as well. We finished the certification use case. And overall, I think we're closing in on most of the, I mean, on canonical use cases. And the last call, I asked the group to start dividing responsibilities and actually start finishing the main requirements document. Because the corpus of the use cases is pretty much closing in, so we should... So, what's the timing look like for that then? What are you thinking? I can't gauge yet, but I can assume a few weeks. Okay. Especially with people being on vacation and being in summer. Yeah, well, right. Okay, thanks. Thank you. Any questions for Oleg? Okay. Just one last note. Within the requirements for a group, we also discuss building prototypes or POCs demo applications. So, I'd like to make a call to the wider audience to propose use cases and use cases that can be easily turned into demos. We want that we can build and demonstrate that certain use case works well on the blockchain. Especially in the financial industry, since we're preparing for cyber conference. And we need to bring something there. I think actually, when we had the face-to-face, we had a meeting to talk about... That was, I think, a general session to talk about the cyber demos. And I think, and Brian correct me if I'm wrong, but I think that the conclusion that we came away with was that it's probably, at least for the demo that we highlight in the booth. Obviously, everybody who's got a booth there is free to do what they... You know, they're free to have their own demos and so forth. But I think for the LF hyperledger booth, the thinking was that we would have more of a video of a demo rather than a demo itself and highlight some of the capabilities, but without having to actually sort of subject the demo staff to have to navigate through a complex blockchain scenario and so forth. Yeah, a combination of a short video rotating on the monitors to kind of grab people passing by. And one or more basically animated slide decks or other animations that could be talked through with somebody more interested in a particular use case. It just felt it seemed like it would be more robust, but I hate that word. Reliable. Then, you know, and inserting blockchain visually to banking executives walking by might be a challenge in a more compelling way. So just something that was here again was the biggest number one goal. Yeah. Okay. All right, next up is Ram. Hi, folks. Yes. So we're starting separate architecture doc to start documenting our work. We're meeting at 11 am PDT today for a working session on that. Since we meet biweekly on a regular meeting, there's no other major update this time around. Thanks. Okay. Thanks. Dave. Hi, yes. I'm just posting the link to our wiki. So we met yesterday. And if you recall, you know, last week, I updated the TSC that we have made the draft 2.0 version available. The link is there. And so yesterday, you know, we typically start off our meetings by reviewing feedback. And the one thing we noticed was that we hadn't received any feedback. So we were contemplating was that because everyone is so happy and satisfied that it's a perfect white paper and there's no feedback for improvement, or maybe they just didn't get a chance to take a look at it. So, you know, we did spend a little bit of time talking about how do we get more people to take a look at it. And one of the things that, you know, we did note that, of course, Todd's minutes include the link in there. And in the top level read me for a hyperledger project, it's referenced there as well. But, you know, obviously not everyone, especially TSC members have commented on it. And so we're, you know, we're looking for some feedback on what would be the best mechanism to make sure that people are reading through it and, you know, giving us some sort of feedback around that. And one of the ideas that was floated was that, you know, if we do, in fact, want to show this to the board. And, you know, earlier on, I think one of the objectives that we had identified was that we did want to present this to the board and members and make sure that they have seen it and are in agreement with what's outlined there. But before we did that, we wanted to make sure that everyone in the TSC has had a chance to read through it and, you know, are comfortable with how we've kind of outlined that. So that's just, you know, I wanted to bring this up and, you know, try to get some ideas and some feedback on how best we should go about doing this. And also, even possibly, you know, can the Linux Foundation help with some marketing or, you know, once again, once we think that it's ready for broader review, that, you know, how best we can make sure that it's getting some visibility and some feedback so that we can adjust it to meet what the community is comfortable with. So I want to kind of leave that out there for people to kind of think about. I think, you know, also, you know, I will follow up with emails to Chris Yu and Todd as well on this, just so that, you know, maybe we could even, if we do get some ideas, we can talk about them in a broader audience, you know, our present suggestions and see if people are comfortable with that. So, first of all, my apologies because I haven't actually read the minutes from last week because I was on a vacation and frankly... Yeah, August is a tough time of year for getting a lot of feedback. My son was married, so I was like, no, no, no, I'm just off. So I think maybe the thing we should do is schedule a walkthrough, frankly. That's oftentimes the best way to either focus people's attention to get their comments in and then we can just sort of go through, you know, sort of section by section and address the comments and that also tends to sort of elicit new comments from the slackers among us. But I don't know, what would people, is one week enough or do they think they probably want two weeks to... And actually, two weeks would coincide with our hack fest and maybe the thing to do would be to schedule some time then, a block of time to go through it and get to the point where at least the TSC members are comfortable. Yeah, that sounds like a great idea. Or is it my headset? That is me, sorry. Yeah, no, no, I was saying, I think that sounds like a terrific idea. We could schedule a walkthrough at some period during the hack fest time and just maybe send out reminders to people, maybe try to get people to commit to accepting an invitation to participate or at least providing some feedback if they can, if they're going to be busy on other activities during that time frame so that we can discuss among at least the working group members their feedback. Yeah, that sounds like a good idea. Okay, super. So let's do that, Todd. Can we put out a doodle poll for what would be a good two-hour block to focus on the white paper during the hack fest? Yep, we'll do. Thank you. All right, perfect. All right, good, yeah. And then just the other couple of little minor updates there. So we went through, pretty much resolved the comments of our own. The only things that we have kind of pending right now is expanding the glossary. So we're kind of scanning through the entire document, picking out terms that we feel would be useful if we could throw them in the glossary. You know, difference between blockchain and distributed ledger, for example, is one that comes up quite a bit. And there is an important distinction, as Mick and Hart were pointing out during the call yesterday. So a couple of minor things like that, but other than that, we feel that we've incorporated the feedback that we have received today. And yeah, and just basically, you know, I appreciate getting some more reviewing. And I'm sure there's a few things that could be added to make it a better paper. The other thing is, you know, we are looking to create a latex version of the document, something that we could, in GitHub, in the hyperledger space. That way it would be easier to, you know, to monitor what sort of edits and updates have been done. So, but we envision they're keeping both of them somewhat intact. So we'll keep the Google Docs version, and then we'll also have a latex version of it. And so that's something that we're planning on adding. And I think that's it for the white paper. All right, so then just a reminder or a plea to everybody to please review the white paper. Certainly the TSC members, because we're going to ask you to approve this, and then we'll be sending it up to the governance board. And so it's going to have your name on it, people. And so I would strongly encourage you, if you haven't been directly involved in the development of the white paper, to please do a thorough review to make sure that it reflects your perspectives. And then Todd, I guess we'll have a doodle poll and we'll find a couple-hour block to actually sit down and we'll just sort of go through section by section, address any comments, and see if we can next, but I'm getting it past the TSC. Thanks, Dave. Thank you. Where did my window go? There it is. Next up is Christopher Allen. I didn't think I saw him on. Okay, so I think he's off. And then lastly, it's me. Continuous Integration Work Group Update. And so the GERA transition, I think is pretty much done. I think there's still Greg's Fabric Chain Tool to be migrated. But he's on holiday, so I'm sure he'll start working on that once he gets back. I know he and I had a chat about that. But I think that for the most part, Gary is up and running and operational. Certainly for the Fabric, Dan, I don't know from your perspective whether everything is up and running, but certainly from the Fabric perspective, I think we're good. From the perspective of Jenkins stuff? The Garrett, used to Garrett for the SCM and obviously Jenkins as well. Yeah, so we haven't made any Garrett changes as of yet. We'll be looking into that. One of the things I alluded to earlier is... Excuse me? I think somebody's not on mute. Okay. One of the things I alluded to earlier is we're looking at doing some repo consolidation, which will make any sort of CI work a little bit more manageable. Right now we've got interdependencies between the repos, which occasionally come up on commits where we need simultaneous commits between the repos. The guys who've done the Jenkins magic here would have to do a little bit less magic to support that more going forward. So we're going to get through that and then see where that leaves us. Okay. And then thanks, thanks, Dan. Then the other aspect of the tooling transition is JIRA, and we've been discussing this week from a Fabric perspective of just sort of doing a cold restart over in JIRA and for people who have issues out on the Hyperledger Fabric repository that if they still care about them that they should just copy them over manually into JIRA and close the issue in GitHub. And then after a week or two we'll go through and the maintainers will triage what's left and either close them or copy them over if they're still relevant. And so I think that's... Well, I haven't had any negative feedback yet on JIRA, but it's starting to get use and so I think it's wearing good shape there. The one remaining piece of the puzzle I think is the wiki. And there's a couple of different thoughts out there for the wiki. And one of them was... And again I really appreciate the sort of the cross-team discussion with Sean weighing in from his perspective on how to deal with the documentation and the wikis. So we have a couple of different suggestions. One is to use something like MediaWiki or Confluence and another one would be to just leverage Markdown and publish using the Read the Docs as we are with both of our documentation that would give us a little bit tighter control over things. And so we could certainly do that. There's an ongoing discussion in the mailing list about that and I would encourage that it continue. But we're working with Rai and the Linux Foundation team to figure out what the right and best approach for dealing with that is. One of the situations we have to deal with is where we're going to host the documentation if we do this or getting MediaWiki or what have you stood up. So we're working through the wiki issues and hopefully we'll get that resolved over the next week or so. And so that's what I have from the CI perspective. Any questions? Okay. So I guess we're at end of job and people can have a half an hour back. Alright, thanks everyone. Have a good weekend. Bye.