Highlight notable-changes of major releases in a TSC meeting

[RafaelGSS]

It can be difficult to determine which items should take priority when preparing for a major release due to differing perspectives and incomplete information. To address this, I suggest holding a TSC meeting immediately after the releaser announces a content freeze to establish the order of the CHANGELOG. This will help minimize the need for rework

[BethGriggs]

+1 to a TSC review/tagged on the TSC agenda for review of the content prior to the release.

I think trying to establish a 'proper' order each time might just lead to more debate and effort, though. In the past, I tried to take the following approach:

• Any notable changes where paragraphs or extra content have been supplied get their own heading under the main Notable changes section.
• Headings within the Notable changes section are organised alphabetically to remove any implied priority order.
• Any PRs labelled as notable but do not have additional text appear under the Other notable changes as a simple bullet list in the form generated by changelog-maker.

That way there's no debate over ordering of the sections, and any contributor who would like their change highlighted as a dedicated heading just needs to supply their content. (As is similar to your request in nodejs/node#47381 (comment)).

I think it'd be better for us to end up with a default set of rules to apply than having to open the debate on ordering each time. Maybe @nodejs/release and @nodejs/tsc can work on defining those rules (or a template) ready for next time.

[ronag]

TBH I think less structure here is preferable and the change log should be done at the releasers discretion.

[BethGriggs]

TBH I think less structure here is preferable and the change log should be done at the releasers discretion.

Agreed on their discretion, we added 'The ultimate decision rests with the releaser.' in our changelog creation steps to clarify that stance.

But, we're also hoping to automate more of the release processes so it may be useful to define some high-level defaults/structures to enable that (nodejs/security-wg#860, nodejs/Release#821).

[Trott]

TBH I think less structure here is preferable and the change log should be done at the releasers discretion.

I don't have my own independent opinion on how much the TSC should be involved, but if releasers are asking the TSC to do this, I think we should do it. I'm +1 on any reasonable request that reduces the hassle experienced by releasers.

So I'm +1 on this specifically because @RafaelGSS and @BethGriggs think it would be a good idea.

[mcollina]

I'm +1 to delegate this to the sole discretion of the releaser shipping that version. This does not mean that feedback should not be considered but said feedback should not block a release.

[ruyadorno]

First of all, sorry that I'm totally out of the loop (as I have been traveling this month and missed the last Release WG meeting) my perspective might be distorted on this topic so feel free to correct me or add any missing context.

That said, this proposal feels like (partially) taking away a mandate that is specifically defined in the Release WG charter. As a member of @nodejs/releasers that is not on the TSC I would like to understand why are we proposing that the TSC holds a meeting to define these notable changes (or anything else release-related really) instead of having the Release WG hosting that meeting.

I'm stating that, not as a complaint (personally from my point of view it has been difficult to find time to contribute in this first quarter, I'm def not looking for extra work 😂 ) but it's just that from a practical point of view the Release WG is a much more flexible forum (technically speaking anyone can join the zoom call for these meetings, while that's not the case with the TSC) such that we can invite any collaborators that might want to participate, while the releaser and the Release WG may still hold the final saying on any details.

[BethGriggs]

I would like to understand why are we proposing that the TSC holds a meeting to define these notable changes

Just for clarity, my +1 is only to having the proposal/content on the TSC agenda for visibility as a call for early input and review to reduce any last minute debate/rework.

Previously parts of the major release process were gated on TSC approval such as landing majors after the cut-off. We actively removed that in favour of more authority/autonomy of the Release WG and to reduce the bureaucracy of the process. I do agree we should not introduce a new requirement of TSC consensus for any part of the release process.

[RafaelGSS]

The intention of having the content in the TSC agenda is to reduce any last-minute debate/rework and make sure the CHANGELOG + Blog posts are aligned with the Node.js project thoughts.

[ruyadorno]

@BethGriggs @RafaelGSS Thanks for the clarification! May I suggest changing the title of this issue to:

Proposal: Highlight notable-changes of major releases in a TSC meeting

[RafaelGSS]

Hey, @nodejs/releasers can we discuss it in the next meeting? It's almost time for a new major :)

[RafaelGSS]

We've discussed it in today's meeting and we've decided to once the draft is ready, we use the tsc-agenda label to mention it regularly in TSC meetings so hopefully we'll avoid rework for Node.js 21. Closing it for now.

[RafaelGSS]

By the way, we need to adjust the label release-agenda to Release-agenda, because it's not showing on nodejs/Release#886