 Well, you can go ahead and kick off the recording then, Mariah. It's recording. All right, you want to kick things off, Andy? Yeah, so I'm Andrea Anderson. I am going to welcome you all to the Hyperledger TSC meeting today. All are welcome here. We divide by the antitrust policies in our community total conduct. Thanks, Andy. And if you haven't met Andy, she's been around for quite some time at Hyperledger. We may have met her at one of the HackFests. She's one of the more prolific coders at Hyperledger with about 40,000 lines of code or so in Sawtooth Core plus SDK work and, I think, our most prominent contributor on the WebAssembly engine Saber. Yep. So I've invited Andy to kick things off for us, just like we had Rodrigo de la Verdeleal a couple of weeks ago to bring the perspective from Palo Verde. So, Andy, I don't know if there's anything from your experience at Hyperledger that you'd like to share with the TSC, maybe things that they might not be aware of or maybe they are aware of, but you want to highlight anything that maybe makes it easier or more difficult to contribute here? Yeah, the only thing I'd like to mention is sometimes with how much volume there is on the mailing list, it'd be great if we could have a central location for decisions made just so that they're easier to search through and find what the TSC decisions are. But besides that, I don't have anything else. OK, that's a really good idea. So when the TSC makes decisions, if there's some centralized catalog somewhere of, I don't know, maybe RFC-like is maybe what's in your head? Yeah, obviously I'm really familiar with RFCs because we do that for thought-tube, grid, and transact. But something similar to that, just a central location that you can see a full, not super formal, but formal write-up. OK, yeah, that's great. That's something that we should think about some sort of consolidated version of minutes that just addresses the decisions made and the proposals offered. OK, great. Well, thanks. And everybody, feel free to reach out with one another, regardless of these kinds of intros. It's good to be connected across our community here. We don't have any announcements this week, but I thought we'd start off with a little bit of housekeeping. We've got three important task forces in flight. And one of the objectives of setting these things out as task forces was that they could operate more quickly than a working group or maybe in a more concerted way than having maybe just weekly discussions here in the TSC. So I wanted to check in and see how things were going, starting first with the CICD work, looking for some sign on the horizon that that is winding up. Thank you, Dan. So yeah, this is Dave Huseby. The CICD task force has been chewing on this problem for a better part of two months. And the last meeting we had, which was a couple weeks ago, was lightly attended due to all of the travel in the summer. But we've been doing our best to drive towards a conclusion. I have not produced a report due to the travel and the lack of buy-in by all players. But if you've been watching the notes, you can kind of see where we're headed. And I can give you some of the highlights here. We have narrowed down the proposal to a few options for short term and a few options for long term. The only thing that's really important to note right now is that there is no silver bullet. After considering a lot of things, there is no one solution that is going to be easy for everybody. There's going to be some level of cost, whether it's an effort or yeah, it's basically cost and effort for people, for all the teams to try to unify. And we're not even sure that's what we're going to do. So that said, I'm reluctant to provide an official report at this minute because we don't have buy-in by all of the teams and all the participants in the task force at the moment. But people are starting to come back online and we're hoping to narrow that down, get everybody on board. And at that point, we will float something to the TSE, but it's just, the conclusions are not, or sorry, the proposals are soon to be, sent to the TSE. I don't know exactly what soon is, but it's not a month from now. It's not tomorrow either. So somewhere in between. Okay, great. I think probably the hard stop that we have is the board meeting at the 1st of August, so. Yep, I'm fully aware of that. I think we will have, I can tell you we will have a proposal before then and we'll give the TSE enough time to consider it. And it's important that it goes, that it's done before the board because no matter what we do, I believe this will incur more financial cost to hyperledger. So it'll take a bigger chunk out of the budget and we'll need to consider that. Okay, great. So Arno is not here. When I last checked in on the Lifecycle, the Lifecycle Wiki page, I didn't see any updates since, I think the 20th of June, one of the last things that we had discussed was breaking out the issues or proposals into separate pages so that the comments could be more easily tracked for those. So maybe we'll look to follow up with Arno on that separately later. And then the working groups. I know that that was intending to trail behind the Lifecycle discussion to incorporate any dependencies that come out of that. I don't know if there's been any discussion in that committee yet. Nothing. I mean, it's basically, we've been capturing a bunch of notes, or I've been capturing a bunch of notes on the Wiki page from various discussions, but as you said, it's really gated by the Lifecycle work. Okay. So I don't think we've got a hard stop that can help drive progress there, but clearly the update that we'll be looking at from the architecture working group later today and some of the other working group updates as those have progress or difficulty making progress, the more that we can provide some improved direction about how working groups operate, the better that will be for all of those. And speaking of working groups, moving to our proposal for today, which is a proposal for a diversity, stability, and inclusion working group. I'll let you navigate on your own screens to the proposal itself, which is linked in the minutes. This work started sometime in fall of last year where we were looking more broadly at community health. And when the topic arose for it to be a working group, some of the feedback at that time was that that was too broad. And so the people that were interested in forming that working group at the time continued to meet since that point and worked on honing into a more addressable scope. In parallel with that, the Linux Foundation has been also focusing on its diversity, stability, and inclusion efforts. And so we've had a few discussions with the Linux Foundation proper. It's been collaborating with us. And then also again, narrowing down what we wanted to do across the possible things that we could do to improve community health to focus first on DCI. Within that DCI scope, we had a lot of discussions about what could we do, what could we do first? And some of that decision making, you would want to be informed by numbers to say, all right, where are we not diverse, civil, or inclusive? And we don't have a lot of data to direct where we would prioritize our efforts first. I'm happy to say that we don't have at this time a lot of civility issues. There's not been, to my knowledge, any, but for perhaps one report across the longevity of hyperledger, any civility issues. So then it really comes down to what can we do to improve inclusion and our diversity? And being able to measure those is one of the first things that we want to go after. We found that as a group, it was difficult to get the kind of engagement that we were looking for from other parts of hyperledger and to figure out how we would resource or capture some of these metrics in the way that we were able to interact. So limitations of not having things, simple things like a mailing list and the visibility that comes from a working group were really impairing our ability to move forward. So as we've gotten more concrete on the steps that we've liked to take and we've also become more aware of the limitations that we were operating under, we put together this proposal and we've circulated this with not just the TSC list, but before that, as we looked to build support for it, it's been socialized with the governing board and with the maintainers mail lists. And so I'm hoping that even though this is the first meeting that we're discussing the proposal itself, that it's something that's not necessarily news to the majority of people on the call. As we skim down in the proposal itself, we've got a pretty healthy list of interested parties that have been working together over different periods of time on this with a couple of newer additions as we started to bring this proposal forward. But that list doesn't even quite capture the full list of contributors. One of the principles that we like to act on in Hyperledger is making sure that the initiatives that we undertake are community-driven. And we have a lot of strong staff support for a number of these initiatives that we do at Hyperledger. But this one in particular, I have to say that I feel like there's really strong staff support just based on the motivations of the staff participating, that this is an area that people feel pretty passionate about and good about contributing to. So that list of interested parties really doesn't capture the full set of participation that we have there. What we'd like to do is get started with the working group, get those tools that we don't have available to us right now, like the mail list and so forth and get underway for some period of two or three months with me helping to guide that initial period. But I know we've got a lot of strong leaders already on that list. And we'll be looking during that initial phase for one or more of them to step up and then select amongst ourselves for a more permanent lead for the group. There's quite a few references there if you have time to go through them of materials that's been gathered over the several months that we've been working more or less behind the scenes there. And that also helps support our ability to execute successfully once this is launched as a working group. And so with that, I'd like to invite any questions or any comments from the other participants that have been working together on the proposal. Yeah, Dan, Mark, one of the things I've brought up on some of the calls, the committee calls in the past is what are we going to do with the data? We don't have clear goals. If the data shows that we don't know what the industry averages are is the goal to just increase participation, then are we just baselining and saying that we improve gender diversity? I mean, I'm all for improving gender diversity, but if the data shows we're 50% ahead of the industry average, what do we do with that? It seems like we're collecting data to collect data. Yeah, definitely not collecting data to collect data. We want to use data as a means of direction for us. And like you say, if it turns out that our participation is actually ahead of industry benchmarks, then that would tell us to focus on some area where we're weaker. Some of the materials that I think Mandy helped assemble did have some benchmarking in it. I don't know if it's sufficient benchmarking at the industry level or not, but what we don't have is any sort of benchmarking for a hyperledger itself. Mark, you touched on something that I'm allergic to collecting metrics, just to collect metrics, as you said. And my question about any metric that is proposed is if we had had this metric a year or two ago, whatever the number, how would it have informed our actions? How would we have acted differently if we had this metric some time ago? So that's what I usually try to think about any metric that we're proposing to collect. If it wouldn't produce something actionable, then don't collect it. Yeah, absolutely. So then what's the answer to your question? And what would we have done differently if we'd had this information earlier? So I think what we were balancing was an interest in moving forward in a data-driven way with an inability to actually have that data. And so we've taken some stabs at some ways that we can take some actions, but also wanting to fulfill that interest in having some database decision-making. And one of the actions that we would make differently or the same would be actually understanding if we do have a discrepancy in the representation that we have at Hyperletra versus Industry Benchmarks. So more specifically with the gender issue, for example, we picked that for the reasons that are stated in the proposal, which amounts in some ways to saying that that's the small amount of signal that we have to work with. But if we had a stronger signal saying that that gender was not a strong issue for Hyperletra, but we had some other inclusion problem, then that would help us spend more time on the problem that we did have. So Dan, how do you see this working group reporting back to the TSC? Is this gonna follow the normal working group pattern, which is driving towards some white paper or some technical article? Or do you see them being more active in the TSC, like doing monthly updates to the TSC mailing list or something like that, almost like a DNI newsletter or something? Yeah, I think that it's likely to be more varied and more contained kinds of deliverables than having a long-term white paper. The intent would definitely be to bring back recommendations as we're able to. And then also act in other venues, like when we're having an event, for example, making sure that that event is executed in a way that helps support the DCI initiatives. So not just maybe written reports, but those kinds of actions, as well as the feedback to the groups listed there. Great, thank you. So I think there was a comment on this at one point on the page. Why is this part of the TSC rather than the Marketing Committee? We had some very specific deliverables listed there that were about engagement plans. And that related to some actions that Hyperledger staff was taking. And so the wording of those sounded a little bit marketing-oriented. And what we did to help clarify that, that you'll still be able to see in the history for the pages is that we moved that off of, there's three work products listed there. There was originally two listed. And so what we did was we added the line for recommendations to Hyperledger staff, which those items fell underneath. And then also just moved those very specific recommendations that were already in flight off of the proposal itself, just because they were a little bit narrow in time than what the proposal should encompass. But it could also be a good recommendation. I'm not sure if you're making it that that this working group also provides feedback to the Marketing Committee. So I had a question about the difference between what we consider a regular working group and some of the actions that this group is planning on taking. For most of our regular working groups, the result is really more like a paper or guidelines or just general guidance or things for the general community to just consume. It seems like this group has in mind more particularly to make policy recommendations and build tools that directly affect community structure. And I wonder if maybe it would be better to classify it as something more than just a working group as a result. Maybe classify it as some sort of committee or task force that reports to some element of Hyperledger's governance structure where they'll build a recommendation that then would be ratified. Because I like the idea that we're discovering what we need to do to affect how we manage the community and make that more official output perhaps of this group. Yeah, there's a lot of different names that we could put any of these efforts underneath. And I think when this came up in the fall, since it felt different than other working groups, that was one piece of resistance that we met. But some of the very tactical things that came out of our experience in the last several months was that there was almost an irony to what we were facing that in trying to create a group about inclusivity, we were a fairly hidden group. There was no mail lists, there wasn't a lot of visibility into what we were doing. And that made it hard for us to have the kind of engagement that we need across the breadth of the community to really understand the community and incorporate the kind of feedback that could be provided. So, well, I think that we could put a lot of different names on this effort. It's the recommendation of this group that a working group is the best choice that we have to give the right kind of tools to make this effort successful. I mean, to further Nathan's point, it almost seems like this should be something addressed by the governing board. From a technical staring point of view, I mean, it's increasing participation, but are we setting a technical direction for a hyperledger by doing this? I mean, would the governing board be able to give this more resources than the TSC can? That's another good thought. The governing board meets less frequently than, they've got a slower frequency of interaction and reaction than something like a working group would be able to facilitate. I think as well keeping this closely connected to the development communities and looking at how the teams work is pretty important. Certainly, the governing board will pay attention to whatever gets produced out of this, I would imagine, but I don't think you all would want, as the governing board said, we've decided, thou shalt change how you all work. You'd want some say in that, right? You'd want, and I think the more public this conversation, usually the better, right? So, it's not like the governing board would be ignoring this. I think it's just best to have it rooted very closely to where the development activity is. Or consider that at least. I mean, I think it's a technical failure, so in a similar way that it's financial failure to have a smaller percentage of women on boards. So I like the idea of having it in the technical steering committee. One thing I'm struggling, and maybe this is putting the cut before the horses a bit because the group hasn't started, but given that these are cultural and systemic things, what, does anyone have a nice example of an action or a recommendation that might flow from this, or maybe already has in previous work that people have actually done, and that helped? Yeah, so we've got some expertise on the group here. Mandy, for example, this is her PhD background. So I know she's got a number of examples. I know she's not able to join us today. Tracy, I might be able to put on the spot, or I might not, but I know that she related in the last meeting that we had a very specific example. So I'll let Tracy speak up if she wants to now, otherwise I'll just yammer a little bit. Yeah, so I guess my example was my first contribution to hyper-leisure recovery. I was trying to make a documentation change, and it was a one-line change, and it was actually rejected because it wasn't large enough in scope, right? I was trying to keep my chains down to a very narrow scope and get something in that was basically a typo sort of fix, right? And I think that would have been extremely disheartening for anybody coming in who didn't kind of want to get this change in, right? To say, okay, well, they don't want my simple change. I'm just gonna leave this community. And it really helped me specifically because I had Nick Gasky who was basically being a mentor for me to make that contribution, right? It was the first time I was ever contributing to fabric. Didn't really know the process of contributing to Garrett and what that process looks like. And he basically helped me through that process, helped me understand why the change was rejected. And I think we don't do enough of that inside of Hyperledger in the community. At least I haven't seen enough of that is the mentoring, the responding back to people, the answering questions or just helping somebody through the process of contributing. And it's not to say it doesn't exist, but I think it needs to be more, right? I think we need to make sure that we're a community that is welcoming to all and make sure that the people who do want to contribute and have taken some time of their lives to put together a PR are in some way recognized and helped through the process to understand why or how to get something into the Hyperledger project. So I guess that was my example right there. Yeah, yeah, thanks. Kirsten on chat was also sort of emphasizing that in a similar way as well. Another example that comes to mind that Mark Wagner shared and I'll let Mark speak up for himself here related to how people interact in the sort of social work settings that we have and is still relevant in Hyperledger when we have things like member summits and hack fests and so forth. So Mark, I don't know if you recall what I'm referring to as far as like going out to get a drink and that kind of thing. I think Mark dropped off the call. I, yeah, I guess he is not here. But so one of the anecdotes that he related to us was about becoming aware that there can be a big gender bias in going out and hitting a bar or something which is considered a social thing for a lot of people but other people aren't comfortable with and that can be not just a gender issue but an issue for people that don't wanna participate for other reasons in a venue like a bar. There's been a number of other anecdotes shared in these meetings and that I think are actionable things that we can bring forward and create some general awareness. Maybe the last one that I'll hit on is being made aware of accessibility concerns for using software. So not just how are we forming as a community but also this sort of feedback loop that you get in what kind of software you create is what kind of community that you're building in front ends for our software are the things that the people who are visually impaired can still make use of. There was a lot of different considerations that we might look at beyond gender which is kind of focused a little bit in this proposal but things that are actionable in very different ways across hyper ledger. So could you just give me an idea of what policies might look like and in particular, given that this is an open source project how you would hold people accountable for those? Yeah. So it's a little bit difficult to explain a solution that the goal of the proposal is to arrive at some solutions. So I can't tell you the end state right now but what we can point to are some of the anecdotes that are just related being able to provide those as ways to sensitize people to things that they might not be aware of. So those aren't necessarily things that require enforcement as much as they require awareness. And there is a degree of enforcement that comes from our community code of conduct. So there's an explicit enforcement in that. So any sort of violations of that there's actually a policy around there. I think one of the most effective ways to bring about some of that change though is not reacting to violations of policies as much as it is doing the more positive and proactive thing like we've done in adding all our welcome here banner to a lot of the materials that we produce. So setting the tone out front that this is a welcoming organization as opposed to a more punitive tone that if you're here, you better behave. So my, as you are deeply aware and I think all of our companies have very specific policies for hiring for how interactions work for what our expectations for the environment and that we're creating. And within those companies there's that we have our HR organizations that can enforce some of those policies. I mean, just to throw something out for discussion purposes only, would we be willing to do something like say the TSC vote would not be or we could not vote on TSC members until at least one third of the candidates were diverse. I mean, would we be willing to accept policies like that to force us to solicit participation more broadly? And I guess what I'm saying is a lot of what I hear right now is still very passive. Like let's make sure we don't step on somebody's toes as opposed to being very active in enforcing ourselves to be active in soliciting broader participation. And I'm just throwing that out there solely for the purpose of driving discussion but will we go to that extreme? So I've got some thoughts about that but I've been fielding a lot of the questions. So I do wanna make sure that I give opportunity here for other people to react. I guess maybe while people are considering a question that they'd never considered before, I can say that we've considered policies like that or policies like that are under consideration at the board level. And so I think from my perspective as one voice on the TSC, that's certainly a degree or a kind of something that would warrant consideration. I don't know that we wanna get caught up in specifics of numbers or the policy itself but that as you say, something more proactive than passive is certainly something that should be on the table for consideration. I think that's a classic issue whereby do you want to be someone who came into a body because you were on a list? A lot of people who would be on a list, I know, I would say no to that. The other thing is in formulating your definition of what is diverse candidate, you are inadvertently treminatory. So there's a lot of book guns there. Use a HUSB term. If the passive way works, then maybe that's better because of that but if it's too slow, perhaps not. Yeah, these are all sensitive issues and you can definitely with good intentions create a more negative result. But one of the things that I'm appreciating out of this conversation is that there is strong interest amongst the TSC and interest to go after some of these uncomfortable questions. And I hope that we can see participation from as many of the TSC members as possible in the first meetings of this working group assuming that we get to a point where we're comfortable voting on that. I guess I will say just position-wise, this is an issue that has to be addressed and I'm all in favor of addressing the issue. I'm just not sure I understand why this is a TSC versus a governing board issue. That's my only, it feels like we're trying to establish much broader policy than just technical policy and that moves it out of the realm of exclusively the technical steering committee. Doesn't mean we shouldn't be represented, we should be represented and we should be held accountable for it. But it feels like a broader issue than just what we're doing. I would agree with that sentiment in that it seems like this policy would directly benefit a lot of the other efforts that go on outside of the technical effort as well. I really like the idea that we would play a strong role in a big part of what constitutes this working group but it certainly seems like more than just a technical working group. Yeah, can we actually get some experts? I think Dan, you mentioned Mandy to provide some recommendations on this. Like having a program like this designed only by engineers seems like a disaster waiting to happen. Right, right. You wouldn't want people who are outside of the discipline trying to forge their way blind through that and that's not the intent of this group. We do have some expertise on and we also have to recognize that as an open source community, there's nobody closer to impacting that community than the contributors within it. And so there's definitely roles to be played up at the governing board level. There's roles to be played at the Linux Foundation but I would think that abdicating our responsibility for some sense that there is a more powerful entity that could do more would be a fairly weak mistake. I'm not claiming that we should do that. I'm just saying that we should get diversity experts to help us come up with something. Yeah, my answer, there wasn't directed specifically at your question, but there was a few comments in there from you and others about the level of engagement from the board and sort of a existential question about whether or not as a working group within the community that we have whether we ought to do this. So I'd like to point out that we do also, we have the ability to go to a wider scope as well. There's chaos, which is a project underneath the Linux Foundation. They have quite a bit of representation from Mozilla and the chaos DNI group has experts on it and they do this stuff. So if we could work closely with chaos DCI group, we could probably leverage their expertise and work more broadly across open source at all. And I see Mark's hands up. Yeah, so sorry, I had to drop for a minute, I'm back. So one thing, I mean, even before we go forward with a working group and all, if we have like the member summit coming up, is there something we wanna do there? Or is it too late to try to plan to have a little table set up or a booth or something and try to start spreading the message that we wanna improve diversity. And rather than focus long-term, what can we do short-term as well? Who was it that, I forget, I think we had this discussed at one of the meetings and I can't recall what the outcome of that was, whether there was room in the schedule or whether the schedule was already full, but it would seem that some sort of booth space or signage or something would be addressable even if schedule time wasn't. Maybe Karen, I wanna say was looking at that and I don't see her on the call today. Yeah, she's on PTO. Okay, so sort of cycling back to the beginning of things to help wind this conversation up for today is, at that time, there was feedback that things were too broad. We brought a narrower scope that is more addressable today and I'm hearing a mixture of feedback about maybe it's not so much breadth as the, yeah, I guess I'm not sure what we're to select there, but actually pushing a little bit in the direction of more impact. So my preference is to keep the proposal worded more or less in the scope that it is. It's always easy to broaden scope, but I think that what we've found is that in other working groups is that with the, you're more likely to have success the more targeted that you make your effort. There any other concluding thoughts from TSC members? Yeah, I think a working group is probably the best point, you know, the best way to go forward with this. You know, I'm just trying to make sure we've explored all the options as a TSC, but you know, but it gets treated as a working group so that would help I think and it can work with other groups and projects. Yeah, thanks Mark. I think that's an important point is that we don't have to leave this, we don't have to have in this proposal the ultimate solution to all the problems and the ultimate way that we can act on those. But if members feel that the proposal hits within enough specificity that we can be successful, a lot of these questions can be explored within the context of the working group itself. I'll point out that we have 10 minutes left and are we going to cover the contributor summit? If we're going to take a vote, I propose we do it soon. Yeah, so I'm not clear from the feedback that we've gotten if we're at a stage that somebody is interested in making a motion. So I think that maybe what we'll do is let people consider this proposal for the next week and provide any other feedback and then we can pick it up again with less discussion next week. All right, we've got a couple of quarterly reports that I wanna just touch on real quick before we go into the contributor summit discussion which you might not have full time for. So I saw that most people were able to take a look at both of those updates. I think that we have contributors from both of those teams on the call right now. So if there's any verbal questions that let's go in order here. So for the architecture working group update, I don't wanna walk through the update itself but if there's any verbal questions that people want to bring up now, this is probably the best time to do it. I think there was a question raised in the report about what they do with Transact and so I don't know if that's something people wanna discuss or not. I think that was a cogent point that was brought up and so I can try to make sure that people are connected there. Okay, not hearing further questions and being short on time, I'll move up to the Sawtooth update. Do we have any verbal questions there? And there was one comment that I had responded to earlier today on the report itself. Okay, great, so I think we got through both of those reports in under 120 seconds which gives us time for the contributor summit. So we've talked at different times over the course of the year about how do we get together for our face-to-face. We haven't been doing the hack fest that we had been doing in the past. We'd spoken earlier about splitting out the different objectives that we had had for these face-to-faces into something that's more recruitment-driven and then something that's closer to doing core development. And so we've addressed the former with a couple of boot camps so far this year but we really haven't gotten together with groups of maintainers and core contributors to do some hands-on work that can be done in a way that doesn't also get distracted by trying to create pitches and things like that for new contributors. I reached out to my company to ask for space. This is one of the things that is always a challenge in putting the events together is what can we do from a budgetary perspective and what can we do for venues. So Intel is willing to donate space so that we can sit face-to-face. I specifically asked for an area where we could work collaboratively but would not really lend itself to people putting up PowerPoint and making long presentations. But we can certainly talk about the nature of the work that we do there. Hey Dan, this is my client. Accenture can probably offer space as well and we have offices in most locations so that should open up wherever you would like to do that. That's fantastic. Sovereign has located a space that can do the larger numbers in Salt Lake City that they're negotiating with right now to have it be free. It is one of those office spaces that we really like to have these kind of events in that's super open and has the tables and has the rooms and has all the complete breakouts. But the key element that we're working on right now is free. Yep, so I think with any space that we can put our hands on when staff asked whether I could find the space that's some space that I found there in Hillsborough, Oregon. So if there's other offers of free space that can come in in a similar timeline, I think we can pick whatever looks like the geographic centroid. But... Well, I will point out that we used to, when this project started, right, we were gonna do six of these a year and then it was four and then it was three. And if we have, you know, if we have a handful of spaces that we can use, there's no reason that we just use one of them, right? Right. So, you know, let a million flowers bloom and if we can have multiples, that means that it may be less onerous for people if they miss one. If we get back to the cadence where we're doing one of these every two or three months, missing one won't be so bad, right? Right. Yeah, so as far as timing, we were looking at getting outside the summer vacation schedule for the Northern Hemisphere and the back to school schedule. And anyway, so sometime end of September, beginning of October was what was suggested in one discussion. So that's the parameters there for one option that's in front of us. If people wanna offer up additional options, that's great as well. And imagine that we might wanna have some discussion on the composition of the group at these. The starting point for this one was considering getting the maintainers and significant contributors who are for whatever reason, not also maintainers together to do particularly a focus on cross-project development. Hey, Dan, how would you see this? Let me try to get my words together here, right? There's also been some discussion of having a boot camp in that timeframe. Do you see this as great, let's do both or maybe not? I think not. Right. So we have to resolve that conflict. And then there's also, I think September would be probably better than October because some of the events in October are things that we've participated in the past, like ATO, like all things open and stuff like that. So we're threading the needle on this one. It's not as easy as, it's like, oh yeah. Yeah, and we do tend to get into some spiraling discussions about optimality on calendars and there's no way to avoid all the conflicts that people have and it also tends to be difficult to book these spaces in without some significant heads up. So for example, getting this space in Hillsborough, Oregon, that October, those October days were the nearest days that I was able to get booking for. Well, yeah, I mean, the calendar might be the driving function on which one we pick. Which ones, you know, again. Again, yeah, you're right. So GSE members, maintainers, contributors, any feedback on the goal of the contributor summit? So it's essentially a hackathon sort of rebranded, right? This is the summit we had last year in Switzerland. Can I add, and I don't think it's right to think of it either as comparable to like the HackFest series that we had had before, nor a hackathon, nor just, you know, kind of an optional kind of thing. I think the idea was, you know, the group of maintainers and even the TSE members here meet face to face. So irregularly that, you know, you don't really get a chance to build the kind of trust that's essential to make good open source projects work and that there are a couple of really important themes like convergence that, you know, we can iterate over email and approximate too, but sometimes getting all the right people in the room to be able to kind of look each other in the eye and commit to something is something that just doesn't happen, you know, over email kind of asynchronously, right? So this, I would encourage people to think about a contributor summit as distinct from those as being something where it's a little bit higher priority to make sure that all the, or like at least a critical mass of maintainers on critical mass of project sniper ledger can make it and that it feels less optional or less kind of unfocused or unconferency as say the hackfaster or have, and not really a competition the way many people think of hackathons. If that's something people want, if they don't want that, that's something that doesn't have to be imposed on them, but it felt like there was a need for that distinct from the other. I think there is a need for that, but that does stand in opposition to what Reeve was suggesting about minimizing the badness of missing one. I guess we're trying to sell it as a sort of single event where that's the one you put effort into if you've got four a year and you can't go to four, then you choose one. So you split the crowd. That was my misunderstanding. I misunderstood and I see we're at time. Yeah, so please take the rest of the discussion to the mail list and you can build on that particular thread. If you've got feedback on the objective or have alternate dates and venues to suggest. Thanks for Rudy's engagement today.