doc: add minutes for meeting 17 July 2024 (#1597)

* doc: add minutes for meeting 17 July 2024

Signed-off-by: Michael Dawson <[email protected]>

Author: mhdawson

meetings/2024-07-17.md

@@ -0,0 +1,147 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-07-17
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=N4uIFgvRRUM>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1596>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Benjamin Gruenbaum @benjamingr (voting member)
+* Ruben Bridgewater @BridgeAR (voting member)
+* Geoffrey Booth @GeoffreyBooth (voting member)
+* Marco Ippolito @marco-ippolito (voting member)
+* Matteo Collina @mcollina (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Rafael Gonzaga @RafaelGSS (voting member)
+* Richard Lau @richardlau (voting member)
+* Robert Nagy @ronag (voting member)
+* Paolo Insogna @ShogunPanda (voting member)
+* Joe Sepi @<[email protected]> (Guest - Node.js CPC rep)
+
+## Agenda
+
+### Announcements
+
+* Rafael about to promote 22.5.0 !
+
+### Reminders
+
+* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/recognizing-contributors.md#bi-monthly-contributor-spotlight)
+
+* Actively looking for location for collaborator summit for the days after NodeConf.eu. If your
+  company could provide a space we love to hear from you.
+
+### CPC and Board Meeting Updates
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
+
+* CPC update
+  * working on code of conduct team selection processes
+
+* Board meeting update
+  * No updates from the board this week
+
+### nodejs/node
+
+* module: unflag detect-module [#53619](https://github.com/nodejs/node/pull/53619)
+  * Geoffrey, discussing with Antoine to split out the work. Main question is if we are ok with
+    landing change to flag. Flag continues to exist, but default becomes on. Would stay as
+    experimental, we could backport to 22, and would let it back there for a while.
+  * Michael, if I remember correctly, this one we thought was not breaking, but has a higher
+    chance that it might cause unforeseen issues. So better to have in 22 before goes LTS.
+  * Geoffrey/Matteo correct.
+  * No objections from TSC members in the meeting.
+
+* inspector: add initial support for network inspection [#53593](https://github.com/nodejs/node/pull/53593)
+  * Chrome helped us resolve the issue and Chengzhong is helping it along :)
+  * Chengzhong: reaching out to Danil to draft a design doc
+  * Benjamin, positive reaction from Chrome dev tools team and progress is being made.
+  * agenda tag already removed
+
+* module: add --experimental-strip-types [53725](https://github.com/nodejs/node/pull/53725)
+  * Benjamin, strategic decisions, lots of stake holders. Good to make a few decisions to help
+    conversation along.
+    * Benjamin, ok to land and iterate, but we allow as much breakage etc.
+    * Matteo, 2 takes.
+      * First one is that we should try to have meeting with the Typescript team. Should wait until
+        we get their feedback. Seems like the asked for some time. Ok with landing and removing
+        later
+    * Marco
+      * Currently blocked as swc having trouble with some architectures so still some time before
+         it would land anyway.
+      * Feedback from TypeScript team is that there are some concerns but they can be solved. Created package to wrap swc which
+        would go under the Node.js organization.
+      * This would allow us to move versions forward more easily.
+      * With that said waiting is good, how long and should be block based on that?
+    * Paolo
+      * Even for experimental features we overthink things. We should release something and
+        experiment and gather feedback from others
+    * Geoffrey
+      * main concern, I tried it out  and there needs to be way better error messages. Had
+        discussed landing but holding it back until docs are updated to avoid swarm of confused
+        users. Can help write those. Not  necessarily a need to rush.
+      * In terms of the TypeScript team, none of them are collaborators but they obviously want to
+        block, do we want to progress with it in that state?
+  * Matteo
+    * I agree with Geoffrey. We should talk to TypeScript team, ask for a timeline, have a meeting
+      with them. They are a key part of the ecosystem. We should not likely ship something they
+      are not ok with unless we are really sure it is what our users need.
+  * Michael
+    * If its more like a PoC, then possibly a compile time guard makes sense
+  * Paolo
+  * ok if we wait for feedback from the TypeScript team if we timebox it.
+  * Robert
+    * If we don’t compile it by default, then no point because people won’t try it out.
+    * We could just wait until the PR is ready versus garding
+  * Geoffrey, would like to give them timeline that would let us hit 23. Also why not both?
+    previous approach was to error and then have output that would tell people
+    to run X to install.  Strip types could be limited and then hooks
+    could be used for full integration.
+    * Do people agree that we should update docs? That would mean waiting a few weeks
+  * Antoine
+    * If it stays as a PR it’s hard for people to contribute to it. If it’s not in main, the bar is high for
+      test. We may only get 10 people using it with compile flag but that is more than if it waits as
+      a PR
+    * In terms of docs, early adopters don’t necessarily need good docs
+  * Paolo, seems reasonable to give TypeScript team at most one month. In terms of docs, we
+    don’t want to set in stone, and its a lot of work to update docs.
+  * Matteo, would give TypeScript team until the end of august
+  * Benjamin, lets try and get Daniel on the TSC meeting next week and voice their concerns
+  * Marco, have gotten some positive feedback from people on tc39
+    * Proposal is to:
+      * externalize into npm module
+      * include the npm module in Node.js just like npm
+      * already created the PR to do that.
+      * will create WASM from source code
+      * PR will look similar, but will include source code and wrap swc
+  * Benjamin
+    * Can we agree on landing
+  * Antoine, only the compile time option is on the table because of the architectures side of
+    Things. Marco believe latest version from swc will be addressed
+  * Geoffrey, land but hold back from release, but increases the chances of backports
+  * Richard, likely not a Node.js 22.x release in next few weeks anyway.
+  * Michael
+    * one approach, land in main with compile time option, backport that to 22.x, then remove
+      the compile time option in main. That keeps most code consistent for backporting while
+      not enabling in 22.x in shipping versions. If its not ready for 23 we could then re-add
+      the compile time guard (or not if it is ready)
+
+### nodejs/TSC
+
+* New Strategic Initiative on Primordials [#1439](https://github.com/nodejs/TSC/issues/1439)
+  * Nothing to discuss until we hear back from Antoine and Ruben on their recommendations
+
+### nodejs/next-10
+
+* Next 10 - Funding Deep Dive [#273](https://github.com/nodejs/next-10/issues/273)
+  * should have been removed from the agenda, nothing to discuss.
+
+## Strategic Initiatives
+
+## Upcoming Meetings
+
+* **Node.js Project Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.