 at least, that would make sense based on that. One thing that I think is key, which I cannot realize as I try to work through this, is and I think some of the discussion seem to inch on one key aspect, which is whether the exit criteria are really about the project as an organizational structure or the project as like, you know, a product, some code that's actually running. And I think, in fact, we didn't really highlight that there was a difference in those two aspects and I think some of the discussion really came from, you know, talking about one or the other and I think we have to agree on which one we're talking about. So in my, in this case, in the draft that I put together, I really focused on the former, which is the more of the organizational aspect of the project with the idea that, you know, the project life cycle is about this. You go first in incubation mode and you say, hey, I have an idea, I have a proposal, I want to start to investigating. And then the maturation level is when you actually manage to put to get the project off the ground, you have, you know, generally speaking, like, you know, a decent community around it. There's people, you know, participating, not just all from one entity and you got your act together in, so to speak, right? And so you have code that's being developed and you have things like, you know, tests and continuous integration, all this stuff has been kind of figured out and it doesn't necessarily mean that the product itself is, is ready for shipping for like general availability, but it means that, okay, now you have a project that's, you know, that's mature, it's functioning as an organization. And so this is really what I focus on. I think if you look at the exit criteria that I put together, some of them, you know, may actually belong more of the other category, and what I also realize that I think is important to highlight is the fact that it's, it's not like we're going to be able to come up with a list of very precise exit criteria that will be applicable broadly on all projects. And there are certain things like, you know, when we talk about scalability, I only listed a few there, it's clear that there are quite a, you know, quite many dimensions to scalability and based on, you know, you, the particular requirements or use cases that a project may want to address, they may, some may be more important than others. And so this is a key, you know, this is an example in which, you know, it shows that one size does not fit all. And so I drafted the document more with that in mind in thinking, okay, this is the kind of things that people need to think about when they are evaluating whether the project has reached maturation or not. And so from a process point of view, the TSE is responsible for assessing whether a project deserves to be moved to maturation stage. And so I thought about the exit criteria as being more like, you know, somewhat of a template for a project to consider when they want to fill out their application, so to speak, to the TSE and say, hey, we think we fit the requirements to become a mature project or consider that such. So, you know, I'm not going to go into the detail of every one of the exit criteria that I picked, you know, through the notes that have been taken, but I think this gives you kind of like my thinking into, you know, how I put this document together. There were several comments. I, you know, it wasn't completely clear to me how some of those comments could be integrated into the document. And so maybe we do still need a little bit more discussion as to what we are trying to achieve with our, as I said, I made several assumptions. And if people, you know, agree with that, if that, you know, I felt like, well, people are not trashing it, which is probably a good sign. It means people are saying, yeah, okay, that may, that makes sense. But I think it would be important to validate that with everybody, whether those assumptions are good and whether there is something else that needs to be done. Once we agree on the assumptions, then we can further find you in the details of the document. Okay. Thanks, Arno. So I think I pretty much agree with a lot of that. Maybe we do need to sort of carve out and articulate that, you know, the sort of the two levels that we're talking about, because it's actually going to be, you know, is Sawtooth Lake or is the Hyperledger Fabric project, those incubations are the top levels, if you will, are they ready to exit incubation versus, you know, we've had a number of subordinate proposals, like the busy work stuff from Bishop, and we have one that we're going to be considering next week from Greg on the chain tool that are sort of subordinate projects, if you will, and, you know, they, you know, may or may not be, you know, being ready, or for instance, the DTCC one, the Shim for Java, you know, those may be being ready even before, you know, the Fabric or, you know, in the case of Sawtooth Lake is ready, and so we may want to exit those from incubation, but they're still part of a higher level incubator, if you will. So maybe we do need to sort of call out the distinction between those. Any other thoughts on this? Comments? Do people agree? Do we need more discussion? This is Mike. I really like the document put together, you know, and, you know, we've had that discussion. Thank you very much for taking the initiative to do that. One of the things that came out just in thinking about that is that maybe our project proposals need to do, when we present the proposal, would be the point at which we start articulating some of those criteria, some of the project specific criteria. So maybe beefing up, I think we had a section in the proposal that talks about, you know, when you're ready for maturation, and maybe we should start holding, and it's probably a good idea to go back for the earlier projects, and actually describe and articulate what the per project criteria are for how we view maturation. And then that would give the TSC an opportunity to evaluate not just the project, but the project's notion and definition of maturity. And use this as a guideline for what should be included? Well, no, I'm talking about two, there's two sets of criteria. Yeah, I think what you're saying, so you're saying so we will go back and revisit the proposals for Sawtooth Lake and Fabric, for instance, and update the, which I'm looking for the section here. There was a section, and sorry, I don't have it in front of me, but I recall a section that talked about kind of some notion of when you're done, right? Yeah, I think in yours you called the closure, and then I was looking in the Sawtooth Lake one, and then in the Fabric one it was called. We didn't know about that though. Yeah, so you would have a section then that would sort of articulate. Well, how the project proposes could be the definition of maturity, which doesn't, I mean, like Arno said, there are some like community activity and engagement and other things like that, which are sort of universal. But each project's going to have some set of criteria as well around which it should be held accountable for its maturation. Hey, this is hard. Bip and I'm agreeing with you, and I'm just suggesting that we beef that section up. Hey, this is hard. I was also going to ask if we have some notion of sort of production ready, because it seems like the project might be mature, but not, you know, ready to run, ready to use to move lots of money, for instance. You know, we might still need to do like a security review or things like that. Do we have any notion of that, or do we need to do that? So, Hart, I think I would agree with you, but I think, again, that's a slightly different conversation than whether or not it's incubating or not, although I suppose you could conflate the two, but I would think that would be more along the lines of if you're doing some sort of steady release cadence that you can have, you know, effectively an LTS kind of release that we would, you know, as a community, you know, the Hyperledger project would anoint as being production ready. I don't know that that's going to be the, I wouldn't next, first one out the door, I would expect that there would be a series, and then we would get to a point where we would declare it is ready for production. You think about, for instance, what Docker did, you know, they had a number of dot releases before they released their 1.0 and declared that it was ready for prime time. Yeah, I agree with you on that, Chris. I just think that as we're having the exit criteria discussion, we, you know, this might be the next discussion that we want to have is sort of the steps sort of after the incubation and maturation. Yes, thinking about Norm's question, though, we should probably, you know, given the importance of security in this space, we should probably kind of maybe think through whether some, at least early security-related criteria should be added to this, right? Do we want to think about security at a later stage or, you know, what amount of security strengths should be part of this stage and this criteria is probably worth talking about? So, Ram, I think, I mean, I think it's important to do that, but I think, you know, to a mixed point, maybe that's something that should be specific to the top of the project to describe, because they may be different, right? Criteria may be different. I'm not saying it will be, but I suspect that there's likelihood that there may be a very good reason, you know, if you've got, you know, if you've got something that you're building that's permissionless, it needs to be, you know, the blockchain itself, that needs to be hardened and secure, but anybody can join. So, right? It's a different function of security, I think. Right. Perhaps some high-level, you know, description of what, you know, what is our notion? Do we kind of think that some level of hardening or security design is incorporated in the project at this stage? Is that something that we want to encourage people to think through before it becomes a mature project? Yeah, no, I definitely think that it's something that has to be top of mind. But, again, I think that, you know, and I think, certainly, where you were suggesting is that as part of the proposal, and we can go back and we can revisit the ones that we've been, you know, that have been submitted is to have an explicit description that would be part of what we review and approve that would describe essentially when the team that's making the proposal would feel that they thought they were done. Now, the other aspect of the whole life cycle was basically also that the project team would decide when they thought they were ready, and it's not like something the TSE is going to be constantly monitoring a project, but it's more like the project team would come forward and they'd say, here's why we think we're ready to exit incubation. But I could certainly see, you know, augmenting the proposal template itself with a set of questions to ask and then, you know, use this as a rough, you know, guide for some of the more generic kinds of things we'd be looking for and have those two sort of synthesized and then the TSE would use that as a measure. Does that make sense? Yeah, that makes sense. Listening about the security talk there, I mean, I realize security I think is only touched into the test coverage. Maybe we should have something about, you know, along the lines. It may be a bit silly because you would expect everybody to do that, but maybe we can highlight that people must have given security proper consideration and maybe have gone through or have plans to go through security review, something along those lines, I don't know. Maybe some kind of peer review from a participant that's outside of the proposal. An interesting idea. There's a subcommittee here, but could you have another pair of eyes who hasn't made assumptions about the code as it's been developed? Well, I mean, if we want to use these sorts of systems to move large amounts of money, we're going to have to have really, really thorough crypto insecurity reviews because obviously any sort of bugs or any sort of problems could be catastrophic. Now that's probably a little waist down the road, but it's definitely something to think about. But again, I think though that that's not a function of exiting from incubation to maturity. That would be a function of any release that we declared that we were going to be supporting for a long-term period, wouldn't it? So what about this then, and again coming back on keying in on your comment, Chris, that there's a difference between maturity and sort of production, but at the end of maturity you better have an evaluation plan. One of the criteria is do you have a security evaluation plan in place? And then the execution of that plan is what gets you out of the rubber stamp for production quality. Would that make sense? Yes. Yeah, I think I agree with Mick. That seems really reasonable and it also allows individual proposals to have sort of individual security levels. Obviously if you're just writing the proposal for testing software, you probably don't really need to care as much about securities if you're writing some sort of core code. So I think this dovetails really nicely with Mick's suggestion for modifying the proposals to have sort of individual criteria. Yeah, I agree with that actually. I think that's a reasonable idea. Since we have this variability we seem to all agree we have to live with. Maybe, you know, and maybe there will be some changes down the line, but you know at least setting some expectations at the time of the proposal makes sense to me. Richard, you've been quiet. Yes, sir, about that Chris. I was distracted by being dragged into another meeting so I actually missed some of these discussions so I don't actually have anything to contribute. I'm pretty sorry. Parta, and he's distracted too. Well, so we got, I haven't heard from, or from Chris Annaly. Thomas, you've been quiet. I like the document as it is. I think it would be a bit premature to set very specific parameters and criteria. That's my opinion. And Stan, you've been quiet as well. Thoughts? Well, I actually agree with Mech and Vip and Ed. It would be great to have a set of criteria for a project. I mean, the document could be more like a guideline. So what would be the type of things that would be expected to be included in the proposal with the maturation. And maybe there could also be like a really small, high level set that all projects are expected to match. Okay. Yeah, I mean, that's, if I may interject, this actually brings up an interesting point which is, I think one thing we could consider doing is, in that lease, I think there are certain criteria that are probably applicable to all projects. And then there are some that are not so. And we could highlight those. I don't know if there's much value in that, but that might be something worth doing. I think Mech brought that up in one of his comments. David, you've been quiet. Yeah, I like the idea of having a set of questions and associated with the different pieces as I think Mech and Hart were discussing. You know, one interesting thing is, so with my white paper working group Pat on, so, you know, where, of course, it's still draft and we still are looking to get more feedback and all that. There's something around, you know, how well does the platform meet the, you know, sort of vision and criteria of what the overall program is as well. I mean, you may have, and that does a couple of things really well, but if it's missing a key aspect of a fundamental concept that is being outlined in our overall vision of what this project should be, you know, that would be important to highlight. And the point about, you know, when a project sponsor is ready to say, hey, you know, I would like to see my project move to the next stage. And they make that sort of proposal and talk through it, you know, to be able to speak to how it fits in with their overall vision and everything, you know, and also in terms of, again, if we had specific questions that were asked about how well the project has achieved, you know, on the various maturity levels that we've put in the form. Ashima-san, Iran, do you have any thoughts? I don't read the idea to have the criteria to evaluate. I think it's strongly depending on the use cases, but we should have some guidelines or basically read. Okay, thank you. All right, so I guess we have a little bit of work to do then to refine this and also to sort of update the template. Arnaud, are you willing to sort of take this morning's discussion and integrate that and come back next week? I can try, but I'm not completely sure how to go at this, because so how we, you know, again, it's not because I disagree, I agree with the idea. It's just that in the end, what are we going to have? Do we have, I mean, are we going to keep two documents, one which specifically is focused on exit criteria, and then we basically have a reference from the proposal template to the exit criteria saying you need to consider those, or do we integrate this into the template? Yeah, I would suggest that we integrate it into the template and give examples of what we would expect people to come forward with. And the examples can be our sort of general guidance, and then as people present proposals, they can fill out the criteria for when they think it would be done. Does that make sense? Okay, somebody else wanted to speak when I started. Yeah, hey, this is Morali from DDCC. One part, right? I think last time when we talked, we talked about having a test network. I thought that was a good idea to have a test network as a, you know, part of criteria for the maturity. Okay, so that would be for sort of a top level product, not for subordinate thing, but I do agree that that's a good idea. Okay. All right, that's, I think that was a good discussion, so thanks everyone. Moving on to the remainder of our discussion. So I think the thinking for next week is to have the virtual hackathon where we're going to try and sort of have people online for most of the day. And there was a draft circulated by Todd of a draft agenda, and I had that marked here someplace. Yeah, I just dropped that into the chat window for everyone. Thanks. So Todd, you want to want to walk through it since you did the work of pulling it together. Thank you. Yeah, this is just a quick basic framework. It seemed like everyone's availability was for next week. So looking at kicking this off on Wednesday and running through midday Friday. And I think the idea is people just had a little more general availability to be working on code having discussions, etc. And one of the suggestions was made to have a couple of checkpoints throughout those days. So the thought was to get this kicked off on Wednesday morning at 10am Eastern time do an hour welcome to set the stage with what some of the goals are for the next couple days. And then move into a virtual hackathon where people use a variety of the existing tools we have in place from there. At the end of that day, there'll be a quick check in on what what took place during the course of the day, what people want to accomplish in the coming day and then people can continue to hack into that night and another time zones. So Wednesday is the standing TSC call so we can use that for any TSC matters as well as set the stage for day two. And then again at the end of that day have a 30 minute check in on what progressed during that day and then on Friday again have a final regroup and recap for what took place. So a couple of things that we want to iron out are one, we have a lot of great existing tools in place, but just want to check in if there's anything else that people want to use during those days. And then two, we want to set some objectives for what people are looking to accomplish during that time. And then lastly, there was a suggestion for, you know, some other ad hoc meetings that take place during that time, potentially having office hours for their maintainers, as well as possibly having some work group meetings during that time and we're happy to get those scheduled so people know when they're happening. That's just a quick overview and then really looking for the TSC and the community to help build this out a little bit more in preparation for next week. So thanks, Todd. I think this is a good start. Unfortunately, I can't do the 10 a.m. on Wednesday because I have a customer briefing. I'm visiting a customer, so I won't be able to do the 10 a.m. I can't do the TSC on Thursday. That's not a problem, but I won't be around to kick it off, but maybe we get a volunteer to sort of just leave the discussion. I would expect that, you know, again, what, so this will be, I think the intention again for this virtual hackathon is to be a lot more hands on actually get people writing code, you know, whether it's, you know, fixing bugs, finding bugs that have, you know, they're low hanging fruit or adding new features or adding tests or just writing examples and driving and testing and coming up with more bugs or, you know, augmenting the documentation. Any of those types of activities that sort of hands on keyboard where, you know, conversation in Slack is going to be, you know, able to sort of help move people along quickly where you could pick up the phone or get on a Google Hangout or use ScreenHero to do some pairing. You know, I think the intention would really be to focus on actually moving each of these sort of two top-level projects forward in some shape or form. And, you know, so I think, you know, the Thursday kickoff is really more of a coordination and, you know, people can talk about, you know, what things they may or may not want to work on and then maybe there's some people that are available to sort of say, I can help you with that, you know, but, you know, to have people on and, you know, potentially have project office hours I think would be useful discussions for that first initial call. But like I said, unfortunately, I can't do that. I have a previous commitment. Dan or Mick, are you guys hopefully going to, you know, to participate and have some things that can be worked or, you know, have some of the, some of the talk to late guys online at the time of the hackathon? Yeah, we're planning to have some participation there. We've been talking about some of the work we've done to create a tutorial for the transaction families. I think that might be able to be extended into some fun hackathon projects. We'll have something a little bit more formal put together for next week, but in a nutshell, it's different kind of games that people could probably gin up without a whole lot of time commitment. Okay, cool. And I'm planning to participate Thursday and Friday, but I'm traveling Wednesday. Were there any plans for work group meetings to be held during the hackathon? I think that's a good suggestion. We should take that on. So I know that I think if groups have already met, you know, during the week and they feel they've accomplished what they need to accomplish, that's, you know, that's fine if teams want to sort of have an opportunity to do an off cycle discussion. I think that might be healthy as well. I know the identity work group is has their standing meeting on Wednesday at 11 a.m. Eastern. So we'll get that out of that right now. Yeah, and the light paper meeting is Wednesday is at 1 p.m. Eastern. So that makes sense. Cool. So yeah, maybe if you get reminders and if people wanted to dial in for that, they could do that as well. In terms of the virtual hackathon, what are the times going to be like Eastern 8 to 5 or 9 to how is the time? Well, I think that what proposing it would be sort of from 10 Eastern, which is 7 a.m. Sorry about that West Coast guys. 7 a.m. West Coast, of course, it would be in some ridiculous time if you're in Japan or China or elsewhere. Unfortunately, but so we would, we would sort of have it, you know, between 10 and 6. It sounds like with a little wrap up at the end of the day at, you know, three Pacific six Eastern. Okay, thanks. And I think people can continue past 6 p.m. I think that'll just be a checkpoint towards the end of the end of the day Eastern time, but I suspect people on the West Coast and Asia will will continue on from there. Yeah, if the current practice is any, but I think, you know, there are definitely people that are still hanging around on on slack past that time anyway. Okay. Hi. This is Kishore from Broadridge, India, Broadridge, India. Quick question for the ACATON. Is there any plan to have a common sandbox environment for people to do work or people just do their work on their infrastructure and submit what they've done? How do we plan to do that? I think it would be the normal process of you work on your laptop or in your own development environment, you know, you seem certainly for the fabric, you know, we've got a vagrant environment that you can stand up and I and it's the same for the Sawtooth Lake and sort of development sandboxes that you can set up and you would do your work and if you make any code changes or whatever would have you you do that there and then, you know, submit a pull request to get any changes merged or, you know, new tasks or fixes, whatever. And, of course, if you're writing sample code then I think, you know, sharing in your personal GitHub, you know, if you have a sample app that you wanted to share with people, you know, doing that through your own Git repositories would be appropriate. Okay. Thank you. Okay, Doug. And then, Todd, what about the July planning? Where do we land with that? Yeah, so July is going to be the week of July 25th was when most people are available. We're just finalizing space on that so potentially we can look at something on the peninsula or San Jose at a member company. One of the other options is the Linux Foundation has an office in San Francisco, and we could rent out some conference space adjacent to that. It's in the Presidio near the Golden Gate Bridge. And there would be a small cost associated with that. So just evaluating both of those options right now to see potentially what's available from any of the companies on this call. Otherwise we could lock down in the San Francisco office. Okay. Let me know where you land with that because, I mean, IBM has offices in Foster City. We may be able to sort of get some space there. Okay. And then we also have in South San Jose, of course that's not on the boonies, but we do have space there. I'll connect with you offline on that. And then the last thing, looking at monthly cadence for having this technical face to face meetings. For the August timeframe, one of the things that could line up nicely is LinuxCon North America takes place in Toronto. It's going to be the week of August 22nd. So that could be a good timeframe and location to get people together. It's not too far from where everyone is, where many people are in New York already. And it would also give the opportunity to draw in some other people into the Hyperledger project by co-locating there. So just gauging general interest on that. Yeah, that's a great thought. I think it would be a bit too close to the July one. Probably it will target another audience then, at least for those traveling to the Bay Area. I'd like to suggest that we already plan for meeting in Alton, somewhere in September, and it preferably would be in Europe. Let's open in that. So there was a series of notes, Todd, where somebody was suggesting, and I thought it was October, or maybe it just said Q3, I can't remember now. Is there some sort of a blockchain conference in Europe in September or October? I thought it was consensus, but I couldn't find anything like consensus EU or something like that. I couldn't find anything in Google, so I wasn't sure if it's a real thing or not. But somebody just suggested we could have one around that time period. And I think maybe it would be an AMRO that was offering to host. I can't recall Todd. Yeah, so I chatted with them actually at the face-to-face, and it sounds like they could be interested in hosting that. I think SIBOS or SIBOS is a conference in, I think it's October. I think that's the end of September. Okay. So yeah, that's September 26th to 29th in Geneva. Yes. We couldn't think about that. Maybe that's what they were referring to. And that could line up nicely. I know the Hyperledger Project Marketing Committee is looking to have a physical presence at that event already. And so lining something on a technical front could make a lot of sense. Yep. So Tomas, I think I hear you actually are paying just having gone to Barcelona for two days. I'm still jet lagged. I have no idea what time zone I'm in anymore. And so I feel your pain having to travel internationally that's so frequently. I don't know. What do others think? Do you want to try and go alternate virtuals and face-to-face and have one around SIBOS instead of August? Actually, a lot of people also take holiday in August, so it may just end up not being very practical to get together for face-to-face. Chris, I think we should see how the virtual hackathon goes and then probably see if the virtual hackathon makes them. Let's put it this way. Is anybody who would be opposed to doing alternating virtual and face-to-face, as I just described? Tom, let's work on that assumption and let's see if we can, especially since it is going to be for many people, it'll be good. Obviously, if it's in Geneva, that's pretty close for Tomas and some of the others that are in Europe. And we can maybe start playing and thinking about who and where and how we would get posting facilities somewhere approximate to that conference. Perfect. Sounds good. Okay. And then, Todd, this point here was immersion into Garrett, so I think Rai and the team are going to be giving a course on how to use Garrett next week. Yeah, that actually took place earlier this week. We did a recording of that. That's posted to the TSC Wiki, so anyone that wasn't able to participate, please go check that out. If you have any follow-up questions from that or want to connect up with Rai, just shoot us a note and we'll get you taken care of. No problem. Thanks. I've been in a time warp. Okay. So, so much for action and reviews. Updates. Oleg, I think I saw you on. Do you want to give us an update on the requirements? Yes, I'm here. Good morning. Good morning. Yes, we had a productive meeting two weeks ago and this Monday, Jeremy Severi presented delivery versus payment, which is a fundamental use case that will work for financial transactions and for real estate transactions, anything, any use case where money is exchanged atomically with, in the same atomic transaction with underlying asset. So, we also discussed and voted to simplify use case template to limited to user stories only. And we believe that will help us and other members of the project or experts from the outside to enter more use cases. The idea is to keep the use case page or use case document to user stories only and requirements from the user's point of view basically to admit any implementation details such as states, transitions and so on. Another proposal was made to add an identity matrix to every use case document so that we can compare them and see what the identity or privacy requirements are for each use case. Because we can really put a matrix to every use case, whether we need to allow to see the payload of a smart contract or the contract code itself, whether we can or not allow the color identity to be seen or the ledger data to be seen. So that's where we are. Super. Thanks. Where's my agenda? Ron. Yes, so we did meet this past Wednesday, yesterday on the architecture world group. The IBM team Marco and team have put together a very thorough documentation of their proposal for the next generation of consensus and that was the main focus of our discussion yesterday. So we had a very good discussion around it and we are still in the midst of it. So we're going to continue that. I think your suggestion about trying to have off cycle session next week during the hack thought to be a good one. So I'll send out a doodle poll to see whether we can find some time Wednesday through Friday to have one more session before our next one will be captured. So I think we're making good progress in identifying alternate mechanisms to the previous model in terms of separating out the validation or quote unquote endorsement from the consensus layers, if you will. And so we still need some more discussion to piece out the pros and cons of the approaches there, but I think they're making good progress. Thanks. Any questions for Ron and David. Yeah, so we also had our working group meeting yesterday and we've updated our working the white paper working group wiki. If you take a look there now you'll see there is a draft version 1.0.0 available and also kind of restructure the page a little bit. And as soon as you hit the white paper working group you'll see that first thing and we've also added a link there so you can view the feedback submissions. And just a quick comment on feedback submissions. If you click on the link you'll see our last feedback submission was, let me click on it, take a look, May 26th where we had one. So we are definitely looking for more feedback. What you'll find in the draft version 1.0.0 we had spent the last two weeks going through Richard's comments feedback which he put a lot of effort into. We really appreciate that. And so we didn't necessarily agree with every comment in there but the vision section was redone and Hart played a major role in that one. Thank you Hart. We definitely think that this is important for people to read through and comment on because there's a lot of room for varying visions on things. And we can definitely see how this white paper could become a proxy for discussions of some pretty fundamental things about what we're doing. But anyways the draft is out there and people are able to see what feedback submissions have been made. The feedback form is a little bit more prominent there. It would be great to have the TFC members provide some feedback. We may want to, next week for example, take a vote to say, is this ready now to be more prominently put on the hyper.org, hyperledger.org, main page to direct them to see a little bit more detail about what we're all about. But before we do that we think it would be great to make sure that everyone has read through it, considered what's in there, and whether they're comfortable with it being representative of what our whole sort of mission and objectives are around this. And just further updates were provided in the minutes in the status section there. We think we have removed all the messages of OBC from the white paper. I think some of the comments that Richard made on that were related to the fact that he took a snapshot just before it looked like after we made the link available, but before we put the new diagrams in there. So I think with those new diagrams in there, if you read through the architecture, we hope people will find it generic enough that it isn't just talking about one implementation. And though the word fabric appears throughout the paper, you know, and I know that I guess the IBM code based on we're calling fabric, we're using fabric with a little less. And, you know, fabric has been used a lot in computer science, particularly in COG, most recently, you know, it kind of represents nodes and links. And so, you know, we think we can still use the word fabric without that being tied specifically to the OBC code base. But if people have differing opinions, you know, let us know. And we've got the mechanism in there for that feedback. And I think that it, unless anyone else on the team wants to bring up anything, I missed. Yeah, I can imagine fabric term could cause some confusion. It might be good to find another term to fit in there. Yeah. Yeah, so I would encourage everybody that's on the TSC to actually do a thorough review and, you know, provide any specific feedback, including me. It's been on my list of things that I need to do. I really need to do it. So, yeah, I would definitely strongly encourage everybody to give it a once over. And David, maybe it would be good to actually have as part of the hackathon next week, not so much a white paper workgroup meeting, but we can actually use maybe that time since you met this week to have sort of office hours to have an open discussion about paper. Yeah, that's a great point. Absolutely. Just one other point, you know, that we talked about, you know, though we have the form available, you know, what Richard did also was very effective. You know, he saved a word version of it, put his comments in there. So, you know, if people want to do that and email it, you know, we will certainly consider that as well. So, we don't want to force people into going through the feedback submission form. If it would be more comfortable to do that, that would be great. But also, you know, if you have some specific thoughts around a section, if you don't really agree with it, give us a suggestion. How would you like to replace that, the verbiage? So, you know, we'll put a little bit more on people to, if they find it, you know, something that they are objecting with a little bit, let us know how they want to phrase it. And that would be a good way to help us understand specifically what they're looking for. But yeah, I think that would be terrific if we could, you know, get people office hours type of thing for just general discussion. That would be very welcome. Cool. All right, thanks. Any other questions for David? All right, Chris is not on, I believe, is still the case. I don't see him. So, we'll skip identity, and they'll be meeting next week. And so, CI. So, I, like I said, I was traveling all day yesterday, sitting on a plane with no Wi-Fi. And I got back, and I just happened to check Slack, and I noted that there was a couple of comments that Jenkins is not working for the fabric on both X and Z. If I'm not mistaken, I don't know if I saw power in that mix or not, but if that's the case, oh my God, awesome. And so, I'd really like to extend my thanks to Trevor and Rai and Remesh and a few others that were helping and getting all that up and running. That's a great piece of work. And so, then I guess we have to, again, I have a whole lot of catch up to do in that regard. So, I'm not exactly sure where we are, whether we ported over all the actual build, or whether that was just that we were able to get a slave spun up on those different platforms, but whichever it's still, I think it's still notably good progress. So, if we had the Gareth that I need to then listen to, then the other thing that I'd like to do with both projects, both top level projects would be to start working with the various, the maintainers on setting up planning for transition over to using Gareth. And again, I think the important thing, and the important reason for using Gareth is to get really persnickety about reviews, and actually we're able to sort of also enforce a number of other checks by using Gareth in connection with Jenkins, because the Lynx Foundation has a number of bots that can do things like ensure that there's a sign off for the DCO, that we can break down the testing into multiple checks that each are able to sort of give up a plus one. And then we can also enforce multiple reviews, so that actually you can have it so that two maintainers have to agree. And I think this is important because when we're dealing with software of the nature that we're producing, I think it's going to be really important that we're very cautious about code that gets in, that it's been thoroughly reviewed, that it's thoroughly tested, that it's had at least two sets of eyes on it and hopefully more. I think this is something that teams are using to great effect on other Lynx Foundation projects, OpenStack and a few other notable projects that require extensive review before merging any code. So I think we'd want to start seeing sort of planning towards how do we transition over the code to be under Gareth and setting dates for when we'll do that so that we can also get planning for Trevor and Rai and others to help on that. So that's it from a CI perspective and I think that's all she wrote. Chris, may I add something? Yes. I feel the need of a meeting with the maintainers or those who are directly interested in reviewing full requests in the code because I think these TSC meetings are really a bit more high level governments type of decisions that we make but we really need to find a forum to find decisions on very technical matters. So going through full requests and discussing them. So Ben had set that up, unfortunately I think his laptop blew up on Sunday and he was unable to have a call this week and we had one I think two weeks ago and then last the week before it was a holiday in the U.S. and so we didn't have a call but I think there is supposed to be for the fabric project anyway there's supposed to be a maintainers meeting actually it's a project meeting and the maintainers are expected to attend and anyone else can attend on Mondays at 10 a.m. Thanks Todd. And so I think that would be the intention for that. And again I noted with you guys on Slack that we also have to start planning for being able to cut a release I'm not saying for a 1.0 but certainly we need to start working towards that and I'm sure you agree. So that's just a matter of getting everybody together at a rate or time and having that conversation. Okay, well I knew these meetings I participated in the two that happened. I think it would probably make sense to announce them that they have this specific scope of reviewing. Reviewing Austin's pool requests for example. Yeah, I think that would be a useful topic. Yep, okay. And I think I saw Ben on so Ben I hope you agree. Okay, maybe a mute. Any other comments? Any other topics people would like to cover if not everybody gets 25 minutes back. And thank you and we'll hopefully see many of you online next week during the virtual hackathon. We're looking forward to that. Thanks everyone. Thanks Chris.