Node.js Technical Steering Committee (TSC) Meeting 2026-03-25

[openjs-meetings-bot]

Time

UTC Wed, Mar 25, 2026, 01:00 PM:

Timezone	Date/Time
US / Pacific	Wed, Mar 25, 2026, 06:00 AM
US / Mountain	Wed, Mar 25, 2026, 07:00 AM
US / Central	Wed, Mar 25, 2026, 08:00 AM
US / Eastern	Wed, Mar 25, 2026, 09:00 AM
EU / Western	Wed, Mar 25, 2026, 01:00 PM
EU / Central	Wed, Mar 25, 2026, 02:00 PM
EU / Eastern	Wed, Mar 25, 2026, 03:00 PM
Moscow	Wed, Mar 25, 2026, 04:00 PM
Chennai	Wed, Mar 25, 2026, 06:30 PM
Hangzhou	Wed, Mar 25, 2026, 09:00 PM
Tokyo	Wed, Mar 25, 2026, 10:00 PM
Sydney	Thu, Mar 26, 2026, 12:00 AM

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2026-03-25&iso=20260325T130000
• or https://www.wolframalpha.com/input/?i=01%3A00%20PM+UTC%2C+Mar%2025%2C%202026+in+local+time

Links

• Minutes: https://hackmd.io/@openjs-nodejs/rJUDCMpOqbx

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting. (Updated daily)

nodejs/docker

• [NEXT-SECURITY-RELEASE] Heads up on upcoming Node.js security release 2026/03/24 docker-node#2424

nodejs/node

• module: runtime deprecate module.register() #62401
• module: doc-deprecate module.register() #62395
• doc: create ai-guidelines and include to CONTRIBUTING #62105
• tools: add ncrypto updater script #61613
• Virtual File System for Node.js #61478

nodejs/TSC

• Update meeting schedule #1832
• Vote on AI contributions #1831
• Update charter with communication responsibilities #1754
• Self-serve model for funding Node.js work #1747
• Draft Statement of Work - Test reliability lead #1629

nodejs/admin

• Ownership of Rust crates #1045

Invited

• Antoine du Hamel @aduh95 (voting member)
• Yagiz Nizipli @anonrig (voting member)
• Benjamin Gruenbaum @benjamingr (voting member)
• Ruben Bridgewater @BridgeAR (voting member)
• Gireesh Punathil @gireeshpunathil (voting member)
• James Snell @jasnell (voting member)
• Joyee Cheung @joyeecheung (voting member)
• Chengzhong Wu @legendecas (voting member)
• Marco Ippolito @marco-ippolito (voting member)
• Matteo Collina @mcollina (voting member)
• Filip Skokan @panva (voting member)
• Rafael Gonzaga @RafaelGSS (voting member)
• Darshan Sen @RaisinTen (voting member)
• Richard Lau @richardlau (voting member)
• Robert Nagy @ronag (voting member)
• Ruy Adorno @ruyadorno (voting member)
• Paolo Insogna @ShogunPanda (voting member)
• Michaël Zasso @targos (voting member)
• Tobias Nießen @tniessen (voting member)
• Beth Griggs @BethGriggs (regular member)
• Ben Noordhuis @bnoordhuis (regular member)
• Colin Ihrig @cjihrig (regular member)
• Geoffrey Booth @GeoffreyBooth (regular member)
• Moshe Atlow @MoLow (regular member)
• Shelley Vohr @codebytere (regular member)
• Rich Trott @Trott (regular member)
• Joe Sepi @joesepi (Guest - Node.js CPC rep)

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

---

Invitees

Please use the following emoji reactions in this post to indicate your
availability.

• 👍 - Attending
• 👎 - Not attending
• 😕 - Not sure yet

[indutny]

Is vote on AI use happening on 25th or on April 1st as suggested in #1831 ?

[indutny]

cc @nodejs/tsc @joyeecheung

[Trott]

Is vote on AI use happening on 25th or on April 1st as suggested in #1831 ?

@indutny Votes no longer happen in meetings. They happen asynchronously using @node-core/caritat (or maybe just GitHub interface stuff for simple yes/no questions). I might be getting details wrong here--it's been a while since I've been attentive to TSC stuff so things might have changed without me knowing it--but the general principle that votes happen asynchronously (so that people who can't attend a particular meeting time are not penalized) is surely still in place.

So a decision to open the vote might happen at one or the other meeting, but the actual vote will be open for multiple days.

[Trott]

@indutny Votes no longer happen in meetings.

(And if all you meant was "Which meeting will have the discussion about the vote?", then sorry to misunderstand, and my answer is: I don't know either but I would like to, so hopefully someone who can answer authoritatively comes along to answer that!)

[indutny]

@Trott thank you for response! I mean the latter indeed, and curious when we'll be discussing the subject before the vote.

[aduh95]

Technically, anyone on the TSC can start a vote following the procedure described in https://github.com/nodejs/TSC/tree/main/votes/initiateNewVote. #1831 is Matteo asking someone to actually open that vote, but no one has followed through so far; the issue is on the agenda, so it might get discussed – or it might just get mentioned, if no one feels like saying anything in public on the topic.
But tbh, the topic has been the topic of many discussions in public as well as private spaces, and I can probably disclose that some project members (including myself FWIW) have expressed support against a TSC vote; (is the TSC the right entity to decide here? could such decision be enforced anyway?). Worth noting that according to our guidelines, it's not possible to veto a vote, so those concerns does not mean the vote won't happen, I'm just providing it for context.

[indutny]

Oh, okay. In this case I'll have to join both meetings to be sure to not miss it! Thank you.

I think the vote is needed to at least resolve the status of the Pull Request that Matteo has opened, but more generally we have a situation where OpenJS foundation says that individual projects can override its' "LLM contributions" policy so discussing this and reaching the conclusion feels necessary. Deciding not to vote is indistinguishable from voting "yes" because of the parent foundation.

What entity could make this decision if not TSC?

[mcollina]

@aduh95 @indutny, there is a "request changes" on two PRs (or should be soon), so the TSC is the body to resolve that objection.

Here are the relevant docs:

https://github.com/nodejs/node/blob/4ee467f91254fdd5d9a1c328edd2e3fc5b541943/doc/contributing/collaborator-guide.md?plain=1#L171-L177

https://github.com/nodejs/node/blob/4ee467f91254fdd5d9a1c328edd2e3fc5b541943/GOVERNANCE.md?plain=1#L151-L156

https://github.com/nodejs/TSC/blob/main/TSC-Charter.md#section-7-voting

To clarify, we just need a quorum of TSC members to dismiss the PR's objection. If there are no objections from TSC members to dismissing the blocks, we will not vote. I recommend we hold an asynchronous vote, but that's not a procedural requirement.

April 1st would be the best slot for US folks to attend, and it's usually the one where we have a quorum for a worthwhile discussion. The Board meeting is on March 27, and that's the earliest we can expect an official response to the question we asked about the DCO and contributions, so we cannot conclude anything about this topic before then.

I won't be able to join this week's meeting either.

[GeoffreyBooth]

Please add nodejs/node#62395 / nodejs/node#62401 to the agenda to resolve the question of whether experimental features can be deprecated, and if so, how; and more specifically how we want to handle the phase-out of module.register in favor of module.registerHooks.

[joyeecheung]

Sorry to crowd the agenda even more, I've put nodejs/docker-node#2424 manually it because it is time sensitive - docker images are still missing for the security release, from nodejs/docker-node#2424 (comment) it seems to be that musl builds are blocking again and the blocking ones aren't even building (?). There is a hot fix PR to address this from a nodejs/docker team member and they seem to be waiting for another docker team member to approve nodejs/docker-node#2426 - if there's no response from other docker maintainers it may warrant some overstepping from TSC to expedite

[joyeecheung]

What entity could make this decision if not TSC?

There have been some discussions on several Slack channels about opening the vote to the collaborators, not just the TSC. I am one of those who's in favor of opening the vote to the collaborators, IMO the exclusive voting rights of TSC is only useful to break decision paralysis when things are urgent or most collaborators are likely fine with any options. The TSC is just a subset of the collaborators that act like the fallback volunteers when other volunteers don't/can't step up, and if we are talking about how collaborators should self-govern and the debate start to center on ethics or societal values it feels wrong to take the hierarchy too seriously. It's also unhealthy because being volunteers, the TSC generally can't and haven't been on top of everything, AI policy is important but as you can see above, the TSC can't even be on top of the policy of docker images with security releases (I don't think it's anyone's fault, you just can't oblige volunteers to volunteer), limiting the authority on a group of volunteer that don't have consistent bandwidth on everything will further reduce the bandwidth they have for things that have more imminent consequences and make other volunteers feel less empowered and the structure will just be even more disfunctional.

[indutny]

I'd be in favor of a collaborator vote! This sounds like a fantastic idea.

I'm sure that y'all have seen it already so I might as well cite it here directly before we meet next week. I've been trying to get public feedback through a petition that already got 93 signatures from github users (and a change.org clone with 64 signatures so far). In addition that I've posted twice on reddit (/r/javascript and /r/node) and the upvote ratio seems very uncontroversial:

• 353 rating on /r/node with 88.8% upvote ratio
• 200 rating on /r/javascript with 74.9% upvote ratio.

I don't mean it as a substitute to voting, but I'd like TSC to know that there are signs that our users might feel strongly about LLM policy and an open vote is warranted. I've also received feedback both 1-on-1, on Reddit, and on Mastodon which strongly favored not having LLM written code in Node.js.

Incidentally a similar motion has happened within Wikipedia and ended right when I was looking for feedback for us. As the result Wikipedia has voted to restrict LLM use when working on articles and to not allow LLMs to write them (with an exception of initial translation). However, they allow for assistive use of LLM with a condition that the final text is still written by the editor themselves. I think as a minimum we could consider instating similar policy at Node.js

[jasnell]

I'll reiterate what I said in the slack discussion, I'm firmly -1 on considering a collaborator vote until the TSC has a chance to actually discuss the issue in a call. Establishing collaborator policy is firmly within the TSC's responsibility and we shouldn't by default defer that responsibility to the large collaborator base. Let's table the idea of a collaborator vote until after the TSC discussion happens and we determine what further steps may be necessary from there.

[ShogunPanda]

I totally agree with @jasnell. That's exactly what TSC is here for.

[joyeecheung]

I don't think "it's within the TSC's responsibility" is a good argument that TSC must exclude others from partaking the decision making/sharing the work. Ensuring the CI is reliable and establishing process/manage funding to maintain it is also the TSC's responsibility. Ensuring our docker images are released on time for security releases should also ultimately be the TSC's responsibility. But the TSC has not been able to take on that responsibility in years/months, and they have a lot more imminent consequences and cannot be addressed by a collaborator vote because they demand work that other volunteers outside the TSC won't do. I think if the TSC has that much bandwidth, then we should prioritize our bandwidth on responsibility that no other volunteer can/is willing take over, instead of taking over what collaborators can/are happy to vote for themselves and then continue to dodge the long overdue work that has been been making a negative impact on the health of the project/security of the ecosystem for years (I think all our collaborator surveys have shown that CI reliability should be our top priority).