Security Collab Space Meeting - December 8, 2025

Security Collab Space Meeting - December 8, 2025 🔗 **Source:** [Security Collab Space Meeting - December 8, 2025](https://www.youtube.com/watch?v=MLWIXWraRrQ) > [!note]+ Document Notes > tags: [security, dashboard, alpha-omega] > author: Security Collab Space > source: YouTube > reference: https://www.youtube.com/watch?v=MLWIXWraRrQ > date created: 2025-01-06 14:30 > > # 🏷️ Title: Security Collab Space Meeting - December 8, 2025 >  ## 🧰 Action Inbox - [H1] File PR to add dashboard integration to CPC onboarding checklist — 05:23 #security - [H2] Clean up security collab space issues and kanban board — 18:45 #maintenance - [H3] Link dashboard from security collab space readme — 04:12 #documentation ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Security Dashboard](https://github.com/openjs-foundation/security-collab-space) - [Alpha Omega Initiative](https://alpha-omega.dev/) ## 📝 Summary - Security Collab Space launched new public security dashboard to track OpenJS Foundation project security posture - Dashboard migrated from private "command center" repository, with contact information moved to separate private repo - Team plans to integrate dashboard into CPC onboarding process and wrap up 2025 Alpha Omega work - Meeting schedule adjusted for December holidays with potential renewal discussion pending - Focus on non-invasive monitoring using public information and scorecard assessments ## 📖 Main Content The Security Collab Space team demonstrated their new security dashboard, a public tool for monitoring the security posture of OpenJS Foundation projects. The dashboard replaces the previous "command center" repository by splitting functionality - keeping security tooling public while moving contact information to a private repository to prevent spam. The dashboard tracks security scorecards, security.md files, and governance changes across foundation projects. It uses only publicly available information without requiring tokens or invasive monitoring. The team plans to expand tracking to include CVEs and npm packages in the future. Discussion centered on integrating the dashboard into the Community Projects Committee (CPC) onboarding process. The team agreed this should be a requirement handled by the security team rather than burdening new projects with additional setup tasks. Plans include creating a PR for the onboarding checklist and discussing at the upcoming CPC meeting. The team is preparing for year-end activities including an Alpha Omega annual report and potential renewal discussion. December meeting schedule will be reduced due to holidays, with focus on cleaning up existing issues and planning 2026 work pending funding confirmation. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/MLWIXWraRrQ?t=0) — [H1] Meeting opening and dashboard introduction - Key idea: Weekly security collab space meeting focused on dashboard launch - Evidence: "Welcome to the Monday, December 8th, 2025 security collab space weekly meeting" #### ⏱️ [01:23](https://youtu.be/MLWIXWraRrQ?t=83) — [H2] Dashboard architecture and migration - Key idea: Command center repository split into public dashboard and private contact points - Evidence: "In the past we had a repository called command center which was a little bit different" #### ⏱️ [02:45](https://youtu.be/MLWIXWraRrQ?t=165) — [H1] Security scorecard integration and monitoring - Key idea: Dashboard tracks security scorecards and security.md files across projects - Evidence: "You can see like what's status of the project in terms of the scorecard" #### ⏱️ [04:12](https://youtu.be/MLWIXWraRrQ?t=252) — [H3] Non-invasive monitoring approach - Key idea: Tools use only public information without requiring project tokens or permissions - Evidence: "The idea of these toolings is not to be invasive" #### ⏱️ [05:23](https://youtu.be/MLWIXWraRrQ?t=323) — [H1] CPC onboarding integration discussion - Key idea: Dashboard should become part of CPC onboarding requirements - Evidence: "Getting this as a requirement or an item on the project onboarding checklist for the CPC" #### ⏱️ [07:15](https://youtu.be/MLWIXWraRrQ?t=435) — [H2] Future expansion plans - Key idea: Plans to track CVEs and npm packages in addition to current monitoring - Evidence: "In the future we plan to add more things. For example, tracking CVEs" #### ⏱️ [09:30](https://youtu.be/MLWIXWraRrQ?t=570) — [H2] Project scope considerations - Key idea: Massive projects like Node.js require selective monitoring approach - Evidence: "Some projects are super massive, NodeJS has like hundred of repositories" #### ⏱️ [11:45](https://youtu.be/MLWIXWraRrQ?t=705) — [H1] Public dashboard benefits - Key idea: Public dashboard helps others understand project security posture - Evidence: "Public dashboard which I think is important also for others to answer like how is the security" #### ⏱️ [12:30](https://youtu.be/MLWIXWraRrQ?t=750) — [H2] Contact points centralization - Key idea: Private contact repository becomes single source of truth for project contacts - Evidence: "That will be our source of truth for contacts" #### ⏱️ [14:20](https://youtu.be/MLWIXWraRrQ?t=860) — [H2] Onboarding burden considerations - Key idea: Security team should handle dashboard integration rather than burden new projects - Evidence: "New projects are going to be super overwhelmed with the amounts of things" #### ⏱️ [16:10](https://youtu.be/MLWIXWraRrQ?t=970) — [H1] Alpha Omega renewal and reporting - Key idea: Team preparing annual report and discussing renewal with Alpha Omega - Evidence: "Alpha Omega has a meeting tomorrow to discuss our renewal opportunity" #### ⏱️ [17:35](https://youtu.be/MLWIXWraRrQ?t=1055) — [H3] Automation impact reporting - Key idea: Alpha Omega specifically requested inclusion of automation updates in report - Evidence: "He explicitly asked us to include the automation update we did" #### ⏱️ [18:45](https://youtu.be/MLWIXWraRrQ?t=1125) — [H2] December meeting schedule adjustments - Key idea: Reducing meeting schedule for holidays while planning year-end cleanup - Evidence: "22nd and 29th, I suspect people will be spending time outside of work" #### ⏱️ [20:15](https://youtu.be/MLWIXWraRrQ?t=1215) — [H2] 2026 planning dependencies - Key idea: Next year planning depends on Alpha Omega renewal confirmation - Evidence: "I was planning my 2026 year yesterday and I don't know what I need to like which path I should follow" ## 📚 References - [OpenJS Foundation Security Collab Space](https://github.com/openjs-foundation/security-collab-space) - [Alpha Omega Initiative](https://alpha-omega.dev/) - [OpenSSF Scorecard](https://securityscorecards.dev/) ## 🗣️ Paraphrase - The security team launched a new public dashboard that monitors OpenJS Foundation project security without being invasive, using only publicly available information to track scorecards and security policies - They're working to integrate this dashboard into the standard onboarding process for new projects, with the security team handling setup rather than burdening maintainers with additional requirements - The team is wrapping up 2025 work with Alpha Omega including an annual report and renewal discussions, while planning reduced December meetings and 2026 work pending funding confirmation ## 📰 Newsletter 🔒 **Security Dashboard Launch**: The OpenJS Foundation Security Collab Space has launched a new public dashboard for monitoring project security posture across the foundation. This non-invasive tool tracks security scorecards, security.md files, and governance changes using only public information. **Key Benefits**: Projects get visibility into their security status while the foundation can proactively identify areas needing attention. The dashboard will soon be integrated into the standard onboarding process for new projects. **What's Next**: Plans include expanding to track CVEs and npm packages, plus integration with the Community Projects Committee onboarding checklist. Resources: [Security Collab Space](https://github.com/openjs-foundation/security-collab-space), [OpenSSF Scorecard](https://securityscorecards.dev/), [Alpha Omega](https://alpha-omega.dev/) ## ✅ Action Items #### DevRel - Developer advocacy: Present dashboard benefits at upcoming conferences and meetups - Education: Create tutorial content for security scorecard interpretation and improvement - Developer experience: Develop documentation for projects wanting deeper scorecard integration - Community management: Facilitate feedback collection from projects using the dashboard #### OSPO - Policy & Governance: Draft policy for dashboard integration requirements in onboarding - Security Management: Establish processes for CVE tracking integration and response workflows - Software Inventory: Plan npm package tracking implementation and SBOM correlation - Developer Support: Create training materials for scorecard improvement and security.md best practices - Strategic Alignment: Define KPIs for dashboard adoption and security posture improvements #### Community - Maintainers: Provide scorecard improvement guidance and security.md templates - Contributors: Create first-issue labels for security improvements identified by dashboard - Sponsors: Develop transparency reports showing foundation-wide security improvements #### WordPress - Core: Evaluate similar security monitoring approaches for WordPress.org projects - Security: Consider adopting scorecard methodology for plugin and theme security assessment - Meta: Investigate dashboard integration possibilities for WordPress.org project monitoring #### The WPCC - Programs: Consider security fellowship program based on OpenJS Foundation model - Projects: Develop security mentorship programs using dashboard metrics ## 🧪 Hypotheses - Public security dashboards increase project maintainer engagement with security improvements more than private reporting - Non-invasive monitoring using public APIs provides sufficient signal for identifying security risks without requiring project integration - Integrating security requirements into onboarding processes improves overall foundation security posture - Centralizing contact information in private repositories reduces spam while maintaining accessibility for security coordination ### 📊 Methodology - A/B test public vs private security reporting to measure maintainer response rates - Compare security improvement metrics before and after dashboard implementation - Survey projects on perceived burden of security requirements during onboarding - Analyze spam reduction in contact repositories vs public contact information ### ❓ Questions - How can we measure the effectiveness of public security dashboards in driving improvements? - What additional security signals could be automatically detected from public repository information? - How should we balance transparency with security in public monitoring tools? ### 🔮 Future Research - Investigate machine learning approaches for detecting security risks in public repositories - Explore integration possibilities with supply chain security tools and SBOMs - Research best practices for cross-foundation security collaboration and information sharing ### 💡 Implications - Practice: Security teams can implement similar dashboard approaches for their ecosystems - Policy: Foundation onboarding processes should include security monitoring integration - Security: Public monitoring increases accountability while maintaining non-invasive approach - Education: Security scorecard interpretation becomes essential skill for project maintainers - Funding: Demonstrates concrete value of security investment through measurable improvements ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Dashboard screenshots and repository organization diagrams - Improve: Add flowcharts showing monitoring process and security improvement workflows #### 🔊 Aural learners - Present: Full meeting recording with clear audio discussion - Improve: Create podcast-style summary of key dashboard features and benefits #### 🗣️ Verbal learners - Present: Clear definitions of scorecard, security.md, and monitoring terminology - Improve: Add analogies comparing security monitoring to health checkups #### 🧩 Kinesthetic learners - Present: Step-by-step repository navigation during demo - Improve: Create hands-on tutorial for dashboard exploration and scorecard improvement #### 🧠 Logical learners - Present: Clear cause-and-effect discussion of monitoring benefits - Improve: Add decision trees for security requirement prioritization #### 🧑‍🤝‍🧑 Social learners - Present: Collaborative discussion format with multiple perspectives - Improve: Include community feedback examples and maintainer testimonials #### 🧘‍♀️ Solitary learners - Present: Self-contained dashboard that can be explored independently - Improve: Add reflection prompts for security posture assessment #### 🌿 Naturalistic learners - Present: Discussion of ecosystem-wide security health and monitoring - Improve: Add analogies to environmental monitoring and ecosystem health ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in meeting discussion - Improve: Add alt text for dashboard screenshots and visual elements #### Keyboard navigation - Present: Standard video player controls for meeting recording - Improve: Ensure dashboard interface supports full keyboard navigation #### Contrast and readability - Present: Clear audio quality for hearing accessibility - Improve: Provide high-contrast dashboard theme option #### Text resizing and reflow - Present: Video player supports zoom and reflow - Improve: Ensure dashboard responsive design supports 200% zoom #### Media and captions - Present: Full transcript provided for video content - Improve: Add time-synced captions to video recording #### Forms and interactions - Present: Clear discussion of action items and next steps - Improve: Ensure dashboard forms have proper labels and error handling ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global foundation perspective on security practices - Improve: Include examples from diverse geographic regions and project types #### Inclusive language - Present: Professional, jargon-free discussion accessible to various skill levels - Improve: Define technical terms and provide glossary for security concepts #### Neurodiversity support - Present: Clear structure with agenda items and logical flow - Improve: Add visual indicators for different types of content and transitions #### Representation - Present: Multiple team member perspectives in collaborative discussion - Improve: Ensure diverse voices in future security discussions and examples #### Psychological safety - Present: Respectful, collaborative tone throughout discussion - Improve: Include explicit community guidelines for security discussions ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Public information monitoring → non-invasive assessment → higher adoption (strong) - Inductive strength: Past project overwhelm → reduced onboarding burden → better outcomes (moderate) - Causal reasoning: Dashboard visibility → maintainer awareness → security improvements (needs validation) - Analogical strength: Health monitoring comparison to security monitoring (appropriate) #### Fallacies - Appeal to consequences: Dashboard benefits assumed without measurement data, needs empirical validation - False dichotomy: Invasive vs non-invasive presented as only options, may miss middle ground approaches #### Tone of voice - Overall tone: Collaborative and professional with focus on practical solutions ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on accusers observed - Reverse victim/offender: No victim/offender reversals noted - Emotional cues and rhetoric: Positive, solution-focused discussion without defensive rhetoric ## 🎯 Conclusion The Security Collab Space has successfully launched a public security dashboard that provides non-invasive monitoring of OpenJS Foundation project security posture. The key innovation is splitting functionality between public tooling and private contact management to balance transparency with practical concerns. Integration into the CPC onboarding process represents the next step in standardizing security practices across the foundation, with the security team taking responsibility for setup to avoid burdening new projects. Success depends on Alpha Omega renewal and continued development of automated monitoring capabilities. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [ --- ## Full Transcript [00:22] Hi everyone. Welcome to the Monday, [00:24] December 8th, 2025 security collab space [00:27] weekly meeting. [00:29] Couple of items on the agenda today. Uh [00:31] we wanted to talk about the dashboard [00:34] launch and I should probably share my [00:36] screen, right? [00:38] All right. [00:47] All right, Ulyses. [00:50] Yeah, here is the dashboard. Yeah, so um [00:53] for give some context to um to who is [00:56] watching this on the recording and who [00:58] is not member of the organization [00:59] especially on GitHub. So in the past uh [01:01] we had a repository called command [01:03] center which was a little bit different. [01:05] Basically it includes an additional [01:07] column for contact points. That piece [01:09] now is private and this is a fresh new [01:12] start for command center but uh with [01:14] some GitHub magic basic with renaming [01:16] and stuff. When you enter again into the [01:17] command center you only see this version [01:19] which is public and it's only include [01:21] the tooling and nothing related to the [01:22] contact points and the contact points. [01:25] If you are missing them, they are in a [01:27] private repository called uh contact [01:28] points if I not mistake it. But yeah, [01:30] the the name is super obvious. So um so [01:32] is there so it's private to the [01:33] organization. Basically the idea is to [01:35] prevent uh from people doing a spam [01:37] using the emails which in most of cases [01:38] are already public, right? But uh the [01:40] idea is just to um centralize this [01:42] information as well. Um so basically we [01:45] have migrated uh all the tools that Raf [01:47] and myself and others have been [01:48] contributing here for a while. Um and [01:51] here basically on the on the readmi you [01:53] can see like uh what's status of the [01:55] project in terms of the of the [01:57] scorecard. So you have the links for [01:59] each of those also you have the links [02:00] for the security MD. Um in some cases [02:03] for example if the project doesn't have [02:05] a security MD as you can see an emoji [02:08] with the X uh symbol. Idealistically we [02:10] are going to do some uh PRs on the [02:12] project to to get the security MDs up [02:16] and running. In some cases there are [02:18] already so I will just do um some [02:21] updates on on the readmi and get more [02:23] updated. So some of these already are um [02:26] security MD there are some context that [02:28] I still need to migrate from the pre I [02:32] mean from the private repository which [02:33] is uh related to some PRs for the new [02:36] project that just recently got uh [02:39] accepted as part of the organization [02:40] members and stuff. So, so there's going [02:42] to be like some changes in the following [02:43] days here to be like more accurate. But [02:45] basically, you can see here uh both [02:47] toolings al you have the the monitor [02:50] tool that Rafael did as well for triging [02:53] changes on the security MD and stuff [02:54] like that. So, basically the idea here [02:56] is to um consolidate information like a [03:00] dashboard about the project. So, uh one [03:02] of the things that you can uh that we do [03:04] proactively for the projects is to run [03:05] the scorecard against them. So we can [03:08] see any changes on the scorecard over [03:10] the time. Also we have the opportunity [03:13] to see changes on the security MD. [03:15] Idealistically also in the future we are [03:17] going to see there is a PC going on um [03:19] on to see for example changes on the [03:21] governance. So if they have a new TSC [03:23] member so they remove someone or [03:25] whatever we can see these kind of things [03:27] as well. So it's more easy for us just [03:29] to get that information back rather than [03:31] waiting the project to notify us. I [03:33] think it's more realistically. And also [03:35] in the future we plan to add more [03:37] things. For example, uh tracking CVEes [03:40] and stuff like that. So if there is a [03:41] new CVE and the maintenance are not [03:43] aware of these kind of situations, we we [03:45] are going to see this uh hopefully in [03:47] the future because we saw recent [03:49] incidents uh where we saw something like [03:51] that. Um so yeah that's that's pretty [03:53] much the idea and and it's an open [03:55] canvas and very open for contributions [03:57] from anyone uh who wants to have ideas [04:00] or time to help us uh building new tools [04:02] around these ideas of understanding how [04:04] is the h project security uh position [04:07] right now and how that evolves over the [04:10] time as well. That's probably the most [04:12] uh important things and also worth to [04:14] mention that the idea of these toolings [04:15] is not to be invasive. Um so we don't [04:18] use tokens to you know track the [04:20] projects or stuff like that. That's [04:21] going to be like more trying to assess [04:23] public information and if we need to do [04:25] something additionally for example the [04:26] scorecard unit you need sometimes um to [04:29] include the pipelines in order to get a [04:31] specific um scores and stuff that's [04:33] something that we can do uh you know [04:35] asking the projects if they want to roll [04:37] on on this initiative and if they want [04:38] to you know em embrace the scorecard and [04:41] which level and so on and and we can [04:42] help them right also worth to mention [04:44] like for example some projects are super [04:46] massive um let's see for example NodeJS [04:48] has like hundred of repositories And [04:50] probably with the scorecard you don't [04:52] want to you know track everything. So in [04:54] some cases we try to do you know just [04:56] and reduce the scope uh in certain [04:58] cases. In others we don't do reduce the [05:00] scope. We just go with everything and [05:01] see what happen and understand how the [05:03] project behaves and then we you know [05:05] just uh focus on maybe the most relevant [05:07] ones and so on. But yeah that that's [05:08] basically the idea and this can you know [05:10] evolve uh a lot a lot of the ideas that [05:13] we see in this tooling are coming also [05:15] from the open pathfinder another [05:17] initiative that we have at the beginning [05:18] of the year and and has been evolving a [05:20] little bit as as um as soon as we [05:22] understanded more how is the [05:24] relationship with the maintainers and [05:26] how much and how invasive we can be and [05:28] how how this tool is going to help us [05:29] but yeah it's going to be in a public [05:30] dashboard which I think is important [05:32] also for others to answer like how is [05:34] the security for each project so idea is [05:36] try to provide some answers here [05:37] basically as well. [05:40] >> This is great. Um I wrote down a couple [05:42] things because I don't want to forget. [05:43] Um first is can we link to this from our [05:46] security collab space readme like that [05:49] main repo. [05:50] >> Yeah. [05:51] >> So I think that's good. Um the other [05:53] thing I was thinking about is oh yes the [05:56] contact points uh private repo. I think [05:59] that's really great and so Robin I think [06:01] for us that will be our source of truth [06:04] for contacts. So won't be a spreadsheet [06:07] anymore or spread out. We'll just have [06:08] that one place and we'll just [06:09] concentrate concentrate efforts there. [06:12] Um the last thing I was thinking of is [06:14] getting [06:15] um [06:17] this as a requirement or a um item on [06:21] the project onboarding checklist for the [06:23] CPC. U I think that's kind of the last [06:25] step. And um this sounds like it's not [06:29] invasive, right? In other words, like is [06:31] this pretty much work that we can do [06:33] without involving [06:35] >> the maintainers at least for the the [06:37] basic integration? [06:39] >> Yeah. Yeah. That's that's the idea. [06:41] Yeah. Also, for example, we want to [06:42] track um let's see MPM packages as well [06:45] in the future. It's a little bit tricky [06:47] because from GitHub tracking the mpm [06:49] packages is not that straightforward as [06:51] it seems. But yeah, that's also [06:53] something that we can do. So once we [06:55] identify you know the mpm packages [06:56] belonging to an specific organization [06:59] then we can start you know to do more [07:01] evaluation on the mpm packages as well. [07:03] I mean all it's based on on information [07:05] that is available publicly and doesn't [07:07] require a spec specific engagement with [07:09] the project. of the idea. [07:11] >> So I think from from the um [07:16] from the CPC perspective, I think what [07:18] we can do is we can do a PR to add um [07:21] add this requirement to the checklist [07:23] and I think the process there would just [07:25] be file an issue in our collab space and [07:29] then we'll do the rest. Yeah. [07:31] >> Do you think we should start with an [07:32] issue because this would be the first [07:34] security requirement we require of our [07:36] projects? [07:38] um [07:39] >> or just created as like [07:43] >> so I I found that the most success I've [07:45] had with the CPC is when I create a PR [07:48] and then [07:49] >> because it's it's nice because one it it [07:52] does give them something very concrete [07:54] to react to which would be like the [07:55] actual change. Um, and it does allow [07:58] them, you know, it gives them a spot to [08:00] to discuss, but I can I can phrase it as [08:03] like a recommendation. Um, uh, you know, [08:06] to sort of soften it a little bit, but [08:08] yeah, we have our call tomorrow, so we [08:10] can discuss it there, too. [08:11] >> Perfect. Okay. [08:12] >> Yeah. [08:14] But yeah, I can file that. [08:18] Okay. [08:20] Any other questions or comments about [08:22] the dashboard? [08:26] uh Chris as a very active member the CPC [08:29] like you think it's a good idea to add [08:30] this to the um to the onboarding [08:34] requirements [08:37] or is this do you would you think that [08:39] this would be I guess the other approach [08:41] would be this is like an an optin but [08:44] I'm kind of curious just from your [08:45] perspective like do you think it's worth [08:47] it? [08:51] >> Um [08:54] sure. [08:55] Uh, [08:57] >> good enough for me. [08:57] >> We do require the security policy is [09:00] required, [09:01] >> right? That technically [09:04] >> um I don't know if it's included in [09:07] onboarding instructions or [09:09] >> if I recall correctly, there's a you [09:11] have to adopt one of our options for a [09:13] security policy. [09:15] >> Okay. Yeah. I mean, I would double check [09:16] that what what we say in the onboarding [09:18] and just like review that for accuracy. [09:21] Um I have mixed feelings about scorecard [09:24] but um [09:26] I would I would defer to uh to to other [09:29] folks on on that aspect. [09:32] Ulysis. [09:33] >> Yeah, I think I think in terms of of [09:35] requirements for on boarding especially [09:37] new projects that they're going to be [09:39] like super overwhelmed with the amounts [09:40] of things they have to do and [09:41] everything's new and so on, right? uh so [09:43] I think just by asking them to you know [09:46] create an issue here or just you know as [09:48] part of the PM process of digesting new [09:50] projects can be just you know creating [09:51] an issue here say like let's see if we [09:53] can on board on this project and this is [09:55] the GitHub organization and from that [09:57] the expectation maybe from any of us uh [10:00] you know take leadership on this and you [10:02] know start doing all the settings and so [10:03] on because also if they are not aware of [10:05] this tooling it's going to be super you [10:07] know hard for them like what is the [10:09] scorecard first thing how to configure [10:10] this thing and so on it's going to be [10:12] like half evening which is something [10:13] that we can do in five minutes and help [10:14] you on boarding. And if you're [10:16] interested on more stuff, we can just [10:17] invite you to one of the, you know, [10:19] collab space sessions and just do the [10:21] proper on boarding that can be or record [10:23] one session and that that can be also a [10:24] good option. [10:27] >> Yeah. Um [10:29] yeah, totally agree. Uh I also think [10:31] like with onboarding there's already a [10:34] lot of things that we need the projects [10:36] to do um that we can't really we can [10:39] sort of help but like there's a lot of [10:41] things that just like are on them to to [10:43] get done, right? [10:44] >> Um I don't know if some of this is [10:46] something that like [10:48] >> we could do on our end sort of for them [10:50] or or help them as much as possible. [10:53] >> Yeah. I mean it this is totally [10:54] something that we can do I think on our [10:56] end and so I think it's important to put [10:58] it in the checklist because that's where [11:01] hypothetically let's say this is the PMS [11:03] that are doing this right that's where [11:04] we'll go to you know to have that [11:07] reminder and to check that off and to [11:09] assign it to ourselves so I think it can [11:11] still go there even if it's not on the [11:13] project to actually do there's a couple [11:15] other similar things in there that are [11:16] like that [11:20] okay [11:22] Great. All right. [11:25] Uh, wrapping up 2025. [11:29] So, we're getting getting toward the end [11:31] of the year. So, I think from um Alpha [11:33] Omega perspective based on our [11:35] conversation last week, things are [11:36] looking pretty good. Um, we are meeting [11:39] this week to talk about the annual [11:40] report. Um, I have a note stock that [11:43] I'll I'll share out right after this [11:44] meeting on that one. Um, but after that, [11:47] um, I don't think there's anything [11:48] really big outstanding. Um, yes, Robin. [11:52] >> Yeah, just a note that Alpha Omega has a [11:55] meeting tomorrow to discuss our renewal [11:58] uh opportunity. So, [12:01] hoping and assuming that they continue [12:04] your all great work. [12:06] >> Yeah, we had our quarterly check-in with [12:08] them and other participants last week, [12:10] which is really interesting. [12:13] Uh, all right. Any anything Raphael that [12:16] like is on your mind for wrapping up [12:18] before the end of the year? [12:22] Um [12:24] I we have joined the what's the name of [12:28] the meeting uh we have joined last week [12:30] with alpha omega is the uh round table I [12:34] guess is the round table [12:35] >> quarterly round table yeah [12:36] >> yeah and uh Michael asked uh asked us to [12:41] to give like in a few sentence how the [12:46] the alpha omega uh helped uh the [12:49] security aspect of OpenJS and Noode.js. [12:53] So I did a summary like a small summary [12:56] and he was very happy and uh he [12:59] explicitly asked uh asked us to include [13:03] uh the uh the automation update we did [13:07] to the uh to the report we are going to [13:11] send in. So just a PII that just in case [13:15] >> I'll link to from the notes doc that I'm [13:18] working on for [13:20] our meeting later this week. I'll make [13:21] sure to include that link to our the [13:23] notes from that other meeting because I [13:25] think we have that stuff captured. [13:27] >> Yeah, but that's a good reminder. Yeah. [13:31] >> Okay. [13:32] Uh December meeting schedule. So we've [13:36] got three more Mondays in the month. So, [13:41] next week, the 22nd and the 29th. So, uh [13:45] assuming folks will be around, I'd like [13:46] to keep next week, but 22nd and 29th, I [13:49] suspect people will be um spending time [13:53] outside of work. So, um [13:57] obviously if folks are going to be here, [13:58] then you know, we can obviously still [14:00] have the meeting, but um I think [14:02] probably the 29th would would be good to [14:04] close, and I'd like to double check [14:06] about the 22nd. [14:09] Yeah, I think it's um I would say that [14:12] if we get the the answer a positive [14:15] answer from Alpha Omega tomorrow, we [14:18] could use the next meeting to uh refine [14:21] our service of work with all the folks [14:24] uh like create some uh high overview [14:28] tasks so I can because I was planning my [14:32] 2026 [14:33] uh year uh yesterday and I was I don't [14:36] know what I need to like which path I [14:38] should follow because I don't know if I [14:40] keep working on that. [14:42] >> So yeah, that would be great. [14:43] >> Yeah. And I think also as kind of like [14:45] as we wind down, it would be good to um [14:48] take some time and clean up our um [14:51] security club space issues and conbon [14:53] board. Some croft in there, right? So [14:56] just going into the the new year fresh. [14:57] But yeah, I'll go ahead and cancel the [14:59] 22nd and 29th and we'll we'll keep next [15:02] uh week's meeting if um if we have [15:05] information from Alpha Omega, we can use [15:07] that that time to work on that. Or if [15:08] not, we can also just do like some [15:10] GitHub triage and clean up stuff. [15:14] >> Okay. All right. Any other items or [15:18] things that folks want to chat about? [15:25] Okay, we can adjourn then. It's good to [15:28] see you all. [15:29] >> Great. Thanks everyone. Talk [15:30] >> soon. Bye everybody. [15:31] >> Bye.