OpenJS Foundation Cross Project Council Meeting 2025-05-27  ## Metadata - Author: [[OpenJS Foundation]] - Full Title: OpenJS Foundation Cross Project Council Meeting 2025-05-27 - Category: #articles - Document Note: --- tags: - #OpenJSFoundation - #CrossProjectCouncil - #OpenSourceGovernance Author: Merlin AI (Transcript) Source: YouTube, OpenJS Foundation Cross Project Council Meeting 2025-05-27 Reference: https://www.youtube.com/watch?v=1tuLCasmKbo date created: 2025-05-28 08:15 --- # Title: OpenJS Foundation Cross Project Council Meeting Highlights — May 27, 2025 ## Table of Contents: - [📢 Announcements and Board Updates (00:12)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=12) - [💰 GitHub Dev Connect Program Resources (02:57)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=177) - [📄 Proposal for services.md Documentation (08:16)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=496) - [🔔 Notification and Documentation Flexibility (11:07)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=667) - [📦 npm Continuity Policy Focus (16:18)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=978) - [🔐 Authorization and Org Structure Discussion (18:58)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1138) - [⚙️ npm Package Management and Governance (23:14)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1394) - [📋 Encouraging npm Org Usage with Flexibility (25:11)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1511) - [📑 Standardizing Code of Conduct on GitHub (29:25)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1765) - [🏷️ GitHub Repo for Community Docs & Health Files (31:43)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1903) - [👥 Project Management and Native Script THC Charter (35:45)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2145) - [🛠️ Working and Private Session Agenda Items (38:03)](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2283) ### References: - OpenJS Foundation YouTube Channel - Merlin AI Transcript Service ## 📝 Summary: This meeting covers updates and discussions from the OpenJS Foundation Cross Project Council on May 27, 2025. Key topics include event support resources, documentation proposals, policy updates for npm package management, governance discussions about project maintainers, and community management strategies. The council balances transparency, security, and flexibility in policy implementations to support diverse project needs. ## 📖 Main Content: The OpenJS Foundation Cross Project Council meeting provided a broad overview of administrative and strategic efforts, focusing on collaboration and sustainable project management. Early announcements informed maintainers about event ticketing discounts. Discussions about GitHub’s Dev Connect program highlighted additional resources for projects. Several agenda items centered on documentation best practices, including introducing a `services.md` file for projects, with flexibility around public or private storage due to sensitivity concerns. A significant portion focused on continuity policies for npm packages, addressing security concerns and advocating for the use of npm organizations without mandating structural changes for maintainers. Governance challenges included balancing centralization with flexibility in documentation and policy propagation, particularly regarding the Code of Conduct files and GitHub repositories. The meeting concluded with planning for upcoming working and private sessions to tackle community documentation and sensitive issues. ### 🗒️ Notes - [**Announcements and Board Updates**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=12) - [Early bird ticket discount for maintainers via Slack.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=12) - [Board meeting recap and pending legal updates (loop back exemption).](https://www.youtube.com/watch?v=1tuLCasmKbo&t=12) - [**GitHub Dev Connect Program**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=177) - [Funding and swag support for NO.js Summit.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=177) - [\$3,000 allocated by OpenJS for collaborative resources.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=177) - [**services.md Documentation Proposal**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=496) - [Document service providers for projects’ infrastructure support.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=496) - [Sensitivity requires choice of public/private storage, impacting notifications.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=496) - [**Notification Flexibility**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=667) - [Encourages clear notification of document status.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=667) - [Addresses confidentiality alongside transparency.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=667) - [**npm Continuity Policy**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=978) - [Policy focuses on npm, with future possible expansion.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=978) - [Options: org-based or direct package access, with separate project accounts for security.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=978) - [**Authorization and Org Structure**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1138) - [Security concerns over account access and publisher privileges.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1138) - [Discussion on whether to require org creation vs. allowing existing structures.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1138) - [**npm Package Management**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1394) - [Clarification on handling direct package access vs. org membership.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1394) - [Consideration of governance differences among projects.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1394) - [**npm Org Usage Encouragement**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1511) - [Compliance guide may recommend npm org usage, but allow flexibility.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1511) - [npm tooling complexity noted as a barrier.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1511) - [**Code of Conduct on GitHub**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1765) - [Push for centralized policy propagation via GitHub repos.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1765) - [Visibility and discoverability concerns if not in root directory.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1765) - [**GitHub Repo for Community Docs**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1903) - [GitHub repo doubles as org landing page and documentation hub.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1903) - [Cross-linking via readme and website for accessibility.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=1903) - [**Project Management and THC Charter**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2145) - [Call for community review and approval of Native Script THC charter.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2145) - [Encouragement of ongoing collaboration.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2145) - [**Working and Private Sessions**](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2283) - [Focus on readme updates, organization of community docs.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2283) - [Private session scheduled for sensitive matters.](https://www.youtube.com/watch?v=1tuLCasmKbo&t=2283) ## 📖 References: - OpenJS Foundation official website and documentation. - GitHub repositories for OpenJS projects. - npm package management guidelines. - Contributor Covenant Code of Conduct documentation. ## 🗣️ Paraphrase:  - The meeting emphasized the importance of balancing transparency with the privacy needs of various projects, especially when deciding where sensitive documentation such as service provider lists should reside. Projects can opt to keep these documents private or public, provided proper notification mechanisms are in place. - Regarding npm package continuity, the council recommended flexibility for maintainers, encouraging but not requiring the formation of npm organizations to help streamline access management and security. This approach respects the diversity of project setups and avoids imposing undue structural changes. ## 📰 Newsletter: Hey WordPress enthusi - Summary: To learn more about critical open source JavaScript projects like Appium, Dojo, jQuery, Node.js, and webpack, and 27 more checkout The OpenJS Foundation: https://openjsf.org/ - URL: https://www.youtube.com/watch?v=1tuLCasmKbo All right. Um All right, everybody. Welcome to another episode of the OpenJS Foundation's Cross Project Council meeting. Uh today is May 27th and um let's get things started. Uh do we have any announcements? Uh one for the maintainers. We have uh early bird discount tickets set aside if so if you are an act or JSCOM. So, if you are an active maintainer of one of our hosted projects and give us a shout and we'll give you that code for that early bird discount. Great. Uh, and of course, if you're a maintainer, uh, this was posted in the Slack channel. Um, so if you're not already, you're watching this, join, uh, our OpenJS Slack. Cool. Any other announcements? If not, uh, we'll go on to the next item. Uh, the board meeting is happening this week, so I don't know if we have any updates from the board, but certainly if anybody has anything that they'd like us to bring to the board, uh, please let us know. Uh, board happened last Friday. Oh, did it really? Yeah. Oh, wow. Oh, that's right. Oh, I I wasn't feeling well, that's why. Okay, never mind. So, then let me rephrase that. Uh, do we have any updates from the board? [Music] Um, well, I think again I think it'd be good for us to uh share with the regular members the slide. So, why don't we work on that? So, okay. Yeah, sounds good. That's funny. That totally slipped my mind. Yeah. Uh good. All right, moving on then. Um do we know if we have anything from these um um you know waiting on labels here? Uh the first one is the uh waiting on legal which is the loop back exemption which I don't have an update on. Uh that's kind of on my plate. Um nothing on staff updates. Uh, and nothing on website updates. So, I think the only thing is that loop back thing that I talked to Ben about actually um I think last week. So, um we're going to try to make progress on the loop back stuff. Great. So, uh that allows us to jump into the agenda. The first item on the list is 1472. Um, Cladio opened this up a couple of days ago. Uh, resources, GitHub's Dev Connect program. Um, I don't think Cladio is on. Nope. Uh, so if anybody knows anything about this, please feel free to jump in. Uh, this is the Whoops. Dang it. Where did it go? This is the uh issue here. Uh, it looks like there's a program that GitHub's doing that could help provide support for NO.js collaborator Summit with funding, GitHub swag, access to GitHub offices, and other resources. So, wow. We have uh we have resources as well. So, I think we'll just pull the resources. So, if you're a project uh at OpenJS, we have $3,000 set aside for the same things. We often work with um community uh like corporate members and just sort of friendly companies who do host us. So, that's great that we'll we'll sort of put that in our in our toolkit and then maybe we can work with Abby uh from GitHub to sort of kind of blend the two. So, yeah. Yeah, sounds good. That's awesome. All right, great. Yeah. Uh let's see here. Um, so the next item here, something that I opened up as we uh worked through some of the remaining code of conduct uh outstanding items, you know, uh, in terms of our process and documentation and everything and something that that has come up a couple of times, many times actually over over the course of our foundation, um, and I feel like we've We we we've discussed this a lot, but I I don't see this like really documented anywhere. This is um essentially like information sharing between a project and the foundation. Um and so I think you know this is a discussion that we need to have and decide what it is. Um you know co code of conduct reports are are um private and confidential. So it's it's not something that we take lightly uh in terms of considering information sharing. But the thinking is if there is some sort of bad actor who's uh behaving poorly in in one project and is is is doing the same things in another project that that sort of information would be good to know. Um, so I don't know if this is a discussion for right here and right now or a working session or you know maybe we get through the agenda and can kind of revisit this. But um I certainly welcome folks to uh comment on the issue and uh have the have some conversation there. We'd like to figure out when it would make sense to share any information um uh if at all and uh and then document that clearly. So that's um you know so that it's there in public. So all right something to think about and we will talk more about either later today or um sometime soon. Uh the next item this is just kind of remaining open. Um there is uh the the issue is uh what version of the contributor covenant of code of conduct should we use? I think we've all agreed that the uh version three uh is something worth waiting for. Some of us have even uh worked with the team who's developing it uh to give some some feedback from from the cross project council and um I spoke with one of the folks who is working on it trying to get a timeline for the effort and I think that it's a bit open-ended but um they brought up a they they uh you know thought that having a timeline would be good for them uh uh to move things forward And one thing that we discussed was um having it uh uh in place uh well before our event later this year. Um so the suggestion is maybe like by August 1st they have um you know uh things buttoned up and the new version 3 uh released. So I'll find out more and see if that date is something that works for them. Uh but the thinking is it'd be great if we had it in place could update all of our documentation kind of wrap up uh the remaining items of our code of conduct uh process and policies work uh and then additionally give us time to um communicate with our projects and and kind of just do that cascading work as well. So, uh, once I get confirmation, uh, or just generally hear back from the group when they're targeting, uh, to be done, I will update that issue and we can move along. Cool. Um, next item uh, is this um, uh, issue 1425, proposal to add a services.m MD or similar documentation to OpenJS projects. feel like we've talked about this a bunch. What am I seeing? Oh, I think we were waiting for Rudd, who commented 12 hours ago and I believe is on the call. Um, Rudd, do you want to um summarize your uh well-ritten comment here for the group? Sure. Thanks, Joe. Howdy, folks. Um so um this is regarding having a services MD file that Ben proposed to capture the uh various service providers that hosted projects are using um as part of their development infrastructure um and to support their projects. So um the item was brought to the security collab space because for um an opinion on implementation detail to do this in like a safe reasonable way that would be um um hopefully satisfactory to project maintainers uh because of the potential sensitivity of the aggregate of this information. Um there was but the discussion uh much like the comments in the issue went kind of a lot of different directions and the general sentiment to summarize it really briefly is that some projects are going to feel like this information is fine to store in a public place and some projects are not going to be okay with storing this information in a public location. So uh the consensus was that we really just need to be flexible on this and give projects the freedom to choose how they would like to store this file. Um if we would like to maximize for um adherence to the policy without um a lot of additional discussion. So, uh, basically that kind of introduces some interesting challenges and I I'm looking forward to hearing feedback from, uh, Ben and Robin in particular because, um, given that we're talking about giving projects this flexibility on where exactly they put it, public or private, um, and where they put it in their own, uh, repost structures to best suit them and their own governance model, um, that might introduce some inconsistencies in how uh, um the foundation folks that are supposed to be getting notified of changes and track changes on these documents um get that. But um yeah, the general consensus would basically like we need to give people the ability to put this in a public location or a private location. Um and um just make sure that they notify um the right folks when the document exists and do so in a way that they can be notified when there's document changes. There's another aspect of it related to um notifying folks like Ben when projects are also looking to um starting to look for partnerships or looking at services, but that isn't necessarily a repository documentation thing and um is more related to just making sure they're contacting the right folks. So, that's also covered in the policy, but that's pretty straightforward um and simple. any thoughts on that? You've may I think you missed some of the discussion we had earlier. Um I think Michael you had sort of pointed out that this information is pretty obvious to find anyhow so we may as well make it public. It's nice for particularly the folks who are providing sponsored services um which I like and sort of that transparency. Um but there's one project in particular I don't know I think we you know oftentimes we have policies and then we can break them on a casebyase basis and I'm okay with that as well um if the project feels strongly. So yeah, I think the last discussion as I remember it was yeah, generally like I can see a lot of it may be obvious but like we we can understand the security concern. So that's why you were kind of asking for the the security punting it to the security working group to say like well what's your recommendations? Frankly, um, just for transparency, I fell on the side of the argument that this information should be private. Um, that's the former intelligence analyst in me who always valued open source to save time and trouble even if yes, we could do it ourselves. Um but um at the same time there was feedback from folks and like um like like was just said this information is likely discoverable if someone really wanted to go through the effort but there are offset concerns about the ease of doing so to reduce friction to doing things. So, um that's why we're just going to offer folks the flexibility and um we can see how um projects implement this policy and do refinements as this meets reality, I think. Okay. Uh what are next steps on this? Well, um I put the markdown version in the issue itself. There's also a link to a GD doc if you all prefer to do inline comments um on um big ideas or just how things are phrased right now um more easily. So I think just looking for you all's feedback. This is also going to go to security cloud space to get their line item feedback as well. but wanted to just present here first for you all to have a chop um and give the feedback from y'all's perspective. So, um that's pretty much where we're at. Great. All right. Well, I encourage folks to um you know uh uh read through that issue and and particularly RD's comment there or the G do uh if you prefer and um help us refine that and uh keep it moving forward. Yeah. Yeah. Thanks to Rudd and and the the folks on the security group. Appreciate it. I have another item if you wouldn't. It's very similar to this around the continuity policy for npm if uh we wouldn't mind skipping to that one. Yeah, no problem. I'm going to take it and post it uh in the right order on the agenda. And now it's official that that is the next issue. Uh go ahead, Rod. Awesome. So uh there was a there was also an ask around an end a continuity policy related to package registries. Um in practice this policy right now is exclusively focused on npm. There's absolutely room to include other package registries in the future, but um really npm is like the primary target for this and we can go forth and be awesome just focusing on that first and uh depending on based on feedback and how we see that goes. We can then iterate to expand the scope to other package registries if we wish. uh the idea here uh and the continuity policy here was based uh in structure and a concept very strongly on the GitHub uh continuity policy that's already in place. Uh the idea here is that um there would also be that sort of account continuity with um the npm packages that um projects are running. The in terms of implementation detail here there are a couple different options. um if and it depends on how the project themselves are managing their access to their packages. So if the project is using an MPM organization to um put all of their packages together under umbrella manage access that way it's relatively straightforward for um Rob and Ben or others to be uh given access to those um that organization the policy I'll get into a second. The other option is if they're not using an npm organization and they're just granting access um directly on packages themselves. That's the other option in the policy that's covered as well. Um if there's other approaches um that should be covered, I'd appreciate uh smarter people's thoughts and feedback if another option is necessary. Um, in terms of account security for this, in terms of like a security for this, um, granting Robin and Ben access to all of these MPM packages, which is pretty scary, is an idea that, uh, we'll create separate accounts for each, um, project so that uh, and those the credentials for those accounts will be stored in um a one password vault and that way um Robin and Ben's own npm accounts don't have like like universal access to everything and making their accounts like really good targets for hackers. Um and so we'll have that kind of author that uh authorization and authentication isolation between the projects. Yeah. Hey. Um, so I I'm fine if it's a compromise and if there's push back from projects on it, but I think that our ideal is everybody sets up an org. I don't see how even adding a service account is not additional risk that we should just at least try to avoid. Like I I understand maybe there's some reason why maybe somebody will come back and say, "Hey, I just we're not going to do that, right?" And then we have to discuss with them what the reason is. So we understand, but I don't think that seems likely. So I would rather us just like push folks to create an org because it just avoids the whole problem. I don't know how people think about that. Maybe other folks have seen push back already um on creating an or that I'm not aware of. Chris. Um, yeah. So, I think it's important that we do not push maintainers to do something and give them the option. Um this was um this is something I I felt sort of fairly strongly about when we were working on this was I don't want to have to say oh in order to be in compliance with this continuity policy you must now shift your uh npm structure by adding an organization or or stuff like that. Um we should meet folks where they are. Um and if that's that they have an organization already great. and if not that we shouldn't have to make them add one. Um, now that being said, what I don't understand from the comments you just made, Wes, is what you you said it like avoid it solves some problem. Um, what what did you mean what what problem is solved by that versus not having the Okay. Yeah. Yeah. Yeah. So, two main things. One is obviously just increasing the number of accounts with publish rights. Obviously, since we would be doing individual accounts, we limit the scope as much as we can, but there's no way to add a person account. Let's call it an account. There's no way to add an account onto a package without it being a publisher directly. But you can add a account into an org without it being a publisher. You can even be an admin without being a publisher, right, in an npm or So, it avoids having another badge on that page, another account that is a target for attack, right? Um, well, I mean, let me interject though, but but if if you add them and they're not a publisher, they can make you make themselves a publisher. It's an extra step, but if the account is compromised, they have the same access either way. That's true. Um, it would take another step and it's not. So, so then this Okay, here's my second point actually then. Uh, like I don't imagine Robin sitting there fat fingering a new npm publish, you know what I mean? No, no, no. I'm not trying to imply that or any of that. Yeah. Yeah, totally get that. So, here's this the second point. Uh, it's visible if it's a direct ad. It's not visible if it is in an org. Um, so it it makes it a target. So uh you so for example every time we add somebody uh I get notifications from socket.dev dev and uh tidelift when a new publisher is added and that new publisher then would become because it's visible uh would become a target whereas just being secret is I know security by obscurity is not a real thing like I get that and and you're right but um and also we're going to talk about it on these calls so like somebody watch the recording uh I get that uh but at least it added one more hurdle that is not there when you just have it literally front and center on the npm package page. I see. Um okay. Um two things. One, I think that's an important detail that you mentioned and I think that if it's not there, you know, we may want to spell that out in the policy that if you do this and you are not using, you know, adding someone to an org and instead directly to the package, they are then listed and and all that. Um, I think that's helpful context for folks to have. Um, and but that being said, I still think that, you know, that decision of what how to proceed, um, should be left to the maintainers. Um, the other thing I'll point out is that I, you know, I don't know, I don't want to put my foot in my mouth, but probably most of the OpenJS projects do have npm orgs rather than just directly a package. Um, and the ones that don't do orgs are probably the ones that have like only one or two maintainers. Um, but then I guess now that I say that, then that's probably going to be mostly who this applies to cuz because other or probably just going to opt out like Express would probably just opt out due to the the governance that exists, right? Things like Node are probably going to opt out of this. Um so these the folks that this will impact I guess in the in the broad sense would be the ones that are less likely to have um an organization. But anyway, Adam has hand up. Yeah, I think this is a really good call out and I appreciate you saying this because I uh actually was wondering the same thing about this and so I think you're absolutely right. should be mentioned in the policy. Um I wonder if another solution here is like right now we don't really have a lot of data to know how this is actually going on and like how many folks might actually not be running npm orgs. Um so um what my takeaway here actually is that ensuring that MPM orgs are used should probably be an item we add to the compliance guide and then the policy can be updated to say like we really strongly recommend you take this approach. Uh however if um you know if you're not using npmorgs here's how you should do it but um we really think you should be using npmorgs and put them on a road map to making that transition but in the interim um they're adhering to um the policy while they can so we can decouple that kind of improvement um from adherence to the policy itself in the short term. Yeah. The other thing that makes it harder to, you know, I I do have this sort of blanket like, well, we don't want to like force people to change how they're doing stuff. And I I do feel fairly strongly about that. But the other unfortunate thing is that organization and team management and npm is a little bit um not intuitive, shall we say? It's it's kind of confusing. I feel like every time I have to go in there and do something, I have to like relearn the the quirks of it. Um, and it's just you have to write an entire doc and spend like days going through the docs and I was still wrong because npm's own docs deny. Yeah. And then and then and then it's also confusing because there's like different stuff with the CLI with the, you know, the publishers or the authors or whatever term they use there. And so it's just a little bit messy. So, it it it makes it a little bit harder to to for me anyway to say like, "Hey, you should use this thing because it's great and here's why." Because it's like, "Well, you're going to have some pain uh to go along with this anyway." But we can move on. I think Wes had to drop anyway. Yeah. All right. Well, um you know, uh RD added his comment uh last week uh on this uh particular issue. Uh so I encourage folks to, you know, go to the issue and comment there as well and can keep working on it. Cool. Uh great. I will somebody have anything else? You good? I just wanted to say thanks for the feedback in advance, folks. And um yeah, if you have any questions or you're not sure about stuff, just toss it in the comments and we can just work through it. Great. I appreciate in advance. Thank you. Yeah, thank you, Rod. Appreciate all your all your work. Right on. Uh next item is 1417. Uh this is the issue that Michaela pulled together for the remaining code of conduct plan of action here. Um you know I think one thing that we are working on is [Music] um uh where did we where have we talked about this in the last meeting and Kate I know you you did an inventory. I'm trying to rack my brain as to what what are where we landed with all that. I think we decided we were going to wait on this um and try and ensure some continuity across projects. Uh there were kind of a few people who were using different codes of conduct. Uh some people using OpenJS. Um so we kind of want to wrap up our own version of this code of conduct before we start um directing people to uh change things on their own projects. Great. Yeah, that's right. That's right. Okay. Excellent. Um okay. So that is um the first part of that issue. Get back to it. Here it is. Uh that's item number one. Um and then uh the item number two is the contributor covenant which we're waiting on. And item number three has its own issue as well. So I'm going to move along because the next issue is the GitHub uh one uh GitHub repo. Um so this is issue 1395. Basically our recommendation uh as a foundation to our projects is that they should have agitub repo in their org which will um you know allow certain policies to propagate to to any repos that don't have those policies already explicitly stated. Um but I think in discussions in the past that you know there's been I don't know if if there's been full agreement on whether uh this is something that we should do. I think the the the challenge I mean we can certainly create a doc we already have a GitHub repo and and we can add the code of conduct to it there. I think part of the concern that I've heard in the past is that if you do it that way and you rely on the GitHub repo to propagate all of your uh policies like that, then you don't have a code of conduct.md file in your root of your repo, which is a common place for folks to look. So I don't know you know what we recommend what we think you know thinking this fully through what what we should do and what we should encourage others to do. Um, Megan, I just uh I wanted to inquire about has on um saying that looking for code of conduct empty is really common to look for. Has that changed at all since GitHub added the tab on the homepage? It's a good question and I'm not sure how how we would know for sure. I mean, I think for me at the very least if I looked for it and I didn't see it, I would look for the tab or the sidebar. It'll say on the sidebar as well. So, you know, maybe it's not that big of a deal. Um the other question is if you have the repo down you know uh on your local machine but still people can just go to GitHub. I don't know if it's really that big of a concern. Does anybody have any thoughts or comments on on this particular thing? Which one are we talking about? We're talking about the GitHub repo. Um I know we you know we already advise folks to use that but you know we should do we should you know dog food that as well and yeah so I don't know that we can resolve this without Toby. Um and I think it would be something to that's better discussed like here in the meeting rather than they sync comments back and forth in the issue. Um, Toby, like the way that I read his comments, it seems he feels like strongly about it, which I find kind of surprising, but it might just be how I'm how I'm reading it. Um, and yeah, we provided the guide to community health files, say use a GitHub repo, and then when it comes to using it ourselves, for some reason, we're not going to do it. Um, I mean, it's the canonical place to put that stuff. uh you know I do see his point about well now we've got to you know track a separate repo for these things and I he'd like to keep it centralized which is not an unfair point. Um but I think at the end of the day it's better to have that content in the GitHub repo. The other thing that came up in the working session was that um beyond just the community health files um using the GitHub repo as because it's also the if you create a profile page in there, it's also the landing page for the org in GitHub and that we should also utilize that functionality and some of the content that right now lives in the CBC readme probably moves over there as a more appropriate place. Um, and that can be kind of worked on in tandem with the, you know, the sort of the stalled effort to to revamp the readme, uh, within the CPC repo itself. Um, so I think these would be good things. Um, I hope uh that Toby would be open to this. Um, you know, I I the stakes here aren't like super great one way or the other. I don't think, you know, either way is necessarily wrong, but I I I do think we should do it. Um but yeah, I don't think we can resolve without chatting with Toby. Yeah. And just to be clear, I I think the intent would be to put the code of conduct in the GitHub repo and not have a code of conduct explicitly in any of the other OpenJS repos because they would naturally pick them up. And so the idea of things getting like out of sync doesn't really we would just delete the one that's in you know the the code of conduct the MD file. Exactly. Yeah. It would introduce another repo but it would like in practice help with centralization. The repo already exists. So uh we've I guess we've already incurred the cost of the separate repo but it's it's sitting there I think empty uh right now. Um but but yeah um but it's also like people are used to the GitHub repo. It's a thing like it's not something brand new. uh you know people know to go there for certain things and yeah sorry Joe you were talking I was just gonna say that we can link to it from the the the read me of the CPC uh as well as the org uh profile read me as well and just make sure that you know people are aware where where it is uh anyone who's not familiar with that concept we also link from the website yeah so I don't think it's going to get lost or you know buried or something. I think it'll it'll be there. Uh and it is kind of the most practical way to go I think to manage it. So, but I agree Toby is one of the folks who expressed concern about it. So, um we need to have Toby in the conversation at a minimum. Um, so I added the label um, working session to this one too. So we can consider that and and some of the other efforts that we take up in our uh, working session work. So all right, no no decisions on this today. Although I'm going to um, just copy this and prepare to send it over to Toby to let him know. We're sort of waiting on him uh, to to be a part of the conversation. Um all right so moving on the next item is the uh health check on the native script THC charter. Um I am getting this confused with Okay. Yeah. Uh so Nathan Walker opened up another issue uh two weeks ago. Um and that's this issue in particular that I'm dropping in the chat. Oh, wait. Sorry. Yeah. Okay. No, the the link to the PR is there as well. Um, so I uh recommend folks uh you know go over there, take a look um and uh you know, drop a thumb on on on either the issue or the PR uh to help them move their their work forward. I know they've been working on this uh charter for a while and have gotten some input from uh members of the CPC and so I think it's in pretty good shape but we should uh take a look and and uh you know approve that help them to move it forward. Um the last item is uh the one that we spoke about earlier uh onboarding and post-graduation checklist to match the new COC policy uh which we have you know on our list of things to do once the contributor uh version 3 code of conduct drops and then we can kind of uh update all of that stuff. So uh that is it for our main agenda. Um, two things. Uh, we should figure out what we want to do in the working session and then also we can have a private session for uh uh a private item. Any thoughts on the um private session uh sorry on the uh working session? Uh first thing that comes to mind for me is the um the readme work and the org profile and stuff like that. Um, but let me take a look at what uh what things are labeled for uh working session. So this is the list of issues. There's, you know, code of conduct stuff, the GitHub repo. Um, migrate project status repo back here is another one, uh, that I think is already kind of in progress, uh, because I know the Cosmos project was was managed in the CPC repo. Uh, there's even a couple of older items here that I think we need to revisit and see if they already been uh, needed any longer. the community voting member simplify CPC governance. Um, anybody have any thoughts? If not, I think I think the the repo readme and the org readme are probably a good uh chunk of work. we could, you know, sit down as a group and start to uh separate that out and see what what best belongs where and um yeah, and kind of make some progress on that. Sound good? Um and then if we can get uh Toby in on the call too, we could we could talk about GitHub repo uh briefly first perhaps. All right, cool. Um, so I can stop recording. I think we have uh members here uh regular members and whatnot. So we can uh get into our private session. So before I stop, thanks everybody if you are watching this uh or watching it later. Uh as always, you know, feel free to get involved in the work that we're doing. Uh go to openjsf.org/c collaborate to find um you know, our calendars and our Slack channel and all that stuff. So um thanks. See y'all soon., OpenJS Foundation Cross Project Council Meeting 2025-05-27, OpenJS Foundation, 01jwbmybcw291wqw3x11gaw46q.