 Record to cloud. And now I should be recording. Okay. We are recording. All right. I'm gonna say let's get started on this here conversation because it is sure to be an active one. As I mentioned, just proposed a bit of a suggested agenda in issue number 307. Michael Dawson's adding the topic of certifications to that. I think that's a good one. So any any issues or suggestions to the agenda before we dive in? All right. Cool. Hearing none. I think for me anyway, a piece of this was really figuring out how to scope this problem because we're talking about kind of multiple things in our CPC meetings related to infrastructure. There seem to be three themes or three threads that I was picking up on. One is, you know, our individual projects and what they need from an infrastructure perspective, their specific support needs. And as it relates to jQuery, for example, you know, how do we help them upgrade or migrate to a better infrastructure? There was the theme of like foundation wide infrastructure support, which is certainly something that like Brian has been looking a lot at. You know, what kinds of services are we providing for all projects versus what are projects kind of figuring out on their own? How do we help them eliminate a bus factor problem? And then, of course, related to everybody, I think, how do we make a system that's going to be sustainable for everybody? Because, you know, speaking from the experience of the jQuery team, it's been the case where we had maybe a couple of people doing a lot of heavy lifting for a while. And then those folks move on and the infrastructure that they build is not really known to other people. So I'm curious if there are other ways of like looking at this problem that folks would see as, you know, maybe a different perspective or an orthogonal view or something like that. I think the other dimension that I've thought a bit about and we've talked in the node community is, you know, is the infra good fit with volunteers and the friction that around that. Right. Like there's there's concern about, you know, there's concern that if we, say, have paid volunteers or paid paid resources help with infrared, it will, you know, demotivate people who are not paid for working there. So it's definitely a concern. The other question is, is like, you know, for some of the things on the infraside is expecting volunteers to be available, you know, basically whenever reasonable going to work out long term, either. So maybe maybe maybe, you know, to try and make that a little more concrete, it's sort of like, maybe we can think of it through the lens of what pieces work well as volunteer in which pieces don't work so well. Yeah, I see my house has those hands up. I'll hand up. Go on. Yeah. So I guess, and I've been a part of a bunch of debates, especially, you know, not wanting to get volunteers to not want to do the work. What I do think, though, would be really helpful is like a baseline that's reliable and on call staff that's available as and thinking of it much more as support. So Brian, sorry for calling you out here, but Brian, I think is a great example of a similar kind of support that we have from like a program management side, where, you know, Brian does so much work in making sure that, you know, our meeting agendas are ready that things are scheduled that conversations that need to be happening are happening. Things would not be moving forward as clearly and on and on time as they are. And Jory is another example of this as a contractor who's been doing a lot of work in the community. And I have not seen anyone say, Hey, because Brian is doing some of this work as a contractor, because Jory is doing this work as a contractor that I don't want to do it. What I do see is stuff like a newsletter coming out or organization happening that volunteers would not normally do, which allow the volunteers to focus on higher level bits that are closer to, you know, the reason why they're helping out. In the case of the of the infrastructure, I think that a lot of where we find ourselves, at least in node, is constantly chasing our tails on keeping the lights on, that we never have time to kind of invest in growing it and building up that kind of infrastructure that we need. So while I will I understand where people are coming from when they say it will drive away volunteers, I would like to propose that perhaps it will actually allow us to have more volunteers. Because when people don't feel the weight of, oh, I need to be on call 24 hours, or I need to be kind of like just doing the maintenance work when they can do the bits that they're excited about when they can get support to actually execute on their vision. I think that we actually will see more people drawn to working on it. And I would really love to see a baseline infrastructure support from the foundation as a whole that gives us some shared infrastructure that projects can all rely on, whether that's subscriptions to services, a Kubernetes cluster operators that were able to contact I don't know what the solution to this looks like. But I would very much, you know, we have 31 projects, they have very different needs, but some of the baseline needs are very similar. I would really love us to see if we can come up with kind of like a baseline infrastructure support for all of the projects in the foundation. Yeah, and that was sort of the lens, you know, and figuring out what you know, so that it provides the pieces which are not a good fit for volunteers and for which, like you said, hopefully won't discourage the volunteers, but enable them while leaving the other pieces to the projects to or the direction or whatever it is, right, but looking at looking at it through that lens is the only it was was what I was suggesting there. If I could jump in on this as well, I think, you know, thank you Miles for the kind words. I first off, I really appreciate that. But part of what makes this possible. And I think part of what makes it easier on my end is that at least from the operation side, it's very clearly defined what things need to be in a dedicated role and then what things can be done by dedicated role, but don't have to. One of the examples is credential management. You know, that's that's a this came up, I believe in the in the issue in the discussion so far, is that one of the concerns with the current infrastructure is that in order to get access to something, you have to have access to everything. And one of the things that comes out, even if it's not explicitly stated there is that there's a fair amount of concern and responsibility that comes with that type of work. And that would certainly add weight to the weight to when you say I volunteer, you know, you're volunteering for more than just taking care of stuff, you're volunteering for protecting stuff. And if that stuff can be isolated, and can be, you know, consolidated potentially with a resource or something like that, then, you know, that that would make the discussion a little easier what do we carve up between what needs to be dedicated and what is, you know, says Miles put it, what are the things that multiple volunteers could then take on because they feel empowered to do so? I think one component that Dave isn't here on the call, but if I'm hoping I'm representing this idea that he had accurately is this recognition to that within a specific project community, like jQuery, for example, there may not be the expertise for, you know, DevOps type support within that particular community, but they they definitely have, you know, a need there. And so there's a question of like, you know, how can we connect volunteers who may be interested in that kind of work and that kind of open source support with opportunities like they exist with them with some of our projects, you know, who have that need? Yeah, that's interesting. It's, it's, I guess, the question will be, are there people who aren't necessarily like it's not the project they're passionate about, it's the infrastructure. Right. And it's the infrastructure, it's the chance to really help them, you know, a project that, you know, in the case of jQuery, a lot of people still depend on. Yeah. I guess there's a question, though, and this might be a little bit of a harsh one, but what are the goals and values of the projects themselves? And like, there is limited volunteers and I know in the Node project, having all these different places where people could put time was a huge benefit. But should that be something that that is scoped per project? Is it something that should be scoped for the foundation for many projects? Is it kind of like out of scope of what they're looking for? Like, is it something that they're doing? Because they have to? I know for Node, we've needed some significantly custom infrastructure, which has led, you know, to to a whole infrastructure team that we have. But, you know, five years, four years later, after the fork, the majority of those people are not putting in the same amount of time because they can't consistently put in the same amount of time. And our infrastructure has become a debt that the majority of the project doesn't have a skill set or interest in maintaining. So it's kind of hard. Like, I feel like I'm speaking out of both sides of my mouth because on one hand, I recognize and I was a part of that build team for a while. And it is a great opportunity for people to contribute back to the project. But the flip side of it is like, if it's not aligned with like, the core bit of what the project is doing, it has the risk of becoming engineering debt and just kind of like a weight as opposed to something that empowers people, which is why we want to do it initially. Michael may have some better insight into that than I than I do. And apologies if I'm kind of glossing over it or or Yeah, no, I mean, I think, I think, you know, history obviously plays in to a large extent in a lot of cases. In my mind, I think we need to do is think about what we should do and keep in mind the existing projects like node that have, you know, fairly big infrastructions and so forth. I don't think we're going to change everything overnight. So I think we should focus on, you know, what do we think makes sense for like, you know, common infra, common services. But keep in mind, like, okay, what does that mean for the projects that already have volunteers doing these things? Is it is it going to be something that that has the negative consequences we're looking at? Or is it like, yeah, it's going to be an enabler because it removes something that they don't really want to do anyway. And you know, I don't see that we're going to be able to put in place a huge infrastructure that changes things, you know, right away. So we should focus more on the smaller steps we can take, which I suspect, you know, some projects will just say, yeah, we want to do that. And some pieces won't affect, you know, some of the projects anyway, they'll say, well, we've already got what we're working on. But that doesn't mean it isn't useful for some of the other projects, right? You know, so if we try and think about what's the what would be the first set of services that we would provide, that might be a good way to like, you know, think concretely about some of these problems as opposed to the big problem itself, which, you know, every time you get into it, it's like, well, it's going to be hard to come to a consensus on an overall, yeah, go one way or go the other way, right? I guess one way to figure out what we need is maybe asking all the projects of how their current infrastructure looks like and what kind of needs they have moving forward. Yeah, certainly understanding that somehow. I think possibly that the onboarding process is a way to get at some of that information because, you know, we've just started this talking to the current projects to put them through that process. And one of the questions that I have been asking them from a just informational standpoint is like, you know, what what are you currently using from an infrastructure perspective? And the reason I'm asking that is because we have a whole bunch of stuff like in digital ocean and in Cloudflare and that kind of stuff that I don't think our old JS Foundation projects are using. And so we're it's kind of a checking both lists sort of so to speak. So we can start to maybe ask that question as part of their as part of the onboarding and then asking the question, do you anticipate having any needs in the upcoming future? Like say in the next year, in terms of your friend, it's kind of get that data that way. I think something that may also be worth digging into that could help with this also would be finding out what infrastructure they're currently using and what they're relying on. I think we'll find pretty quickly, for example, that a large number of our projects are relying on TravisCI. TravisCI was acquired in the last year by a holding company and, you know, there's nothing specifically happening right now, but I know that there is like a temperature that something could happen from like a risk management and hedging risk perspective. Yeah. Interesting for us to figure out like, hey, who are the service providers who we are utilizing the most? And either A, trying to see how we can like negotiate some sort of blanket contract with them to give us all kind of a better deal or alternatively try to see how we could collectively replace those bits of infrastructure that introduce risk. Yeah. Or having a common, like basically if say we're all using TravisCI, for example, having a common approach would then maybe make it easier for us to have a help desk who could help with issues or something like that, right? Yeah. So I didn't start a note stock for this. I'm sorry. I'll try and summarize after the meeting but on my piece of paper that I'm doodling on, I've written three different threads so far. One is identifying what those common needs are, which kind of gets to that these questions that we just, what are you using? What are you relying on? The second thread is what are those services we want to say that we that we're coming out the gate with as a foundation. And then the third thread is how we want to make it, how to make it easy for volunteers. So that sort of like staffing question. You know, I was just thinking like maybe to add to your list, like the things I can think of that every project meet off the top of my head are like probably a website, source code control and hosting, build and then distribution. Now, I guess then that will vary like you know, certainly for you know, node we build binaries and we have a site where we distribute them for some projects that may be just pushed to npm. But it's like those are the areas I could think of that if every project needs them, what would it make sense to do to make those easier? Yeah, and I think historically like at least speaking from the JS Foundation point of view, we may have for example always helped the projects with you know their domain and SSL certs and that kind of stuff. But then as you go down that list of like source control, well you know sure we'll help them admin their GitHub repo if they need. But build and distro that's not necessarily been something that the the JS Foundation was super active in with the exception of jQuery because it was Yeah, if I can interrupt there for one second. If one of the big things kind of at the forefront of affecting the JS ecosystem right now though is supply chain attacks, perhaps build and distro is something that we want to focus on now. I'm totally into that. Like I'm not I'm just saying historically it's not and that may be part of the reason why we're no good at it is because historically it wasn't. But I mean into it if we want to support that super into that. And this also seems to me like things that could become part of the Commons JS program. Depending on what kind of infrastructure or best practices we build, these are things that we could share with the ecosystem at large. Sorry for interrupting. No, no, no, totally fine. I mean I think it's a good point to like make you know why we want to support in those areas. Wes is here. Wes I'm curious as a maintainer of Express if you're you know kind of what you're thinking is around needs or wants or hopes and dreams related to in growth. I didn't intend to join this meeting and necessarily participate. I meant to just listen. I'm at my desk and I'm not really in no good place to participate. But I do have some thoughts but I'd rather just sit and listen until later. Sorry about that. Sorry to call you out. That's all right. But yeah I don't want to disrupt my co-workers. Very kind of you. I mean are there any you know outside of the website source control build distribution? Are there other things? Looks like maybe just in terms of getting an exhaustive list. Are there other things that should be on that list? Domain management. I think that could go under website or maybe yeah maybe that's separate domains. Yeah okay. Well I mean I think yeah because there's usually we may have a project may have a website but they also a lot of them also have little microsites for other things they may be running. So I think that's kind of separate. Yeah sounds good. So any others people think of? I guess email and stuff. Where does that fit? Say I mean there are maybe two different ways to approach this. One historically many projects have had their own mailing list infrastructure that they've managed but there were also were some that came in from the JSF where it was managed by you know by the JSF. You know at this point we have a groups.io subscription and we can have as many lists as we want that are on that domain. If we wanted to add additional domains to it then each one of those requires its own subscriptions but I mean I can add as many lists as we want under list.openjsf.org and there's no no additional overhead there's no additional cost or anything along those lines. For example if we wanted to have an Appian maintainers list or something like that it's that's very easy to do. I guess the question is some people may want like a vanity URL like miles at nojs.org or something like that and how do we do the management of that. That as well as DNS has actually been something that's been a little bit of a pain in the butt like especially with like hey we want to launch like a new subdomain or we want to do something with the Node.js domain. I think right now we have to file a ticket with like LF's IT team. It would be nice to remove a hop from that and be able to manage our assets without leaving our foundation. Yeah so that's and that brings up a good point domain in general. So from my perspective there are two reasonable easy ways to handle this. One is if a project doesn't want to handle it at all then we can handle DNS for them and they can file tickets but we can also handle domain registrations and things like that and then delegate to somebody else's name server if the project wants to do that. The advantage of that is that you know miles in this case it gives you full control over the DNS of course but also it means that the renewal process is much more straightforward because the bill's all come straight to us. So either way it's fine I guess is what I'm saying. There's a there are options here for everybody. So Neil were you gonna add something there? Yeah I was about to sell the same thing for the mailing list and for these channels that we provide them and I think your miles and brain has summarized it. I think kind of going down the list of things that people might ask for in addition to something like a mailing list there are other tools like Slack what do they call Slack orgs are they orgs in Slack? I don't know. Channels yeah workspaces that's the word they use yeah. You know things like that which a project might want to have and might also want to you know have someone at the foundation or some some function within the foundation to like make sure that the bus factor is eliminated. But I also don't see that as like a need that's like a nice to have for a project. One thing that you could put in as so long as line story credential storage. I mean I'm happy to maintain a central last we have last pass enterprise here. I can handle separate folders for different projects if they just want to have a separate neutral place to keep certain certain credentials particularly for sites that don't have multiple user account. Just last pass. Sorry go ahead. I was going to say they're just there are a few of those like tar snap for example which is used for backups. There's only one one login for that so we have to share it. Michael you were saying this last pass let you like store encrypted files with credentials in it or you know so for example in node we have a hope we have like you know ssh keys that we use to access our our test machines and we have a way that we manage who has access to those or doesn't have access to those. But it's it takes work. I didn't know last pass gave that kind of functionality too that's what I was asking. I'm not sure that it does I mean I can look and see but I'm pretty sure it doesn't. Okay I was just reading more into what you said then I should have then so never mind. Yeah I was thinking more credentials as in username passwords versus ssh keys. Right well yeah we have similarly in that same repo we have some username passwords and stuff. Hey I found a room just so you know last pass does allow you to save other arbitrary encrypted things. Oh I'm sure. Yep. Oh interesting. It's very nice. I can see that being a common problem and it's not necessarily now the one we you know what we've ended up doing actually gives you like based on groups that you're in. You know so basically people who are in the test who have test access can get access to the test keys and so forth. So it's it's I don't know anyway we could look at it though but that might be something where I suspect the many projects have a similar shared resources and how do you how do you you know share them among just the people you want to have access and then revoke that when you don't want them to have access that kind of stuff. So so with last pass you can also do shared folders so you could put you could create a folder for each group and then put the keys or passwords you know they can all go in the same folder and then you share and then you could manage it on that list type basis. Right and then you add people in in or out of those groups. Yep and actually with that prodding I just discovered that yes there's a place right here where you're going to add an SSH key. Oh that's excellent and we were currently using the shared folders to manage the zoom credentials so we could certainly do the same for this. So that's that's probably a good one to put on the list. So I mean just kind of noticing here that this particular issue of credential storage is if you know if we sort of address that for individual projects that is part of a step in how to make it easier for volunteers to come in and help out you know because we can control who has access to the credentials so if there's a trusted you know person who wants to do something you know we can help them get at least access to the services that they might need to do something. So that seems maybe like low hanging fruit. Yeah now we would want to I mean we would have to look at it to make sure that it's not like haul back to one person who owns our last pass account but that individuals who have access can reshare those kinds of things. I mean with last pass I believe you're allowed to have one owner. I could be wrong in this but I I mean ours is centrally managed so you know say for example I decided to take an unexpected vacation and disappeared for a certain period of time there would still be access to my account and that's maybe one difference between doing it as an enterprise versus doing it as an individual account. I even just mean the project having to like open a ticket or send an email versus being able to have people empowered to say here you have access. I think in the end it depends on what you're trying to accomplish. I mean if what you're trying to accomplish is having this be say a small project that's trying to reduce bus factor then that's maybe a positive but also there may be that wouldn't fit for every project you know in a situation that you're concerned about of having to open tickets and things like that. Yeah maybe one size doesn't fit all. So I think and I could be wrong if you say that you let the when you do a first initial share if you say you can view the password I think that then means that that account can reshare. We'd have to test that but I believe that because I just went in and looked at one password that shared with me and I can see the password and I can share it. There's another one where I can't see it and I can't share it. The can't see it isn't actually able to be protected because when you paste the password into a browser even though it's in a browser field you can modify some CSS and still be able to see it. It's not actually. For sure I meant more specifically though the sharing so when you do like you know there's a sharing center and you can go in and passwords that have been shared with me I can then go and reshare with a new with a different last-pass user. So that would that would mean we can federate the management of the sharing to the projects themselves not having to open up a ticket with the you know the root user or whatever the you know main. Yeah another possibility that we could do although this is getting like really into the weeds like what we do and note is we have a secrets repo which has the encrypted keys for everything in there and then there's like it's encrypted so everyone can use their own GPG keys to decrypt it. That's a federated distributed way to do it as well. So that's another way that we could think about like secrets management although it's a little bit more of a you know pain in the ass for those who aren't familiar with GPG. Yeah but it seems like something that every project will likely have an issue with and kind of solution would be handy. So we've got a list of you know I guess several different pieces of infrastructure types of infrastructure that we are going to want to have some answer for. Websites, DNS, source control, bill, distribution, email, credential storage, maybe Slack type things. Slack type. I mean Slack, Zoom. The sort of comms things. Yeah maybe that's a good communications it's a good top level. Yeah. You know your email, your Slack, your Zoom, your whatever tools you need internally to Yeah. And we've always had a very vocal discussion when anybody per you know suggests any one of the tools but at the foundation level it can probably only pick one and say we can support this and you're free to use whatever you want but if you want a free one here this is the one right. Right and I kind of feel inclined at least initially to kind of go with that kind of approach like you know here's the here's the package and this is what we're supporting as we're getting started. If you want something else you're free to do that but I just think we we can't at the moment really support in number of different options. No. And it gets more and more costly right so Right. I mean I think too for some of this stuff that when we establish the baseline this isn't the baseline that projects must have it's the project it's the baseline of what's available that projects can consume if they so choose but if they have a better way of doing it you know for example knows a great example where you're fortunate to have so many volunteers if that is a better way to do it than by all means that's certainly something they keep doing if it's working. Yep. Yeah. It's basically you know here's here's a starting package if that's all you need and you want to do that that's great otherwise you know you're free to free to do whatever but you know you can't get the same level of service that's all. So as we're at almost 245 I want to maybe shift the conversation to the hopefully easy which I'm putting in quotes air quotes easy next steps we can do to start making progress on on some of this because you know I'm speaking from my experience some of some of these questions that felt like such a hairy naughty issue that it's been hard to figure out what is the right next best step and so I think it'd be great if we could maybe as a group figure out what one or two of those might be and what follow on action we want to what follow on actions we want to take do we have a good description somewhere of the things that are already in place that a project could take advantage of you know like the DNS management because that would be like a starting point to say here's here's what you can currently get DNS management or domain names or whatever and then to build on on that I'm not sure that we have something that is like comprehensive I feel that at varying points we've said to the projects hey did you know you can get this did you know you can get this but I don't think that's that whole story has been put down somewhere and certainly not in any other format beyond like for example my goofy emails because it seems like that would be a starting point it's like here's what you could already get we don't even have to do any work right and then you can say what's the most important thing to add to that can I can I ask a quick question because this is one of the things that's been pending is an open issue the long time for express so I think the you mentioned the domain it got moved to the foundation at some point but there were some open questions about whether or not we have the cloud flare account moved over that would be maybe another thing to add to this sorry I just I know I'm a little bit late on the the topics of things that should be maybe infrastructure offered but the cloud flare or some other services like that might be things to add I tossed a link in the chat just as the express open discussion from I think many years ago that still hasn't been resolved um cool I'm I think probably Brian Brian or I can look into that today I guess it's only a year old but it felt like a lot longer they age very quickly issues okay so so coming up with a good description of what's what's available right now for projects that seems like a relatively easy non-controversial thing to create the other one I would maybe throw on the list since it's a particular interest is you know is what do we what does the foundation currently do in terms of certificates you know I know there's been discussion of let's encrypt and so but that actually requires like quarterly updates and and it's not it's not obvious how that is easy to keep up with right because it now means you got to do something every three months which is reasonably frequent I believe there were some there are quite a few search that I believe that needed to be renewed for JF Foundation and if I recall correctly because this actually this happened before I came on but from speaking with people I believe we just got a two-year cert on most of those um just to you know it puts the problem two years down the road but at the same time it's not happening every three months right and that that would be like you know if we if that's going to be our approach it should be just like hey okay just ask and you know the foundation pays for the cert right yeah I mean it seems like a fairly reasonable ask I mean yeah something we can all get and then from my mind it's kind of like the you know forcing something to be done every three months with the risk of it not getting done it's worth a little bit of money to just get it for two years and not have to worry about it right that was what you were thinking yeah you were saying that the foundation can actually be I guess like so that the bills go directly to them in some way right yeah I mean far and away that is the easiest for all of these things once we settle on what the what the services ought to be uh choosing things that have a where we can set up a direct billing arrangement it just makes it so much easier for everybody involved right so it's like you know we got we got a little bit of time but you know I think for the the node one it would be worth exploring if what we're doing already fits into that because there's just you know Rod said hey we could try looking at let's encrypt but I think if the foundation is just like k we can pay it's not that expensive it's probably easier not to have to worry about all that extra automation and and there's issues about wildcard certs and stuff so I don't know how we could get you know what's the next step in getting towards a here's what the foundation will do by default for you yeah I mean I think that's that's the fundamental the outcome of this discussion plus also what we've been discussing at the board in the strategy sessions too yeah but I'm just looking at like as a tangible next step that would be one to say like if we can we write that down and say here's our preferred here's a preferred certificate management for a project you can do something else and we'll you know potentially still pay but here's the here's what we think is easiest for everybody yeah yeah I mean once we get that documented I think the path here for anything that involves anything involves budget would be for us to get it documented here through through this meeting yeah then figure out if those this makes sense and then put it together as a proposal for the board and then it becomes a you know a line item in the budget and then once the board gives it a go ahead then really it's just a matter of actually getting everything done so should be reasonably straightforward to get from here to there okay so who has an action to do what for the next step on that one so I I mean I think the next step here is probably for Jory and I to get together and clean up the list and put it into something which resembles a proposal that we can then get back together and review and then once we've got that then it's a matter of getting you know on the agenda for the board which I know the person who does that so that should be pretty easy narrative for it it was Brian so yeah I mean I think that's probably our next step okay sounds good and with probably with like in that case I you know want to get it back into the issue where we're talking about certs and just get some feedback from the rest of the community members but yeah Michael is there anything are there any certs that are in imminent danger of expiring well I think it's three months okay so it's not it's you know we've got our hey an email hey it's going to expire there's I can point you at the issue here I'll find it that'd be great thank you yeah I know that I've seen it I just don't know where yep thank you it was like over the weekend even that it came out so let me find that but I'll I'll paste it in the minutes in a minute okay cool great thank you so does this group of people you know assuming that for example Brian and I get together and and come up with them that menu so to speak the description and menu of of what's available now do we want to meet again to to address this is this something that is this a group of people that wants to meet on some kind of recurrent basis do we want to work at Hock who wants more meetings on their calendar I think that personally what could be a good first step would be some sort of either survey or outreach to all the individual projects to surface the kind of information that we need to know to make decisions I feel like something like that can be done asynchronously without a meeting we can meet after we have some research does that seem reasonable to individuals I think definitely getting more data on that that makes sense although it's is it that like do we is it that a survey where we ask questions or are there people who actually know what the infrastructure is I'm just thinking like what's the most effective way to get the information is it a survey as is what I'm not 100% sure on well from my experience the only way to get information from just go ask them directly I haven't had just a boatload of success sending you know a google survey out and getting a lot like uptake from everybody but going out and asking really active maintainers and all of the projects for 10 minutes is basically how I'm able to get any information from yeah like a tell us about your build infrastructure for you know 10 minutes 20 minutes and then whoever's meeting with them writes it all down and then then you've captured what hopefully what you're going to get right yeah that's and like I said that's why I'm just kind of suggesting like like onboarding the onboarding process is one way to do that because I've already got planned a planned to at least capture one one kitten from each of these projects for when it's 30 to hopefully get the get that information I mean the other the other approach would be like to tackle each of these you know we've talked about say D&S credential management like to try and tackle it based on each of those topics as opposed to trying to go and get like tell me everything about your build infrastructure right because sometimes that means it's hard to get either get a fire hose or you get a high level summary yeah like if we went to if we if we you know we put together that list that says here's the services that are already available and then we validated that those were a fit or not fit with the existing projects by figuring out whether they're using them not using them doing something completely different or I like that actually I like that I like that way of looking at it you know I'm sort of like the certificate one you could go and say how do you manage your certificates ah oh well do you want us to help by doing this or or no we want to do it you know it sort of validates what you've got to it seems less like also it's it's less challenging perhaps for for a project to say yeah I can I can tell you it's a smaller bite size ass that's just yeah yeah yeah I would also just suggest to that we we may want to consider the difference between what legacy projects use or existing projects use and what we recommend new projects use yeah because we may uncover in some of this is there some convoluted processes or that there are vendors being used that you know through some particular relationship that the use of that vendor can't be expanded or at least not at the price that a project is getting it and we wouldn't want to disturb yeah if there's convoluted processes convoluted for a reason we wouldn't want to disturb that just for the sake of getting everybody the same but at the same time don't want to replicate it either no no no I don't think any of this should be you're forced onto it it's just like hey here's what we're recommending for new projects if this makes sense to you you know it's available and if you want to switch over then it's something we help we help with right yep because it comes down to that you know you can only you can only economically support one or some small number of things right and it's and being part of the foundation is hopefully that we we find something that's good and get some economies of scale so and yeah so if you go ahead sorry go ahead no go ahead okay if you I know speaking from a maintainer perspective if you came to me with this survey one of the first things I would ask other than the ones that I've already brought up would be this question that send deal posted in here about physical infrastructure for CI stuff has that been covered in the mean I know it was late so has that been covered otherwise in this meeting nope that's sort of under we said build was an area but and it would fit under that but we haven't dived into it okay because that would definitely be probably the number one thing on my list as a maintainer of things that I'm looking for so I'm sure you'll probably get that feedback and if we don't have a good answer or direction at least you know right we did talk about like if a if a bunch of people were using Travis which kind of fits into that but it's I think we talked about that in the package maintenance working group a little bit and I and I'm actually I've got some opinions first because GitHub actions just opened up yeah oh yeah there's other options exactly yeah right and and also I think though neither of those solve the other types of things like what he was talking about here which is things that are not provided by CI provider so I'm you know I have one idea in mind right now but I think there's probably a lot that different projects have what that aren't going to be like oh use Travis oh use GitHub actions so like having virtual machines or something that's certainly something I could see where it's like you know through like the the node community has done a really good job of getting volunteers you could imagine the OpenJS foundation working to get volunteer resources for its member projects and then when you come it's like yeah okay we can give you a VM from here or whatever yeah that's kind of what I was thinking so there's two projects that I'm kind of thinking about here one is not really a OpenJS foundation thing yet but it's that npm sort of proxy registry thing which will help would would help distribute load and that requires some infrastructure the other one is doing two-factor auth publishing for npm packages so this is another thing that Express is interested in but would require at least an API the the solutions that we are looking at would require some API consistently running somewhere to handle some orchestration so those would be two very concrete use cases where having some infrastructure provider that was sort of ironed out and hopefully free but if not free you know at least easily you know manageable financially all right so um it is just about one before the top of the hour and I do have a hard stop but I do I have also these two notions of next steps this description document and some some data gathering process is everybody okay with the action items out of this meaning being that Brian Warner and I will connect and put a plan forward for that data gathering and also a document for your review on that description of what's available now and then we can we can asynchronously take a look and set a next meeting is that does that capture what sounds good to me I'll also post this this video here and about an hour I've got a couple more meetings that left this afternoon but I'll post the video along with the summary of notes to the issue and to YouTube for you sounds good all righty thank you all very much for your time I hope you all have a wonderful rest of your Monday all right thank you Joe bye bye bye bye thanks y'all