 I'm Dan, so we can go ahead and we'll start the recording and we'll get the meeting started. All right, welcome everybody to another fun and exciting edition of the Hyperledger Technical Steering Committee. I'm your chair Dan Milton, and joining me is the capable Tracy Kurtz to help drive the agenda here. What you saw earlier was part of our governance process here that we have to keep this a constructive community. The other thing, one of the other things that we have is our code of conduct, which is just one of the other tools that we have to help make sure that this is a welcoming community for everybody to participate in. If you're not already aware, we also sometimes have some chat dialogue going on the chat server, which is chat.hyperledger.org. And in the TSC channel, sometimes have some conversation going, and I've dropped the link to our code of conduct in there. I think we've got a fairly full agenda today with some topics around our upcoming meetings. And then we've got some new business to discuss for a social impact working group, and then some updates before that from some of our working progress. So I will hand it over to Tracy here to hit the next item on the scheduled agenda. Yeah, so the first thing on the agenda is to talk about the meeting that we have on October 4 that we have scheduled. Since we have the hack fest at the same time, we're suggesting maybe we should cancel that. And so just wanted to get the TSC's view on that before we went ahead and did that. So maybe do we have anybody opposed to that? It sounds like nobody's opposed to canceling the meeting. Just to be sure, can we get an aye for everybody who agrees with that from the TSC? Aye. Aye. Aye. Aye. Aye. All right, great, thanks. So we'll go ahead and we'll cancel the October 4 meeting. And we'll definitely all be connecting at the hack fest. Speaking of the hack fest, we do have the event reminders here. So on October 3rd and 4th in Montreal, we have a hack fest. The registration link is available as well as the agenda. We do have a little bit later here to talk about maybe the agenda a bit more because there's still not a lot of information in there, not a lot of suggested topics. So that's something we'll want to do. We also have the APAC hack fest that will happen the week of March 4th. Obviously, details coming soon on that. And then, of course, the schedule has been announced for the Hyperledger Global Forum that's happening December 12th through 15th in Boswell, Switzerland. So with that, I guess the next item on the agenda is to talk about the hack fest that we are going to have in Montreal. So let me go ahead and post the link in the TSC chat if nobody else has beat me to it yet. And maybe we can talk about some items that we want to add to that. I just dropped that in there, so we're good to go. Thanks, Todd. To kind of get some of the conversation going, I think some of our dialogue in the past, and this is captured in the preamble and the agenda there, is that we want to make as much use as possible this face-to-face time for interproject and interworking group collaboration. We don't want to do that to the exclusion of helping to ramp new people that might be joining for the first time at that face-to-face gathering, but we want our first priority to be making headway on some of our work and maybe a little bit less so on pitching, if you will, to new parties. Something that I didn't get around to adding to the proposed agenda topics yet that we have had a thread on is test nets. Silas, during his project update, had said a good bit about what would be valuable for the Burl Project, and that's how we chime in on the thread with some ideas about what kind of an application level test net would be. So I think we could have some good dialogue there about what could be supported from the hyperledger side from infrastructure and outreach and so forth and what would be constructive amongst the projects or just individually for each project for making use of that kind of environment. Yeah, Dan, that's also part of the discussion of the future of the bug bounty, because this is test nets for testing, for also, it serves a security purpose as well. So I'll loop back with you. Maybe we can broaden that discussion also to the future of what we're going to do with bug bounties and our security program. Yeah, completely. Are there any other general concepts around what we would be discussing face to face, short of just the individual topics that people are about to throw into that on the conference agenda? I may want to lead a discussion on designing for containers, make things a little more portable. If you use Docker and Docker as a feature of your architecture, then it really limits what you can do on Kubernetes-based platforms, because you end up working outside of the Kubernetes framework. And I know Red Hat views that as a big security hole. So I might want to engage in conversation with people if they're interested. I don't know if that's a separate topic or just informal gathering. The CryptoLib team has discussed in the last couple meetings about we're putting together an agenda for the Hackfest. So we're going to be covering a number of topics there. And it's one of our key collaboration projects where we're trying to get adoption across all of the platforms. So we're seeking to have the broadest base of participants in those discussions as well. So maybe I'll drop the link. Or maybe we can, hey, Hart, can you drop the link to our agenda? Didn't we start the agenda documents? Sorry. Anyway, yeah, CryptoLib is going to be a big topic there at the Hackfest as well. I thought that out. I don't think so. Go ahead. I was just going to say, I don't think we have a proper agenda yet. That's why I laugh, because it's like, oh, yeah. We haven't started that yet. We've just been discussing it in a meeting. I think you were supposed to do that, actually. Yep. Sorry. That's my fault. Yeah, somewhat associated with this, we're looking for interest in whether or not this idea of an off-ledger identity wallet that comes from how credentials and information that's signed by the ledger is exchanged off-ledger is something that has interest as a generic project outside of Hyperledger Indie and whether we should spin some of that project out to make some of those components more reusable between the blockchains. So we'll probably be discussing that as well at the Hackfest. That's definitely interesting to me. Another thing I'd like to throw out is some of the projects have had their core maintainers have faced-to-face meetings on their own or off to the side. And Hackfest may be a good opportunity for core maintainer groups. I know it'd be hard to get everybody there, but if there was a critical mass there to do release planning and open that up to the group of people who are likely to become maintainers or potentially could become maintainers, just to get things done face-to-face that normally are harder to do over email or a phone. And I know it's only a couple weeks away. Would it be difficult, given the time frame, to pull even a simple workshop on gender diversity? I know from talking with my significant other, many things that I consider trying to be inclusive are actually exclusive. So I didn't know where we are in that regard if we hold that up for something different. But I think some training would be good for many of us white middle-aged males, at least for me, because things I do, like, hey, a bunch of us are going out for a drink after work. You want to join us, actually, becomes very exclusive, I guess, even though you're trying to be inclusive. So I didn't know if that would be something worth teeing up or if there's not enough time. I think it's an important topic. I think that because it's important, it might not do well to rush getting something like that together. And since we only have less than two weeks here, might not be able to organize something that would be effective. We do, though, I want to, say, have some discussions planned within the members meeting that goes ahead of this hack fest to help look into some of that. Well, it sounds like discussion around this topic is pretty well covered right now. So encourage people to get into the hack fest document itself and get some things on the board. And we can finally move on now to resume our discussion on the community health work group. So I guess Mark's last comment there was kind of a nice tee up for that. Where we left things at last week's call was maybe rather than pursuing a working group that we might splinter off some of this into something of a task force on the one hand. And then maybe some things that are more rote counting of commits and that kind of thing that could be automated, maybe that goes into a lab for some scripts. And then we did continue this conversation over email. And one of the things that I think was salient there was a lot suggesting that maybe the governing board might be a good place to turn some of this discussion to particularly where I was raising suggestions of including stakeholders like human resource specialists that that might be a bit outside of the normal scope of the technical steering committee. And Dan, I wanted to also bring up David Boswell's email. He's unfortunately speaking of community health. He's unable to join these calls just given his other responsibilities in life. So he always listens to the recordings. But his thing and one of what he was thinking about was a task force could take problem statements from the community and really provide a problem statement, do some research on that problem statement, and then provide some recommendations for the larger audience, the larger community, or specifically to the community that asked for the specific help. Obviously, I think it probably makes sense generally to share that amongst everybody because everybody may have the same problem that exists out there in the community. So I think that's where he thought maybe this task force would end up going is maybe a mailing list or even on the TSC with some sort of hashtag where we could suggest problem statements as well as then have a small group of people go off and research that problem and provide recommendations back to the larger community. Yeah, thanks, Tracy. I think that with David Barrett, there is probably a well-contained scope for the first task force looking specifically at that geographic diversity question. Regarding the idea of collecting metrics and forks contributors, stuff that happens to be measurable, I would guardedly think that that might be a good idea. So if you take the comparison between ops measurements, sometimes you don't know where a signal might exist. So you just throw everything into a bucket and see what you can end up graphing. I think the danger with that is we'd have to make it clear that it doesn't make the question that these are pertinent things to be measuring because often you end up overvaluing things that haven't been measurable. I think it would be interesting if people were able to do dumb automatic metrics as a parallel track, that then maybe the specific task force could then see if there are correlations or things that could be drawn out of otherwise fairly dumb data. I mean, if we can get stuff off GitHub, or if we can get stuff off mentions on chat or ingest this kind of stuff, at least that data would be there then to. So I think I've lost a little bit of Silas's audio. I don't know if that was complete for everybody else. Yeah, I think Silas was saying that maybe, and I think this was something that we were thinking when we initially suggested the working group, right, that he thinks a group of people to go off and figure out the sorts of metrics that might provide useful data. Obviously, we don't want to collect all the metrics in the world, but we do want to collect some metrics to allow us to determine how things are going. And so just from the last meeting, we had suggested a lab as well, and that lab has been created. But I think it is definitely a good idea for a small set of people or a set of people to come together and figure out what those metrics are that we should be focused on, that this would actually end up leading to some sort of value. Yeah, I think when it comes to commit statistics, that's pretty straightforward and non-controversial. When it comes to things like demographic statistics, then we're in a more sensitive ground. And that's where I think getting some charter from the governing board and the right kind of talent involved that understands what the rules and regulations are there is an important scenario. For all this talk about statistics, can someone help me? Can someone give me some idea of a non-obvious statistic that you'd want to compute? I think on my side. Go ahead. Sorry, I don't know about non-obvious, but something that is interesting that isn't that I sometimes look at in a sort of manual way is looking at commit on forks ahead of masks. So how many people have forked my code or some code and added non-trivial commits on top of it, for example? Well, I think that we can get to some more obscure statistics or things that would be helpful. But even if we just had kind of a common set of simple statistics that we were helping the maintainers to look at and understand their trends over time, I think that would be helpful. Not all the projects are tracking the same numbers. And it's not about trying to get people to focus on the numbers, obviously, because numbers can cause some anti-patterns inside of our communities, but at least getting folks to realize where they are in terms of diversity of contributors or growth of contributors will help us, I think, address some positive behaviors. I have a high level question related to the change of name from working group to task force. I'm not completely sure what is implied by that. Yeah, I was gonna kick off some discussion about that as well. I think some of the feedback that we got on the original concept of a working group was if we're going to include non-technical topics, then we're kind of stretching what the original premise of a working group was for some people. So maybe something that's a little bit different would be appropriate, but I think we don't have any definition about what a task force is versus a working group. I know that Chris had some thoughts on this. I think it might have been Chris that was suggesting the term task force and maybe he's got some specific thoughts on what that structure would be and how that would differ from a working group that would be interesting for us. I'll add just a few minutes more to talk about this before we should move on to the rest of our chat. Brian's been putting some stuff in the chat. I don't know if people have seen it. He is having problems connecting from China. Okay, so for what it's worth, I think what you just talked about then makes sense to me. If we want to use a different term just to say, this is not the usual technical working group and we kind of keep that line moving forward. I think that's reasonable. Yep. No, and that's really what I had in mind is I don't have a problem if we have something where we are looking at, okay, so what things do we want to measure as a function of, again, I mean, I fell last week that we could do it with just a lab and then it's just a project that people are collaborating around, but if we want to have a quick task force or something that is making specific recommendations, I think that's fine too. I just didn't think that a full-blown working group is really the right thing here. Yeah, and just to second that, it feels like most of our working groups are focused on some form of external deliverable and this one is really about our own internal health. It feels like a different kind of beast in some ways. It may be that the working group's structure is the right way to do it, but it just doesn't feel like the same kind of project. And we need to make it to... The field influence meter is measured. Yeah, the thing that would make me want a lean towards working group is I think this is an evergreen topic, just like architecture and identity. This is the kind of thing that, you know, well, there's probably an associated body of code in the labs, but you know, this is something we know needs to keep coming up, something that, you know, it deserves a space. Whereas I think Task Force comes across as, hey, here's a specific thing to do and then it's done and we wrap things up and go home. So in the interest of time today, why don't we do some more thinking and if there's something more that we can report on the mailing list, let's do that. And then when we speak next week, maybe we can have some more concrete ideas about the structure of a Task Force which is a working group or we'll get more comfortable with this being part of a working group and still acknowledging some of the legal requirements that would come into play for, or our ignorance maybe of legal requirements that would come into play for diversity metrics. So with that, I think our next topic is the quilt update. Hi, can you hear me okay? Yeah, can you hear me, thanks. So not a lot to report this quarter steady but slow progress. One of the core maintainers who was very quiet, last quarter has a lot of picking up. Again, this quarter we had a good few calls where we did a lot of issue triage and clearing out of old stuff. We've covered a lot of technical debt catching up on unit tests behind a lot of what's there and we have one additional contributor, a former Ripple employee who now lives in, I think he's living in Cambodia or something in the jungle somewhere but he still contributes to a lot of open source and is interested in getting involved. So he has started by doing quite a few code reviews for us, very detailed reviews which has been very helpful. And then recently one chain reached out and have expressed an interest in getting involved. So Tracy has sent them an invitation to our next community call just next week. And that's sort of where we are. One thing worth mentioning there has been some work on a go implementation of the ILP stack that's being done by someone at Coil, my current employer. He's been sort of doing it as a side project. I'm hoping to encourage him to incorporate it into the project so we can continue to see Quilts as the home for various implementations of the different protocols. So once he's comfortable that's sort of ready for a release I'll see if I can persuade him to include it into the Quilts project. And that's it. Okay, thanks. I apologize I didn't get a chance to do much research ahead of your update. That's partly my fault. I apologize, the report was only finished today. Okay, thanks. My recollection from your last report was that you were going through some challenges with some of the initial planned committers dealing with some other priorities. And so what I'm hearing you say now is that it's maybe a little bit of an uptick back in the right direction for you over the last quarter. Yeah, that's probably fair assessment. I think we're still struggling with resources. You know, we've had a few conversations with various people within the fund the hyperledger around how we can get other projects involved. It's really just a challenge that mostly because of my personal and the other core maintainer, David's other commitments. You know, we're very stressed. So it's difficult to attend too many of the events and so on. I'm in Cape Town as well. So travel is quite a big issue. Could you remind us the intent of your scope? So currently the scope is to produce basically implementations of the protocol stack for the interledger protocol. So the reference implementations were written in JavaScript by the original team behind the protocol work. Those have stabilized somewhat and we're looking to produce alternative implementations that are useful in other stacks. So Java and Go, I think are good focus areas because then they potentially can be incorporated into chain code and so on into their hyperledger project. But the main focus is for someone to be able to write an application that uses the protocol on whatever stack they're using. And then so doing, we can start to demonstrate the protocol's use over a variety of ledges. So Adrian, this is on. Adrian, I just had a click through onto your intellectual slash go ILP. I get a 404. Hmm, I was looking at it earlier. Maybe he's moved it. Yeah, that's no problem. But I'd be interested if you want to dump a link in TSC. No, I still see it. Maybe I pasted the link incorrectly. Sorry. I'll post it in here. If I go here now, I'm definitely seeing that. Yeah, get a 404 too, right? Oh, maybe, I think you may have it. It's still private, I apologize. I will, I'll chat to DJ and see if we can make that public. So could you tell us where you are with the standard effort or standardization of the protocol? So there's been a lot of work on cleaning up the what we call the RFCs and the documentation. If you go to the interledger, so that same URL slash RFCs, you'll see that a lot of the old stuff that was prototyped and worked on over the last few years has been removed from the list. There is significantly shorter of documents. There's a bunch of new ones that have been captured. So some things like the configuration protocol had been prototyped but never documented as have been captured. And I think in general, most of these specifications are stabilizing. So, you know, they're being used as the basis for alternative implementation. If you're talking about standardization within standardization bodies, yeah, we haven't really pursued that any further. As I think as I said last time, it's difficult to identify the right forum for that. Yeah, I know and I remember the story and I feel for you because I know you have quite different venues and not really found one that was welcoming enough for supporting enough. Well, it's kind of because we're in a weird crossover space right between payments and what feels like should be IETF or tech, but it also has a whole payment aspect. So our approach as it stands is we've documented what we believe the standard should be. The documents all open. So from that perspective, you know, a lot of the recent specification work has actually been done by community members. There's a guy from the Intellegio User Group in Japan who's done significant contributions to the documentation over the last few months. And if there's a standards body who wants to pick this up and we think it's the right place to do it, you know, it's very much a community-driven thing. Anybody who wants to put resources behind it and make it happen will probably be able to steer the ship in a particular direction. All right, thanks. Okay, thanks, Adrienne. I think it sounds like, was there another? No, that's it, thanks. Okay, well, thanks. So next week we will hear from Calliper. And then next up today is the Performance and Scale Working Group, and I think Mark is ready to discuss that. Yes, good day, everyone. I had sent the link out on Monday, so hopefully people have had a chance to review it, so I'm going to do in-depth. Essentially, we have sent our metrics documents off to the Hyperlegio Design Team. Gordon, who worked with us as a technical writer, has done a great job in giving out some good suggestions. And he's managing the process from here out. So hopefully we can announce this in Montreal. I don't know if there's plans for that or any of that. I guess Brian or Tracy, do I work with someone on that or how does that happen? Yeah, so Mark, I knew we've been working with Meredith and Gordon on the white paper to get that done. I think what we're looking for is a gay or nay from the TSC as to whether or not we think it's in good shape, the same way we've gotten approvals for the white paper working groups, white paper. And then once that's done, we can let Meredith know and she can work with our creative services team to actually get it into some sort of Hyperlegio branded white papers that we can actually release on the web and wherever else we want to release it. Okay, thank you. So the main issues we've had is basically related around geographic diversity. The folks that were in APAC that had joined earlier tended to drop off once we got the caliper project up and running. And I realized the time zone is bad for them. It's like 10 30 at night when they have to join our calls. I had sent an email out to the performance and scale working lists, asking if there were better times or anything or trying to find a solution to help pull more people in. And there was one person from Australia that responded that said that it was a barrier to entry for him but that he had moved on and wasn't interested in the performance and scale group anymore. So we never actually moved the meeting or anything. But in general, I think this is part of the bigger discussion for the community working group or whatever we're gonna call it. So once the metrics document is going out, this is version one. It is designed to, we could probably keep working on it for another year if we really wanted to, to get more in depth and more examples. But the goal was to get this out given the wide variety of implementations. Some of the descriptions are not as in-depth as they could because while they may be great for fabric, they wouldn't be valid for sawtooth or similar type of things. So some of the definitions may seem watered down, but they're, they work across everything we could think of. And that was the goal. After this, we're gonna start with use cases or workloads basically to get more in-depth. We'll probably be a separate document. We'll determine that as we see how the work goes versus a new version of the other document. And this is an area where we could, you know, more people could join who have more expertise in specific use cases versus overall architecture of, you know, one of the frameworks or something. But, you know, what's more important for IoT or a low latency or things like that and get into what the key measurements we think would be for each of those different type of workloads and maybe variables you could play with, things like that. So questions. Hey, Mark, it's Mick. I gotta, so I deeply understand the difficulties in coming up with the consistent set of metrics across the platforms that way. And just first wanted to commend the group for all the work that it's done over the last, what, year, year and a half. That's been fantastic. So. Thank you. So one question that I would have on that is, and again, this goes back to some of our notions about umbrellas and multiple platforms and things, as you've gone through these metrics and trying to sort of force fit them together, would it be more natural to identify sort of taxonomies of platforms and sets of metrics that go along with those platforms? That is, has your discussion uncovered sort of some differences that we should be talking about as uniquenesses of the platforms? Yeah, I believe it has. And I'd invite any other PSWG members to hop in and answer here as well. And maybe that's something we should look at doing. Or get, you know, and maybe we can pull that out when we get into the workloads. Yeah. Go ahead. That was something, sorry. No, please silence you first. Yeah, I just wanted to very much plus one on the word taxonomy is exactly what I was thinking there. I think that I think the document has got some pretty interesting divisions there, but I think maybe if we could see front and center a little bit more, be a bit more specific about the trade-offs that are made in terms of the systems model. So for example, like terms like network threshold that is used in this, basically mean a portion of noting an eventually consistent setting, whereas I was thinking of that was a kind of saturation load and how that, I think there is something around the dimensions of like for now, full asynchrony, lottery mechanisms, which you do mention. I think it's kind of coming out, but I wonder if that could be, I'd like to see that further definitions where it's like, so that we are comparing apples with apples. Cause I think there are quite different models that, for example, the consensus algorithms work under. Yeah, it's funny that you lit on that because what I was about to comment on was that what became a running joke within the working group was trying to define commitment and finality. And that occupied a great number of discussions and frankly, fairly circular discussions. What we, one of the last things that we did was we got some diagrams that we faced mostly on the PDFT diagram out of the Castro. Those are in the appendix. And I think what that brought to lighter that discussion is that it's very difficult to look across all the options and have some common verbiage around what that means. And so what this represents right now is the closest, or the best rather that the working group could come up with that would work across those definitions. And Dan, I guess my question would be this, do you feel like it's a natural, and okay, this is a loaded question cause I'm very aware of the kind of discussions you've been having on this. Are the metrics natural for these platforms or does it make sense to sort of step back and say, wow, what we've really discovered is that there are two different families of things here and that maybe we should be focusing on maybe the metrics provide us with a way of differentiating between the value statements for the different platforms. That is in a way what you're doing with the metrics as proxying for value for a particular performance. Well, I think one of the open questions that we were looking to hit in the next round of paper is the impact of faults in a workload having a sort of fault node that can be measured. And that's gonna come to bear pretty directly on what I think you're alluding to with the dichotomy of consensus mechanisms out there between voting and lottery based. Well, and by the way, my intention was not just to focus on consensus, then that's an obvious one that has some implications on finality. But sort of the balance between compute for transactions and decentralization for attack resilient, let's see for example, they have very different implications for system architectures, but also for their metrics and a particular platform maybe trying to optimize for a particular set. And I just wanted to make sure that the ability to capture those sort of unique, capture both the comparative metrics and the unique metrics. So anyway, that just struck me when I was reading the metrics document was just that there is both an interesting problem of bringing things together into a single representation but also an interesting opportunity for characterizing distinctiveness. Yeah, and I hope we got some degree of that. One of the things that you should see there is that some of the metrics should be conveyed in the context of the size of the network where we define the size of the network to be kind of the limiting effect on availability. So if you were to stand up like a one node network that should be conveyed in those results because that's probably a not very tolerant network. Right, okay. So a second question Mark that you brought up was this connection with Caliper and the impact that Caliper's had on the project. Can you talk a little bit more about what is the relationship given how important Caliper is for actually doing sort of an implementation of these things. Can you talk a little bit more about the relationship between the working group and Caliper? Right now I don't know that there is an official relationship at all. Caliper, we sort of stewarded it towards getting released as a project. We want to make sure we had the definitions down fairly well before they went off and implemented something. But I think Vip and May have played with Caliper a little bit, but I don't know if anyone else on the team has. I don't know, I haven't heard anyone on the call speak up and say they have attended the Caliper calls or anything. So right now that's something I need to, I'll need to make sure I get involved with. Okay, thanks. There is no formal relationship, but we do have the data from, you know, not just the data, but the methods that they use informing some of our discussions. That's for sure. And of course, they were part of the, they were definitely ushered into Hyperlegia through this working group. But you know, I think Mark is saying that the timing may be the problem with those people attending the call, but it may not be that they would attend the call. And in response to Mick's first question, there are two things here. One is when you're deciding on using a particular platform, having come, coming into it from the outside as a user, you need some framework in order to even compare the different DLTs. So in that sense, we went ahead and tried to tease out the common metrics that we could use. But of course, we ran into all of those problems, which is, you know, the finality versus, you know, all the problems related to the differences in the value propositions, like you say. But I think the second paper that'll come out of this would weave all that together in some way, because we are going to focus on use case scenarios, in which case the differences in these platforms and the target use case would become a lot more focused. And I believe that is, you know, so in the first case to develop these metrics, you know, as objective quote unquote, objective metrics that lays across every DLT. And the second would be to bring out the differences in terms of the target use cases. Thanks, Vipin. So one of the things I recall hearing on a TSC call within the last six months maybe was, I think it was Brian saying he didn't necessarily want something that was out in, like, the initial thought I had was at some point we get to where here's the characteristics, here's a selection guide you could use for your, you know, for what you're trying to solve with a blockchain. But I thought I heard Brian saying he didn't really want something that compares the different hyperledger projects to each other. And it may have been in a different context, but so I, you know, I'm all for having something as a selection guide, but I don't know how other people feel. I, you know, it was more that a naive comparison that said, you know, one project is always faster or tends to be faster without, you know, really characterizing what that is or quantifying it, what I thought, and tend to engender tension between the projects. But where projects have invested in performance tuning and have some novel characteristics, I think it's worth being objective about it. It was just it's, you know, people on the outside always want simple reasons to pick one over the other. And I kind of don't want to give them speed as one of those simple reasons unless, unless generally there's one built for speed that is defensible by metrics, you know. Okay, thank you for the clarification. Any other questions? How do the TSE members feel as far as going to a vote today to adopt this draft? People feel like they've had their opportunity to review and get feedback. I'm all for it. Yeah, on my side, I feel like the paper reflects a lot of the things we've talked about in the architecture group, pretty happy to be here. Yeah, I've been through it a couple of times. I'm good with it. Yeah, it seems fine. Yep, good to me. Okay, great. Tracy, should we do a vote? Sure, so all those in favor, say aye. So, by accepting it as a draft, does that mean that there can still be amendments or additions made, particularly in terms of definitions? Yeah, absolutely. Our intent is that we would, as a working group, this would be like a 1-0 draft of this document and then we would push out amendments after we've gotten some community response so there could be like a 1.1 of this document when we make data amendments. Might be worth just adding a caveat or a blurb to that effect. This is actually, so you do bring up a good point that we are looking for feedback and there may be some modifications as we go forward with something like this. People are gonna be looking at it almost like, you know, with the same way that they look at some of the other performance and benchmarking organizations like SPEC and so forth and we're not there yet, right? And so it might be worthwhile saying we welcome feedback, something like that in the intro. Yeah, I thought that we had verbiage in there. I don't remember. So if that's the case, that's fine. Okay, so with that in mind. So Casey, there are still some comments. I just look at the doc here. There's still some comments on the document itself. Are we going to resolve that those first before we have a vote here? So I think what we had decided at the working group was that we were gonna do more or less a feature freeze like what we would do for a code drop and know that there's some maybe some suboptimal things like in particular that thing that you've commented on with the difference between reads and queries. Yeah, that could be cleaned up and we probably want to clean that up in a 1.1 because they're more or less synonymous or interrelated there, but there's not a substantive defect there that should delay this version. Yeah, I mean specifically to my comments, but I see there's a bunch of other questions, some from Casey, some from someone else. If no answer to these questions fly to the person who asked the question, then that's fine with me. I'm just asking the question in general. Yeah, I think just the aspect of it being in open document is that we resolve things continuously and so we're at a point now where further resolutions would be assumed to be graphed. Okay, I'm very good with that. Okay, thanks guys. I guess we'll be clear then. So all those in favor of this being a 1.0 release of the paper with future changes to come, I would also add and the caveat that that the comment about the wanting feedback be put into this before it becomes 1.0. All those in favor of those caveats, say aye. Aye, aye, aye, aye, aye, aye, aye, aye, aye, aye, aye, aye, aye. Anybody opposed, say no. Aye, aye, aye, aye, aye, aye, aye, aye, aye, aye. Any nay. In favor of opposing it, say aye. It sounds like we passed unanimously anyway. I think that's good to go. We'll call this 1.0. Mark, do you want to check and make sure that comment is in place and then we'll we can get back to matter, sniff then Alison. Yes, I will make sure that that gets put in there. Okay, great. Thank you, everyone, and thanks to the team for all the hard work. Yeah, thanks to the rest of the working group. It was over a year of effort there. Nice job, nice job. It's uncomfortable times for them to join that call a lot of times. We can take this weekend off. Okay, so we are down to about three minutes or less here. I don't think we can have a good discussion about the last two agenda topics. So what I would ask is that people review the social impact working group and also think about more broadly what we want to be doing with the working groups. Some of what has come to light in the discussion about the community health working group is whether and how we want to address non-technical working groups. And think about what the implications of that are for the the resourcing support that we get from the Lex Foundation as well as the time that we spent on the mail list and in this call in discussing those topics. And then while we won't have time to discuss it right now, I wonder, Dave, if you want to just tee up some of what people should be thinking about over this week for the bug bounty discussion. Yeah, thank you, Dan. So the discussion would I posted to the mailing list a report on our past year of our bug bounty, how it went and the successes that we had and some of the problems we had. The I was just going to field questions related to the report in the mailing list, but then I wanted to have also the discussion about our future direction. There's significant money to be spent here or to not be spent here. And I made my recommendations in the mailing list. We can go into more of that when we have more time, but thinking forward. Do we want to continue to spend, you know, thousands of dollars with hacker one to provide us with like triage and management services, knowing that we do have an all volunteer security team that is more than capable of doing all that. So we can still use the hacker one platform without paying them money. So that's really nice and they will still process payments for us and handle the money for us without us paying the money. It's just whether we want to have hacker one staff, helping out with like triage and management of reports. I mean, so, but how much have they actually helped? I mean, most of the things that have come through are, Hey, you know, I can, you know, I can hack your website. Yeah, we explicitly repeatedly said this is not in scope. Yes. As far as I can tell, we had zero help from them to squash that bullshit. And yes, well, I mean, basically they all came through and none of them were addressed and made, you know, initially by staff. Those are all excellent things to think about over the coming year. Thanks everybody. Thanks everybody. Bye.