doc: add minutes for meeting 23 Jul 2025

Author: ruyadorno

meetings/2025-07-23.md

@@ -0,0 +1,111 @@
+# 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.
+
+