So welcome to our second no, just sort of next 10 years of of a. team working session, we are going from the issue that was created in the repo and everything, that sort of logistics that we discussed last time. It is issue number. You can get that issue number. Uh. Sorry, having trouble scrolling. Issue number three, what's going to add that to the minutes? So we just got the repo set up and the only thing that was tagged for the agenda was the things that we discussed last week, which was the Values Direction, Directions document for Core Core, which is issue number two. I will open that up. And I'm going to. Share that. I can find the right screen. There we go. So this is what we sort of finished off talking about last time, which was putting together a document which kind of is a starting point for where we would capture some of the output of the work we're going to do in this group in terms of like figuring out what's strategic for node in the next 10 years. The initial comments around what it would look like included, you know, including a bit of a mission, you know, the values of the project and a priority list of those those values kind of a constant you would see of priorities, I think it's been called. And then, you know, the key technical areas. And so I agreed to open this issue and then we would continue, we thought we would continue to to work on that, to figure out what that sort of the what we think that document should be called and what it should look like. So unless other people have other suggestions, that's probably a good place to start for today. And then we can you know, if we finish that, we can think about what other areas we want to start to dive into that make sense to everybody. Sounds good. OK, so, you know, picking up the the the sort of structure, you know, are there people have had thoughts on that. What would we call this document? Um. I'm not sure I've come up with a good name yet either. Like, I guess we could look to see if, like some other projects have any. Does anybody know of other projects having something similar? I can't think of an example off the top of my head, but it's normally in the top of the Friedman thought. I also can't think of any examples, but it makes me just think of just as a mission statement, which is a commonly used term for this kind of thing. Right. OK, so you're thinking like it could even be like mission goddammed. Yeah, I mean, if it has these things listed in this, you know what the content says to me, that would be. Pretty descriptive, shouldn't values maybe. Help or hurt, so I'm thinking of saving a lot from like, you know. Like companies or teams or whatever will often publish something like this, and it sort of includes that, OK, you know, it is a little bit of both. Anyway, I don't think name the name of it is going to, you know, make or break. OK, what everybody I usually name sorry, go ahead. I was going to say I usually name my songs after I write them. So on the see where we get. Sure. OK, so everybody would be would everybody be happy with just misinformed is like a starting point short. OK. OK, how about we'll say from. OK, so then let's move on to and actually I should probably take this in the minutes as opposed to taking it all on the issues. So I'm going to flip over there. Sorry. It's going to pull that off so I can do that. OK, so then in terms of content, um. You know, do we want to try and write, you know, fill out the the sort of top level mission part or dive into like the values? I think the key technical areas is kind of a longer conversation once we've got those other sections ironed out. I would say the values which might help to shape what a mission statement looks like. Yeah, that makes sense to me. Now, I do remember. Go ahead. Sorry. Go ahead. It's just it's just that's an easy place to just brainstorm and we can just throw things at the wall. And then once we get people to write them, that that is a pretty easy way to start. OK, so let's do that. I seem to think that, like, is it Mozilla who has a priority? Like there's somebody there is some well known project that has like we value this over that and. Just trying to way that was brought up, it was it's in the HTML spec, I believe. Right, OK. Was the reference that came up in the last meeting, the collapse of. I'm just going to search for that. It's surprisingly hard to find I think somebody found a link to it. I did this search just last week. Right. And I it took me a while to dig it up. I thought there was a link in. This is one of our last notes or something, it's in the notes for that, I thought, OK, well, let's see if we can find that. You're searching for that now, see if I can find it. All right, so there is a minutes for that. OK, there we go. So here. So I think here's the thing, going to paste it in the chart. I can find the chart. There it is always I think I just closed instead of opening it. It's OK. There it is, it's yeah, I mean, I just pasted in there. Sure, but he's reading it, but one thing I think, you know, we don't necessarily have to follow this no guide, but I do think. So we don't have as many layers, I would say. Mm hmm. But I do think saying something like and this is also a this is also a values as far as technology goes, I think we should also make clear that there are values that are not necessarily going to drive technical decisions, but should drive discussions or, you know, how how we approach exclusivity or like those kind of things. Right. I agree. So this and this is really only a guide for like, what are some technical values? Like, we I do think we should value users over theoretical purity. Right. But that has nothing to do with how do we provide an inclusive environment. So I think there's just two sides to that discussion we should have. So this is. OK, so I'm actually going to share the minutes instead, because it seems silly to be. Stop, sure, this one. Right. OK, so that yeah, so this is purely around the technical values, which is good to make, make make sure that that we clarify that up front. OK, so maybe we could just start by throwing some in the other thing I could ever watch. Everybody can edit this Google doc with the minutes, so feel free to start typing things in in terms of, you know, the values that we think we should be. Covering, right? Maybe would it make sense for us to spend five minutes and have people just type in you thoughts and then we'll go through and discuss them afterwards? You've just taken a one I was going to write. OK? Do we still have access to the phone network board, the Darsey set up? Is that from the previous minutes? Um, it's the link to it is somewhere you're thinking of using it or thinking about looking at what was there. I think we voted on some things and about what we thought were good and maybe they translate to values. Right. OK, so let me help you with that. It was definitely in the I've lost the link now. Oh, here it was, here's the kick off if you want to take a look, there are pieces in the chat as well where the Chacko. OK, so I find it now, Chad, again. So here's the link, the link to it should be in there, if you can take a look. Open up. Take a look as yet. Yeah, like the one West mentioned, which was like users over something, right? Yeah, I think I haven't written I'm sort of writing in another thing, OK, before I copy the in OK, never mind, I'll let you do that. One thing I've been thinking is, for example, prioritizing your user experience, um, is very important to the project in my opinion. But it's not going to be possible to prioritize you over security or performance. For example, on every case, it would probably probably be possible in some cases. So I'm not entirely sure if we can have a hard rule of X or Y or Z. I don't think they're hard. They're ever like it's not a hard rule, but it's kind of like in general this would I think it's good to have a like in general we would prioritize, like if it is that we would prioritize security or performance over user experience by default. And we can say, what do you think, Michael? You're the only one who's straight. Now, can you promote people? I'm sorry. Yes, participants. I'm looking up. Thanks for letting me know, I can hear out west. I'll make you co-host as well. OK, thanks. I think I'm not sure that lets you promote people, but yeah, I think it does get perfect then. And anybody else want to be co-host. Just let me know here. I'll make Jocasta just. Have as many people call. But, Joe, if you're still driving, don't yeah, that's right. Sorry, I forgot. I am not driving, but I am on my phone, so I probably won't be the best person to help more people. OK, here, I'll promote Bethanie two that I can get my. Hey, guys, sorry, sorry, I was a bit late. I had a work call. Quick question. So where exactly what question are we discussing? We're talking about technical values. OK. And if you go to the minutes, we're typing them in under the the section, you'll see them much like stability, user experience and so forth. OK, thank you. I'll just go in there and try to. Also, Joe, I added her name to the media coverage, so you don't need to since you're out. Thanks, Divya, appreciate it. My pleasure. So I still see people typing a few things, so I think we should go for a few more minutes, maybe we'll continue this way until 10, 30, and then secondly, give people enough time to finish up. Do we think we need more time? A couple more minutes, sounds good. OK. I hate Google Docs, I was like, I don't think I spelled constituency's right and mandatory reformat copied and pasted. Yeah, I want to copy and paste and yeah it's the spacing and the stars are the only thing that really matter to me. The rest gets stripped out. When I converted into the the markdown that we load in. Who looks like I'm sending an email with blue text. I still really think there was another example of. Users, users over. OK, so it's ten thirty people need a bit more time, do we think we're good to start? Time to stop discussing and think, OK, I won't comment, I saw and there was like, we should make it clear list of the consistencies, that's probably a good way to start the discussion just because that will affect. Like these other values, I think that makes sense to people. Agreed. OK, so I'm going to pull that one out. Uh, of course, I got that, um. So where is that right? Here we go, so I'm going to pull this one. Constituency's. So I think we've got end users, right, how how detailed do we want to be with it? Would it help? Because I because I also think end users here is a really broad category. I think there's a ton of different type of end users and it might help for us to understand some of up there as well. Let's type them out and then we'll. So there's like front end tool consumers, right? Like a webcam with one person. There's a backend like API author. Well, we could maybe just call it server authors write whether those are serving websites or or APIs. OK, there's library authors. So this is where I do the best companies end users or do those are do we want some sort of separate category for like a library author to me is like more invested in the community. Yep. Or as an end user, more like. Well, I kind of I touch it sometimes, but I don't necessarily. But I like I there's like another step. Right. We have library authors sort of are more invested in this is kind of package authors. Right. Just I think library authors the is about the same category as implementors on Page Temo or those mentors and I maintainers. Yeah, I think that I think that's a case where we don't really it's not really the same. Right. Like in their case they have the people who write the spec and they have people implement this back. Right. So I'm not sure we have the equivalent of implementors. We do have, you know, not just maintainers. Right. But in some way. In some way, if we consider their product is the spec and that's what they're talking about. Our product is the core APIs. So technically, the people who are most building on top of the core APIs are the library and package maintainers, right and right. Although everybody uses them to write. I that's what I'm trying to say. I don't think so. A Front-End tool author probably if you go look at the webpage configures sorry, not tool author, user write and consumer. Like if you look at a web that config it might only use like require and path like that's a common write. Things like would you even really consider them. I mean I guess in some of the very latest of ways. Right. Where, where library authors in theory are using much more heavily the actual node APIs. And I think the same thing does go in a lot of cases for server authors. They're using a server framework, which probably abstracts away a lot of the node. And I quoted my videos up, but I quoted APIs. Right? True. So I, I think it's like in my mind I have no disagreement that, like the library package, authors possibly should probably be a different constituency. I think the end users, even if they don't use the API. So there's considerations that we need to like in node itself, like, for example, if we're going to make a breaking change that might still affect them, even though they're not consuming the APIs directly. Oh, totally. I didn't I didn't mean to imply that they're not constituency's. I was just trying to imply that I think that there are different levels. Yep. And end user GEP. Yeah, I think that that is worth like in my mind, it's worth calling it at least, that the library package authors separately from end users. I don't know if you had other types of end users in their right, but like. I think there's like Hobbie developers who build one thing, if you think about the growth of Noad, like a lot of it has been due to the fact that a hobby developer can pick it up and write some Iot thing or write some distributed system experiment. And to me, those are sort of they don't fit neatly into front end tool, consumer backend server type thing. But they they might like write do a wide swath of types of work. Yeah. Like I'm just throwing this in there. But like enterprise developers, like, like I don't know if your gear would categorize, like the front end can go underneath there or kind of you're getting it. There's the professional versus hobby side I guess. Yeah. Maybe maybe actually doing. How do you structure that makes no sense. There's different concerns for a enterprise level versus. Yeah. Professional I think is a good word too because it also avoids the loaded right term. That is enterprise sometimes. Right. I think it's good we can, like, put as many of those in there and then as we go through the discussions, it's like, would we actually, you know, would we call out any of those individually versus end users? Right. Like calling it the park library pocket package authors. I think it's a good start. I'm not sure if we need to pull out any of the other ones. Because I don't think, like in my mind, if we make it too complicated, it also kind of dilutes things, right? Like if we have one hundred different constituencies and try and explain everything. It'll be a losing battle. That makes sense. Maybe. I guess I was just trying to think of the difference, but maybe just calling it application developers would would be a good start for I was thinking for the combination of. Well, will that. Hmm. Then I almost wonder here is there's like end users right at the end because then because then application developers there could also be like, you know, different from an application would be like a tool author and they maybe aren't publishing it as a library, but they're just writing a small note script to automate something. Right. Like and it's just a one off script. That's not a library. That's sort of a slightly different experience than an application developer might have. Hmm. Sorry, I'm sort of brain dumping. Anybody can come here just so that's the idea is like let's let's let's say like let's move on to some of the other constituencies and then come back to that one and see if it makes sense to treat them separately. And I guess the question will be, are there any there's there's like our core maintainers, the library package authors, application developers and users. I guess there is like, you know, like application developers. There can be like application deployers Hoya's operators. I like operators as a word, but. Because that's kind of like another group that. You know, or are important to, you know, an application keeping up and running into the like, you know, the success of notice that it's if it's impossible to operate a node application, even if it's quick to develop, that doesn't this is going to be so good. And are you referring to like people that fall into the debs category to what seems to confuse things for me, like I haven't like that you're basically saying you're going to be a developer and an operator, right? So I don't know that it's strictly dev ops people, it's anybody who would end up having to operate it after it's built that could do depending on your model, that could be developers. Often, though, it's like a separate team. Who's, you know, actually deploys the applications into the production environment, has access to them. And I don't think at least from from what I've seen, that's completely changed. The other people can correct me on that one if they think it's always now the developer, that does both, but my God, I can actually help because I was a developer and then I got switched to jobs so I can actually help you. It's more like right now what we do is more about building pipelines and deploying, asking, then giving it to the developers to deploy it themselves. So you basically set up like all the whole processes of the build deploy, like we're testing, like you build up the pipeline and then we just give it to them. And then we maintain the servers, basically the servers that we're getting maintained from our end point. Right. OK, and what happens when things go wrong? Do you get paid of the developers? Get paid directly. We get paid because we need to check if there's something wrong with the servers or with the pipeline, if nothing is wrong on Earth. And then we have to pay to developers to let them know that something's going wrong in their code and then fixed or updated. And that's still kind of what I've seen over the years, is that like there's the developer who focuses on building the system itself and then there's a group who focuses on making sure it continues to run correctly. And for the first point of contact, if things go wrong and then pull the developers in to help when it's clear something a bug in the code versus something in the infrastructure, I think we'll know. Also, we also evacuate people. And then you also the server people and you also the infrastructure network people. So it's like a lot of it's a little more complicated. Yeah. So I was going to say on that note, actually, I think we can just list domains here and recognize that oftentimes people will fluidly move between them. Gebert calling operators a different constituency than developers has some meaning because the if we go look up at the list of values, things like diagnostics are going to be in some way, not always. And again, I'm not trying to be, but those are going to be more important to operators than. Right. Alpers in theory. Right. And so, like, there's certain values that will end when we're talking about the constituencies it'll help us rate. Like, do we think operations is more important than the developer experience that will help us sort of give clarity here, whereas like the nuance of, well, there's all these other things like now if if network engineers needed hooks into node core to get their job done, then maybe I think we'd call them out as an end constituency. But I don't think they do. I think that operators and developers are pretty clear, big buckets. Yeah. And I think we want as few big buckets as we can as we can. So I agreed with that. Are there any other so that we've got five so far, there any other major ones that we're missing? So we have the core maintainers, the people who are building node itself, then we have the library package authors, a large group of people who build packages on top of node. We have application developers who then pull those together until like the end solutions that actually are run. And then we have operators who. Who? Actually run those helped to run those things, and then we have end users, and I guess the question then is like, what are the end I can like now I'm thinking that like, for example, in the case where we have applications developed. And then operators running them end users don't really play into that so much anymore, but if you have somebody who will who creates a tool and an end user runs that tool directly, then those end users still makes sense, right? Yeah, that end user might still have some level of interaction with Node in that, you know, today they need to install node. And I think that's valid. But I also think there might be a future where they don't have to install node, you know, if you bundle it as a binary all with your hip thing. But I still think them understanding that they are using a JavaScript runtime or something may have some value for us to. Yeah, yeah. I'm just trying to how we differentiate from because it's not so much the end users of an application in this case then. Right. It's. It's direct. But even if you've written an application. You can actually then have an allocation that end users use directly to write. Yeah, we only really care up to the bounds of they need to know that they're using node, right? Right. And that's why I said if they have to install node to run a thing somebody else wrote, then they are in part an end user. But as soon as you go past that, it seems to me like we don't we shouldn't call the constituents. Right. So it's kind of like direct end users, but that's not a great word, but it's like people who run Noad. Applications directly on their machines rate. We might be overthinking it. Yeah, but but anyway, we got I think there's a group there, whatever we call them, any other major. Contextualizes. So let's see if there isn't let's assume this is our set. I think we started this discussion because there was a section here which is like considered, which is this one, right? Do we have like an equivalent? And so are you all going to drop a little bit early? Talk to you. Here's Joe. Can we what would our order be if we were to serve the order of the HDP spec one is really what I think of as like inward out or maybe outward in any way, right? Yeah, but it would be like we like the the outside layer of this is most important. We have some nugget in the center, which is theoretical purity, and that is the least important. If you can make it all the way from the center all the way out, then great. But if you have to make a concession, right, try to make the end user experience direct end user or whatever. Great. And then work back from there. But I think in some cases, the way we've broken this out, I actually think that it's better to make. So I would put developers more important than operators, which are more important than C, but package authors are like pivotal to the node ecosystem today. Right. And I think you might get some argument over the operators. I've seen like there's Mateo tweeted, you know, we prioritized developer experience so much that when you get to deploying it and maintaining it, you have a big problem. But that's the kind of thing that's the kind of I think that's a good breakdown and sort of going to make a joke here, but like, isn't that good? We've already hooked him. You know, again, it's a joke. They've already read their F.A. Now, look, at that point, it's just a matter of working out the details. I actually kind of think that for the quality of the experience as a whole, that is actually the right way. If there's details, we need to make better in the operations space, yep, that's fine. But at least we've made the developer experience good enough that folks chose to use the platform. Right. Which is a sign, a good sign to me that that's actually that is even though that might be today the case, we we haven't delivered fully on our operations goals. Still, I think that's the right priority order. Right. OK, so we'll write something out and I'm sure we'll have lots of developers over. Operators over. Um. Maintain or over. Packager. Well, here's a package authors' over maintainers. Early developers are package authors as well, right, and we could like, you know, you could say that developers include. And I guess you really want end users in here, right? And users over. I'm not entirely sure this format is going to bear the same amount of fruit as it is for the HTML spec, I know and think about this because package authors, while they might be developers, there's two boats. I do think valuing the application developers over package authors is sort of a false dichotomy. Right, because there's a when you say package authors do. There's a whole nother realm of things that just don't even apply when you're writing an application that we want to have an experience around. Right. So saying that we value them over, well, it's like, no, there's just this whole other realm of stuff that matters to a library or a package author that is not the same. Like a package author. We're going to. Oh yeah. Anyway, I just think it's we're trying to sort of shove this metaphor, this format into the way our right. I mean, OK, so then we could just say value X over Y is part of what we're trying to get to. Right. Think of these constituencies, if there's something that's that we can't satisfy them all. I think we you know, we could probably agree that we value the core maintainers, like we should value these other constituencies higher likely, right. There's more work for maintainers that's preferrable than trying to push the work up the stock. I mean, just to be aware, though, if you say push the work up the stack, if we say more work for maintainers than what we're saying is not small core. Right. So sometimes these things, if we want this to be the foundation of our right mission statement, that then it will directly conflict with things that people have strong opinions on, on the higher up stuff like like what the small corps looks like. I'm not opposed to making that. But I think we we we've spent a fair amount of time on just this part. And if we find that everybody agrees that maintaining maintaining a small core is supremely valuable, then at that point, no. We're saying that we value core maintainers over library authors. Right. Because we're no, we're we're going to push the complexity onto the library. Others. Right. Right. But I think it's worth having those that discussion. Right. Because that's like there's different values to small core, but it's like what's the cost is the is where we've that's where we're getting into these discussions and why we hopefully this this is intended to try and inform and say, well, as a group we've said no. You know, even if it's harder for package authors, maintainers, we're happy with that. Right. Because that's what we've said. Or the versus the vice versa. I think we could have that discussion as a whole separate. Yes. Yeah, well, we have six minutes and we have six minutes left. But I think this maybe we should close out on the constituency's and then we'll have to, as the next conversation, get into like. How would we how would we value those things, because it's kind of like I think I think that at least having like a hey, this is where we we could actually say, like, here's some possibilities. And then as we work through the different values that may actually, you know, some of them support one versus the other as well. Right. Yeah, I think I think having had this conversation now, I think it is hard to make a clear this over that statement until we have an understanding of where more folks lie on some of these key technical parts. Right. OK, so, yeah, we could we could try and see the relative comparison of these and then that will actually maybe point us to which ones were actually valuate. Right. Yes, a good point, yeah, OK. So maybe let's close today with saying, like, are these the constituency's? Application developers and yeah, and I think the I think it's good to keep library package authors separate for now. So. OK, so let's just say there, those are constituencies that. That's a good. See if I can get this formatted correctly, probably come up with much better wording for some of this, too, but, uh. OK, so I'd say given that we have only a few minutes left, maybe we should. Leave today's discussion at that and then next time dive into these values and sort of figure out which ones we think would be prioritized over others and sort of use that to drive the direction next. So that makes sense to people. We could try and do that in an issue as well, like we could open an issue that's like here the different values, you know, how would we rank them in terms of priority? That might be good in terms of helping do that, partly because I think there is a ton of folks who are not on this call who have need to give input. Yeah. Right. OK, so we will see will open an issue, discuss open. Maybe open open issues. And maybe open pass issues open. I mean, should we PR in the constituencies, I think that would be good to actually capture that. Makes sense to me because then because then as people have proposed changes, they could just open a power to add or write rather than trying to find the minutes or whatever, like it seems like something we should be referring back to. So it's like, OK, there it is in the repo. OK, so we should open our open issue with values and ask people to comment on their priority, on their ranking of priorities. Right. For that works well, as for the agenda, next week, the agenda for next time. And he volunteers to do these two. I can do the first one. OK, thanks. That's fattiest, right? I'll volunteer to do the second one. OK, and we are at times, so I think that that was a good start. Thanks, everybody, for spending the time. Maybe the one thing we should do is I just chose the time for this one. I guess I will just rotate like pick the next one in the rotation list, provided it doesn't conflict with the TSC one, in which case I would just skip and go to the next one. Does that sound good? Sounds good to me, OK, so I'll go to go ahead and do that and I'll add it to the to the calendar for two weeks from now. Thanks for your time. And we'll talk to everybody later. Thanks so yes, yes, thanks, bye. Thank you. Bye bye.