doc: add minutes for meeting 17 Nov

meetings/2021-11-17.md

@@ -0,0 +1,121 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2021-11-17
+
+## Links
+
+* **Recording**:  <https://youtu.be/6YlIQA02xZI>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1122>
+
+## Present
+
+* Antoine du Hamel @aduh95 (TSC)
+* Beth Griggs @BethGriggs (TSC)
+* Сковорода Никита Андреевич @ChALkeR (TSC)
+* Colin Ihrig @cjihrig (TSC)
+* Gireesh Punathil @gireeshpunathil (TSC)
+* Matteo Collina @mcollina (TSC)
+* Michael Dawson @mhdawson (TSC)
+* Richard Lau @richardlau (TSC)
+* Robert Nagy @ronag (TSC)
+* Michaël Zasso @targos (TSC)
+* Tobias Nießen @tniessen (TSC)
+* Rich Trott @Trott (TSC)
+* Guy Bedford @guybedford (Guest)
+
+## Agenda
+
+### Announcements
+
+* No announcements this week
+
+### CPC and Board Meeting Updates
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
+
+* No board meeting update
+* No CPC update this week.
+
+### nodejs/node
+
+* doc: update conditions, add "deno" and "types" [#40708](https://github.com/nodejs/node/pull/40708)
+  * conditions in the package.json imports/export
+    * allow custom resolution
+    * for those that are not implemented, still value in having them well documented
+      * examples could be browser or react native condition
+    * Added a section to the doc called conditions-definitions - <https://nodejs.org/dist/latest-v17.x/docs/api/packages.html#conditions-definitions>
+  * If not documented, then there could be conflict between implementations using the same
+    names
+  * Right now 3 browser, development, production
+  * Added some guidance as to when conditions can be added to the list
+    * use case for why should be added to the list
+    * should be some existing implementations
+    * etc.
+  * PR adds 2 new ones, types and deno. Types was added by angular. They do have
+    others that we have not listed, but did not want to open that can of worms yet.
+  * Could also be something that we move to the a different repo, place
+  * Matteo a few concerns, but resolved in the current text
+    * old text seemed to imply we supported them
+    * branding/marketing
+  * Michael - would this make more sense under the OpenJS Foundation
+  * Guy, a while back considered a package.json spec, but pushback on that.
+  * Matteo fine with it staying Node.js project
+  * Michael Z, ok with it staying, but one advantage with being outside, is that it does not need to
+    be linked to the Node.js documentation.
+  * Antoine +1 to what Michael Z said
+  * Michael point that resonated was documenting something that project has not documented.
+  * Michael Z, also applies to types one, would be good to know that the project wants/intends to define
+  * Guy, if getting confirmation of project interest make sense to people could be good criteria
+  * Ronag, kinds of feels out of scope for Node.js project
+    * which ones are relevant to Node.js
+    * Matteo in strict terms, maybe just types
+  * Development/production in webpack
+  * No objection to landing in core if we get implementor feedback confirmation,
+    move out later if there is enough momentum to do that later.
+
+* Rename default branch from "master" to "main" [#33864](https://github.com/nodejs/node/issues/33864)
+  * No updates this week.
+
+* Migration of core modules to primordials [#30697](https://github.com/nodejs/node/issues/30697)
+  * <https://github.com/nodejs/TSC/issues/1104> opened to discuss possible options
+  * Ruben has listed a number of additional options that we should consider
+  * Ronag, having vote on those 3 is not feasible
+  * Trott, question of having vote on 3 is different from if those 3 is right.
+    * too many will not result in positive outcome
+  * Possible goals
+    * Tamper Free everywhere
+    * Tamper Free just for module loading
+    * Selectively if possible without negative performance
+    * Not tamper free
+  * Approaches
+    * primordials
+    * move required code to C++
+  * Ronag from first question, only viable option is Tamper Free just for X
+  * Rich probably want to use tamper-resistant
+  * Gireesh, performance should not be a consideration if people looking for hyper
+    Performant for areas which are security critical. Rich not sure everybody will agree with that.
+  * Gireesh, don’t use current performance as baseline.
+  * Antoine, Bradley’s point was about ESM module system.
+  * Ronag can make sense in module loading system, performance less important there.
+  * Michael Z, complication is that module system uses other core modules
+  * Ronag need list of modules that we want this for, along with deps.
+  * Gireesh, we should let Ruben pitch in his proposals
+  * Michael, to me is seems to come back to “where” and “how” as two potential questions.
+
+### nodejs/TSC
+
+* add security triaging to core repo GOVERNANCE.md and/or charter? [#1100](https://github.com/nodejs/TSC/issues/1100)
+  * Rich, putting together a meeting for people who might be willing to be involved in triage
+
+### nodejs/next-10
+
+* Mini- Summit Nov 18 -2021 [#99](https://github.com/nodejs/next-10/issues/99)
+  * It’s tomorrow. Hope to see people there.
+
+## Strategic Initiatives
+
+* No update this week.
+
+## Upcoming Meetings
+
+* **Node.js Foundation Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.