Node.js Technical Steering Committee (TSC) Meeting 2024-06-12

[mhdawson]

Time

UTC Wed 12-Jun-2024 15:00 (03:00 PM):

Timezone	Date/Time
US / Pacific	Wed 12-Jun-2024 08:00 (08:00 AM)
US / Mountain	Wed 12-Jun-2024 09:00 (09:00 AM)
US / Central	Wed 12-Jun-2024 10:00 (10:00 AM)
US / Eastern	Wed 12-Jun-2024 11:00 (11:00 AM)
EU / Western	Wed 12-Jun-2024 16:00 (04:00 PM)
EU / Central	Wed 12-Jun-2024 17:00 (05:00 PM)
EU / Eastern	Wed 12-Jun-2024 18:00 (06:00 PM)
Moscow	Wed 12-Jun-2024 18:00 (06:00 PM)
Chennai	Wed 12-Jun-2024 20:30 (08:30 PM)
Hangzhou	Wed 12-Jun-2024 23:00 (11:00 PM)
Tokyo	Thu 13-Jun-2024 00:00 (12:00 AM)
Sydney	Thu 13-Jun-2024 01:00 (01:00 AM)

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2024-06-12&iso=20240612T1500
• or https://www.wolframalpha.com/input/?i=03PM+UTC%2C+Jun+12%2C+2024+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1FNdFJfdRXa9dx-FdDpPwlD43uM-HkVIS8ugmNxJv8tI/edit

Agenda

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

nodejs/node

• module: allow module.register from workers #53200
• src: make --env-file return warning when not found #53177
• doc: deprecate NaN or negative number as delay to setTimeout and setInterval #53005
• Ambassador program #52857

nodejs/TSC

• Moderation Team annual certification #1569
• Module customization hooks and worker threads #1566
• Open OpenCollective and Github Sponsors for Node.js #1553
• Coordinating nodejs security audit report finalization and publication #1546
• New Strategic Initiative on Primordials #1439

nodejs/admin

• Non-violent communication / strategic workplace conflict resolution training for the TSC and moderation team #877
• Better process for communicating feedback to members by the TSC #876
• Creation of an official Discord server for the Node.js project #872

nodejs/next-10

• Next 10 - Funding Deep Dive #273

Invited

• Antoine du Hamel @aduh95 (voting member)
• Anatoli Papirovski @apapirovski (voting member)
• Benjamin Gruenbaum @benjamingr (voting member)
• Ruben Bridgewater @BridgeAR (voting member)
• Geoffrey Booth @GeoffreyBooth (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)
• Michael Dawson @mhdawson (voting member)
• Moshe Atlow @MoLow (voting member)
• Rafael Gonzaga @RafaelGSS (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)
• Shelley Vohr @codebytere (regular member)
• Danielle Adams @danielleadams (regular member)
• Myles Borins @MylesBorins (regular member)
• Rich Trott @Trott (regular member)
• Yagiz Nizipli @anonrig (regular member)
• Joe Sepi @sepi@joesepi.com (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

[GeoffreyBooth]

We can probably remove these from the agenda, I had tagged them just for awareness. (Unless anyone else involved in these threads wants to discuss them.)

• module: allow module.register from workers #53200
• src: make --env-file return warning when not found #53177
• Module customization hooks and worker threads #1566

[mhdawson]

We only had 5 people make it to the meeting today so we cancelled. See everybody next week.

[mhdawson]

@GeoffreyBooth I think unless you've had suggestions otherwise, since you tagged those items for the agenda you should be ok taking off the tag so they don't show up on the agenda for next week.

[benjamingr]

We only had 5 people make it to the meeting today so we cancelled. See everybody next week.

Sorry, ran late with the kids due to the holiday here, not that 6 people instead of 5 would've necessarily fixed things :]

[GeoffreyBooth]

I would’ve joined late too but it’s fine. @mhdawson I’d already untagged them.

Maybe a meta-issue we want to discuss is whether there should be a team whose focus is on CLI stuff, that can be responsible for --env-file and related things. Then issues related to those features would have a place to be discussed besides the TSC, to avoid every disagreement rising to the TSC level.

Along those lines, there hasn’t been a loaders team for quite some time now; I’m the only one consistently attending the meetings anymore. I have no one to ask for guidance from for loaders issues other than the TSC.

[mhdawson]

In terms of the --env-file would the @nodejs/tooling team make sense?

[anonrig]

In terms of the --env-file would the @nodejs/tooling team make sense?

--env-file is currently blocked, therefore requires voting to be resolved. assigning a team to the CLI makes sense in the long term, but doesn't resolve the conflict we're facing right now.

[GeoffreyBooth]

--env-file is currently blocked, therefore requires voting to be resolved. assigning a team to the CLI makes sense in the long term, but doesn’t resolve the conflict we’re facing right now.

The idea is that if there’s a team responsible for the feature, that team could have periodic meetings and talk through disagreements in an attempt to find a resolution. The recent loaders meeting with me, Paolo and Gabriel was very productive and we resolved all open questions (at least, open between the three of us) about how to handle the off-thread hooks/worker threads issue. Perhaps if the tooling team held a similar meeting where all interested parties could discuss this issue, and the group had a full hour on that one topic, a similar resolution could be achieved.

[anonrig]

The idea is that if there’s a team responsible for the feature, that team could have periodic meetings and talk through disagreements in an attempt to find a resolution. The recent loaders meeting with me, Paolo and Gabriel was very productive and we resolved all open questions (at least, open between the three of us) about how to handle the off-thread hooks/worker threads issue. Perhaps if the tooling team held a similar meeting where all interested parties could discuss this issue, and the group had a full hour on that one topic, a similar resolution could be achieved.

@GeoffreyBooth the pull request is blocked for more than 17 days. we don't need more discussions. we need a resolution.

[GeoffreyBooth]

@GeoffreyBooth the pull request is blocked for more than 17 days. we don’t need more discussions. we need a resolution.

I assume you’re referring to nodejs/node#53177? What about nodejs/node#53060, which was blocked first? The only justification you gave was

I’m -1 on this change. It makes the existing implementation harder to maintain for almost no gain. We should not throw on env-file instead.

If your only concern was the maintainability of the implementation, that sounds like something that could have been resolved by discussion and compromise. It seems like you actually just prefer an alternate behavior, which is fine, but then the question is why we can’t just have both via two flags, even if we flip the default (like if --env-file warns and --env-file-required throws). I’d guess that your position is that the complexity of two flags is not worth the maintenance cost, but if several collaborators are telling us that they want both behaviors, perhaps it’s not really “almost no gain”?

Even though there are a lot of comments on these PRs I don’t really see discussion like what often happens in team meetings. I don’t see much engagement with @BoscoDomingo to discuss ideas for how to achieve the use case he’s trying to support while still respecting your priorities. I don’t think this needs to be a situation where it’s zero-sum and we either choose one option or another, and one side has to win and another has to lose; there might be a compromise here, but I don’t see much attempt at reaching one. At the very least, a meeting where everyone can be heard would be a good start.

[mcollina]

I’ve done plenty of meetings to
resolve technical issues, and those are often needed to resolve disagreements and find a common ground. However, there is also the way of not disagreeing in the first place. In other terms, what battles to fight and what battles not to fight.

There are also deep technical arguments where a debate is useful to understand differences. Having said that, these long debates could wear people out. I highly recommend we avoid them if possible. Voting is often better.