 I would hope that the Tamashian team would also be working on similar thoughts. I think we should probably do that in the context of issues in the code base and the incubator. But then I think the other aspects are going to be working on the requirements and use cases. So we'll have a track for that and we can have track for project life cycle in template and for the code conduct. Chris, I went ahead and muted everyone so you may need to come back off mute. Sorry. I was going to finish up what I thought the various work items we had to cover were. Again, I would hope that, you know, with that many people that we could break out into breakouts. But I'd be able to see if anyone had thought about other things we should be doing. Either everybody's on mute or there are no other ideas. Chris, this is Patrick. I was going to mention when we were going to cover the requirements or group that I would like to do a breakout during the face to face focused on use cases and requirements. Yeah, that's exactly what I thought we'd have. Yeah, we'll start with that and flesh it out. Then it's the mailing list and we'll try and finalize it next week. Perfect. Sounds good. One question. In how far do we have to, can we bring in the use case out of the technical steer code or do they come via the governing board? Anybody can bring use cases. Decision on the overall outline. Who takes that steer code or board? I'm sorry. Who takes the fine decisions on what use case you want to cover? Is that within the technical steer code or does the board come in and put you? Yeah, I think the TSC. The work group should work through bill consensus and bring a proposal to the TSC. Okay, thanks. Hi, this is Austin Hill from Blockstream. I just joined. I apologize for being a few minutes late. So are we talking about use case development for the TSC in general or for the hackathon that is being planned in a couple weeks? I think in general for building out the use cases and requirements for what we'd like to do from a head to ledger project perspective. Do we have a repository or a standard place where we're asking everyone to start depositing a use case? Yeah, I think Patrick will run through that in just a minute here. And answer your question, Austin. We don't have anything formal yet, but we should do that. So I suggest Todd, we go to the next slide. Great, sounds good. So Patrick, is your preference that we make you presenter to run through your updates? No. It's okay. I just talked to it. I'm ready to go. Okay. Sounds good. I sent out an email last week asking for volunteers. I got six volunteers. I'll read the names. If you had intended to volunteer and sent me something, maybe I missed it and there's still an opportunity. So I have Thomas at Digital Asset Holdings, Benedict Primrose at Accenture, Judy Priest at Cisco, Stefan at, I can't pronounce that, Deutsche Börse, and Emmanuel at Accenture Technology Labs. If you had intended or still want to volunteer, please send me an email, patrick.homes.intel.com, and I will get you on the list. Not a lot of progress this week. I'm coming up to speed on the best way to do this. I'm talking to other people at Intel about best practices. I plan to talk to Todd as well about that, and I've also started collecting use cases. I agree we do need a place where we can put them rather than just sending them to me. It was clear, though, that one of the first questions that's going to come up is what is the scope of these use cases? I've been sent use cases for the music industry, and use cases for health studies, medical studies. So we need to figure out the scope, and that's one of the first things we'll be working on. As I mentioned earlier, I'd like to do a breakout during the technical face-to-face, but time it in such a way that the people working on this don't know some of the most critical meetings. For example, if anyone from IBM is going to be talking about the architecture of the contribution, I don't want to miss that. So we'd have to schedule it around. And that's it. Any questions or comments for Patrick? Yeah, I was asked. Sorry, it's Vikas from CLS Bank. I just wanted to know, is there an end date for collecting these use cases? Because we haven't submitted any, and we would like to submit a use case from the payments and settlements. Wonderful. No, I have not put together a schedule yet, or an end date for use cases. For now, you can send them to me if you want, and I will figure out a way to get all those posted. Or you can wait until that's set up, either way. I apologize for the trouble here. I didn't hear a name from IBM, is that right? I think we have somebody at this point. Maybe we have to get them to say, hey, was there somebody from IBM in that list, Patrick? No, there was not. Okay, I'll make sure they reach out to you. Any other questions for Patrick? Patrick, did you already, this is too much, digitized, did you already decided some kind of a collaboration platform so we can continue this, not in a bilateral talk, but in the public? No, but I will get that set up, say, this week before the next meeting. Any other questions? Next up was the white paper. White paper. Right, so I put an outline out in a Google Doc. And then I think somebody had proposed that we use some tool, but I've never heard the tool before and wasn't clear how that would be used. I don't know if they're on the call or, I mean, I figured we'd just use a Google Doc and edit in common, maybe somebody could need the actual editing to welcome any thoughts. I think Google Docs are a pretty powerful collaboration tool. I thought it was probably fine. I haven't had a chance to check this morning to see if anybody had had any comments on the outline. I look through it and for me the outline looks perfect. You can start with that, I think. All right, so I was going to start adding some of the content from the IBM white paper that I thought was appropriate. And that we just sort of comment. Excuse me, where was this, I'm not sure, I saw this document. I know I sent it to the familiar. So it's not shared, it was a mail? The link is in the agenda as well that Todd had sent out to the GitHub repo. Sorry, I'm reconnecting to the go to meeting. So again, I suggest we just get in there and edit it. Is there anybody that would like to take on the task of being the lead editor for the white paper? Chris, this is Dave. I could take on that. If you need someone. I will then make you an editor. All right, Todd, what was next? Yeah, so moving on, the next thing is an update and discussion around the DAH IBM experiment progress. So I know IBM has put the code into the incubator repo. I looked yesterday and I didn't see the DAH code. So Tamash, is there an ETA for getting the DAH code uploaded? Yeah, it is available in its previous location. I did not push it yet to the collaboration space, but it was actually the same thing. All right, so let's put that in there. And then I think from an IBM perspective, and I'm not sure who's on from IBM, but maybe Ben, maybe you could give us an update. I know that we've been working on some of the aspects of the proposal. And maybe, Ben, if you're on, you could update us. Yeah, if you look into the OPC repo at this point, there's a number of issues that we have created to work towards that and prepare for the phase-to-phase. So specifically, we are looking at the ability to integrate an interpreter. Just use any interpreter. We picked up the interpreter from Bitcoin source code and tried to call that interpreter from a chain code so that we want to prototype the ability to pass in a Bitcoin transaction through OPC system and to the interpreter and be able to interpret by that interpreter and turn around and update the transaction log as appropriate. So that's the path that we are exploring at this point. And hopefully, we'll be able to show that kind of like show and tell at the phase-to-phase meeting. Now, are there any aspects that people could start working on before the phase-to-phase? Do we have any stories that people could start working on? This is Joel. I'll just point out that we've done a lot of work on binding into the Bitcoin interpreter, both the Bitcoin interpreter and into the blockchain elements. So feel free to ping us on any help needed on that side. Yeah, we were wondering about whether we should just pick up your interpreter and integrate that, but we couldn't find it. So we decided to go with Bitcoin interpreter. But I believe that it would be a very simple switch for us. Yeah, okay, we can help out and point to the things that it helps technically to integrate. All right, great. Okay. Anyone have any questions, concerns, thoughts on the current proposal on the experiment? I think we can move to the next item, just trying to agenda. I think the next step was... The Code of Conduct, Arno had sent out two options. All right. Thank you. Hi, everyone. This is Arno speaking. So yeah, Code of Conduct, the TSC decided we should have a Code of Conduct. Some people say, well, we do even need one. Unfortunately, the kind of things that nobody would like... I mean, everybody would like to be able to do without. But experience shows again and again that it's useful to have one and it's become common practice. When we started discussing this, Chris suggested we take the Cloud Foundry one. I mean, obviously, there's no point in developing one from scratch. There are many to choose from. And of course, the question then is, well, which one do you choose? So Chris suggested we use Cloud Foundry one. I took a pass at taking the text and basically trying to just do more or less a query replace of the name. I made some small adjustment when it referred to things that were specific to Cloud Foundry. But it's more or less the one from Cloud Foundry. There was one significant change, I would say, which is that in the Cloud Foundry Code of Conduct, it basically talks about the fact that it's bad to remain silent in front of bad actions. And it says that in a fairly negative sense. At least some people felt it was pretty negative. So I replaced this with a piece of text that I took from the directory C1, which aims to the same goal but has a more positive wording. And so that's the last bullet of the keep in mind section. And then Mick Bowman, actually from Intel, made a reference to the directory C code of conduct. He thinks that it's pretty small and sharp. And so I'm actually very familiar with directory C myself and I like it too. So I thought, well, what the hell, we don't have to force anyone to use one particular one. We could just take two options and now a quick vote decide which one people prefer. So I also did the same big operation taking the directory C code of conduct and adapt it to a project. In general, my sense of how they compare is the directory C1, just from the structure point of view, the text was designed in such a way that the code itself is very short and crisp. And so it fits into nine bullets that fits in half a page, which is kind of neat. And the way they achieve that is by having a bunch of references to terms that are defined in the glossary, which itself is much, much longer. There is one difference in my opinion, which is significant, is that the code of conduct from South Country talks about what you're supposed to do when you step down, when you retire from the project. And it talks about how you should do that. It should be considerable into not just dropping the ball and disappearing, but making sure that the project doesn't come from retiring from the project. That part is not actually covered in the directory C1. I don't know if it's an issue. We could add it if we wanted. Obviously, all of this can be edited at will. But I think there are two valid options. And rather than forcing one particular, as I said, I think we could have a quick vote and decide which one to go for with. And as I said, amendments can be done either way. There was one comment made against the... Actually, it was entered by Alicia against the directory C1. It has to do with the incident procedure section, which actually exists in both versions, both options. Alicia mentioned that sometimes it can be a crime, and then the leaders of the project may have to report to authorities, basically. I think that's true. I don't know how much is important to point that out in the code of conduct. Usually those things, there's a fine line because it depends on the countries and everything. But, for instance, the directory C1, for that reason, as a note at the end of the introduction, it says note that this code complements rather than replaces legal rights and obligations pertaining to any particular situation. So I think that's an important thing. It's not meant to replace any laws that may be applicable, and that will obviously vary from country to country. So I wonder if maybe we should add a similar note. That's a good point. So that's one thing we could carry over also. If we choose to go with a cloud foundry-based one, we could take that piece from the directory C1 and put that in so that they could cover this. So I think, again, I think both are good. I worked a little bit on the cloud foundry one, so I'm more familiar with that. But reading through the directory C derivative, that's also good. I do like that it's very succinct. So it's a little bit clearer in that respect. And of course, I've worked in the W3C for a long time, as well as you. I'm in the meeting. I can leave. So I don't know. I think we should, and people should speak up if they have any first reaction or comments. But otherwise, as I said, I think the most practical way forward is to have a quick vote decide which one to work with as a starting point and then make adjustments. The ability center over near the corner is a problem. Hi, this is Vipin. Support the sort of W3C1 over the other one. But like several people have remarked, both are quite similar. And this is, as Arnau captured, you know, I have a slight preference for the W3C just because it is concise. I'm quite happy with both of them. I really like the wording change that was made for the cloud foundry as well. Stefan here. I'm also fine with both. I would like to refer to the W3C. And Dave all here, you know, pretty much the same. I agree. W3C already has that little bit about the legal side. That might just be the easier one to do. Sounds like there's a slight preference for the W3C1. So maybe you could do a roll. Do you want me to do a roll? Go ahead, Mike. Hey, Dave, real quick. This is Mike Dolin from Lakes Foundation. For those saying they have a preference for the W3C code of conduct, does that also include the glossary? I mean, that's one document, right? I don't think you can separate the two. You could make different adjustments to the glossary if you think something is not right, but... Okay. I just wanted to make sure we're not just talking about the 9th and the code, but also the glossary as well. I think it's the whole document. That's my understanding. Okay. So again, I was hearing a preference for the W3C, but I'd like to have maybe basically all the TSC weigh-in. So far, unless they'd like more time to think about it. Let's put it this way. Is there anyone who would disagree with adopting the W3C derivative? And if you're on mute, you may need to come off. Hello. This is Primrose. I read through both of them. And to be honest, I found the one from Cloud Foundry a little bit easier to understand and to follow. For W3C, it sounded like quite a legal document. I'm not entirely sure why I came across that way. The Cloud Foundry one made it feel more of a community than W3C one. It could just be my perception. I think that's a fair comment actually. And I believe the result is from the breadth of the people involved in the W3C one. W3C is a very internationally oriented organization. They have offices all around the world. And all the different groups within W3C were involved in the making of this. And it went through a lot of scrutiny. And so I think that's why it's quite crisp. But maybe, yes, like you said, it looks more legal oriented than the Cloud Foundry one. Hey, this is Hart here. I was leaning towards the Cloud Foundry document simply because I was just not a huge fan of the glossary in the W3C documents. So Chris, it sounds to me that there are people on both sides. So I think it might make sense to have an offline poll and then people can vote whether they really object to one or the other or whether they prefer it and then based on the results, we can decide next time. So I don't know if the Linux Foundation has some poll mechanism that can be used for that or we can use a doodle poll. Yeah, we can just send a poll out to the TSC mailing list. Maybe we include more than, maybe it's just strongly favor W3C favor OK with W3C. Strongly favor Cloud Foundry OK with Cloud Foundry just to capture sort of the... And Mike, I'd open it up to everybody. I mean, I don't think it should be limited to just the TSC members. I'd like to get input from... Yeah, I guess I assumed it was for everybody. I'll just use the TSC mailing list if that's all right or do you want me to cross-post it? All right, so let's put out a straw poll. And then again, I would encourage people to get in if they have thoughts about what we might be able to leverage from the W3C one into the Cloud Foundry or vice versa. Make some suggestions and let's see if we can't wrap this up next week. All right, project proposal template. So Gippen, thank you. Yeah, so I did get a few comments, mostly related to the spelling or other things, but a couple of significant things did crop up. I have reworked the document with the suggestions last time, mostly the licensing and the trademark stuff has been added. And I tried to make it also function as a template with the sections involved and also removed any strong language about using this particular format to handle the solutions, meaning if the solution does not require a certain section to be handled, then left it open in that sense. The actual wording is the topics given below are just suggestions addressed only if they are relevant to your problem. And it goes through a list of various possible sections you should address in the solution. And then the motivation has been separated and kept separate. One of the things that came up just this morning from Primrose is what is the definition of a team champion? So this thing has come up even before. So the technical lead or the technical champion, I had put it in there only because I wanted somebody to be driving the project proposal instead of it being just loose and nobody is kind of driving the project. It languishes. The question that came up was was it somebody who is proposing the project or is it somebody from the Hyperledger Technical Steering Committee who would be appointed to be a... So we need a clarification on that technical champion bit. If Primrose wants to elaborate on that, she can. Just after I finish my spiel. Well, yeah. Why not do it now? Just talk about this technical champion thing. Maybe we should remove it. So we have this concept of maintainers and committers, right? And so the maintainers are basically the ones who are... They're the product leads, project leads, I should say, for a given component. And they are the ones that would have the final say in terms of what things get merged and so forth. And then there would be, out of that, there would be a community of contributors and potentially a community of committers, people who are allowed to commit. But, you know, just like in Docker and a few others, we put the same notion of a maintainer. Now, I guess that could be the same as a champion, but, you know, in the context here, I suspect that the champion would be somebody who is bringing the project forward for consideration, pardon me, for consideration. But I see you have a project champion can change in the middle. So if that was the case, if this is intended to be the person who's... or persons who's got oversight, then they would be, from my perspective, the maintainers. And typically you'd have multiples, so that, you know, if somebody gets hit by a bus or changes jobs or whatever, life goes on, as opposed to having a single benevolent dictator kind of a thing for each project. Yeah, we could change the language for it to be a plural rather than singular, but does the concept have any use or is it to be made more clear? That's... I mean, you just made it a little more clear. The other thing I wanted to tell you was that in the status part, you can have a link to the life cycle proposal that Chris, you created. So then there's no ambiguity about what status means in that life cycle document. That's where I have left it. Maybe we can continue discussion or maybe we should adopt it, but maybe during that phase to phase is when all, you know, this thing gets nailed down and we agree on the proposal. Yeah, I think it's getting close. I think this notion of champion or maintainers, I think we do have to have, you know, an identifier of who the initial maintainers are being proposed. I think that needs to be... Again, I'm not sure we have a project champion. I think we just identify the maintainers and they're the same as the ones that are bringing the proposal forward. But I think it's getting close. I put it, you know, turn it around and ask members or the non-members to weigh in and put in some thoughts on the proposal template. Proposed proposal template. And again, you may be on mute. Hey, this is Mike. I got just a question on the list of bullets in the solution space. So it looks like you're covering quite a few things in there, kind of the technology spaces, licensing issues, some legal, some logging and traceability privacy issues and some things like that. One thing about these systems that is interesting is the characteristics of the deployment that is not just the component technology about how the pieces fit together. Could we make sure we include a bullet that captures our, as part of the proposal, our vision of how it would be used? Yeah, I did... I do think I have it in some form or the other, make it a little more, a little more, in fact... The one that's closest is the third bullet. The how-to was meant to address that, how to host and test the project or it could include what you just said as well. Okay. So I created that new bullet there, how-to, which is apart from the solution, different from the solution. So it is not only how-to-host and test the project, but also how-to-actually-use. Is that what you meant or is there something... Sorry, I'm just... Yeah, I was looking at the Google Docs right now and the one, the bullet that I thought was closest to it was the effects on the network throughput, visibility to other participants. So it's kind of deployment characteristics. I mean, this can include everything from... I think Kristin in the IBM White Paper talks about the geographically local and a certain validator count. There's some implications for things like that as well that are at least characteristics of the piece of that technology. Sure, we love it. I love it. Thank you. I guess we'll defer the final sign-off until later. I mean, obviously, this doesn't mean that it cannot be changed later. No, I think it's getting close. So I think we got some good feedback here. I would encourage people to review the document again and any comments and suggestions in the margin. And we'll go through this again next week and try and wrap it up. So I think the next item is the project lifecycle proposal. And I lost my... So thanks, Kristin. Okay, so the project lifecycle, we discussed last week that, you know, in addition to just a proposal template for proposing new projects, new components, and or work items, that we also need, especially for a component, you know, something that is manifested in a component in its own repository. And we need to have a lifecycle for these things. I think it's likely that, you know, there'll be new components proposed. We'll be refactoring and so forth over time. And so things will come and go, ebb and flow, and you'll have an opportunity to potentially deprecate certain things. So I took the open daylight template, the lifecycle that they had, and I adapted it a little bit that way. I think it's the first hall pass where you just came through. And I added in a deprecation and end-of-life phase. They had a notion and there's a top-level project. I don't know if we're going to get there yet. We can always adapt as appropriate. But, you know, I think, you know, the processes, you start with a proposal that fills out the template that Vipin was just proposing. We'll finalize that. So it's got to have those things that we can adapt this proposal must to align with what Vipin has. And then we would have a review by the TSE of the proposal, and the project would either be turned down or added into incubation. That would be the first place that it would go. It would go into the Hyperledger incubator. Pardon me, ORG. And then, you know, once the project gets to a sort of mature status, the maintainers of that project can then request that it have a graduation review by the TSE and, you know, again, at that point you have to have code-based test coverage that can ensure it was what the other mature projects have. And then for the first ones, that'll be, I think, a lot of this sort of eyeball that. We want to have an active and diverse community of developers. You don't want to have a project exiting incubation where it's just, you know, one vendor or just a couple of individuals. It really needs to be a diverse community of interest. And the other point that they had in Open Daylight was that it followed the mature release process for at least a couple. And again, we'll have to, you know, we have to define our own release process. But, you know, you'd want an incubating project to essentially be demonstrating that it's essentially already a mature project. Then the TSE review and approve that. If they do, it becomes a mature project, and it goes from the incubator org into the main org. There's a little bit of work associated with that because of the nature of Go. We have to change a few things around. But within a project that's mature and goes through its lifecycle at some point in time, you know, we're going to potentially want to deprecate that repository for the reason. And so then it would go through, and I recommend it a six-month period. We could make it shorter or longer. That's, I think that's up to us. Where we give notice to the public that, hey, we're going to deprecate this guy. It means that after that six-month period, it won't be maintained. And then once it goes through that, and then it goes into end-of-life, and essentially we archive it. It's no longer actively developed. So that's the proposal. And I'd be interested in thoughts from others. So, Chris, there is one comment that I think is worth mentioning here on the document. And I wanted to thank the people who pointed out typos and kind of errors, and I tried to address those. But there's one question that remains, and I apologize. By mistake, I first clicked on Resolve, so I just reopened it. But the question has to do with how much do we talk about the transitions between the different phases. And the document that stands doesn't talk so much about the transition except for the very first one going from the proposal to the incubation phase. And you might infer from just reading the document that this is a linear progression only when the question pointed out, you know, that was pointed out was, well, there may be cases where you go through the same stages several times. You can imagine cycles and the like. So, I mean, the document I think doesn't touch that point. I don't know if people feel like this needs to be done or not. I mean, we could also have some general statement saying, you know, there is no particular, you know, transition path is implied here. And a different possible path might be taken depending on a case-by-case basis or something along those lines. So, you're referring then to, like, if you're going from incubation to mature, the TSC may say, no, you're not ready yet. Exactly. If you stay in incubation for another period and then you come back, and I think, no, I would have thought that was implied. We can certainly make it clear that there's no guarantee that a request to graduate will be granted. I don't know. We may be able to look at something like the ASF to see if they've got a process. I didn't notice anything in the open daylight that addressed that aspect of things. I have seen, hi, this is Bipen again. I have seen in some other places actual state transition diagrams addressing this. But I mean, I don't know how far you want to go. It all depends. Exactly. That's why I'd rather not go there personally. I thought it was better to just describe the different states and try to keep them fairly broad so that, you know, we don't get, because, I mean, you could invent a lot more phases, too. But, you know, there's a limit to do. I think we need to find the... Now, you know, something that I haven't put in here, but, you know, again, I would ask people to give a little bit of thought. Going through a deprecation process has an impact on the end users. You know, we may want to add in that, you know, a request to go from mature to deprecated maybe needs to incorporate or include some sort of a end user outreach that, you know, gets a sense for what the impact would be. And maybe the TSC needs to, you know, to perform that part, that role. So, I mean, I'm happy to make it a little bit clearer that, you know, it's not a guarantee. You may have to, you know, repeat the proposal phase a couple of times until it gets approved. You may have to repeat the graduation request a couple of times until you're really mature and then... I think the same thing for deprecated, if the end user community comes back and there's no way Jose, you know, and doesn't go deprecated. Or, you know, maybe the time, maybe the extent, or the period is extended. So, thoughts on that? Hey, Chris, yeah, I mean, that's a very important point, and I would agree to include some verbiage to that extent in here. That's Dave. That's Dave, yeah, thanks. Any other thoughts? Well, I'll invite everybody, again, to say, you know, take a close look at some comments. If you have any, and I'll try to address a couple of points that we talked about here. I think that's the agenda. Todd, do we have anything else? No, the back cover and everything. Has anyone else got any other business? Chris, I would like to chip in. I had a terrible network connection before, so I missed the last question today, agenda planning of the HECA plan. I'd like to just...