doc: add minutes for meeting 21 Aug 2024

meetings/2024-08-21.md

@@ -0,0 +1,106 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-08-21
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=1t6DuX4-Ae4>
+* **GitHub Issue**:<https://github.com/nodejs/TSC/issues/1607>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Yagiz Nizipli @anonrig (voting member)
+* Benjamin Gruenbaum @benjamingr (voting member)
+* Ruben Bridgewater @BridgeAR (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Chengzhong Wu @legendecas (voting member)
+* Marco Ippolito @marco-ippolito (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Moshe Atlow @MoLow (voting member)
+* Rafael Gonzaga @RafaelGSS (voting member)
+* Robert Nagy @ronag (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+* Paolo Insogna @ShogunPanda (voting member)
+
+## Agenda
+
+### Announcements
+
+* Marco 20.17.0 will be released just after this meeting
+* Rafael, 22.7.0 will be released tomorrow.
+
+### 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.
+
+* No updates this week
+
+### nodejs/node
+
+* lib: Symbol.dispose should be enabled with experimental flag [#54329](https://github.com/nodejs/node/pull/54329)
+  * two issues
+    * the whole ecmascript feature is unfinished, should there be an experimental warning?
+    * for the future how do we want experimental global api additions
+      * in v8 experimental features are hidden behind a flag while incomplete
+      * the suggestion could be to apply SemVer major for each experimental feature exposed to
+        the global scope, or basic TSC consensus for each one.
+    * Marco, generally we should be cautious on polyfills, should likely mark as SemVer major as
+      the default approach
+    * Benjamin, in the specific case of Symbol.dispse, it implements the minimum to allow other
+      tools to prototype and implement. In retrospective, agree it should go through the TSC,
+      make it SemVer major by default. We have process/tooling to handle that. Last year warning
+      might have made sense in this specific case, but not so much anymore, but don’t feel to
+      strongly.
+    * Michael any concern over policy of making SemVer major by default
+    * Marco, agree that for specific instance don’t need to do anything, but in the future polyfills
+      should be SemVer major.
+    * Chengzhong, when exposed on Global scope -> SemVer major. In addition should it require
+      an experimental flag to start if feature is incomplete
+    * Antoine, if we use experimental flag, that is not SemVer major, right?
+    * Chengzhong, agree without experimental flag SemVer major, but not if it has the
+      experimental flag
+    * Benjamin, believe it may depend on the situation, so probably better to mark always as
+      SemVer major to have it go through the TSC for analysis/discussion.
+    * Antoine, not sure if we need that for additions which are under a flag. So don’t think
+      something under an experimental flag should need SemVer major
+    * Benjamin, if there are cross-cutting concerns that originator is not aware on.
+    * Antoine, would prefer to just make it informal.
+    * Marco, not SemVer major in terms of breaking, but is in terms of consensus, so marking as
+      SemVer major.
+    * Antoine, not opposed to always be SemVer major if understanding is that it would be
+      removed after TSC discussion.
+    * Consensus is
+      * that we will ask that experimental APIs on the Global scope will always be
+        marked as SemVer major to start, expectation is that TSC will typically remove after
+        discussion if its behind an experimental flag.
+      * won’t add experimental warning to Symbol.dispose
+      * document the new process in <https://github.com/nodejs/node/pull/54330>
+
+* timers: add sleep alias[#54404]( https://github.com/nodejs/node/pull/54404)
+  * Paolo seems like its easy to mess up
+  * Benjamin, main concern is that we already have 4-5 ways to schedule a timer
+  * Paolo, we could remote the override,
+  * Benjamin, might be better to remove scheduler.wait()
+  * Michael, is it really worth it, lets document scheduler.wait() better
+  * Paolo, agree we can just publish scheduler.wait(), but would be good to add warning if you
+    call setTimeout without await after importing the async version.
+    * Paolo, could this be SemVer minor. After some discussion seems reasonable to propose,
+  * Chengzhong, echo scheduler api. Active discussion on experimental api, some discussion in
+    <https://github.com/WICG/scheduling-apis/issues/95>, about the naming please comment there
+    if you think it should change.
+
+### nodejs/admin
+
+* Conversion to Enterprise account [#905](https://github.com/nodejs/admin/issues/905)
+  * Issue closed, 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.