 of those key parts. We're going to have a prop. So this is why we've come into existence. We're just starting off by writing, trying to write set of rules about best taxes. How do we, in a good way, offer our help to a package developer that may want help and may not even want to give up ownership. It may want to keep ownership that may be a little too stressed of what's going on. So in the open source world, let's go to our repo, we're documenting what we're doing here. We're reasonably large team, perhaps 10 people participating in great communities every two weeks. And we're covering some very basic stuff to begin with, you know, like what are rules on licensing? How should we encourage people to follow in the same version? Because when we adopt a package, we're going to have no idea what state it's in. We're going to have some rules. Yeah, we must have a repo. It must be kind of critical. It must be something people are using. It must have lots of downloads. And you know, there must be a valid reason why we're taking it over. So we're going to talk a little bit more. I'm going to hand over to Emily here. So these are some of our goals. We obviously want to connect and get feedback from some of the package maintainers out there. Once we figure out kind of like what we're doing, we want to discuss what that work looks like and build maybe some tools for the community. Some of that has sort of gotten started, some ideas. And then we're going to need to evangelize what we're doing to everybody. So people that might be interested in this work, obviously us, hi. Some, you know, the node collaborators, package maintainers and project collaborators. We're some ideas of who we thought might be super interested in this. And this is like a basic agenda of some topics that we can talk about. Of course, we can delve into whatever people find might be useful as well. So these, this is the drafts, obviously. So if you're curious about what we've been working on and what we started, where we're at, this is a good place to start, hand it off. Idea that to the community is the support field in the package. He aims to tell to people that use those library. What's the kind of support the maintainer or the organization want to bring to the community? For example, target none. It means take your own risk or response best effort. I'm a vacation. Bye-bye. Or of course, regular seven. For example, so all day you have a support team that reply to issues. For example, backing this module is a hobby script. So beware. And there are other values that you can put in that Jason, of course. And okay. And for this stuff, we build a separate one in the term, a client tool that simply check the correctness of those information, for example, or we are adding a new comment to add to your package Jason this field. This could be useful for companies that need to choose a module and must be conscious about the support of this package. I was just going to say, can I add two cents? So how many people here already use the license field of the package Jason in terms of figuring out places? Okay, that's a pretty good number. How many people think that looking at the support that's provided information to make you something you would use in a similar way? Okay, so that's good feedback. We were thinking that by providing more information and some of the tools to help validate it, it'll let end users make additional choices. And I guess, James, that's the question. So the license field uses the SPDX format standard. For this, would the intention be to basically provide a standard format for the identifier so that they're going to introduce their own? As part of what we've documented, we've documented an initial set. Here's the initial three letter acronyms, what they mean. And the idea would be, for now, this repo would be the source of that people can PR an additional one. So they can use it every six months? It's insensible. We've tried not to make it like there's no ordering and find. So basically, if you want something completely new to PR it in, and that's something that people can then understand what you mean. And then the other, the one other question there would be, I assume that as part of the three code, there'll be a standard text, where they'll play text for each of those, Yeah, we can actually, yeah, maybe we'll go through, but maybe after we can jump into that and show with that in more detail afterwards after you guys get through. So this is very similar to something I've been personally thinking about for a while. Which is that software licenses offer this really amazing signal that you can just see MIT or Apache and it tells you a lot of what you need to know about the legality of it, but not a lot about the maintenance, not a lot about the support contract. And when we think about open source today, there's the OSI definition of open source. And that's just about the license, that's not about the maintenance at all. And that's very ambiguous and that's where a lot of problems come from. The two challenges I can see with using the package JSON format for this, and I'm not saying that it's not the right place to do it. One would be that it doesn't have from immediately looking at a repo unless it has built on top of this metadata, the same signal that a license file does. And one of the things that I've been using the term social source as an idea of like what this could be, but like in the same way that we have a license, could there be a file or three letters that you put in? Like how is a way that we could have the same signal that doesn't require having to go through and look through a bunch of metadata to parse it out? And we agree. Yeah, I think if we agree on the values, then package JSON might be one way to deliver it, but coming up with other ones, like yeah, you think a file in the repo, when we say put this file in with separate JSON or a different form totally makes sense. Yeah, and one of the things I thought about there was kind of like the way the, oh god, the CC license, like CCBY, OY, like this is like these series of acronyms that kind of tell you everything you need to know. The other small concern that I would have with the package JSON, and this is like you probably should just ignore me, but is we parse the package JSON into every single time you require a module at least in the scope of a module as part of our resolution algorithm. And so I'm not hugely in favor of throwing lots more metadata into every single package JSON all throughout the tree. Now this may just be like a micro optimization, but like because it is a pattern that people use all over the place, but my intuition is if there's other places we can put it that may be preferable, but like that's a micro optimization and maybe you should ignore me. No, no, you're right, and we'd be delighted to get to the point where we have so many packages where maintaining we could be a problem for the ecosystem. You know, but a dream of getting back where we'd like to answer. And whoa, I'm not even getting the mic. Just think about we were wanting to get to the point where like an npm init would add this in for you with the fault value. So when you get the mic, sorry. Related issue to the previous is what happens when people start to, you know, realize that they don't feel like they want to maintain a package anymore. Because at that point, if this data is in the package JSON, it would effectively require them to push out a new release with a new version in order to push out the package JSON data. And this may be too much of an ask for someone who's effectively giving up when we're dating a package. It can entirely well be considered a major change here. And at that point, yeah, asking for that is not just not going to get you the updates. So what actually you're talking about is the package maintenance team not being able to support because what we're really talking about is when we go out on board and adopt a project, it's really it's going to be a team of developers where evangelize for the weather actually be doing this, not just a developer. Right, but I guess I'll, this, this may be something that the team would do when we adopt it, but I'm in my mind, we're still going to ask everybody to put this in. Yeah. But I, I still think that if you're in the case where you've like totally just said I'm doing nothing, then maybe that's something like the package maintenance team might have a role in finding like this module is clearly been abandoned. We'll adopt to the point where you do this one we already changed that. If you're not, if you're a module owner, and you just don't want to have anybody bug you anymore, I'm hoping eventually it's worthwhile for you to do that one little thing because it may cut down on like whether you get issues, whether people are complaining and bad paying on your door, you can say, no, look, I said it's unsupported. You know, part of it is like if there's a mismatch in expectations, the users think this is a highly well maintained module. On the other hand, somebody, the owner thinks this is just a hobby that I do on the side. You have no support communicating that if you close the gap, then both people should be a little bit happier because you can point to this and say, well, this is my expectation and there's no reason you shouldn't have the same expectation. I can see in the case where the module owner just doesn't do anything, but it's really hard to do anything in that case. I'm not as worried. I just want to add that to all the points that we just discussed that even now it's more not having it in the package of JSON file because, yes, changing the package JSON file much required to be published by putting it in the repo may not be a different file and also less effort or not in the path of critical access to a mouse point. Yeah, like there's performance issues impacted by that and speaking as a person who wants to actually store all the packages on the world and just deal with the cost of that. Let's not make it fatter. But a critical thing to us is just like MPM on it or tools that can today, after you're installed, parse through all the files and figure out whether your license is okay. We need the data to be there once you've done your install. So I don't know where also that's in the package JSON. And that's kind of indicating like having a separate file that is dedicated for that is probably better for tooling creators or companies that happen to own tools to know where to look for them. How do you get those files now? You're effectively defining the specification. It's not that hard to get. If you replace the support with a URL to the place where the support's defined, I kind of agree with the point because support can change when the code doesn't change. In fact, that's really particularly likely when you abandon things. You published it and it's not so much that it's too much work, but the reality is that like all of the versions lost support at the same time. Not just the latest version. The version before is also not supported. So if somebody has an MPM install of a slightly later version because it's locked in the package of JSON, which is everybody. Sorry. Yes, the earlier version locked in the package JSON. It'll still have this word, you know, best paid, you know, any So I can have already support looking for a support not any file in every book. But all modules have GitHub reports. I like the idea of it just being like, I want you to go from the package to the information, but I quite like the idea of like, you can just be a URL, which you post wherever. I want to make that easy. Yes, that could be like the same as your main. Sure. We could say as part of what you publish as your module, you include this file. That would be worth Yeah. But I do like the part where you can change it separately. So I and also be curious, I mean, with support, I mean, like, if you have to be building out a person, like the benefit of this is it's farce, right? In support, like we could do YAML front matter, but that's gross. I might just do that same section in support. So then maybe support Jason, like, yeah, but, you know, I think that saying we shouldn't put things in package Jason, like, you know, the parsing parsing thing is a problem, especially if whatever I say, it's become standard to do that, right? That's what everyone does in our system. And I think it's, it's ignoring this, the state of the world to ask to not do that. Like that's how things are expected. And I think that if you wanted to do that, we'd have to go and like define package Jason as a spec and say anything else. And this is a validable throw, which we're not going to do. So I do think it's a little bit of a like, it's a little bit going around the rest of the world. If we don't do this, like the state of the ecosystem. And I think that, you know, this is something that people can very easily build in their personal eyes. And when I'm MPM selling, I can also run this other MPX script that will, or other package that will throw if any of the thousands of new modules have something that I'm not willing to use. I think having a parsable in a very central spot is normal, this point. The package Jason although is not really the only place that has packaged specific metadata. The MPM repository already does deprecation notices. And I'm not sure, I think it's got a couple of different, the disk pack itself that you're installing, that's part of the package specific version independent metadata that might not be an inappropriate place for this sort of information as well. But that might require a sort of defining what does an MPM package repository look like. So one more thought that's a challenge might be scope creep. So again, you can tell me to stop. Relying heavily on package Jason makes this an extremely JavaScript specific solution. I think that this movement that we're talking about here is as important as open source, is as important as licenses. And we really should be talking about solutions that are language acoustic. And yes, in the same way that there's a license field that can refer to a thing like CCBYNO whatever, the artifact that codifies this at length, I think if possible should be platform independent. And something that has that signal I was talking about before. And it is very possible that that is not the scope of what your team is trying to accomplish. But I do think that this is very important. It's something that's missing from the programming ecosystem. It is burning out tons of developers in every single community. I think it's something that we could as a foundation approach the OSI about and be like, Hey, let's work on this together. So I would challenge you to perhaps think at a bigger scale of influence and effect. And that the package JSON may actually be limiting our ability to scale this up. For licenses today, we do both, right? You can have a license field in there as well as the license sign. But here's the package JSON says license, but then the actual license file. Yeah, like the package JSON is metadata, but it's very possible that the package JSON has the incorrect metadata in there. And the license file in the repo is a different license. And firmly not a lawyer had on. I'm pretty sure that the physical license in the folder would likely trump that. So I just, I don't know that it's the source of truth, but yet it is what we write a lot of tools were lying on that being a reliable source of truth. Yes, absolutely. So I just want to echo what I was saying, which is so important to the open source You don't have to solve for that. Maybe we solve for JavaScript, I'm just going to introduce that later. I just want to also echo or annotate points for the referencing. They can have use cases or you can have examples when you create every program tells you, hey, you should have the reading file, you should have those, like that is becoming a pseudo standard almost likewise. And the the next community, like a reading file, like capitalize the license file. Those are also semi, semi, or pseudo standards. And in the web community, the browser world, the dot one note is also another example of that. The dot one note is also state because it's just free form. As long as the dot one note is the street text, you just have many files but there's a manifest. I'm just referencing those as points. I also do want to add to my lesson, kind of back that up in a previous role, I have access to a lot of the entire registry licenses and how they do them. And like random numbers and there there are a lot of typos in package JSON files. And a lot of weird things that you wouldn't expect to be in the license field of a package JSON. So like, yes, I agree with that. Slightly different question. Have you figured out how do you relate to the emeritus projects of the OpenJS Foundation? I don't think it necessarily relates directly to whether you're emeritus or something else. It's it's more about like, if you could be an emeritus project but still have active support, right, like it's it's not about we're adding features, we're adding this, it's more like if you if you report an issue, what kind of response can you expect, you know, is there is it going to be like never or our best effort or well, we usually try to respond within seven days or and the target actually is around what versions of note you're supporting. So that's actually a little bit note specific. So I'll go back and say we should absolutely try and generalize and you know, we don't want to limit ourselves there. I think we should put something in place. We think we'll work there and then go and say, well, this is actually a broader issue, but like a working example is good. The target one is about like, these are the LTS releases we support. We target supporting all LTS releases or just the latest LTS release or all releases, right? And that's still an emeritus project could choose any one of those options, right? It's about as a consumer, when might I have to change for update, like because the very next release current comes out, that's all I support. So I got to do that. Actually related question. How's that actually different from the engine view? Engine, I think says specific versions of note, right? So maybe there's some overlap there and have to think about this was more like, you know, you could say the one week that we can look at the things we define, but like LTS was like, we're targeting supporting all LTS release and no one particular version, but like today is eight and 10 and tomorrow is 10 and 12. It means 10 and 12. So the timing may be the thing that affects it. And then the backing one is like, for an emeritus one again, I think we still have a foundation, which sort of says like, what kind of backing is there behind us? Is it like one person in their basement who just does it for fun, which is the hobby one, or is there like a business or organization that, well, it's not like you can choose one module versus the other based on that, but it's more information like licensing. I just wanted to add, because what Miles was outlining is actually, you know, I think the pitch of what type list is doing. So when you go in and claim a package and type list, you can indicate in there which releases are obsolete LTS maintained whatnot. And the whole model is that the corporate side, you know, we would ingest type of status, you name that flows back into paying the package managers or package containers, and we get the data of what's supported and reports all of that. Right. So they're, I believe they're, they already have that implemented and they are also working with four side or talking to a side on it. So it might be worth chatting with them and seeing if there's some integrated work. Do you know contacts or who, I personally, I wasn't willing to talk to them, but I can certainly look at them. Yeah, I think you can find us in contacts who might be interested in talking to us, we have also evaluated to collaborate with the greenkeeper, for example, for adding new feature and new automation, let's say. So we have starts to talk with them, but not build something useful right now. Looking at the image, I noticed that all the things are uppercase, all those target response backing and everything else lowercase. Is the uppercase mandated or is it in terms of, yeah, we just, we just made them all uppercase. Okay. Like even the name, name, property value has to be lowercase. So like, I, that's totally like semantics and like small things, but like the rest, a lot of the rest of this ends up being lowercase by the fault. Is that something that could be changed? Absolutely. Like there's a reason for them to be lowercase. I think it's where it came from in a lot of cases, if we have short forms or acronyms, those tend to be capitalized, but it's nothing more than that. I was just curious about that because it like stood out to me from my, and my experience. Yeah, like I don't know, what do they do for licenses? It's the acronym, but like none invest effort or acronyms. Yeah. Okay. Yeah. And I think some might be lowercase, like it's like, I'm not, be like, MIT is an acronym, but if something's not, I don't open this place. Okay. So we just like, we might look at that more carefully and just be consistent. Yeah. This is also in graph. Yeah. We can fix it. Thank you. Okay. What's next? Next, we have, no, no. Yeah. Then we have tried also to list all the criteria to understand which package needs to be helped first. So we have tried to recap all the a long, a long, a long issue that has been discussed. And we finally built this, this list. So what do you think? We have for sure the number of downloads, the module, the number of the downloads of the dependency tree. For example, there is a package that is useful for Express that is used by Express itself and not directly, for example. So that it was tricky. How many packages depends on the module? How the number of the dependency, in this case, for example, less dependencies could be more easy to fix that module. We, of course, evaluated also the test against the number ration, because this could be more secure to help that code base in order to don't break, of course, the API. If the dependencies are updated or not, if there are also deprecated dependencies, if the repo has many issues open, or, of course, if it's maintained by the company. We don't have an answer for this question yet, because we don't know if we want free, help companies, in this case, for example. Of course, the last activities. The maintainer are working on that module or not. Most recent, yeah, it's a plus. So I think that this list could be more long. Do you have other ideas? Are you familiar with npm.il? There's a lot of pretty good metadata that comes from that that has things like how many commits were made between releases, whether or not there's a review file, whether or not there's a license file. A lot of the information from that project might be helpful here too. Thank you. I personally, I don't think that I have listened to that sign first, so we can rest of you. I was just curious what you meant when you said that you want to help. Do you mean like you want to reach out and ask them, also maybe for feedback about this process too? I mean I guess the point is to help them to be like, hey, we want to help you make sure you don't burn out or someone will take care of your package when you're done. Correct. First, we have identified some pilot packages that help us to help them, let's say. So we can try the tools that we are going to build, or also workflow and process, and then bring all this know-how to the entire community in order to help like without any bias, let's say. But for sure we have to, in the first step, we need to go with little steps. Let's say the pilot packages is the first. They find the list of all the packages. We don't know how many, for example, but without prioritizing our fans or something like that because we want to be agnostic, let's say. So we try to list those routes in order to find potential maintainers that needs help. I just want to add a couple things to that. So there's two parts. One, we want to figure out how to let people and companies care help maintainers. So if there's businesses who really depend on a whole bunch of modules, it's a risk to their business if those modules are having problems keeping up the day, being maintained. And so ideally, some of the things we talked about is tools which matters to look at, say, help the business understand, here are all the modules you depend on, and then hopefully, how do you turn that into a business case and turn it into say, let's go out and make contributions to these modules because it's in our own business. So there's sort of that angle of not just the package-making team going out and helping, but trying to help close the gap so that people who are depending and get the benefit can help. And then separately, we got quite a good number of people who sort of joined the team saying, how can I help? And we're trying to build a smaller backlog list that says, if you're interested in helping, here are some things that package maintainers, and that's where the previous ones, we can't do that for all modules, but critical models, here's some places where you can get involved and help as useful because a lot of the time people are like, well, I don't know how to start, right? So it's like to build a backlog that says, here's how you can start, and a bit of a team that can help people who want to get involved, maybe bootstrap them or whatever. So that's what we mean by the help side. So on the, on this? When you're, is this on? Yeah. That'll be close. Okay. So when you are saying to have people help, do you mean help this team, like figure out these processes or tools, or do you mean help like the maintain packages that are becoming a longer maintained? Right. It's to help the actual packages themselves. So yeah, like we obviously want people to help with this stuff in place, but the end goal is to try and get more help for the end, like solve the problem, right? Yeah. So you're trying to curate a list of package maintainers if you are willing to try to get help more. Right. Exactly. Like they're, we think that it's important for the ecosystem to work with the sex possessive node, they're interested, and we can help build a concrete list that then other people, as opposed to like, if you just say, hey, everybody come and join my project, it's, it may become that that's actually harder. And we're hoping by having some organized group kind of figure out the way those things work, we can make out actually better for the package. It's a hard problem, but that's kind of the goal. I really respect that a lot because I think that one of the things about volunteer, voluntary, like associations and programs is that it's hard to get started without a human like to interface and like kind of hold your hand and like, encourage you even like, for the first few steps. So this idea that, that you're going to provide a human interface to people who want to get started maintaining or want to help making packages, I think this is super cool. So. So on the previous slide, on the terms of the criteria, whether it's supported by a company, you know, I would stress that really needs to be tightly watched. You can see this as being a vector. The company gets a module out there, they decide they don't want to support it anymore. And they basically rely on the community just to kind of take over free support for something to do, but out there, they're still averaging benefit from. So, you know, whether they want to help or not, I think you actually want to emphasize on that, are they the sole supporters of this thing? And are they basically abandoning it, you know, expecting the ecosystem just to, you know, keep it going. The other thing that we need to watch here is, when does an open source module become a company supported module? Right. So when an individual is working on something and they get hired by a company, right? And that company is getting commercial benefit out of that module, right? Is it still the ecosystem that we still need providing support for that? So when do we pull the support back when there's a company involved? Yes. These are the things we are discussing. So it is early days here. A lot of the work we're doing here now is perhaps most exciting as their full work of writing code. But unless we provide a framework for all of these people to operate within, then we won't be able to do this. And we know eventually we're going to be right. The ecosystem is getting very large. And we're seeing some people get reaching the points in their life, as I said, well, perhaps they can't do all the things they thought they could do when they're a little bit younger. They have some different objectives. And these are now critical for not just for individuals, but for very, very large corporations. But unless we have a framework for handling this, we won't be able to engage those other entities. It's really those other entities that will have to be engaged eventually. So one of the first candidates is a package that I inherited long ago, which is MQTTJS. This is long, long ago. I inherited this between 2012, 2013. Did a lot of nice talk, conference talks about it, and so on. Did a lot of nice examples of things demo. Then my job, like, changed what I was doing. And I'm now a MQTTJS as part of my job at all. And right now, the repo, we just pushed a major version out. So things are not super bad. The main problem is that it has 130, 140 issues open of people asking for anything. And there's no absolute zero time to even start to tackle it. There are several issues in the repo itself that, for example, we are tied to an old version of MoCA. Well, we're not tied, but we run MoCA with some legacy flags, essentially, because the tests are super flaky. So essentially, it's impossible to say that something is passing or not. So this makes doing any work very, very hard. You just run it several times and say, okay, I'm confident enough, this is not breaking anybody. There are several reasons for that. And because it's a very old school base, it grows inorganically or, you know, it grows with sprints of people working on it wanting certain features and then moving away very quickly. And, you know, so just want to say that that's a target. It's currently used by Microsoft, IBM, probably, well, I don't know, I need to check that for IOT SDK. This is my shaming moment. So we chat as well. This is recommended by WeChat in China. And there is issue being posted in Chinese. So just so that you know, okay. A lot of, it's been used in a lot of fun places, but more of it's part of the dependencies of Node Red, which is an OpenJS product. And yeah, that is the situation. This is basically a tiny group of people that's, you know, trying to keep up. There's one volunteer in Comments Support for MQT5, which is, whoa, but still, it's essentially very, it's very hard. There are certain issues that need to be fixed, very hard issues related to connection as somebody has, there was somebody that did a fantastic, well, I don't know if they work something. Yeah, somebody posted an analysis, a text analysis of all the issues that have been opened. So somebody did a, this is amazing tool that given a bunch of issues, it tells you what are the key topics. And one of the key topic is connection management. And I know perfectly why people get freaked out about connection management. Okay. And, you know, there are bugs there. They're not bugs, but, you know, fundamental issues in the library that, you know, if you give support of flying mode, so if you want support of flying mode, then you support Reconnect. But then if you can connect, how do you distinguish the fact that you can connect versus the, versus a server that's now there? Okay. So that is kind of a fundamental issue in the library. Yeah, I just want to say all of this is all the problems. Okay. And this is very typical, unfortunately. Express is the major thing that the Express team is doing is doing support requests. They are always asking for people to have them with support requests. The reason is this is what these two modules have in common, they are used by people new to that. So essentially, they came by, a lot of people came by, oh, this is just a thing. I don't know anything about this. I think I am in the case of MPTT, I'm just trying to get something up and running quickly on my USB Pi or on server that I know nothing about all these technologies. And then they say, what is this unmasked thing that they need to use? And I'll, you know, I'll go and deal with that. It's a topic, you know, and, and that's kind of the bigger, the bigger, kind of the bigger issue now that there's a lot of community work to be done. Most of the time, like great template says, hey, if you have a problem, no, yes, thank you, go there. Don't stay here. This is, you're about getting any help here. Okay. And stuff like that. If you post an issue in Chinese, I know. I'm sorry. Like, you know, that's the thing. We feel awesome by Jason. So we need support. So I guess really, you know, just to end up that, you know, this is just some of our initial ideas. You know, we want to figure out what works, what doesn't work. So we're working on best practices, but we also want to think about like tooling. Is there some common tooling that we can generate that helps package maintainers in the end? Obviously, we don't want to tell anybody what they need to do, but in a lot of cases, if you have a best practice and a tool to back it up, like, why not, right? Like, if you have a reason to do something that's different, go for it. But again, it's like trying to avoid everybody having to figure out some of these problems or things that can consume a lot of time every time over. So like Neil mentioned, well, how do I deal with like questions that are like not related to my project? Well, maybe we can come up with a tool that helps you do that more easily or tools that, you know, also in terms of tooling, like, you know, there's a bit of work to validate the support level, but we'd want tools to help you generate those kinds of things. So it's just to say, we have lots of other ideas and that's other things we'll be looking at in the future as well. I guess that's the end of our, there we go. So the people are here today and there are quite a few more that I tend to meet regularly. It will be a slow thing to start off with and the first few packages we help out for probably teachers an awful lot and a lot will change and many of the things you've mentioned will probably come to fruition will change and we'll learn. But unless we do this, we will know what will inevitably happen to the system. So thank you everybody. And I'll throw in one more thing before I ask questions. Just, you know, I think we got a lot of really good feedback on the support idea. We'll incorporate that and our next step was to start like socializing that more broadly. So if you can keep your eye on the repo and jump in to make sure we understood what your feedback was and incorporated it. But that's, you know, sort of one of our main next steps is to try and start get that out there and figure out how we make it or make your reality. So I think I'm out of the question here. Amazing work question. There's a meeting from Monday. Is that so that? I can't make it. Yeah, like unless somebody else like, I don't know, you can post it or let me check. Okay. Yeah. And I guess that's a good point. Well, I was gonna say, but two weeks from now, we'll have another one every Monday. Sorry. Yeah, every, every Monday, right? Every Monday, we have one. Sorry. Every second Monday, every second Monday, 3pm Eastern Standard Time. We'd love to have more people come out. These are the kind of things we're talking about. If you can't do that, it's all in GitHub. So contribute there too. But yeah, very good point. Enough questions. Thank you, everybody. And it's going to be a slow process being with, but once we get going, we know this is a reasonable approach to take to things that are critical to the ecosystem. And if anyone has any ideas, we're more than willing to listen. Thank you all for coming.