doc: add minutes for meeting Jan 24 2024 (#1496)

* doc: add minutes for meeting Jan 24 2024

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

Author: mhdawson

meetings/2024-01-24.md

@@ -0,0 +1,116 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-01-24
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=KzBhROQFcDE>
+  * seems like the recording dropped at 34mins, not sure why, unfortunately because
+    there was a lot of good discussion
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1495>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Geoffrey Booth @GeoffreyBooth (voting member)
+* James Snell @jasnell (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Chengzhong Wu @legendecas (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Moshe Atlow @MoLow (voting member)
+* Richard Lau @richardlau (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+* Myles Borins @MylesBorins (regular member)
+
+## Agenda
+
+### Announcements
+
+* Antoine - 2 successful collaborator nominations - lemire and zcbenz
+
+### CPC and Board Meeting Updates
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
+
+### nodejs/node
+
+* enable corepack by default [#50963](https://github.com/nodejs/node/issues/50963)
+  * Myles, speaking as fellow collaborator
+    * Believe questions are being framed incorrectly
+    * Question is about enabling yarn, pump and having them just work
+    * When looking at what Node.js is shipping only 10% is coming from supported Node.js
+      versions, lots still come from older versions
+    * yarn and pnpm have large enough downloads,
+    * npm don’t want to support/integrate with corepack as it does not fit with view of how
+      package managers should be integrated
+    * corepack was started due to context that limited willingness to add yarn/pnpm to Node.js,
+      but extended beyond that.
+    * believe we should make yarn and pnpm just work, but that does not necessarily mean
+      corepack
+    * should define governance for supporting clients
+  * Michael
+    * Need to factor in work on the project to support any particular solution
+  * Richard, if npm was not currently bundled we probably would not bundle, so if we define
+     criteria for bundling, npm would likely not meet them. Situation is not equitable, but we have
+     historical baggage and those constrain what is reasonable.
+  * Michael a bit of a response
+  * Geoffrey
+    * Sounds great in abstract that we let yarn/pnpm run without doing anything but at what
+      cost?
+    * It’s finding an option with the right cost/value balance
+  * Myles
+    * Question, is are we going to ship these and take on responsibility for the clients
+    * Corepack tries to take those on, but does it actually let us say “no” to us taking on
+      responsibility
+  * James, do believe it’s an important distinction that it does not bundle the clients that should
+    not be lost. Exploring different options does make sense.
+  * Myles yarn, pnpm just working can lead people to thinking its the same, which is a concern.
+  * Myles in support of finding equitable environment
+  * Richard - when installing things, having up front questions; that is how npx works;
+    corepack like npx downloads software that we are not responsible for.
+  * Geoffrey, somebody needs to be champion to finding consensus. Issues and PRs need to
+    be opened to capture goals, etc.
+  * Ruy, in the first discussion back in 2020, there were lots of questions back them, and
+    agreement was that we should run an experiment.
+  * Geoffrey, just because we skipped finding consensus earlier, does not mean that we have
+    to accept implementation.
+  * Richard, unfair to characterize as non-consensus
+  * Geoffrey, consensus as experiment is quite different than implementation
+  * Michael, Ruys point I think is that it should not be a surprise that there are still divergent
+    opinions because those were raised and what was agreed was only an experiment.
+  * Geoffrey, will post comment that TSC members who were present, best way to move
+    forward is to define goals, and work on agreement on those. Getting those PR’d into some
+    Node.js doc even if that requires a TSC vote is a prereq.
+
+* lib: promote process.binding/_tickCallback to runtime deprecation [#50687](https://github.com/nodejs/node/pull/50687)
+  * skipped for this week
+
+* lib: rewrite AsyncLocalStorage without async_hooks [#48528](https://github.com/nodejs/node/pull/48528)
+  * @lgendecas will check with Stephen if this can be removed from agenda, there was progress
+    on the V8 front, so it might be unblocked.
+
+### nodejs/admin
+
+* Redesign of Node.js Website [#818](https://github.com/nodejs/admin/issues/818)
+  * removed from agenda, as presentation was made last week.
+
+* Events / Collaborator Summits for 2024 [#814](https://github.com/nodejs/admin/issues/814)
+  * Have confirmation that they can host the collaborator summit, took a while due to estimate of
+    attendance. Have space for 30-35 people on April 3-4.
+  * Question is if there is enough time to get people to show up to event. Maybe we should do a
+    poll, if we get enough people then we can move forward, otherwise we can move to some
+    time later in the year.
+  * Michael, is it possible to have Node.js track?
+    * Joyee, not sure but should run survey in parallel
+  * Joyee, people ok with the plan.
+    * Have space for 30-35 people on April 3-4, in London
+    * run poll to see how many people are planning to attend the summit
+    * wait for a week to see how many people are planning to go.
+    * If number is enough for critical mass, if not then we should plan to delay.
+  * Ruy, propose hosting collaborator summit collocated with conference in Colombia, end of October this year
+
+## 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.