doc: add minutes for meeting 23 Jul 2025 (#1771)

Author: ruyadorno

meetings/2025-07-23.md

@@ -0,0 +1,150 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2025-07-23
+
+## Links
+
+* **Recording**: <https://www.youtube.com/watch?v=4vkdCjeJnI0>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1769>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Gireesh Punathil @gireeshpunathil (voting member)
+* James Snell @jasnell (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Chengzhong Wu @legendecas (voting member)
+* Marco Ippolito @marco-ippolito (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Filip Skokan @panva (voting member)
+* Rafael Gonzaga @RafaelGSS (voting member)
+* Darshan Sen @RaisinTen (voting member)
+* Richard Lau @richardlau (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+
+## Agenda
+
+### Announcements
+
+* New collaborator: Aditi-1400
+* Survey for collaborator summit in October:
+  <https://docs.google.com/forms/d/e/1FAIpQLSfMp3OE-HKsKq7GzUFNwuGfs7-t1PQalmsMHMIflLH8Y_SVcQ/viewform>
+
+### 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
+
+* No update this week
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to
+the meeting.
+
+### nodejs/Release
+
+* Proposal - Shift Node.js to Annual Major Releases and Shorten LTS Duration [#1113](https://github.com/nodejs/Release/issues/1113)
+  * TLDR from Rafael: strong support to move to an yearly release, making the deprecation window
+    shorter
+  * got feedback that 24mo of LTS seems too short for some enterprise
+  * Gireesh: we need to be aware that increasing the frequency of updates may increase the number
+    of issues companies face when updating major versions
+  * James: instead of making every major release a LTS we keep the odd vs even number
+    differentiation but we switch the cadence to a single major release every year
+  * Rafael: one issue with the odd-number releases is lack of adoption, not sure about the yearly
+    release
+  * James: it’s important to get the major / breaking-changes in the hands of users as early as
+    possible
+  * Marco: with the current schedule there are periods of time we have 4 concurrent release lines
+    to make security releases to and so forth
+  * Marco: maybe making backport more strict
+  * Michael: what’s the difference between making major releases LTS vs non-LTS (odd numbered)
+  * James: historically the reason for having this schedule is to try to cater to different
+    ecosystem users, big enterprise vs small companies vs modules authors / maintainers, we still
+    need to support all those audiences
+  * Filip: another big audience is CI, module authors want to be testing in latest / current to
+    make sure their libraries are still working, switching that model to a prerelease channel
+    does not have the same connotation
+  * Joyee: there's another audience which is users of tools that relies on node, like cli tools
+    that depends on node and they tend to use the current release line, we learn about them
+    whenever we break things
+  * James: typically that's the tool author that is making that decision to their end users,
+    regardless stability guarantee is a big distinction and these authors will not adopt
+    prerelease lines
+  * Rafael: some major releases have none or almost none breaking changes but the major release
+    happens more because of schedule
+  * James: that predictability is important to companies and enterprise
+  * Michael: going back to the conversation of the cost of having 4 different release lines to
+    maintain at a given time, what about the odd-versions never get security releases in order
+    to reduce the burden?
+  * James: that guarantees nobody ever adopts or uses the odd-versions
+  * James: overlapping LTS versions are important for companies that need that support guarantee
+  * Richard: one of the reasons we do semver-major releases is to bump up V8 versions, since any
+    V8 update is semver-major
+  * Richard: people expect that predictability, it’s very important to the enterprise world
+  * James: none of that is theoretical, this is all based on real world user feedback
+  * James: we probably need a couple of different proposals we can work through
+  * Filip: we need to take into account our own dependencies and their release schedules, openssl
+    is going to switch to a two-year LTS schedule, it would be a good exercise to overlap that
+    openssl calendar with ours and see how that aligns
+
+### nodejs/nodejs.org
+
+* Node.js Icon Standardization [#7880](https://github.com/nodejs/nodejs.org/issues/7880)
+  * Ruy: it looks like the OpenJS Foundation marketing team already followed up with the approvals
+    required, the ask is more for following up updating the logo and was also marked as
+    tsc-agenda for awareness
+  * Checklist of places that need to be updated in <https://github.com/nodejs/admin/issues/985>
+
+### nodejs/TSC
+
+* Interim TSC Election [#1763](https://github.com/nodejs/TSC/issues/1763)
+  * James: Matteo is the current chair now given that there was no other
+* Update charter with communication responsibilities [#1754](https://github.com/nodejs/TSC/pull/1754)
+  * James: this is the original proposal to which there’s another alternative being discussed at
+    the moment
+  * Joyee: when something happens we need to do post-mortems and be in a position to do so,
+    empower the team to do something about it
+  * James: why do you feel that you’re not empowered?
+  * Joyee: it’s more specific scenarios, somebody else getting in the way, saying no
+    theoretically on behalf of the foundation
+  * James: sounds more like a communication process that needs to be improved rather than adding
+    / tweaking policy to work around that
+  * Joyee: it’s not intended as a policy but more codifying the practices we have already been
+    following
+  * Joyee: for example we remind people who are perceived as representing the project on social
+    media even when there’s no consensus or people who go to standard bodies speaking on behalf
+    of the project without collecting consensus. It’s already what we do. Whether they accept
+    the feedback is up to them but at least the TSC can be empowered to do the calibration
+  * James: anecdotally companies have been dealing with this since the introduction of social
+    media, trying things like having employees put notices that their opinions are their own,
+    but ultimately the public will still associate their personal opinions with their employer
+  * Joyee: not about what others can do - not in our control. More about what we can be
+    chartered to do, and not get told to shut up because we are not in a position to do. For
+    example standards-position repo is not something we are chartered to set up but we already
+    do it.
+  * Joyee: open to changes to make the wording reflect more about what we can do, not what
+    others can or cannot do
+  * James: maybe some other guide documents might be better than the charter for that specific
+    purpose
+  * Joyee: some actor needs to be empowered to take actions in these scenarios, doesn’t need to
+    be the TSC but TSC is the most likely to take on the work and has been taking on the work,
+    doubt other parties would be interested in the work
+
+* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614)
+
+### nodejs/admin
+
+* Create a directory for funding individual contributors [#981](https://github.com/nodejs/admin/pull/981)
+
+### nodejs/node
+
+* meta: clarify pr objection process further [#59096](https://github.com/nodejs/node/pull/59096)
+
+## Strategic Initiatives
+
+* Skipped as we ran out of time
+
+## Upcoming Meetings
+
+* **Node.js Project Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.