Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.08%. Comparing base (4bd6820) to head (569468e).

@@           Coverage Diff           @@
##             main     #881   +/-   ##
=======================================
  Coverage   80.08%   80.08%           
=======================================
  Files          39       39           
  Lines        4676     4676           
=======================================
  Hits         3745     3745           
  Misses        931      931           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Have you considered my suggestion in nodejs/Release#1068 (comment) i.e. require every PR to conform to a template, and then when a PR is labeled notable-change, part of the templated section would be chosen to be part of the release announcement? I think that would make it easier to guide PR authors to write good PR descriptions and reduce the hassle needed after a PR is labeled. The <details> format means that there would be a distinction and process change in PR descriptions between ordinary PRs and PRs labeled as notable-change, which doesn't seem to help readers of PRs, or may encourage duplication in PR descriptions which isn't great for readers in posterity.

What I imagine as a next step is to update the NOTABLE_CHANGE_MESSAGE in the nodejs/node repo to add instructions and an example/sample to guide contributors, and see how far it takes us. My expectation is it should work "well enough" to begin with, and that would tell us if we need to do more.

That would still mean a hassle for PR authors once it's labeled notable-change, no? If we make the section generic enough to be part of the PR template for all PRs, then the author generally don't have to do anything more after it's labeled notable-change. They can just put the summary in the templated section as soon as the PR is opened and forget about it. That might eliminate the need of the bot all together, too, though it doesn't hurt to keep it to emphasize it again.

That is to say, if we want to introduce a format for the PR description, it's better to think about what a good PR description for all PRs should look like, instead of only focusing on what's convenient for the releasers and ignore all the other PRs that are not notable changes, even though it's just a matter of one label between notable-change PRs and the others. PR description format should cater to human readers, first and foremost, no matter they are notable or not, and the automation can just adapt to a format that's pleasing to human readers, which is what we have been doing with e.g. the collaborator email parsing code here as well.