From 3de15b813622d034a9f28fcf8d72d850b2ab34d1 Mon Sep 17 00:00:00 2001
From: Michael Dawson <mdawson@devrus.com>
Date: Mon, 25 Nov 2024 11:19:56 -0500
Subject: [PATCH] doc: add minutes for meeting 20 Nov 2024 (#1655)

* doc: add minutes for meeting 20 Nov 2024

Signed-off-by: Michael Dawson <midawson@redhat.com>

* Update meetings/2024-11-20.md

Co-authored-by: Marco Ippolito <marcoippolito54@gmail.com>

---------

Signed-off-by: Michael Dawson <midawson@redhat.com>
Co-authored-by: Marco Ippolito <marcoippolito54@gmail.com>
---
 meetings/2024-11-20.md | 153 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 153 insertions(+)
 create mode 100644 meetings/2024-11-20.md

diff --git a/meetings/2024-11-20.md b/meetings/2024-11-20.md
new file mode 100644
index 00000000..f9b33d55
--- /dev/null
+++ b/meetings/2024-11-20.md
@@ -0,0 +1,153 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-11-20
+
+## Links
+
+* **Recording**: <https://youtube.com/live/ev_8e8UVfNY>
+* **Minutes Google Doc**: <https://github.com/nodejs/TSC/issues/1652>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Yagiz Nizipli @anonrig (voting member)
+
+* Ruben Bridgewater @BridgeAR (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Marco Ippolito @marco-ippolito (voting member)
+* Matteo Collina @mcollina (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Moshe Atlow @MoLow (voting member)
+* Richard Lau @richardlau (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+* Paolo Insogna @ShogunPanda (voting member)
+
+## Agenda
+
+### Announcements
+
+* Marco: 20.18.1 just released, kudos to Antoine for helping to automate release process.
+* Matteo: GitHub program for security open source, we can get some $ if some of us go
+  through some training. Good way to skill up on security issues. 5-10 hour commitment
+  per week. Matteo will open an issue.
+
+### Reminders
+
+* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight)
+
+### CPC and Board Meeting Updates
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
+
+* Matteo, from the Board the biggest topic is planning for next year. The biggest expense will be
+  the conference. CFP opening soon, need to discuss if we are going to do a collab summit
+  there.
+  * Express project is becoming an impact project as project has improved governance and level
+    of activity.
+
+### nodejs/node
+
+* test: improve zlib tests [#55716](https://github.com/nodejs/node/pull/55716)
+  * Yagiz: the pull request uses node tests where it was not used before. Reasoning
+    for change -> we currently have two test runners, current test runner depends on things
+    that other runtimes don’t have. Hard to do without node test. Since there are not
+    requirements for naming and descriptions which has led to duplicate tests.
+    * Michael, one question from last time. Using node:test to help let other runtimes run
+      tests seems to be going into the opposite direction.
+    * Joyee: took a brief look. Previously they were not wrapped in an async direction, don’t
+      see how it's different/improved from my look at the tests that have been updated so far.
+    * In terms of missing descriptions, we could just improve comments. Just because node-test
+      requires a description does not mean that description will really be better as people
+      could add a 1 letter description.
+    * Yagiz, there are already tests that use node-test. See this as an opportunity to clarify
+      what the future direction should be.
+    * Joyee, have found it harder to find test failure with node-test. As far of these tests they
+      don’t really look like porting them to node-test improves.
+    * Yagiz, no requirement, but while working on these tests for workers, found it hard to work
+      with them, and thought this will help the community tests. We could close this PR, but we
+      need common discussion about the direction.
+  * Michael, possibly add doc to collaborator doc to capture the direction, form consensus there.
+  * Ruy, last code and learn had people moving to node-test. But seems like there was not
+    necessarily consensus on that.
+  * Yagiz, consensus on using external test runner?
+  * Matteo, don’t think we do. In particular we should not test things it depends
+    on with itself (for example process, etc.). For other things possibly ok
+  * Matteo, promise with resolvers (currently available after 22.x), prefer if we hold back
+    on that due to compatibility with older versions.
+  * Yagiz, kind of agree with not using node test runner to test the dependencies. Can work
+    around promise with resolvers by creating work around.
+  * Joyee, have you checked what kind of stack trace you see with promise with resolves
+    versus what we get with the common.must_not_call. If improves stack trace them more
+    positive, if it makes the stack trace less useful then negative.
+  * Yagiz open PR to contributor guidelines to document things like “don’t use node test runner
+    for deps” and use it to build/document consensus.
+
+* assert: add partialDeepStrictEqual [#54630](https://github.com/nodejs/node/pull/54630)
+  * added a while back as there was not consensus on the name
+  * Ruben, name is agreed now but still work before it can land.
+  * Marco, it does not work 100% yet, still some technical issues, proposal is to land
+    as experimental and then iterate.
+  * No longer blocker, can be removed from the agenda.
+
+### nodejs/nodejs.org
+
+* Add Vetted Courses [#7201](https://github.com/nodejs/nodejs.org/issues/7201)
+  * Matteo, will PR in and we will discuss and deal with any blockers there.
+
+* feat: add streams guide [#7123](https://github.com/nodejs/nodejs.org/pull/7123)
+  * Matteo planning to look in next week or so. Leave on the agenda for now.
+
+### nodejs/TSC
+
+* Clarify the Charter so that contractors are explicity counted as affialiated [#1650](https://github.com/nodejs/TSC/pull/1650)
+  * On the agenda as FYI to the TSC.
+  * No objections in the issue now, Matteo will take to the CPC for approval.
+
+* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614)
+  * Nothing to chat about this week.
+
+* Open OpenCollective and Github Sponsors for Node.js [#1553](https://github.com/nodejs/TSC/issues/1553)
+  * On agenda to get TSC members thinking about, discuss more based on situation next week.
+
+### nodejs/package-examples
+
+* Starting a team for the package examples initiative [#3](https://github.com/nodejs/package-examples/issues/3)
+  * Good to mention in the TSC meeting, to better document EJS/CJS usage and provide
+    better more up to date examples, similar to node-addon-examples.
+  * Idea is to delegate to the package maintenance team and others who are interested
+    Challenge is that we’ve had people join teams but then not be active.
+  * Michael, if somebody becomes active enough they could join existing teams? As
+    long as those teams agree, makes sense to me.
+  * No objections
+
+### nodejs/bluesky
+
+* Who should have access for this repository? [#2](https://github.com/nodejs/bluesky/issues/2)
+  * <https://github.com/nodejs/bluesky/issues/2>
+  * Joyee, give access to some existing teams
+  * Michael, model that would work the best is to define the content that is ok to post, and then
+    Trust people to post the right thing.
+  * Matteo, issue is that we also need people who will respond, best option is likely to delegate
+    to the foundation to post/respond
+  * Matteo, some specific things (like announce of new collaborator) less review for others
+    we’d need a more detailed review.
+  * Joyee, agree that similar to fast track process we can get some stuff out more quickly
+  * In terms of replies we can also have some automation, also not everything would need to go
+    through the repo, we can have additional access to foundation staff so they can post/reply
+    directly as well.
+  * Other issue about how many accounts. Seems like we can start with one, if there is energy
+    about spinning off more. Keep in mind that we may have more in the future.
+  * Michael, agree that starting with one makes sense, challenge before was belief that news
+    about the project was not appropriate for the main Node.js account.
+  * Matteo, believe current bluesky audience will be interested in what is going on in the project.
+  * Joyee, social should be social, and should be more interactive. We can start with one and
+    The we can poll for whether people want more or less content.
+  * Michael, having the main account repost peoples posts would be an important part of the
+    of our approach.
+  * Joyee the sdk is quite flexible.
+
+## 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.