Video details

Michael Dawson: Next 10 years of Node.js


Michael Dawson


Well, welcome to the follow on to the next 10 years of Node.js, a session that we held at the collaborative summit. We had some really good discussion there and, you know. But it was longer, longer discussion than we could possibly fit into the two hours that we had. So this session is the first follow on. And I had a proposed agenda, which was to talk about logistics schedule, so forth. Talk about some initial priority streams that we would work on. As you know, there's lots of different topics in the original box. Note where we were brainstorming the areas we should talk about. I mean, I think we have to pick like one or two to focus on to start with. And, you know, we did do that. We did do some of that in the initial kickoff. So but I think review that and agree that that's where we're going to continue to work. And then one of those was, you know, I think we had a few different topics, but my take was they all sort of related to technical evolution. And so I thought we could sort of continue those discussions, as in the time that we had left. So that's some good to people. Objection. OK. I will take a silence. Yes. Let's move forward. So the first one was on the logistics and schedule, kind of like how do we want to continue this discussion? I think, Meatiest, you were, you know, some of the questions you had were hinting at, you know, we could set it up like one of our teams are working groups where we have like regularly scheduled meetings. We can have something in the calendar that then auto generates issues, that kind of stuff. And if you want to expand on your thoughts on that front. Yeah, so. Not sure if we need a working group, although it might be helpful, generating each other's at least. To help folks know, Andy, when these meetings are happening. Indeed, not working properly. We had experiences with meetings without issues, and we ended up moving to. Those extra meetings, speeches as well. Because folks who'd I did forget are would not know the. The link to the meeting. Yeah, that probably makes sense. I guess that assumes that we're going to like have a number of, you know, ongoing meetings, which I think to get through this we would need to do. I don't. But as I I guess we should make sure everybody thinks that's a good idea and that we should plan for that. Yeah, I think we need at least several meetings and last we decided to have these discussions on. Hey, any anybody else have any other thoughts, comments they want to make? I can volunteer to add Callendar. Lash auto generation. So it won't be too hard to do. I guess the question would come back to then similarly related to meeting times is logistics. I tried to pick this time as a. As a time this kind of between Pacific and European time, but I don't know how how well that will necessarily work. I do notice we only have like we have three people on the TSC. We don't have certainly don't have everybody who is at the summit. Perhaps it's something we can try to hash out in like the issue itself are an issue, just like do a doodle or something and maybe mention members or a different way to mention all active people. Right. Could be interested. Right. We are probably going to need to rotate the time. I could do it. Yes. Give me things. If we want people to be able to certain. Was it even a good time from today is in between for several time zones, sometimes songs, that is too. It's the middle of the night for some time zone. So. So, mate, maybe. Could you use the famous prom that he has meetings and rotates among those four times as well? Just not the same time as the GSC meeting or that week. I think that's a good idea. Because that's like that way we don't need to figure out additional times. And we know that people like to see members, for example, at least some of the weeks are available at those times. Any any objections to doing that? OK. So I'll assume that that makes sense in terms of times. I guess it's like how often to try and get together as the other. I don't know. That Weekly is going to. Like weekly field at another weekly meeting for me, I'm just not sure. What do people think? Weekly feels too much. Yeah. Like, I almost wonder if, like, I mean, it's the yeah, the erosion, it's hard because the original idea was like, you know, a summit where we could come together and you can make a lot of progress because you've got everybody together for for a substantial amount of time. The longer we sort of drag it out, the less you get of that momentum. But on the other hand, you know, not being at a summit, people do have all the other polls on their time and. I'm tempted to say, like it's either, you know, biweekly or every four weeks would be my suggestion. I guess four time zones, that again becomes an issue, but I'm good with either. I yeah, I, I think we can probably just pick one and then and change it if we need to. Yeah, I think it may have to be every two weeks if we're rotating time zones just because otherwise we could go a couple of months without seriously. Yeah, maybe we should start with that and see how it goes. OK. So then I guess that sounds like we've got any other logistical type things, do we think we need a repo where we should we put issues, that kind of stuff? I'd say yes. Just as somewhere where we can look for the generated meeting issue. And also maybe store minutes. Yeah, it makes sense. I worry a little bit that it may not get visibility, but. In terms of probably still want to try and have some discussion in the main repo as well, or make or figure out how we make sure that it's not, it's it's very visible that way. And it's do we have any volunteers for opening an issue like opening an issue in the admin report, ask for that repo. I guess we'll come back to that. Any other logistics or stuff like that? OK, so let's move on from that. So the initial priority work streams, we can go back to the issue, which was the Google doc from the first session. Repace here. I'm in that session. You know, we we spent a little bit of a little bit of time on looking at what were the things that made. No. Just successful in the last 10 years. What were the key values that supported that success and what worked in the management of project and what didn't? You know, we didn't have a ton of time, but you can look at look through that issue in terms of, you know, the things that we summarised. You know, it called out that as if I just look at the from that we did a fun retro guard and the things that were sort of the top were, you know, key things that made note successful in the last 10 years package Eco-System key values that supported such success for focus on enabling collaborator's focus on helping new collaborators. And what worked in the management project, what did not, was things like working groups, consensus seeking, although there was a comment about how we can be more efficient on that front and how we handle larger changes might still be a bit of a challenge. And getting you don't get diversity of people in the meetings and time zones, I think was also seen as a challenge. Terms of, you know, maybe what? That didn't work so well. We then got into, again, looking in through the file, we got into some key technology trends, so things like TypeScript WASM discussion of a no just sporting browser, API is networking standard static and a hard time compiling. So things around WASM Promise based API is better diagnostic debugging traces as some of the, you know, the key technical trends that are important to the future success. That was one of the things we sort of voted on in and start to date to dig into. And I think it's something we can continue to. Talk about the. The second one on the list was we talked about should we have a road map, priority list or something along those lines? And, you know, it was around for the what would be key for the next 10 years to agree or, you know, degree that we need to focus on to be successful for the next 10 years. I'm just paraphrasing. Someday, you know, there was a bunch of interesting discussions in there about like, you know, how do we get things and how do things go into core versus not, you know, or just, you know, the small core, the small core, not small car. There's also the what is it? You know, are there. What does it mean? Are there things that, you know, maybe you want to be in the node project but don't necessarily need to be in core? Should they be delivered some other way, like through, you know, libraries or something like that? That's Tom. So that, I think, is like the very high level summary, and I'd recommend, if you want to get back to the details, you can. It was recorded so you can go back and watch the session. I proposed for today that we look at the agenda as the you know, it. A number of those came down to looking at like technical evolution. So what are the key technology transfer? No, Jess. Priority seems strategic investment areas, and I guess maybe where we can start today is like if we agree that there's some key technical technology trends, how what's the best way to surface those, you know? You know, and capture them and sort of communicate them. And so I had listed in the offices the potential deep dive area for today, which. Is, you know, continue our discussion on key technology trends. No, just priority themes, strategic investment areas, priorities of consistent, which sees hierarchy priorities and what gets into core. I'd suggest we start with the second one, which is like. How do we think we should capture, you know, what we think is important for the project, which should be focus areas like I am not necessarily, you know, a roadmap that says feature X is going to be in release Y. But the first starting point would just be even like, what are the themes that are important and that we're focused on? That makes sense to people. Is the question, why do we want a list somewhere in a repository? Well, we're present treatment, light issues and stuff we're presenting the high level technologies we see is important. Yeah. It's like how do we how do we think to best capture and communicate that? Right. Like, you know, we could say, well, we should have a detailed road map. But I mean, past discussions haven't led us there. We've had the strategic initiatives as one way to do that. We could say, like, you know, we should have a strategic initiative for each of these things, although those have mostly been like things that are active versus, you know, this. I think we had some discussion around areas we should do work. And even if we don't have, like an active champion and work on going. Right. I guess my first guess would be if we're going to be setting up a reaper anyway for like focus areas for the next 10 years, could they originally start off as issues in that report? We're going to be using for meeting issues anyway? I think that's good for discussion. I thought here is like, you know, can we come to a recommendation as to what we think we should have? For the in the end, it's going to be part of the node core repo or the cause, because this really needs to be integrated. Like, you can't be like, hey. Some small subset went off and thinks these are the important. It's like it's got to be this is what the project. Has decided it is important and is communicating that right. So maybe, Darcy, I'm going to see, you know, from the NPM experience. You have you have like a strategic three themes or anything like thought that. Has been used in terms of long term goals. Yeah. We're putting those together right now. Obviously, there's been a few changes in this past year or so. So there's a few more people at the table. And we're you know, I think what has been the goal since I joined up almost a year ago now has just been that we're trying to, you know, collaborate more with the node project and bring our folks back to the table here. And I'm excited about, you know, what it means going forward in the next 10 years to continue to collaborate and work on great initiatives together, including broader standardization of certain aspects of what it means to build a node project. Right. So package maintenance and those sorts of initiatives and projects are sort of the things that I see more more standardization and even changing for us, changing the governance of sort of how we we work and hope, hopefully including more people to come to the table with our projects specifically as kind of the hope for that. So we kind of like it's not formalized yet, but it's you know, since I've got to do since I've been maintaining NPM as of last July, that's sort of been the hard work is is cleaning up and trying to organize the project in a way that will hopefully set us up for for long term success. And yeah, and I think there's a lot of work to be done around standardization and changing governance of our project. And now we've got some great, great people involved now with the project. So, yeah. Yeah. I was just wondering, more like not the content but like how it's captured, communicated. If he had any plans or thoughts that. Yes, so that's not been done. It's still still it's the fruit is still in flux there. So, like, our road map is not 100 percent like external, which is not great. Right. We tried to do a good job, a better job at communicating like what's coming down the pipeline. We were using GEB project boards before, but there's no real road mapping tool which kind of doesn't communicate well, sort of the longer initiative like the right. LongTail initiatives. We have been using Zamenhof bit for that kind of stuff to get those graphs, but it's not exposed. There's no transparency there to the community. So that's something that I'm actively trying to figure out how we can do that. Yeah. Again, we can communicate where we think we want to go. And no longer. Sara LongTail. Yeah. OK. So I was just wondering if there's any things that I brought back. No silver bullets. I don't know. Anyway, it's I always figure it's worth asking if there's something we can look at and say, hey, should we just adopt that? Brett Bradley I'd go back to you know, you were talking about, you know, priority theme or sorry, constituents or priority of consistency's. I think you were talking about. Yeah. So this is actually documented with that. I think it's the H2 male spec itself under the design infrastructure and. Currently, we don't really have any prioritization on what makes a feature a good fit for node's core. Right. We also don't have any sort of guidance on what a feature needs to focus on. Right. So we get a variety of responses to Pier's, which are somewhat conflicting if you look at them as a whole for the project. Some peers are claiming that performance is the most important thing to a specific API, while others are acknowledging that they are not a incredibly performant API, but they are a useful API and we do these very ad hoc. The priority of constituencies is basically a rough guideline. Of course, there will always be exceptions or conflicts within. The states. Things like users should be valued over implementation, over performance and things like that. And it gives just a guideline that when we're having these discussions, we can state that one argument should have a higher priority than a different argument. Right now, all arguments are treated equally. And that means that when we encounter a blocking scenario, because two things are in conflict, we don't have a way to kind of argue about what is best for the project. Right. And so we end up with deadlock and things just stall out. Right. So it's almost like like I can see that, like, you know, in terms of what are a gap maybe is is we don't have, like, the mission statement. Then from that you could see you could have this priority like water, you know, the mission being what are we trying to accomplish? And then the you can have that priority of cost cuts to Insys, which kind of says and as we work on that mission, this is what we think the order of like. You know, we have this is important, but not quite as important as this other thing and so forth. And then below that. You could see I don't know, I'm just sort of brainstorming like we could see a set of, you know, not. And maybe I'm just mapping out the standard. Like, then you could have goals to say, OK, now this is what we're trying to achieve. Like, these are. These are, you know, not more specific goals, like we we believe we need to have be a first class platform for WASM deployments or we need to be a first class. You know, have first class debugging or something like that, and then, you know below that you can have a roadmap or whatever, which I'm not sure we'd get to. I don't know if people have seen open source projects with something like that or some alternate or. I see it in design docs in particular. I don't see it as roadmaps in particular, design docs are often stating what they are prioritizing and why. And so let's think about this like import maps. The design doc for it has a lot of focus on performance, stating that even though the priority is basically usability for the Web as a whole, this feature is exceptional. And although it is very difficult to write a import map yourself, it allows a better experience. So while the experience of the import maps themselves are kind of poor and the performance is the optimization that they're doing, they're doing it in order to get kind of this other goal accomplished of a better user experience. So they are able to prioritize based upon the India user experience rather than a tooling experience. For example, Vrai, on acclaiming this document as a source of truth. Wondering if anybody else has any thoughts or suggestions or like on what we think the project should or should not have. Like we could also say, oh, no, no, we shouldn't have anything like this. I mean, we can talk about individual features, if that's what you're asking, are you still asking a kind of a higher level organizing? I'd like if you know, so for example, we say it's strategic for the success of note that we have a great WASM implementation. Where and how would we document the. Like it. And so they. And, you know, and do that in a way that it influences the, you know, the goals of the project, the direction of the project. I'm just picking that at that, you know, maybe not their thing. But like any anything like that, like if we think there is something strategic to success going forward, how are we going to capture and communicate those things? Question, there is no if even if we have these things, I mean, this is an open source project. People usually work on things they find interesting and fun. Like, if you're at a company, these priority lists makes more sense. That's because that's where you allocate your resources that you're paying for. But that's not the kind of resources we have in this kind of project. It's more like what the people think is from and what the people find interesting. So let me you a priority list of things. How how does that affect that? Well, it like. So I agree. But but unfortunately like that. So we could, you know. We could also agree that says, no, we should just, you know, the next 10 years, whatever happens, happens. Right. But I am I'm I'm not sure that's the best strategy, right. Like this, because what you say is true in that we can't actually, you know, nobody's getting paid to do different things. But that's still in my mind, doesn't mean that we shouldn't have a view on what we should be doing to make sure that no continues to be successful, whether it actually happens or not or people work on it's a different thing. So I guess I mean, what we're looking here is kind of a wish list where we would encourage people that have time and interest into working with something, encourage them to work on specific things that we think are valuable that we're we're looking for. Yeah. I mean, it should be like from our views, like, you know, it's got to be the project participants views that these things are strategic. I guess another good point is that if someone does want to work on a specific feature, they can refer to that list to see if it's likely to be enabled. And matched an without without because at the moment, the only time you find out that your feature is not wanted is when it gets blocked. Being merged into call list would serve as a kind of. Check. Yes, I want to work miss and yes. Well, now it's kind of raining. And I think even extending that, if we kind of don't lock this down is like, OK, we've done this and we're done. But more try to approach it as we've published this. And, you know, we're open to adding things. I think that that also helps in that case. You know, instead of having to get blocked, once you've done the work, you can kind of PR it to the list. If it gets blocked on that, then you can. No, cool. I'm not going to waste my time doing this work, which is like one of the pieces of feedback I've personally heard from a lot of folks who are outside of core that they Pyar something and it gets shut down for X reason. And having that proof of it being on the list and being something that's validated would actually help decrease that barrier. Yeah, I think it's like. Right. It's it's highlight. And again, it's got to come back to. We've got to believe there are things are strategic. Right. And if we believe that, you know, this is important to our success, then as Tierney says, it helps people identify areas where, you know. The project has said, oh, this is strategic. So so contributions that move that forward should be better received than something that is like, oh well, you know, that's interesting, but maybe not important or strategic or, you know, to other people in the project. Right. I would go a little bit further, even saying that it's not just the authors of PR, but people reviewing things could have a better sense of what we're aiming for right now. When you're reviewing, you often take a very personal viewpoint to what you want to see in court. And so we can have things blocked because we state that it shouldn't be in scope of node. But if if there is a project kind of list of things we do want to see in node, we could actually stay. You may personally not wanted a.. But it appears to be something that the node project is working towards as a whole. So we don't have existing examples of this. We actually removed extension list file support from our E.S. module loader because we wanted to fix a problem with Web assembly. And so that was a rather tough decision. We ended up dropping support for something because we knew in the future. Well, as the modules working group, we felt that it would be important to support Web assembly and we didn't have a good story for it. So it kind of also goes in the way of. It lets you review things in light of what's coming up ahead. So you don't introduce features that are going to hurt you later on. I tuj plus one to that Bradley, I have seen what you're talking about. Again, in the context of like contributor's being feeling unwelcome or being feeling like they got shut down unduly by like a single objector. That is a huge thing. And I think having that validation is a good way to kind of help address that. Additionally, you know, I think this also potentially helps address one of the pieces of feedback that I've heard and that we we've pushed hard against in the past, our past, which is like no doesn't have a roadmap. And I feel like we're pretty intentional in not having a road map. And I think that while we're not going to have a road map, I think that this helps at least give a proposed road map or proposed vision, which is what people are kind of looking for in a roadmap. And it kind of solves the thing of here's what we want to do. We're not committing to this fully, but these are the things we're interested in doing as a project. And that kind of gives people a way to rally behind certain things. So it helps us prioritize certain features. If one is something that are, you know, large amount of the ecosystem really wants, that helps us prioritize and have a signal. That also helps honestly to the point that was being addressed a bit earlier is full transparency. A lot of contributors to note are paid by companies to contribute to note. I am one like I am able to do this on work time. A lot of other people are too, and it helps. Justify more of that. So it helps justify people be able to say to their can their company. Hey, I want to go ship this in node. And then they can do that, which I think is at least how node works now. And maybe this is something we want to change and that's fine. But at least how word node often works. Now, I think that that is a beneficial thing to be able to give people a justification to be able to come work on the project as part of their work time and be compensated for that work through their employer. Right. And I agree with your comment on, you know, I don't think we wish. We probably don't want to use the road. The the the roadmap where because that has often the implication of this release. You're going to get this this feature. And I don't see us getting there because of the volunteer nature. You know, we work on features and they kind of get in when the when we've got them done, which and I think that that's worked and that's fine. This is more about the what's our vision and how do you align the work that's going on with that? That vision, a collective collective vision. And I think, like, you know, tyranny identified a few things that that you get out of that is that, you know, people can then point that the work they're doing is aligned with the vision that that vision. You know, in theory helps, you know, business goals as well. And even like I think, you know, there wasn't one good example or I saw call asking putting out a question that said, well, hey, is wasn't important to note, you know, should I keep working on this? And, you know, I think it kind of helps answer some of those questions as well. So it sounds like there's there's support for capturing things at that level. It's, you know, where. Where should people see those? And how do we communicate them? I think that is a filing core is going to be our best bet because, like one of the things I've seen. Sorry. Sorry. If I die interrupt you there, Michael. No, go ahead. Yeah. OK. One of the things I've seen is just that things outside of court that I talk about core get less, you know, care and attention and affection and maintenance. And I think that having this as a thing like committed to core is, you know, I guess ironically, you know, we're committing to it to some extent that this is a thing that we want. And, you know, by literally committing it into core, I think that helps solidify our assertion. And it also like, you know, if someone comes in and it's like, I want to contribute to Noto, here's this file with a bunch of things that are like, you know, things that they would like. I can probably work on one of these. And then they can go from there. Like, I think there's a lot of benefit to having it in core over separating it somewhere else. Right. I would agree. I think it also gets more scrutiny as it lands. So and we want this to be collectively agreed. And if there's going to be arguments, discussions, I should say, maybe that those happen upfront versus later on. Right. Hey, Michael, I actually want to bring up a point. You know, I like Peter's point, but I was thinking more in the terms of having a visual task more or something like that, which we can have now and get on. You know, why do we have something like that which people can just go and see, like, OK, what are the new features that are there and have like a file attachment to the features that give a bit more descriptive, like, you know, like a high level overview kind of thing. I was thinking about some sort of way. I think that's maybe a little lower level down, like one level down. I am my one worry is we do have some boards, but the maintenance of those. We've had a hard time keeping up to date with them. Yeah. The other thing I'd say to the the board thing is if, you know, we wanted to do that, we could implement that over this. The other thing I'd say there is. It it is a we we as an orig are very get and get heavy in terms of like managing everything, things division control. And I think sticking to that and making going through it in a way that is familiar to everyone who we spent here for a long time and who who is coming into the projects is going to be the way that we have find most success. This right. I see you here. This feels a little bit static like it. I think it just just gonna be a few people that actually care about this document that will actually get expressed. You know, the opinions and what they feel is important. I don't have any better ideas, but some companies, you know, let you create a request. Then anyone can go in and votes, you know, a thumbs up that they think this request is important that way, capture as much feedback as possible on the one that's specific strategic initiative or whatever, because that's important for me. We have a document. I feel like maybe 10 percent of collaborators would actually be represented in that static document. Right. So are you. But because that that's a very important part is it needs to be collective. So I guess to that point and kind of backtracking or undoing what I just said about, you know, having as a document, GitHub does have their new discussions feature, which includes voting. And so you can have a category. And we could have a category for that. And then we could just use to get a BPI to pull that stuff into a dock and automatically update that. If we want to, like, automate that and have that be like a more static dock or a dynamic and unofficial dock. But if we wanted to go down that path of like having a more eco system, wider communal thing, or having this be a staging process into that, you know, people can have open a discussion, have it be upvoted or downvoted, and then over time we can kind of pull those into the dock or we could have that be the thing itself without. That would also require less maintenance from us in terms of like the project board. But I mean, maybe that that's the process to get it in or something like that. I don't know. Or a process to have, you know, someone from the TSC or core, you know, commit something in or propose something like haven't haven't been on top of that maybe as an additional path to getting stuff in of like, you know, some some random person comes in and says, like, hey, I went typescript support by default in U.S. or in our, you know, loader. And I doubt we're gonna do that. But, you know, if that gets you five hundred thousand votes, like maybe that's something we should consider as something to listen to from our ecosystem. That's almost like that that I still even see. Like that example is a feature request. And that that that makes total sense of what you just described. But thinking almost a level above this, like has the project decided that TypeScript is important to the success of note or not fair? And yet, like, definitely take that example with a grain of salt. The first one that came to my head. But like, you know, as an example, a thing like a vague insert, whatever example you want there. Yeah. Like, generally, how do we to address that. Yeah. It's important to have a path for people to suggest. You know, it's the how do it how do you suggest something new that gets in to the things that are important to the future of Noad? And how does how do we gain enough input? Collective agreement that they are important. Right. Because like the typescript example could be, we could say, well, type scripts, you know, it's gaining popularity, but could we just ignore it? And Noad will succeed. Maybe right, and you could make that decision or you could say, no, no, no, no, no. We'll be successfully more successful if we provide a good experience for typescript developers. Therefore, we should do X, Y and Z. Right. And then when that request comes in, then that sort of has a sorry. Run goes. There's no aspect of this is that there's different levels here. Like we have the T.S.A. with collaborators. We have contributors. We have users. Yeah. Most Pacific order there of importance. But but who gets, you know, who votes and who gets to create the actual, you know, requests anybody on that list? Or, you know, how do we separate that? I think the like it can't it can't be a strictly voting thing. I think, like the voting would be input in2, you know, we can't tell it like you as you as you were mentioning earlier, we can't tell people the what to work on. We can't force people to think something is important when they don't believe that. So this will only actually be helpful if it reflects what the project as a collective believes is important to the future. So I think I think input from end users makes a lot of sense. But it's got to be, you know, the collaborators who have said this is what we believe from all the information that we have. This is what we believe is important to the project and what we think we we need to do to make sure we continue to be successful. It makes us. So I think it. Yeah. I mean, I think it would be interesting, like we could spend a lot of time on the processes. But I think it would be useful to come up with work. And one of the early things we could try and achieve is like, what would that file look like and what would be some initial contents? Because I think making it tangible on that front would help to get more discussion, input and so forth. Right. There's a there's a lot of people who are in the meeting who haven't like a shared context or thoughts to do, any of you all have feedback on that or any other feedback? So I guess one thing that comes to mind for me is the existing Strategic Initiatives Initiative, I guess, and how this would interact with that or not interact with that or replace it. Nobody answers there. It's just a bunch of questions that come to mind. Yeah, I think, like the strategic conditions require a champion. And we're somethings that we know we we get an update on regularly so that if there's no if there's nothing actually happening, it doesn't make sense to be a strategic initiative. Right. I could see in this case. So I I guess what I see is that this is a higher level view of what we think is important, independent of whether we're actually doing anything to make it happen. And the strategic initiatives may then be concrete things which we are doing to. Make those you know what, with what we've captured as being important, Hoppes happen as we go forward. Does that make any sense? It does make sense. I'd still be worried about some kind of confusion between the two. But it can certainly be addressed with documentation. I also think there's another thing there. I was just looking at this of there. We have five different kinds of structures in the TSC and three, and there are two in the comp. Com, probably trying to do some of that would be ideal eventually. But I think that like to that point finding a name that is an initiative or like, you know, something, something that's more looking forward and like ideological or something like that is probably going to be helpful for how we approach this and that we can probably figured that out like, you know, as we're going through and creating this. Because, yeah, I mean, I, I, I'm trying to think if we have like or we're kind of talking about is trying to capture more of that unspoken. You know, the. I forget which one it was that has the priority of consistent with CS. But I've seen a few things like, you know, we prioritize this over that, like it's trying to get across in some sense as those are trying to get across technical and or other types of values that inform the decisions in the project. And I think we have those. It's just I can't think of where I would go to learn about those right today. And then, you know, that's that's almost a first level and then the next level is and what are the important technology and technology areas and evolution? What's what are the evolutionary things that we think are important to, you know, continue to be the leading runtime and so forth. Sorry, could you repeat your first point? Can you see which one that was on? Sorry, I'm blanking on. I'd like to. That's why I was asking. OK, great. I think I was just saying that, like, I think the project already has a number of. Sort of, you know, views on what was important to what has made it successful and decision, those do influence the decisions, but they're not they're not written down necessarily anywhere that I can think of. And maybe I'm just blanking on those two. But like, in terms of like like that discussion on the priorities continues is constituency's. You know, obviously performance has been very important to the project, has always been very important to the project. But I don't know anywhere that we've got something that says, you know, we would value performance over X. I mean, maybe, perhaps that can be a four word list in this, like a list above the list of actual things we wanted, right? Yes. Document. Yeah. Right. That's what I'm thinking like. I think we would want like I could totally see it constitute constituency's or priories as part of the sort of first level that says as a project. This is kind of our top level values below that. These are the things we've identified in alignment with those values that are important and key to the future success. So it's I think then it's like maybe we can think about that. I mean, we're almost we've got four minutes left. But I think. What would make sense to think about before the next meeting is like if we were to propose adding two or three files to the root of core? What would they be and what would the contents be? Right. Like, no one could be me. So I thought I'd say maybe. I mean, I don't know if we have enough file enough content here that needs multiple, I'd say, especially given the intent of what we're trying to do, having centralizing it into one insurance, splitting that context would probably been beneficial. OK. So one file. But like, what would the main sections in that file be and what would we call it? Like just to make it concrete? You know, what would we call this? And what would the main sections be would be, I think, worth people thinking about. Maybe we should open an issue actually to discuss that. It would be good to have any issue, and that's an example of what that document would contain. And then it's easier to discuss what to call it. Well, yeah. Yeah. But what we've got to figure out is also what do we think it should contain. So we could start with that. I mean, I think we've got an agreement on that. We could find the name. I think we we've outlined that pretty, at least from the folks who have been speaking through this. I think we've kind of addressed that. It should have, I assume, some kind of, you know, intro to what it is, values of the project and then specific domains and things that we'd like to see within the next ten, you know, till the ten years. And can those can both be lists and then that's kind of it from you know, again, from. Right. Let's discuss so far. I think one of the key things is we do need to actually compare those values and give them some sort of weight for discussion between each other. There is for me two different things, you know, discussing values and discussing a roadmap and things were in feature wise thing going put together for me to do two different things. Well, so I agreed that they're different. And I think one informs the other. I think values inform. And I do think we're going to try to avoid that. The phrase the earth, the approach of a roadmap and more ideals of like here's what we'd like to do and explicitly avoid it being a road map because we are allergic to to road mapping as a project, unfortunately. But let's face it, we'd love to do. And our values are two different things. And I think the values inform what we'd like to do, if that makes sense. You know, if if you're going to like if we're gonna add our second outracing thing that like, reduces performance by two hundred times. Yeah, we value tracing, but we probably value performance more. If that makes sense. Yeah. So, yeah, I think we have some some content there we can put into that issue. But I think with there's still lots of discussion before world finals about putting that in as a starting point. I think those things can kick it off. OK. So, ah, that that sounds good. And we're pretty much on time, but our first output of this discussion group or this will be that file when we open an issue. Discuss the contents of that file and what the name might be. And then. OK, that sounds good. Anybody? So I'm back to I guess we're gonna need to create the repo. Go back to any and that that issue is even going to go into anybody willing to volunteer to just open the admin issue to create that repo. Does this need to be a ribeau? I think we said we wanted to repo just so that, like, if we have automatically generated meeting minutes and meeting like issues from meetings, it's got a place to go. All right. I'm I'm I'm like I'm sort of torn myself, like. But I suspect people would complain if we tried to put all that into the node repo itself, like the car repo. We could potentially reduce the TSC repo, but I'm happy to have it be a Ripple's one. I'm not like. Reprint is. Sorry, would you say? I said it sounds like it's a ripple then. OK. Chip. OK. I guess I'm not hearing too many volunteers yet, but. And we're at time, so let's leave it at that for now. We can always take it back to the issue we had and go from there. We talk to everybody later. But.