 Sounds good. Yeah. OK, so good morning, everybody. Good afternoon, good evening, wherever you happen to be. We have a, I would say, I think this is a light agenda. So let's get going. The first item is the hackfest planning. And Todd has an update on Chicago. And the registration is up, so you can cover that. And then also put out a query for where we want to have the European event, the hackfest rather, in Europe. Then the second item up is the TSC election. And so I think that starts today, correct? And so we have a final list. I didn't see any notes that said, oh, my god. But maybe you did. And then Mark will review for us, I guess, just the status of where we are with the performance and scaling working group charter. I think it's still being ratified by the working group. And then Hart wanted to take us through a brief update on the white paper. Anything else for the agenda? OK, if not, Todd, kick it off with the hackfest planning. Sure thing. So the US hackfest is confirmed September 21st and 22nd in Chicago. I've dropped the registration link into the window. If you plan to attend, please get registered as soon as possible. Also a link for draft agenda, similar to all the previous hackfest, we run these in a conference format. If there's topics you want to discuss, things you want to work on, or things that you want to hear about, please drop those ideas in there. We'll firm up the agenda as it gets closer. For this hackfest, I think a couple of things really looking to further enable collaboration between the various projects and also have increased focus on actual hacking. Presentations are still great, but I think one of the things we've been hearing is people want to do some actual hacking and collaboration that way, face to face. Anything you want to add, Chris? Yeah, I think that's important. I know Brian and I have been having some discussions about that, and it really would be good to have a lot more cross-pollination, if you will, between the different projects and interaction, and maybe even some hacking. And so I think for the Chicago hackfest, we will defer having any face to face meetings of the various working groups, because that tends to really limit what we can put in our agenda for at least two or four hours, depending on how many we get through. And so I think if you have a working group, then I would strongly suggest that you think about, instead of spending a lot of time, I should say, but rather maybe have a call with an extended agenda. And I did also notice when I was registering that I guess there's a fee now if you're a no-show. Is that new, or am I just not remembering that from the past? That's something new, I think, across Linux Foundation. They've been implementing that. And it's just so that people let us know if they're actually not going to show up. We end up spending a lot of money on catering and planning for folks that don't arrive in the end, so just to incentivize people to actually let us know. Oftentimes, we'll see 30 or so people that register and don't show up, and so that's a fair amount of money that hits the budget that we can save otherwise. OK, thanks. I hadn't seen it before, so it is new. And so everyone, be mindful of that. So just let me ask for clarification if I may interject. Just clarification on the no-show. So if I register and then in two weeks, I figure I can't go, I deregister. I can do that, and then there's no fee, right? Totally fine, no issue at all. That's right, thanks. And is there a cutoff for that, Todd? I'm not sure what it says, and there may be 72 hours or something like that. They're relatively lenient, but yeah, just give us a head start, please. Yeah, OK, thank you. Yeah, because some people, including myself, may get dragged into something and can't show up. OK, election. All right. Oh, I'm sorry, we didn't cover Europe, sorry. OK, are Brian or Marta on today? Brian is, yeah, hi. Hey, Brian. I think we're going to talk. Yeah, go ahead, sorry. Yeah, just going to add in. It seems to be that there's support for either the week of the 23rd or the week of the 30th to do an event, a hack fest in Europe, as probably the last hack fest of the year as we get into the winter holiday. And so there's, I think, strong support for being an event in Berlin. And what we'd like to try to pin down on this call is which of those two weeks, perhaps preferences for cities. We have some options in different places in our opinion of where it might be best. And then I wanted to sense people's receptivity to doing it over a weekend rather than during the week, because there are some options that come available. Schools are one. There's another hack space that's been offered in Berlin that is easier to get to on a weekend than others. So why don't we just take these one by one? Are either the 20th or the 30th of the 30th, those two weeks, any strong reasons why not to do that for anybody on the call? This is Dave. This is Dave. Sorry. Can I jump in here? The SIBOS is in Toronto from the 16th to the 22nd. So if we do it on the 23rd, that might be back to back weeks gone for people that might be a little bit harder. Yeah. OK. And I would also note that there is a hackathon in Beijing, I think. And while I saw you on, I don't know, I think it was the 21st, it might be. I can't remember now, but I think I signed up for that. Yeah, actually, the hackathon is after the links come. I've seen how the links come. So it will be the June 18th and the 19th, if I remember correctly. October 18th. Do you mean October 18, 19? I could be right. It could be misremembering and that conflicting with SIBOS, which I think I have to be, all right, weird. OK, so noted the concern about the week of the 23rd. Any concerns, any other concerns about that week or the week of the 30th? We get the 30th, the Halloween. Yes, which is kind of a family holiday for many of us, even if just in the evening. Not to mention it's hard to get through TSA when you're dressed up as a Halloween concert. You have to see Dan when he gets dressed up. Got to pay extra. OK, and keeping on the scheduling theme, strong likes or dislikes for doing this on a weekend rather than two days during the week. Again, this being in Europe. I'm not hearing any strong likes or dislikes. I definitely prefer the week than the weekend. I can say that. And then finally, cities. We were thinking Berlin partly because there's a ton of interesting blockchain activity there. Some of our members have operations there, offices there. That would be great to have them involved in the HACSF. I think doing that would better enable them to participate. It's less expensive as a city in general than London or Paris. Paris isn't too bad. But there's other interesting opportunities to like Lisbon and so forth. But would anyone be opposed if we focused on Berlin as the city to have this and came up with some options there and looked elsewhere if we didn't feel like we could come up with good options? OK, well, unless I've actually been on mute this whole time, it sounds like no strong objections to kind of a strategy. So I think Todd, this is strong enough for us to go back and come up with some options and then try to converge on a decision in the next week or two. Sounds good. In the next two weeks, please. Thank you. Oh, actually, one thing just occurred to me. The timing for the annual members meeting, is that like a couple of weeks right after this? Yeah, I think it's November 9th and 10th. OK, so that'd be pretty close on the heels of the European meeting then. If we made it later in those two weeks, yeah. Well, I know from my travel perspective, it would be easier. Somehow those events could overlap in the same location. So these ships have already sailed on both of those separate events. But it's a certain amount of convincing that needs to be done for international travel in my company. As always, I'm sure. Yeah, I think we just ran into deciding we wanted to do a member summit in Asia after polling our members and trying to figure out the better options we did consider in a bunch of different cities. And then it seemed like support from the community for doing a hackfest in Europe before the end of the year as well. But doing it in December starts to get too close to the vacations in all of these. Another note there on the member summit that the W3C Technical Plenary Advisory Council is in Burlingame, California that same week. So I know there's a couple of us, Arno, and the two others that are involved in W3C activities standardization around what we're doing in hyper-legitimate. Might give us some conflicts there. OK, all kind of issues noted. I think we'll aim for something in kind of the middle of those two weeks, the 20th and 30th, either late, but with the 20th there, to avoid people's or early, the week of the 30th. And trying to see what we can do to avoid too much conflict with Halloween. OK, let us take a look at that, come up with some options. And we'll come back for further discussion on the TSA. Moving on. All right, the next topic, TSC annual election. We've circulated this several times via email. Talked about this the last few calls. Shortly after the TSC call today, we will send out a note to start calling for nominations. The process and timeline were in the agenda doc that went out. I will paste the list one last time into the chat window. Now please check the master tab. That's what we're going off of. If you are not on there and should be, please send me an email as soon as possible so we can rectify that. Otherwise, after this call, we're moving forward with this list as final to kick off the election process exactly as we've detailed and approved previously. And I'll just put the timeline in here as well for folks. Any questions there? All right. Thank you. So that brings us on to Mark. Amy, Mark's on mute. Hey, I'm trying. Can you hear me now? Yeah. Yep. All right. Now, the first time I'm calling it from an Android phone because I'm in Sweden, the local calls are expensive. So for the charter, there was some feedback overnight on the consensus rules and things like that who can vote. So I felt it best to not proceed with a vote on the mailing list for the performance and scale working group because not everyone would have a fair shot to review it. But I did put the link here in the chat window. The changes we're making and proposing to this are highlighted in bold based off of feedback from the group and one is from the last TSC meeting. So I would just, in particular, on the process of the group regarding how I've defined, proposed, we define who can vote on the working group issues. Is that something that would be acceptable to the TSC? And again, this has not been approved by the performance and scale working group. But is this something that would be approved by the TSC if it stands? I'm not sure what you mean by vote. Are you talking about voting to approve the working group or voting for things that are proposed by the working group? Anything in the working group that we did a vote to bring the charter to the TSC. And the TSC wanted some changes made so we brought it back. In general, anything within the group that we want to make final, with air quotes around it, would need some type of vote or agreement. So I think most of the working groups have been working off of consensus. I mean, they may have an email that goes out and says, hey, does everybody agree that we're done? And we can bring this to the TSC in front of a formal thing. It's much more of an informal thing just to make sure everybody's on the same page. And so I think we would encourage that working groups continue to operate on a consensus-building model. And if there is dissent, that's fine. And maybe the thing to do would be when it is brought to the TSC, the dissenting parties or whatever can make their case as well. I mean, that's really, I mean, I think in terms of any formal voting, it would be the TSC that would do that according to who's elected and all the quorum rules and all the other stuff that's in the charter. But I think for the working groups, consensus is probably the best approach. And I see that I could. Good. The question was, what is the definition of consensus? In the case of a working group, is it a simple majority? So consensus is really, I think, something that the chair needs to assess for themselves. If it's clear that there's never going to be complete agreement, then obviously you start to work towards, OK, so if what would be your minimum required to declare victory and put that to either party, if you will, either side of an argument, and try and get at least a little bit closer. And then even if you can't get all the way there, the chair can say, look, I think we have consensus. We have a minority disagreeing opinion. They can bring that to the TSC and so forth. But a lot of working groups operate on consensus. I think if you are no, didn't we have published chair guidelines? I think that's public at the W3C. And there's a good write up on consensus there. Yes, indeed. There is. I would be happy to send a link. I had blogged way back then about this. And there is, indeed, there is actually education material that the W3C put together to help the chairs. That is worth looking at. I can dig that up and send the link to the list. But it's basically, like I said, it's basically the chair is the decider when he or she feels that there's essentially, we're not going to get any further right in terms of towards complete agreement. And then you give the minority side an option to weigh in. If it's a 50-50 kind of a thing and there doesn't seem to be a majority, if you will, then you can also bring that to the TSC and say, we can't get passed. And I mentioned many of us TSC members will be on the working group. Well, at least monitoring the working group don't presume to be a member and can help arbitrate difficult conversations if needed. And if we're lacking for consensus mechanisms, we can always come up with a proof of work one, which basically says, well, if you're willing to help write a dissenting opinion or help build a better test suite. I mean, essentially, yeah, proof of work, right? You're allowed to dissent, but invest in helping us lift the level of understanding of these challenges by the entire community. Yep. OK. Hello. Again, as an example in the architecture work group, we've been following the rough consensus model. There's ETF guidelines as well on roughly how that works. And I can send a pointer to that as well. But so far, the informal rough consensus approach has worked in the architecture work group. And I've seen the same in the identity work group. I don't think we've had any serious conflicts that we couldn't talk through and get the majority to agree on. And in fact, I don't think there was even a strong minority position so far that we couldn't talk through and get to rough consensus. And this is Victor. OK, I appreciate that. I think maybe it is me who raised the voting issue. For I have gone through the working group who chartered that notice that there is a clause about PSWG should oversee any performance related projects. So since recently I have been working on a benchmark project and I want to discuss with PSWG in last regular meeting. After my presentation, some folks have asked me some questions. But finally, when I ask whether should I present this project to TSA, there's no response. That means no idea. So I want to know if the work group is going to oversee other performance related projects, how should we make decisions? There could be yes and there could be no. But what if there is no idea? So I discussed with Mark, maybe not directly. I'm commenting on the charter and raised this issue. Indeed, the biggest threat is passivity, not enough involvement rather than perhaps too much passion. So I think you might want to think about whether a recommendation can really be considered having been approved unless you've got a chorus of voices saying so. I'll still leave that up to the chair to decide kind of on a point-by-point basis like how much feedback is enough to really say this represents a consensus view rather than an individual view. OK, thanks, Brian. Right. I was on funeral preparations on, so I couldn't attend Thursday's call. But I will work. I will go back and undo some of the changes to the document and present it to the performance and scale working group again. I appreciate the feedback on the suggestions. Thank you, Mark. And thanks for continuing to work on it at a tough time. Yeah, absolutely. OK, anything more on that? And maybe just I think I heard wrong and I heard RNO offered to send some material on how to build consensus. So I think it's useful. I know I recall back when I was first named a chair at the W3C that it was very handy for me. So at least the stuff that RNO is going to circulate. So much appreciated if you could share that, RNO. And then finally, we have, yeah, thank you. And then finally, Hart wanted five minutes of our time to talk about an update on the white paper working group. Sure. Thanks, Chris. So I wanted to say a few things. First of all, we are approaching what should hopefully be the completion of a draft of the white paper that we can send to the TSC and others to get final edits and final approval. So hopefully that should be out in the not too distant future. That's point number one. Point number two is we, as a working group, thought that it might be better to rename the white paper the hyperledger position paper. And we're curious what the TSC thought about that, as well as what approval process we would need to go through to make that happen. And the third point we wanted to bring up was we have a actually relatively good infrastructure where the white paper is now a tech document. It lives in a GitHub. You can issue pull requests and so forth. But right now, this lives in mixed GitHub account. And we think the Linux Foundation account would be a more appropriate place to store this. So we wanted to move the documentation over properly to whatever was appropriate. I don't have a problem in moving the repo into the hyperledger org. OK. Brian, you had me use subversion. No subversion, unfortunately. So yeah, so just go ahead. I think the, so I mean, I don't have a problem at all. I think that's, you know, whether it's in a wiki or whether it's in a repo, I think that those are both appropriate. And so I think the thing to do would be for, I'll start a thread with Rai and Mick and Hart and we'll get it moved over. Sounds great. Thanks, Chris. Yeah, that's about it for the update. Are people generally OK with calling this a position paper instead of a white paper? Yeah, I like the sound of that. I think the white paper title had always been a little bit awkward. So yeah, I think that has a good direction. Yeah, I think that makes sense as well. So just to play it back to see whether my interpretation is what you're suggesting, white paper implies this is something you should read to understand what this thing does or how it works. But of course, there is no thing here. There's a collection of things. Whereas a position paper outlines almost a set of principles and or even beliefs or statement of direction that I would say are acted at an earlier stage or at a higher level of abstraction. So that's the thinking behind the proposal. I think it makes a lot of sense. Yeah, that was our thought process, basically, Richard. So thanks, yeah. Cool. I'd like to point out that for the technical stuff, can we just email directly to help Desk at Hyperledger? We'll get better response if we do that instead of just emailing Rai directly. All right, yeah, that was it for me. Thanks, everyone. I don't know, Brian. I mean, were you on mute? Maybe I don't have a problem with the name change. And it seems like others are supportive as well. Is Brian still on? Maybe I lost him. A technicality, probably a trivial one. Am I right in thinking? I'm not sure it's the incubation entry or exit criteria. Do one or other of them make reference to the architecture white paper? So we might need to align that or check that line in the criteria. And I do this, isn't it? I believe the architecture white papers is still a separate thing. Yes. Fine, fine, fine, OK. Yeah, and that's the document that the architecture working group is preparing. Yeah. Anyway, on that point, we did release the first article. Thanks to everyone in the group and to folks in the marketing committee to help us with that. Yeah, so maybe it would be worth a minute or two from you on that to just make sure everybody's aware of that first article and then talk a little bit about the other artifact that you guys are working on. Sure. So I don't know if everyone got a chance to see it's been published in the Hyperledger site. So the first article that we covered was just a quick overview of the overall architecture framework. And most of the actual content was focused on the functional requirements at the high level for the consensus function, if you will. And it went on with the generic description that we're going to be there in the architecture document and covered the particular implementation that's supported by the different projects, fabric, sawtrupleg, Iroha, Indy, and so forth, and the comparison of the consensus approaches there and the pros and cons. So if you haven't had a chance to look at it, please take a look at it and send us feedback. Like all other documents, this will be a living document that we can update as well. And the thought is to go on and do the same thing for the other modules, layers that we've been working on. The next, the immediate next one being the smart contract functions. Any other questions for a moment, if not, then unless there's any other agenda items, we'll give people 25 minutes back. All right, thanks, everyone. Enjoy your summer. Well, have a good day, everyone. I mean, let's look forward to seeing all of you soon. Good. Bye.