 All right, welcome everybody to another exciting edition of the Technical Steering Committee for Hyperledger. This is Dan Middleton, your chair, and driving the agenda here will be Tracy Kurt, Community Architect. It looks like we've got a relatively light agenda today, so I don't want to keep people on unnecessarily as we reach the end of it, but we do have maybe one or two topics that we'll add ad hoc here from the time that the original agenda was published. And with that said, if you want to take us into the event reminders, Tracy. Sure, definitely. So first off, we have the HatchVest is coming up next week in Montreal as a reminder that does conflict with our TSC meeting, and last week we decided that we will not be having a TSC meeting next week. So our next TSC meeting will be October 11th. We also have the APAC HatchVest is coming up the week of March 4th. We're still working on all the details here, so those details will be coming soon. And lastly, we have the Hyperledger Global Forum in December in Basel, Switzerland. The schedule is announced, I believe. We just had an announcement that the prices are growing up, so if you haven't already gotten your ticket in, maybe now is a good time to think about that. I think it's either the end of today or Monday. I can't remember what the day is, but it's soon. So, you know, if you're interested, have a look at that. Yeah, I think the announcement that I saw was the 30th is I think the last date for registration. There you go. And it's not the last day for registration. It's the last day before the prices go up. The last day for cheaper registration. Exactly. All right. So the next item on our agenda then is the I put on the HatchVest agenda planning. I know we did this last week in the call and we got a lot of great proposed topics. Want to make sure that we have some time just to if there's anything else that needs to be proposed or also to remind people that if they have proposed topics, they can start slotting those into the agenda as well. So again, the Montreal HatchVest next week. So that's that particular item. Yeah, it looks like kind of on cadence with normal as we approach the dates, the agenda starts filling itself out kind of quadratically. So it looks usually pretty empty as we were a few weeks out. And then as we get close, it starts to fill up and it looks like we've gotten a lot of topics added since the agenda was fairly empty this time last week. I also threw on started to throw on some some ideas for just fun time afterwards, which is not as important as what we want to accomplish while we're actually at the meeting proper. But it is, you know, fun part of being in the community. So feel free to think of things for after hours, things as well. All right. And I think if nobody has anything to add on that, besides what you can do offline yourself with the document, we can take a look at Caliper. I noticed as I was checking for the update earlier this week and then up through this morning, it does not look like that has been filled out. Do we have anybody from the the Caliper team on a call? All right, I'm going to take that silence as a big no. So for the rest of the steering committee, I just want to observe that the Caliper project when it was added part of the part of the guidance was that that they should be working closely with the performance and scale working group. And I don't think that we really saw that happen. Things fell away pretty quickly. And as I observe the the repo headed into this, I also don't see a lot of activity there. So that does make me a little bit worried for the health of that project. I saw Mark is online. Maybe he can give some comments. I was, you know, just just getting ready to say something, but thank you. No, Dan, Dan's been very active in the performance and scale working group as well. And so, yeah, we haven't heard anything back from Caliper whenever we ping them. The other comment I was going to make is I don't know if we as a TSC, you know, for the agenda, we should send out something more official to like each group that they need to report. Add it, you know, you need to be on the TSC call, because I don't know if anyone on the Caliper team actually comes to the TSC calls or is on the TSC mailing list. If they're not, then they're not going to see that they would do for a report today. Yeah, that's a good point. I kind of wonder if a basic expectation for maintainers of a project or leaders of a working group is that they're subscribed to the TSC mail list. Yeah, and I just want to add yesterday I was on the Caliper contributors chat channel and I did put a reminder out there for that. And I've also seen on that chat channel a couple of folks who are requesting to become committers for the Caliper project. So, you know, I don't know so far. We haven't seen a response back to that request from the Caliper community. Maybe we need to reach out via email and see, but definitely something to keep an eye on. And back to something you said earlier, Dan, initially when the Caliper was trying to become a project, they were placed under the PSWG for, you know, to sort of shepherd them through the process and wait till things were synced enough that it was appropriate. At that point, my belief is that, you know, that that relationship or guidance sort of ended. I'm happy to start that up again if we think we should do that as a TSC. Just as a general comment, is it possible, perhaps, that we require the reports to be early and have people confirm that they'll be at the meetings before we put updates on the meeting agenda? Because it seems like we get a lot of, you know, missed or late updates. Yeah, so if you look at the project update schedule, you will see that project updates are supposedly due on Monday before the TSC call. That has not really been the case. Most of the time, we've needed to send out reminders. So I'm perfectly fine with that. It was the original intention. So yeah. I mean, I think, and I chatted with Todd about this a while back. This is Chris. I think that it's, in fact, likely people are not subscribed to the TSC mailing list. And they don't get these notices and they don't see this and they just forget. And so I think that we need to make sure that we're doing you know, that we're not sort of, you know, pretending that everybody is tightly, you know, paying attention to what's going on at the TSC. A lot of people just get focused on doing whatever they're doing with their projects. We do ping people one on one. So it does go out in the agenda the week before it's in the wiki calendar. And then we reach out to people through email and through chat. OK, good. I mean, but so OK, that's interesting. I did notice that the caliper commits have subsided since about August, but that's summertime and, you know, I don't know if that's a function of the project's health or what, but it had been pretty active up through July. Maybe we can add the project maintenance into the CC list when sending the TSC meeting agenda. I feel like there's a lot of already active outreach. So like Tracy and Todd have mentioned, there's there's a lot that we don't see that the community architects and the rest of the Linux Foundation staff are doing to to reach people directly. And certainly send out some some notice afterwards that that we've got some expectation that people are subscribed to the TSC. I think that, you know, we can be somewhat accommodating to the fact that people are focused sometimes on on, you know, what they're trying to actually do for development. But, you know, if we see something repeated where where people are basically going dark, then that does seem to fall on us as one of our responsibilities. So, you know, I don't think we're there yet with caliper. Like Chris mentioned, the commits have fallen off and they're not here to give their updates. So those are definitely flags, but I expect that we will see some of them at Montreal next week. And so maybe we can we can figure out what's going on at that point. But, you know, we can we can certainly be thinking before our next meeting, what our options are, if a project does go completely dark for some period of time. I have to say, I've been quite surprised at the number of teams that haven't turned up with updates. That's really quite surprised me. I mean, my expectation is that people would at least let you know if they're not going to be setting up. And, you know, it's understandable if people are busy, but like not even turning up is kind of surprising. Yep. OK. So I think we probably need to be labored at more. Well, one quick comment, if I may. Would we want to send mail to the mailing list for each project rather than the chair in case the chair is on vacation or something? Then other people in the team can see it. It does seem that having some sort of policy as to what the contact mechanism is to not just the maintainers, but to the projects as a whole would would be good. Though I would echo Dan's sentiment that the staff and the community architects have been doing a great job of reaching out individually, and that's been really helpful. OK. I think Mark's suggestion to mail the mailing list as opposed to individuals actually kind of makes a bit of sense. Yeah, I agree with that. So, yeah, let's let's do that. But let's also maybe start to set the expectation with with projects that they are subscribed to the TSC list. It seems like we're maybe a more cohesive community if we're all at least attached to one common communication channel. All right. Well, we do not have a working group update for this week. After we get back from Montreal, we will have an update from the health care working group. And we've got a last minute agenda item for them at the end of today. But next on the list is the bug bounty discussion. Is it looks like Dave is on to to help take us through that? There's my mute button. Yeah. Hi. Good morning. So we've had a discussion on the mailing list over the last couple of weeks about what to do about our bug bounty with hyperledger or sorry, with a hacker one for the next year. The choices were to continue paying them the money that we did for paid support and also to drop down to just doing email support, not paying them the money and relying more heavily on the security team to handle triage. And it sounds to me like the discussion went in that direction. And I think that's appropriate. I just wanted to open it up to questions for right now and then ask for a quick vote if we're all kind of in agreement. So is that the absolute lowest cost way that still keeps us some connection to hacker one? Well, we'll still have connection to that. Like, we'll still use their platform. We still have all of the tools that we have been using in, you know, over the last year. It's just that when reports come in, nobody on their staff will jump into triage and handle everything. We can use their platform. Well, yeah, I agree with you, Chris. Yeah, so we had like twenty two reports come in. Only three of them were valid. They sort of headed off some of them. Most of them, I said, you know, hey, your scope document. So yeah, I mean, we wound up handling most of it. We paid them because we assumed that there would be a lot of reports. And I was hedging more on in a conservative way. But it turns out, you know, we didn't really need it. So that's why my recommendation is to just drop down to email support. Yeah, that's yeah. I was going to say, we've made good friends there. So if we need help, we can ask. It's it's not like they're it's adversarial or anything, right? I don't I don't anticipate us needing any help, though. And it would be great for us to solidify the security team through, you know, action, I guess. So yeah, any other questions? Well, I mean, if there are no more more questions, it looked like we had a consensus on the mailing list. So I would ask for a quick vote to to not pay for support and to drop to email support and rely on our security team. I'm in favor of that. Yeah, I agree. Yeah, I agree. Thank you. All right. Anybody opposed? Right. Well, well, great. Anybody on the security team expect an email from me. I'm going to try to rally everybody in in Montreal so that we can all meet each other. And thank you. All right. Thanks, Dave. All right. Next on the agenda here, we have some topics to discuss around a social impact working group. I think maybe Marta will be leading that up. Seeing Marta on the thread here. And I'm sorry. As soon as I can get to my phone, I will be happy to stop normally so we can find that. Yeah, sorry for that. So the we would like to ask the Posturing Committee to review and make suggestions. If possible, maybe even give a vote over launching a social impact working group. The background for this is we've been working with several people, both members and very, very open source community of non-for-profits and connected to all sort of institutions that have social impact or work in social impact. And they've been all saying that hyperlations are a great place to incubate and discuss and do work on how can blockchain impact social social situations, how can blockchain help? We've been informally meeting or that it was actually the community driven by Rick Clarks and Alisa Worley, Rick from Mercy Courts and Alisa from Centre. So they've been informally gathering over the phone with the broad community working. Of they had a face to face last week with some of the people on the phone and some of the people on in person and Accenture offices in New York. And it seems like this movement has pretty a lot of traction. I understand that there is a discussion about where should the community work and work for under or vertical work and work for under. But it would be great to have this group approved or discussed by TSEE now as we don't want to visit wonderful momentum that we had and let them really organise themselves. They would love to have a face to face meeting and they'll all be saw or miss the other person. OK, I lost a little bit of that audio, but hopefully others got it. Otherwise what it sounded to me was was Marta was just as she was trailing off their team up the discussion for us. A lot of momentum with the stakeholders that that she's pulled together and wants to keep that momentum. I hope people have had an opportunity to read through that and have some opinions for us. So just in looking through this, this is really it appears that this is a proposal specifically for examining usages and driving those usages in a particular domain, as opposed to the sociological anthropological study of what the impact is of blockchains. And I guess I would sort of in that vein that the deliverables are consistent with that seem appropriate. But I'm kind of curious also about in particular in this domain about kind of community formation around these and should that not also be a part of enabling these kinds of systems and part of the examination. About community, I mean community of users of the tech of the usages and technologies, Marta, are you on still? Yes, I am trying to find a better spot for my internet. So my first question is just just a clarification that this really is. I think Marta has now entered the matrix. Is there anyone else who's been working with with Marta on the proposal that can maybe also help discuss it here? I think I found a better internet now. Let's try it. All right, sounds a little more stable. Great. So the first question was to clarify that this group is focused on deliverables and looking at how blockchain can help in social impact situations, like non for profits, aid delivery and so on, rather than social sociological and anthropological aspects of it. Of blockchain. Yes, this is correct. The first product that the group would like to put together is use of opportunities matrix. Seems like we've lost out on audio again. No, I finished talking. OK. And I didn't get the second question. So the second question was really, especially in this sort of non for profit, non profit and these kinds of applications, there's no one of the aspects that needs to be considered here is how that community of users comes into existence on a part of it. So I see I see a lot with the sort of applications and the potential usages on that. Just I guess my real question is what are the unique characteristics of the social impact usages and how will those be approached and addressed? It seems like a particularly it seems like a domain that's that's radically different from the great announcement that Walmart is using blockchain for doing all food tracking, right? That it just seems like a very set different set of kind of constraints on the problem. And I'm curious about how those kind of constraints will be pulled out. This is a very good question. I think that indeed it's a very different domain. It's a very broad domain and the need for this group emerged from the fact that there is no place where we could start across all of these working groups. This is something that I've been consistently hearing is a place where we can start thinking about solutions rather than just discussing the the constraints or problems and then not doing anything about it. So addressing those constraints and they are obviously, you know, things like last mile problems, lack of internet, all of the aspects of that. There are some good examples and that we can work with like the World Bank World Bank project, World Food Project as well. These are not done in hyper ledger, but or with hyper ledger frameworks, but these are some of the interesting aspects that we can look at. And I think that we have the main expertise, but both from non for profit and companies that are just simply interested in helping society that will help address those problems. Thank you. That sounds right. OK, I wanted to ask that. I think that's exactly what I was a little bit concerned about. I was just making sure that that this working group, because you're because the domain of interaction is going to be so much different, I'm really curious, in particular on the technical side of what comes out as requirements for the platforms. You know, what when you look at your at this domain, I'd like to see one of the deliverables be a report back to like the architecture working group or something about gaps that you see in the technology for addressing it. Yeah, that's that's definitely something that everyone wants to do. They want to, as you can see from the charter, they want to really work closely with some of the working groups. I think also performance and scalability will be impacted as we look at very constrained environments. But yeah, I think it's a good opportunity. Just to add to that, this is Nathan at the Sovereign Foundation. We have an identity for all council that does similar work in this space. And we've found it very helpful when they produce requirements type documentation for the technical team. And like Mick mentions, one of the difficulties that's often happened is that the team itself that's working on kind of these use cases has had trouble articulating all of the requirements that they have in a way that helps the technical team pick them up and develop them. So from the TSC side, one of the things that we'll want to watch is making sure that there are good connections between the projects and these technical reports. So that instead of them, you know, publishing them and not going anywhere that there's actually some actionable steps to support some of the things that are required. Hey, Nathan, does that identity for all committee function kind of like a conscience at Sovereign? I mean, is that where a lot of the privacy protection requirements comes out of? Yeah, exactly. And a lot of the requirements documents that they generate talk a lot about the exploitation of disadvantaged populations, how offline use cases are so important and the discrimination that occurs when you make assumptions about the technology platforms for the client code and things like that. So it's been enormously helpful for some of the requirements to the indie platform to have those folks regularly meeting and giving us feedback about what's actually happening on the ground. Silas here, my concern with this would be that from the point of view of a community of implementation projects that is social good, really a domain at all. So I mean, I think you're acknowledging that in the breadth. But I'm just wondering if we were to compare with the idea of picking a particular area, whether it's remittance or whether it's some kind of aid supply chain use case and spinning up a working group or something like that that looks specifically at that use case. It seems that might be more focused and deliver clearer specifications and relationships. What do we gain by having a single umbrella that lumps together social good, not to mention the fact that not everyone will entirely agree on what a social good is. Is there something maybe I'm missing about why it makes sense to have a social good umbrella? You know, that that's actually a good lead into another aspect that we should be thinking about right now, which is this this working group is one of several that I think are being explored right now that that we could think of as sector or vertical specific working groups, something that might be called another in other organizations like a special interest group. And it seems like a lot of the interest in these groups come from business stakeholders that can help help describe use cases and have discussions that explore the space and in a way that's that is a little bit different than what you were getting at. I think Silas on from an implementation point of view that, you know, we we want to be focused, I think, first and foremost in hyper ledger and being the place where coding happens. And so I wonder as we look at what could be a perfusion of these special interest groups, whether we actually want to codify that as a slightly different structure than the technical working groups that we have. So maybe in a way that, you know, we can enable them to grow at a lot of these working these special interest groups and at the same time not lose the part of our culture that's around development. I don't necessarily see hyper ledger as just a development machine. I think it, you know, development without the understanding the social impacts of what you're doing is a dangerous thing. Yeah, so certainly we wouldn't be looking at not doing special interest groups just that we have maybe a slightly different governance structure around these groups that that might be a degree or two removed from technical working technical deliverables. But in this case, I mean, the working groups in general are doing things that are kind of white paper based. You know, if you want to be focused on code go create a project. I think, you know, what we're getting out of the identity and architecture groups are white papers, right? Describing concepts and yes, it's technology but it's really about sort of abstracting out what's happening across other domains and feeding into the technology groups. And I see, again, I see this as exactly the kind of thing that I'd like to see more of, which is somebody that can feed concrete requirements back into the projects. And it's that relationship between the working groups and the technologies that I think we're not exploiting well enough right now already. So I don't have, I don't have a problem with non code related working groups like you described but I guess my issue is what about projects of social good making them part of the same problem space? Is there really connectivity between those disparate use cases? So Silas, too, I just- Marta, you've gone very quiet. Right now? Can't really hear you Marta. Tom. You thought- Can you dump your comments in chat perhaps? What I would add from my perspective, having watched a group similar to this function inside of the Sovereign Foundation is that these groups are quite accustomed to working with one another. They understand their use case differences and their overlaps fairly well. And it's similar to what you would see and say the healthcare working group that even though there are very distinct differences between say insurance use cases and provider, healthcare provider use cases and supply chain cases and administrative data cases, they understand the problem domain collectively and they know kind of where each use case is playing and they're pretty good about trying to make those distinctions. Though it often comes across in vertical specific jargon, I think what you'll find is this group is pretty functional in terms of trying to decompose that problem. And the reports will have some concrete steps that apply to all of them. So I don't have any opposition to the idea of kind of grouping some of that together, especially if as a technical group or an architecture group, we can give them some guidance about how to separate the problem to better map to the technology. So to play devil's advocate here and maybe it ties back to Dan's point a little bit is, do we need something different within the hyperledger organization? This is a technical steering committee and if this group is off looking at something that's not necessarily technical, do we need a different structure within hyperledger to sort of run that and the groups would still work together, but it's not purely a technical nature like the architecture group, the performance and scale group. Yeah, I think if we look at this in the context of, let's say we've got the social impact group now, maybe we've got a banking group, we've got a healthcare group already, maybe we have a supply chain group, we have a lot of things that are gonna bring in probably business stakeholders with important viewpoints, things that we do want to attract and understand, but we could very quickly become overwhelmed with those business level kinds of discussions at the expense of really focusing in more on the delivery of projects, which was kind of our original mission with hyperledger. So again, that wouldn't be excluding those activities, it would just be that maybe we wrap those in a slightly lighter governance, maybe we don't necessarily need quarterly updates from maybe ultimately two dozen different SIGs coming through that we would necessarily discuss in these TSC meetings, and still probably wanna produce reports from them periodically and we can read those offline, I understand from some earlier discussions that over in the Apache Foundation that there's quite a few projects and SIGs and working groups and that those are generally reviewed offline and really only escalated where there's exceptional cases. Yeah, I think the thing to think about would be reporting structure. I mean, the question is if there is an issue inside one of these groups, and by the way, my staff will garden these groups, these special interest groups a bit more directly than we might with say architecture identity just because we view it as pretty important that we get more users through these kinds of efforts and more use cases, more engagement with the business sector and meet them halfway and that there potentially is even value to these even if they're not driving new requirements directly down to fabric or sawtooth but simply in being able to meet many of these constituencies and the developers within those constituencies halfway so that they can map their jargon as I think Mark put it to our jargon and I think that's been useful in bringing new companies and new developers in on the healthcare side and maybe the public sector side and will be for the others that we launch but the reporting structure is still important, right? It really is, does the TSC want to take responsibility and ownership if a problem emerges something we as the Hyperledger staff can't solve directly or is there another place within the organization into which they could report kind of as a parallel to the TSC? I'll say I've mentioned it to Mark and to Dan O'Pri at the marketing committee and any mention of, hey, do you want a new job to do? Without a lot of clarity on how many hours that means how much work that actually means is not something that they let me left at but I think we can have a conversation like that. Well, the other thing that I'm wondering is does it make sense for groups like this to have deliverables in the same way that maybe technical working groups are supposed to have deliverables? I think it ultimately does because it helps keep them focused. I think if it were purely a talk shop, it would be, it would feel a little unguided. I think just for the sake of having a healthy community, to make it more than a coffee clutch or would be pretty important. And that doesn't mean it has to be specific deliverables. It can still be, we expect you to write reports, we expect you to look for opportunities when there's code to spin that out into labs or into their own separate projects, but yeah, some focus would be essentially, I think. Our experience in the sovereign community is when there's not a lot of good communication and back and forth between the maintainers and between these interest groups, either the interest groups get very frustrated, they're not being heard or the developers get very frustrated when the things they're building aren't useful. So I like the idea that there is some sort of tight coupling or tight communication, even if we decided to restructure some of the way these groups are reported, having some regular interaction helps keep these groups grounded in the technical realities and also keeps us grounded in the business realities of who's gonna use our systems. Yeah, I mean, Nate, I agree with that, but then again, to Dan's point, I mean, and maybe not everybody's in agreement on this, and that's fine, but I mean, we primarily are about building stuff here, right? And yes, we wanna make sure that we're getting the appropriate requirements and so forth channeled into the various projects, but that again, that actually hasn't been happening. As far as I can tell, we haven't heard from any of the sort of the industry vertical working groups, we need to have X, Y or Z. If it's happened, I definitely missed that. I'm sure there's been conversations like that, but again, I think the focus of the working group should be some sort of technical deliverable along the lines of the white paper, the architecture, the performance and scale paper and so forth. Those are technical deliverables and so that I think that curve falls under our purview here. I agree that having teams working groups check in and give us a readout of what's going on, that would be useful. Maybe it doesn't need to be quarterly, it may be, I don't know, but again, I mean, we can be overwhelmed with having working groups for every possible industry vertical and every possible sort of angle that somebody might wanna consider whether it's social impact or anything else. And I do worry that then we end up focusing more on the, not really the core mission of the organization. And hi, this is Leonard to focus to, sorry, second what Chris has just said, I think that's important really. It's a paramount importance that there's some output coming out of the social impact working group, for example. And that's what impacts are all about. Impacts are there to measure the effect on different aspects of society, whether you're looking at an industry vertical, for example and any gaps that are identified and any use cases to make things better. So the pain points are being observed and discussed, not measured in terms of how much, but in terms of yeah, these are the impacts we identify and how can we make things better? And that is the outputs of these working groups which then become inputs to the various projects in terms of high level use cases and impact statement, pain points identified. And from that, the different projects can sift through, analyze and determine how the projects can be improved based on these identified impacts from these working groups. So I think it would benefit us all if we construct it and report as Brian has said in the right way so that it's effective and of value to the entire hyperledger and you might say the soldier which is more or less ourselves than the TSE. Yeah, that's also a good point. And I think maybe we can start with a more general user case working group that will deliver the best practice in adopting hyperledger techniques in these user cases. And if that results in a lot of technical issues in some specific area like the healthcare or social impact, then we can equip it a new working group more specifically. Well, we had a requirements gathering working group but it kind of spun down and didn't seem to go anywhere. And I think that's partly because being too disconnected from either a specific framework or from the use cases in which they're operating meant that there wasn't really a there there, right? And we do have 10 different technology sacks now and so having a working group to collect requirements for those different pieces of technology is kind of doesn't work as well as if it were gathering requirements for just one framework. I just want, I want this group to consider that there is substantial value to these working groups if they generate content and reports and useful output, but even if they don't generate brand new requirements to the underlying frameworks. I mean, you could say it's because fabric and sawtooth are actually pretty generalized and mature that they haven't needed to drive a specific requirement yet. You could also say it's because many of these groups are still starting at a very beginner place when it comes to thinking about how to use these technologies and haven't really been able to articulate, yes, we'll need 10,050 transactions per second by next year or anything like that. But some examples on the healthcare working group, for example, a conversation about one particular use case, which is the breast milk supply chain led to a group of motivated people saying, well, let's actually see if we can reduce this down to a demo. And so there's now a hyperledger lab with CTO and BNA files from Composer and a bunch of active discussion about, how would we build this, what would it look like, that sort of thing. And so that process of discovery, that process of meeting them halfway and seeing what works, I think has been very useful for that healthcare community, even if that's something that's gonna be repeated in some respects on a supply chain one, if and when we launched that or on the public sector one or the social impact one. So I still think we need these and writing code is not enough. We need to be recruiting. This is partly about recruiting companies, but also really the developers at those companies ultimately to help us build code. Yeah, I think that's a good point. So maybe what I'd ask from the TSC as we wind up this conversation is to think before we reach Montreal or the October 11th meeting, think about if there's just a little nuance change to what we do with working groups that would facilitate special interest groups in at least two aspects. One would be let's let the recruitment effort that the staff is doing on our behalf be more or less unfettered. So they can get a lot of these, a lot of the enthusiasm from the community going without necessarily process from us. And then by the sort of the compliment of that is let's have a structure so that when there's exceptional things that need to be discussed we're available to facilitate that. But at the same time, not start to lose our DNA on development. So with that, we had one thing come on the mail list just prior to the meeting about the healthcare working group. And they're in the midst of a leader change there where the prior leader as I understood it has moved on. And so they're looking to ratify a new leader. I don't think there's been enough time for people to comment on the mail list. I don't expect from my understanding that situation that this is a contentious issue but I wanna allow enough time for that but also give it a little bit of air time here so that the ideas are at least socialized among us. Is there somebody from the healthcare working group on the call that can just tee that up and then we'll give it a week or two to percolate and then we can ratify it after that? I don't think Rich was able to join us today because I know that we had thought this would probably show up on the October 11th agenda just given the timing of when that email came out. But if there's anybody else on the call. I'm sorry. Most of the healthcare working group meetings and I can answer specific questions. Maybe if you just want to tee up for everybody the issue at hand here. Rich has been the interim leader in the last six weeks, eight weeks and he would like to make that permanent and I believe that everybody is really glad to have Rich. He is very motivated. He does a lot and as far as I can tell there isn't any controversy about it. Okay, great. Well, I think that should be pretty simple then. It looks convenient that we can pick that up at the healthcare update then on the meeting of the 11th and ratify it at that point. I would also like to point out that Rich runs the Seattle Meetup and I've dealt with him over the last six months or so and I've found he's really organized. He really runs the Seattle Meetup really well. So I know I don't have a vote but I would definitely endorse Rich and his desire to lead this working group. Thanks, Ry, that actually is very helpful to hear. And I know that Rich has also, they've discussed it within the healthcare working group. They've had it on like the last agenda to talk about as well and looking for feedback from the group and no negative feedback has been provided as of yet. So, you know, as Rain said, I think everybody's kind of okay with it, right? Not having a difficulty with Rich becoming the chair. And other people have been given a chance to stand as I understand. Yes, when Rich started talking about this, he opened it up for anybody who was interested to put their name in the hat and I don't think anyone has. Okay, great. Well, we'll finalize that then at the meeting on the 11th. Well, if there's really no one else that's stepping up to do it, I don't know why we don't just vote now. Yeah, I think the reason that I wouldn't want to take a vote right now is just that, first of all, I don't think it's going to hold anything up at the working group if it's not codified by the TSC. And then secondly, I think the first community-wide email that I saw about it was the one that just happened less than 12 hours ago. So I would just want to make sure there's an appropriate amount of time for people to respond, just in case there's some aspect that we haven't been made aware of as unlikely as that is. Okay. I see it like shareware. We get them for free right now. Let's see how it does with this report here. Well, let's hope he's not malware then. Ouch. That first update better be in on time. Rich has already been informed that there is an update. He was like, wait, what? See what you've signed up for? Right. Okay. Well, we're down to the last few minutes here. I don't know that there's anything new material to discuss on the community health working group. The two updates that I'm aware of is that there's been a little bit of discussion in the marketing committee about what we can do to make sure that we're messaging things well. One comment out of that was to make sure that all of the projects and working groups are aware of and referencing the COC that we have. I can't even remember what that means, the... Code of conduct. Thank you, the code of conduct. So that's something that we should all be aware of. And that's sort of the rules that keep everybody behaving well. I think everybody already does behave in a healthy way. But we're also beginning to looking for maybe a more positive way too, to look at how we are attracting and retaining people. And then the second thing is that the board will be taking up this discussion as well. And so maybe we'll have some feedback out of that meeting in Montreal that we can talk about on the 11th. Hey, Brian had some stuff in the chat window. If you wanna take a quick look, Dan. No, it was just really, it sounds like you didn't say it explicitly, but the social impact working group is not being voted on. Right, I think typically we've taken a meeting or two to discuss things. And I think the one issue at hand is to talk about, do we set this up as a SIG and what does a SIG mean? And that's something that I'm hoping that we can come out of. Can I urge you to consider taking a vote? Because the proposal has been up for a couple of weeks now. And that's a community that wants to get started. And we can figure the reporting structure and whether we call it a SIG or working group in parallel. Because I don't think anyone sounded opposed to launching this group. I just don't wanna hold back conversations in progress for what might feel like bureaucracy to the outside. So to say that another way of the idea is to approve, get getting the group started. They can have their channels, their mailing list. We can get them set up so they can start meeting. And then the question of how we help these sorts of industry specific vertical groups produce content that's helpful to projects and projects can be supportive of these groups is a topic we want to continue to discuss and decide how we can help do a better job for them, not necessarily just specifically for the social impact group, but in general. And in particular there are other groups that will be beneficiaries of that discussion. I like this decomposition. Dan, are you bigger? So on the unfortunately bureaucratic side though, does that still have the wrinkle of if we create email lists and so forth called working groups and then we gotta switch those to SIGs afterwards that that's just thrash for them. But that seems like a small issue for us to deal with compared to getting working group coming. If we called the mailing list, social impact and didn't put any suffix on it, then we'd be fine. I know that that would break the current model, but. No, it's very inconsistent with what we've done in the past. I know, I know. I just give them a mailing list and then say, oh, by the way, that old mailing list, forget about it. Let's go over a new mailing list. We just changed them all recently anyway, so. I say we vote for it. Let's see where everyone feels. I'm in favor of having the SIG discussion a little bit first and then maybe it's not too much of a lowdown for them if they're officially created a week or two from now. Does anybody else feel real strongly one way or the other? I think the changes that would be required to go from the working group to the SIG are gonna be small given that they're going. I'd be in favor of just, let's just see if it's what the general opinion is. I'd be in favor of voting now because I'm going to be out the next two weeks. Okay, and did you have an opinion about this, Ben? I am in favor of this, especially the use cases coming out of this as an architect. I'm always hunting for use cases. So that is really the output of this working group that I think is very beneficial for upon. Okay, well, let's go ahead and take a quick vote then contingent that on the wording whether it's a working group or a SIG. For the user case working group? For the social impact working group. I'm in favor. Okay, so all those in favor of a social impact group that will discuss it for that charter. Say aye. Aye. Aye. Aye. Aye. Aye. All those opposed, nay. Okay, I'm assuming there were some abstains in there because I don't think I heard everybody's voice. Anybody get abstaining? All right, so it sounds like we're passed then. So Rai and I will work on getting those mailing lists and chat channels set up and sending out an email to the co-chairs. All right, thanks everybody. I see some of you in Montreal. Yep, of course you're all in Montreal. Thanks everyone. Have a good day, cheers, bye-bye. Great day everyone, bye-bye. Bye-bye.