 Floor is yours. All right, thanks Ry. So welcome everyone to the November 11th TSE call. Looks like the folks that we have on the call are all people who've been here before, so you know the drill. You must conform to the antitrust policy notice as well as the code of conduct, which is linked into the agenda. So we have some announcements to start us off. As always, the Dev Weekly newsletter goes out each Friday. So if you have anything that you'd like to report about your project or your lab or the work that you're doing and reach a technical developer audience, this is a means to do that. The second item I put here is, as I was going through and looking at kind of what's upcoming for reports, I noticed that the 25th is coming, which is the US Thanksgiving. So I'm recommending that we go ahead and cancel that particular meeting. Hopefully nobody on the call has any issues with that. Okay, and then the next one here, I noticed right before the call that Min had sent an email to the TSE mailing list about the Minty project presentations that are happening on November 15th and November 17th. So there's actually two separate presentation calls where you can hear about kind of the different projects that happened during the mentorship program this past year. So if you have time and are interested, please consider attending that particular item. And then, Rai, I think you added this last one. I did, and I just wanted to point out that the conference, the HBCU Blockchain and Fintech conference hosted by Morgan State is free tomorrow and Saturday. Link is in the description. Hyperledger will be there. Feel free to join us and it's gonna be a good time. All right, thanks Rai. Any other announcements that anybody has like to add? Okay, so we did get three reports that came in this week. One for Aries, one for Indian, one for Iroha. I noticed at least an hour ago when I checked there weren't many folks who had had a chance to review any of them yet. I think the one that had the most was about four people out of the 15 who had a chance to review it. So I'm asking that you go forward and review those. I did notice that there was a question in, I think it was the Indie one. Arno, you had asked a question specifically about the Indie DID. Yeah, I mean, to be fair, it's not so much a question about the project itself as much as the choices they're making on the specification. I mean, but I wouldn't hold it against them. It's just, I'm curious. The whole idea was to be decentralized and have identifiers that are in full control of the user and respect the provider mechanism that depends on GitHub. And I'm like, doesn't that defeat the point? If you are now depending on GitHub being there, it seems a bit odd to me, but. So I'm still interested to hear from the Indie crowd what they think about it, but. Sure, so Nathan, I see you have your hand up. Is that related to maybe this? Yeah, just as a kind of the note there is that it's meant as a source of documentation of what our methods are out there to go investigate. The authority in terms of what methods your code supports comes from the implementation that you have. The idea being that your code should support as many of the implementations as it can. And that's kind of one of the impetuses of splitting Aries out from Indie originally was to make it so Aries was generic and could support more than one decentralized method. The trouble we always have saying, well, where's the decentralized specification for the decentralized spec is which form of decentralization is the most decentralized or the right kind of decentralized which creates all sorts of, you know, contortions and knots in the debate. So if you're interested in that debate, the decentralized identity foundation, which is also hosted at the Linux Foundation is where most of that debate has occurred. And that's also why the GitHub repository that specifies method specs is hosted over there is because that's where everyone argues about it. Yeah, I suspect that would be pointed there, but thanks for a little bit of the background. And I understand the challenges. It's not an easy problem to solve, but. All right. I did not see, I only saw one other question, but I think that was more related to connecting David Boswell with people who were working on the climate work in Aries to get them connected to the climate, the climate sink that we have. So, and I know Stephen's not here to answer that question. So we'll hope that he answers that specifically in the report itself. Are there other questions that people had about any of the reports, Arun? There was a question last week by Dano to follow up from Avalon, and I didn't reach out to Eugene from Intel and feel, unfortunately, preoccupied, preoccupied for the next three weeks until the Thanksgiving in the US. And he said he will join us, call soon after that. And he said he has a proposal for what comes into Hyperledger versus what goes into CCC. Okay, great. Well, thanks for following up and letting us know. Arun will look forward to getting him on the agenda when he's ready after Thanksgiving. And I did, there was a question that came in via email, and I see that Sarah from Rojas here, she pointed out that, you know, coincidentally, a lot of the documentation about how to do security things is out of date. And I've added some of that to the thing. So Sarah, if you had anything else that you wanted to say about that, it would be great. Hi, no, it's just a question that appeared a bit later and not really related to the report. I think it was about indeed the security documentation as we have like two kind of teams right now working on two version as well for Roja. And one of the teams that is actually not, like the Rojo2 is not released and they were looking at the repository structure and the documentation that's supposed to be there. I just saw this and yeah, I decided that we will make the document as you suggested on GitHub, like just a document and host it on GitHub and just provide the link to it. And hopefully it will be okay. So it's not a question anymore. Thank you for your help. Now we know what to do about this. So yeah. Thanks. Okay. Other questions or comments regarding the reports? I'm going to, I'm going to leave these reports on here until next week given the small number of people who had a chance to review, but if there are questions now, happy to talk through those. Okay, I see no hands. So I'm going to assume no questions now. So let's move it into the discussion section. So last week, we had talked about the white paper task force that was suggested to create a white paper regarding the role of blockchain in the election process. As we talked about that last week, we decided that there were some objections to that being a official white paper from Hyperledger. I did comment in the issue itself, the fact that we discussed it and that was our outcome, but I didn't want to close this issue without having a discussion with the rest of the TSE kind of next steps since we had only really talked about making sure that we commented back on the particular issue. So, Arun. Oh, thanks Tracy. Last week I couldn't speak because we were waiting on back proposal as well towards the end and quick updates on this proposal, right? So I guess I agree to the wording that we may not call it a white paper. However, the interest came in from some of the community members, especially who are involved with the government projects and they had a request to showcase some of the use cases that they have and recorded from there, saying that what worked for them versus what did not work well in their POC. And these are some of the institutes that are centrally governed through the union government in India as well as they are involved with election commission of India. So some of the members that you see on the list over here, they do come from those departments, right? The government agencies. So after this call, I guess David suggested me to get in touch with public sectors, special interest group, and I did reach out to Jim Mason from Public Sector SIG. And after speaking to him, it looks like he also has some of, I mean, he knows few of the people who have built solutions on similar to this. And he expressed interest in getting together people or maybe asking people to share more information on such projects. So having seen this interest in community over here, but also the interest that Jim has shown, I would propose that we probably move this proposal to public sector SIG and let them figure out what should be the next steps. And so I agree that we may not be able to call this a white paper, given all the discussions that we had last week. But instead of closing it, how about the resolution could be that we move it for now? Close. Okay. So that's a good point with the public sector SIG. I think they're obviously a good place to have a discussion whereby it might be more around use case documentation rather than white paper, as you mentioned. I guess we would probably still close the issue here on the TSC side, but yet the public sector, SIG could take that up. Nathan, I see you have your hand up as well. Well, and I think the thing we want to emphasize is this is good work. I mean, it's something someone needs to figure out and we shouldn't presume that conclusions will be bad conclusions without the work happening and getting the work to happen is more likely to get us where we want to go. So whether it's a white paper or not and wherever the work occurs, I think it definitely has a home here at Hyperledger and we definitely want this kind of thing to happen. So it feels like we may be getting too involved in the details at too early of a stage in terms of what things are labeled if that's going to discourage the work from occurring. But I think whether we call it a white paper, whether we call it kind of an exploration or a case study, there's a lot of labels we could put on it. I think most of that depends on the outcome of the work and not whether or not we're going to get started. Yeah, completely agree, Nathan. Jim. Yeah, I just want to second what everyone then Nathan was saying. When I reacted to this proposal on the last week's call, my reaction was we just need to find the proper expertise that can give this work the attention it deserves. I do think this is really good work that the community started organically. We should make sure that we can connect them with the right expertise we have. It sounds like the public sector sick seems to be the most proper, the proper home for this for now. So I agree we should suggest that they go talk to them. OK, Hart? So yeah, I think I agree with pretty much everything Nathan and Jim said. And I guess this is another question if we really want people to be able to do this work and we want sort of the organization of Hyperledger to be able to help, but we may not want to make it an official white paper or something like that. I can think of another sort of some other efforts sort of like this that people just haven't proposed to the TSC and are sort of doing. But maybe if there's a framework to do this kind of thing in the future, it might spur things like more cross-project collaboration and stuff like that. And is there something that we need to take from that, Hart? You mentioned a framework, is there something that we should be putting together as the TSC? Well, I don't know what we want to do. But I mean, I think we should definitely give these groups like if they want to have a meeting, great. If they want to have like a wiki page, great. Even if we don't want to officially endorse things, if we don't want this, is this the official white paper kind of thing? Yeah, yeah. Yeah, no, I don't think we're trying to dissuade these folks from using hyperledger means to communicate and to start the process of writing down their thoughts on this particular topic in any way, shape, or form. So I think my question here really is more around process since this is a decision log entry. What do we do with this decision log entry? Do we leave it on or do we close it now that it's got an official home in the public sector SIG? It's unfortunately process is something that we have to deal with. And Tracy, can I make one observation? Sure. And I think this is an interesting point about how hyperledger has grown to a scale where it's just really big. And I think we can start thinking of the community as a large community versus what it had been when I joined four years ago, which is a small one. When I joined, there was only one SIG. We didn't even call it SIGs at the time, but only one group focused on applying hyperledger in the industry. There were only a handful of projects. It was knowable in a way where I think we've grown out of. And I'm wrong. But part of the issue here, as I understand it, is the people interested in this paper didn't even know that the public sector SIG existed. So I think we need to think about what does it mean for hyperledger to be a large community? How do we make things more discoverable? And how do we do things like what Hart is talking about on the TSE list about how do we try to intentionally create more threads across these different parts? You've probably heard me say this, but there are at least 70 different activities going on in the community if you add up all the projects, all the labs, all the SIGs, all the working groups. It's just to put all the onus on somebody to have visibility into all 70 of those things, to understand the right home for the thing they want to do. It's just a really high burden to put on people. So I think this is just an example of where people got stuck because they didn't know everything that was happening and just didn't know where to go. OK, good point. Some things that we then need to take forward as a community, a larger community. Jim? Yeah, I feel like TSE is sort of becoming a obvious front door for people that's in that situation. They've got a good idea. They've done some good work that want to be contributed to Hyperledger. And they don't know where this work belongs. So they naturally go to TSE looking for advices. I wonder if there's some practical things we can do here, for example, for the issues to create a template. Listing the things that a work could be targeted to. It'll be a list of existing projects, existing SIGs. And if it doesn't belong to any of them, then you'll write it out. So that's a way to guide future proposals to some existing groups that have relevant expertise. Yeah, good point, Jim. We definitely should have a template for these issues that we've moved kind of a decision log over to. We did have really a template when it came to the decision log, but we don't have a template when it comes to just creating an issue here. So good kind of next step that we can take. All right, so again, I'll ask the question. Do we have a problem with closing this issue since it already has a home? That sounds like the right thing to do. And just put a note saying this is where it's going. Yep. Do we need to vote on this? Just do a quick one saying anybody objects like you just did. And I think that's good enough. It's not really controversial. OK. All right, so does anybody object then formally to this being closed with a note that says it's going to be taken on in the public sector SIG? All right, I'm taking silence as everybody agrees that's the direction that we're going to head. All right. So our next item then on the list is the chat system and moving the TSC chat back to Rocket Chat. So we went through this very quickly last week. Looks like Rai did open up the TSC chat in Rocket Chat again for us to be able to comment on. I just wanted to make sure that everybody was aware that we were officially moving back to Rocket Chat and to see if there was any sort of discussion that anybody wanted to have on that particular topic. Grace isn't here, is she? I'm here, I'm sorry. Oh, you're here? OK, one question didn't you have about what we promote? Is it Rocket Chat? Because we're kicking the tires and the basic contributors on the Discord Room. We wanted to know what the TSC expected as far as how long we can do the split break thing before we have to commit to one. So comments from anyone? So the question that you have, Dano, is around since now everything is officially back to Rocket Chat, but we're also kicking the tires on Discord, what the plan is, and how do we make sure that people are going to places that they need to go? Is that correct? Yeah. And what's the timeframe for a decision on those about that? Yeah. What it might be. Right, do you have any ideas on kind of from the Linux Foundation standpoint, what the official stance is on the different chat systems that exist? I am not going to say anything officially, but my position has changed over the last little while. My personal position is that we should go to where the communities are and want to be, because telling them that they need to meet us on our terms where we want them to be has not proven to be particularly fruitful. Right, Dano. And just one thing I want to point out, what the community member who's not a maintainer interestingly said, hey, there's a lot more chat going on on this Discord about hyperledger-basic, and we should all move there. So I think there is some community desire to get some presence on Discord. And we've been working. There's great permissions on the hyperledger Discord. And one of the cool things that there is there's a thing called an announcement channel where you can post releases and other servers can subscribe to it. So it still has some networking effect, because almost all of the Ethereum space chat service has all migrated to Discord eventually, which I think was kind of interesting. They all got off of Gitter. They all got into their matrix servers, and they're all on Discord now. Grace? Yeah, I think the point from Dano means the basins would be ecstatic if we moved to Discord and are willing to help in any way we can right, just to be like, if there's any integration work to who or whatever is needed. I know others may not want that, but just, yeah, it would be a huge win for Basu. It's just a point if we didn't decide that. I understand there are many other projects that need to be considered, but yes, but happy, happy, happy to help. We've been talking about this, about how we would be just, you know, any work that needs to be done, we would be happy to put them with the plan. I appreciate that. And I think implicit in what I said, but I guess not explicit was if only Basu and Cactus end up moving over there to Discord, and that's where the community wants to be. I think that's a good thing that we're there. We have an official presence and people can know that when they search for Hyperledger on Discord, they find us. Peter? I just wanted to offer some more anecdotal evidence of Discord being a popular choice around the community. I heard from people that they know a lot about the features it has. They know a lot about what it can do, and they would love to have it. And they were very happy as well to hear that the current beta or tryout Discord was created. Okay, thanks, Arun. Hey, so I just wanted to bring the topic right to the, where I just spoke about right. So I agree to what the scope that he's speaking about. So we are literally talking about different aspects of community getting together. So on one side, we are saying, hey, here is how different maintainers get together and then they discuss about a feature on one chart forum. This is where we need probably more interactions or kind of a discussion forum. Have that continuous chart or something like that, right? So rocket chart was serving that purpose. And then on the other side, we have somebody who wants to get started with a project and they are looking for resources to get started with it. And right now we are asking them to move to our channels. And I agree that forcing somebody to start using our means of communication could not be, may not be a nicer way of welcoming somebody. So how about we segregate these? And I think having a Discord server for Hyperledger is fine. But what is the purpose that we are trying to solve over there? Are we saying that all the questions should be raised over there? Are we just saying, hey, this is one of the many means that we have? Yeah, I think we're causing a lot of confusion is where we're at right now, right? We have rocket chat. We've had rocket chat for a while, very long time. And we've got now, we created the chat on matrix slash element, we went over there and now we're creating Discord and people are going over there. And we truly do have a split brain around where do people go, where should they go? I wanted to reach out to Dano this week and I didn't know where to reach out to him. It's like, I went to the rocket chat because last week we said we were going to be moving the TSC back to rocket chat and Dano wasn't on rocket chat. So I'm like, okay, maybe he's still on element. I can find him there, right? And I did find him there, right? But obviously if I'm having the problem of knowing where to go to reach out to somebody in the community, then somebody new to the community is not gonna know where to go. For example, on Discord, there was somebody who reached out about a fabric question. There's nobody that I know of fabric-wise that's on Discord right now. And so I had to send them back to rocket chat. So I think that we need to do a much better job in making a decision about the direction that we're gonna head and heading that direction, right? And I think just having somebody who's in the community who wants to be involved in Beisu or Cactus but also wants to be involved in one of our other projects that's still on rocket chat is gonna be a problem for them, right? Cause they're gonna go to one place, they're gonna sign in with their ID and the community is not gonna be there to answer their questions cause they're gonna be off on the other chat platform. So I think that we need to potentially take a step back and have a discussion about what is the direction that the entire community wants to head instead of here's one community that wants to head over here and here's another community that wants to head over there. Completely my opinion. So I'm gonna let Hart speak up as well. So Tracy, I agree with you totally. I think the fewer... I'm gonna summarize what I think you said and you're welcome to tell me I'm just getting it totally wrong. But I think the fewer platforms we have in general and less ambiguity about where to ask a question or message someone would be great. That helps a lot of things. I also think an advantage of using something like Discord is that if I recall correctly, Rocket Chat requires you to have an LFID and that's a sort of a barrier to asking a question where if I want to ask like a casual question I have to sign up for everything. Whereas for Discord or something else like that it might be a lot easier and there might be a much lower barrier to asking a first question. All right, Daniel. So I am on Rocket Chat. I don't know why I didn't show up in the directory. I have all three of them open up and running all the time. But I think if there is a policy towards this what I would want to go towards it's to let each project pick one and only one chat platform. We don't want to move force fabric off of Rocket Chat because it's got a nice entrenched ecosystem there are people working on it. On the same time, basically being on Rocket Chat is a barrier for us to communicate with the wider Ethereum ecosystem. Because as Hart mentioned, they see we're gonna create another login and everyone in the Ethereum land has a Discord login and they're not gonna wanna make one more login. So it's being on Rocket Chat instead of Discord hurts us with our communications to the broader ecosystem. So if that proposal were in place that we could choose each project would choose one and only one chat platform I think we would choose Discord. And I would expect right now fabric would choose Rocket Chat to continue with that because that's where they have all their basis. And we would just need to put in a lot of channels that says fabric questions go here. And the same thing in the basic channel in Rocket Chat Hey, we've all moved to Discord here's the invite. Yeah, and then it wasn't that you weren't there it was that you weren't listed as being online at the time. So I did find you there. So no problem there. I think that the bigger question is are we one large community or are we separate communities is where we're really at at this point when we talk about having people who need to be logged into Rocket Chat versus people who need to be logged into Discord versus people who need to be logged into pick your favorite chat platform which unfortunately I think I have five separate chat platforms during my machine right now which is a big challenge for me individually. So in the past historically, right? We have been one large hyperledger community and that's why we all exist on the same chat platform. So I think that it really does boil down to a discussion of is that what we want to remain or are we changing historically what we've done in the past? So Bobby. Okay, I spend a lot of time on Discord and I think that a lot of people are on Discord so you can't deny that fact. There's a way to set up a channel and have subgroups under that channel. And if a particular project wants to direct their fan base so to speak to the chat or to the communication channel they want they could just list it right there and direct people correctly. But people are on Discord. So it's easy to just set up a presence. I will admit until a month ago I had no Discord account. So I guess I'm behind the times if you will. I don't think this is a question of should we use Discord? I think this is a question of should we get rid of rocket chat in favor of Discord for all of our projects or what is the plan, right? Because that really boils down to a tool's question. I do have, my virtual hand is up. This discussion really got kicked off. This is an acknowledgement of the current state of where we are. Our Chinese communities are not on rocket chat or Discord. And Julian Gordon our APAC VP was brought that up. It's like all of the stuff for Hyperledger APAC happens on WeChat and a lot of it happens on Telegram. So we already have, this is already an issue. It's just an unacknowledged one previously. Well, yes, it has been an issue for a while. It's why Sorabot exists, right? In the Aroha channel. Hi, yeah, we have about unfortunately it requires some maintenance. Sometimes it brings some issues, but overall it works and it allows to communicate in Gitter, rocket chat and Telegram and brings spam from Telegram to rocket chat, which is horrible and requires manual intelligence. So from what I can hear, there are certain communities who want to move to a different chat channel or a different chat system. There are other communities who haven't spoken up either because they're not represented here or because they don't have an opinion or they don't want to speak up. But I really do feel like we're reaching a point where we're going to make a decision about the direction of Hyperledger as a larger community that really needs to have some deep thought done to that. So I guess this is not a closed discussion. I don't see anybody else wanting to speak up at this point. I do think this is going to continue to be an ongoing discussion until we figure out tooling or until we figure out what we want to do going forward. So I now see two hands up, Jim, you were first. Yeah, sorry, Jaycee, hopefully a quick question for me. Was there a sort of a mandate to save on cost by consolidating on the single one? I think this was brought up earlier. Bessu has its big following on N-Cactus on Discord and Fabric has everything on Rocket Chat. Is there an option to do both at the same time or three if there's another significant following somewhere else like we chat? I'll speak to the historical reason about why we are where we are. We started out on Slack and we couldn't keep any of the messages longer than about a week and it would have cost tens of thousands of dollars a month to keep Slack going. Rocket Chat was the supported open source chat platform that was available to us at LF. So we jumped over to Rocket Chat and well, some of us jumped over to Rocket Chat. So that's, it wasn't necessarily a cost saving but a cost avoidance. We didn't want to spend tens of thousands of dollars a month on Slack. Yeah, thanks for that, Arno. Now, just quickly, I wanted to say, I hope we can think hard about what we want to do before we do anything more because it's starting to feel schizophrenic when we say, oh, let's move there. Oh, no, maybe not. And we're all over the place. That's not good. Yeah, I think this really requires us to spend some time thinking about what our requirements are and finding the pros and cons of the different sorts of solutions and really documenting those as a decision criteria and points into what we're going to do here. I think that's the right step forward. Peter. Quick question based on what Ray said. Are we going to have the same cost problem with Discord that Slack was chosen or is it a different pricing structure? I was looking at it. I think we can enable every feature possible on Discord for like less than $500 a month. And that's only if people really insist on it. All you get from that is like custom emojis and custom reactions and a bunch of stuff like that. There's nothing functional that I saw. I could be wrong, but I don't believe that to be the case. Okay, that sounds a lot better than tens of thousands of dollars. All right, Grace. I know by saying this, I'm volunteering myself, but is this a good candidate for a fast force and have a subset of us make a, you know, and I as kind of the different channels, costs and make a recommendation to the group? I think that makes a lot of sense, Grace. Yeah. And I thank you for volunteering. Yeah, you're welcome. So, yeah, let's, other folks who are interested in that discussion and getting involved in a task force let's have you reach out to Grace and we'll get that task force started. I think it's a good idea. All right, so let's move on to the DCI working group inclusive naming proposal. So Grace, I think you and the team have come up with some specific items that are in addition to the recommendations that you had presented to us before the steps that we would take to kind of implement those recommendations. So did you want to talk about kind of what you guys have done and then maybe we'll have a discussion on that? Yeah. I'm not sure we were 100% ready for primetime, but that's okay. So yes, we made a few recommendations for how we can implement the process. So last time we came to you all, we made these kind of, I guess three or four recommendations, sorry, I'm pulling out myself, around just how hyperledger can be more inclusive with its language. And so we had some proposals here, one of which was a way to implement it was through the DCI length tool, which Peter was nice enough to put together. And yeah, so the next step came in coming out of that, we didn't get really any negative feedback or on the recommendations, but we did get feedback on the process. So what we did was come up with scroll down if you don't mind, I think right here on the screen, there's somebody. So you can see the recommendations here in inclusive language for each of the group, each of the teams. And then if you go down to the implementation proposal, just to pick up where we left off, we made kind of a few recommendations on how to implement this in the community because that was kind of the key questions from the group. So the first one was to have the DCI working group present at a maintainer onboarding meeting, these DCI recommendations to hopefully train and inform the community on these best practices. That way, we don't just send a mandate over the fence and say, do it, but instead say, hey, let's talk about this, why we decided to make this recommendations and how they can be easily implemented in your project. The second is adding to the quarterly report template a question if your project was implemented the DCI linker tool. And then the third is, and then included in that, which Peter's next step to do is just some instructions on how to implement the DCI link tools, that makes it easier. And then the third recommendation is just to add another question to the quarterly report template of having included inclusive language statement in your project's documentation and or wiki pages. So yeah, this is kind of the three things we thought we could do to make it easier on the community to implement and also a good education opportunity too. Thanks, Grace. So you mentioned that you weren't quite ready for prime time, is that because you are still seeing comments coming in on this page, is that because you were thinking that there would be additional implementation options or what was the thinking behind that? We were waiting for some, just the instructions to be added, I believe. And I believe, and we were going to review these just to finalize in the DCI working group tomorrow. Oh, okay. So the group has seen it, but we and the proposals been shared on the mailing list, but I had not gotten broader approval just yet. Sorry about that. No, that's fine, Grace. I think this could be a good opportunity for the TSC to pre-way in before that DCI working group to see if there's anything that jumps out at them. So Hart, you help your hand up. Yeah, thanks for putting this together, Grace. I guess the question from the TSC end is what do we, you know, what are the steps? Are we requiring this? Are we recommending this? Are we suggesting that people run the linter tool? Does the linter tool have to pass? I guess the question I have is how light or heavy-handed do we wanna be with sort of this proposal and what people are supposed to do with this tool? All right. Thanks, Hart. Arno? Yeah, so in fact, if you look in the comments below, there was a little bit of an exchange between Dan and I. You know, we were talking about, I mean, Dan made the point that we probably should soften the requirement as the first one there on the page. You know, we went through this with the repo, common repo structure, right? Where initially we said, well, you must use repo linter. And eventually we figured, well, that's a bit harsh and doesn't always work. So we settled on saying you need to implement this. And, you know, one way is to use repo linter. And maybe we should adopt a similar policy here where the requirement is not, have you implemented DCI lint, but DCI lint, but, you know, have you implemented the DCI, you know, what do you call this, the guidelines? And, you know, leave it to each project to decide how they go at it. I think it's good to point out DCI lint is there and they can leverage it, but we don't have to make that the requirement. Okay. Grace? Yeah, just to respond to it, Hart, and I know I agree the tool is not a requirement or that, you know, it's just trying to, a way to make it easier. Oh, if projects choose. But the, you know, the real message is, you know, just including inclusive language, you know. Yeah. The tool itself is just a way to accomplish that if they so choose. Yeah, but so the proposal doesn't make it sound like that, right? If we put in the quarterly report the question, you know, have you implemented DCI linter tool? That's like yes or no. I mean, maybe you could say, you know, have you implemented the DCI recommendation, you know, possibly using the DCI linter tool? I would do it. Yeah. So maybe in changing that second one too, has your project implemented these recommended language changes, particularly the map remains labor because, yeah, that makes no sense. You're right. I can edit on the fly if that's helpful. No problem. Yeah. I think that's a great idea. I mean, the big worry is that, you know, there are things like false positives or something that, you know, drive developers crazy. You know, some project probably has the word Jedi master in their code base. Is that okay? I mean, you know, it's just stuff like that that might, you know, might end up I guess causing extra work for developers. Okay. The comment that I had on the implementation proposal was just around getting the word out, which I think is a standard challenge that we have, the TSC communicating to the different communities, different projects and different maintainers. You know, I see the recommendation is to use the maintainers meeting that exists. You know, I don't know if that's going to reach everyone. It seems like there's, you know, people who don't have the opportunity to attend that call and that sort of thing. So I would just, you know, ask that the DCI working group think about other opportunities to be diverse in the way in which we communicate this to people, right? Be it a recorded video with closed captions, right? Be it something that thinks about kind of the sort of translation that might be needed in order to properly communicate this to non-English speakers, right? I think there's a lot of things that we can think about that would not require somebody to be available at, you know, 8 a.m. Pacific on a Thursday morning, right? When they might actually be sleeping. So just thinking through kind of the process by which we get the word out about the sort of DCI engagement that we would like to have from the different projects that have been maintained. Yeah, good point. Definitely the Dev newsletter makes sense of the one option. But yeah, no, I'll take that back to the group too and just make sure we're covering our basics there. That's great feedback. And I like what you did there with your diverse avenues. Yeah, no problem. Thanks, Grace. Hart? So yeah, I think all this sounds great. And I think like adding, you know, a line to the quarterly report, like, you know, are you following inclusive language guidelines is a great idea out of curiosity. Does anyone know if we have had any problems with these? You know, maybe I'm just naive and, you know, not following closely enough, but I haven't really seen any of these, you know, once we've sort of done the master domain switch, I haven't really seen a lot of this language in hyperledger. I don't know the answer to that, Hart. If somebody does, please raise their hand and we'll let Peter speak and maybe somebody can answer Hart's question. Peter? Yeah, I also don't know if you answered that question, but what I was gonna say is that thanks for the feedback because the tool does have a git ignore syntax like ignore file that you can put in the repo and it will just skip over certain things, which probably that I must be the candidate of, but also what I've noticed when I put DCI lens in action on cactus is that there's a configuration files of third-party dependencies that will not allow you to remove certain phrases because their configuration schema is fixed and that's just how they are and they have not updated it yet, or maybe they don't want to, I don't know. And so for those occasions, when it's not really your decision, there's a way to configure it. And my realization just now is that this should be also mentioned somewhere front and center on the guide. So I will incorporate that as well to make sure that when people look at this, this includes their first impression, this information. Okay, great. Thanks, Peter. Dano? I think it's not that we don't have, I don't think we really have an issue with it. It was just that we need to be mindful of it. There are a couple more examples coming in from Ethereum that I think are worth pointing out. We used to have in Beisu, white lists and black lists. We don't have a lot of lists and tonight lists. There used to be an opcode called suicide that was changed to self-destruct. And there is something in the consensus mechanism for blocks that are being, they used to be called uncle blocks and now they're being called armor blocks, which is the gender neutral anti-uncle. So it's just littered about that we're starting to do it. And I think the value of this is just to remind us to be mindful of it. When you see an opportunity, you should take it. Yep, completely agree, Dano. Okay, any more comments on the proposal that Grace and Peter and folks can take back to the DCI working group as well? All right, well, there was one other thing that, Rai, I think you added to the agenda last minute here. I don't know that we have time to cover it, but if you wanna give a high level so that we can make sure that we talk about this next week. Sure thing. This is the homework that Arnau gave to me months ago. And I was spurred by Sarah's question from Aroha to take an even deeper look. These are what I recommend. And I have a series of four what I think are lightweight recommendations. So I please take a look at these and give me some feedback as to whether or not you wanna do any of this. It would basically replace all of our current disparate ways of handling security stuff with a more direct way of send an email or go to hacker one. Okay, so we'll definitely include this one on next week's agenda. So make sure that you take the time to review the proposal that Rai has put out here for us to provide feedback on. And we will continue that discussion next week. In the remaining two minutes, is there anything that anybody wants to bring up? All right, so we will then see you all next week and have a great week up ahead. Thanks, Tracy. Thank you. Thank you, bye-bye. Bye. Yeah, thank you, Tracy. Thank you.