Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notable change description text format #1068

Open
joyeecheung opened this issue Dec 12, 2024 · 5 comments · May be fixed by nodejs/node-core-utils#881
Open

Notable change description text format #1068

joyeecheung opened this issue Dec 12, 2024 · 5 comments · May be fixed by nodejs/node-core-utils#881

Comments

@joyeecheung
Copy link
Member

joyeecheung commented Dec 12, 2024

Spinning off from #1063 (comment) , when the notable-change label is applied, the bot says:

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section.

But it's still not very clear what you are supposed to do - at least my interpretation is that one should just edit the PR description and the release announcement will copy whatever that's in the PR description, but it seems that's rarely the case. In the past notable changes PR I see people do all sorts of random stuff based on their own interpretation of what the bot says, and in the past release announcements I've also seen summaries that didn't match any of the things people did in the PR. There are many notable change PRs with well-formed descriptions which don't get copy pasted into the release announcement, presumably because they don't match some unspecified format to indicate that the descriptions they prepared are the text that are supposed to be copied.

To copy what I discussed with @aduh95 on slack

I wonder if we can devise a standard way for people to denote a block of markdown as text proposed for notable changes, and the the automation can gather them to form the basis of the release announcement and open a PR to the blog automatically while the proposal PR is sent. Maybe a one line short description too, so the automation can collect them and form a Bluesky post, and send a PR to the Bluesky repo, which can be edited a bit there and may or may not have to be sent from the official account (can be sent from releaser’s account first and then the PR is amended into a repost, but at least the text can be collaborated on GitHub)

A proposed format that would be automatable:

<!-- Bullet point content for release micro post: foo.bar -->

<!-- Summary for release announcement starts -->

## Support `foo.bar`

This pull request introduces `foo.bar`, which allows users to do bar with foo.

<!-- Summary for release announcement ends -->

And the automation will replace "This pull request" with "This release" for the text summaries, leading to

  1. In the bluesky post draft generated for the release, it will be something like

    Node.js v1.2.3 is out!
    
    - foo.bar
    
  2. In the blog post and changelog etc. draft generated, it will just include whatever in that starts/ends block, and replace "This pull request" with "This release", and leave it for people to make the wording look less weird for a release announcement.

If we want to go with the less-human readable but more explicit about what's automated route, or allow multiple summaries in one PR (I imagine this would be generated by something like git node release summary, and I modeled it after what's used by https://github.com/nodejs/node-core-utils/blob/main/docs/ncu-team.md).

<!-- git-node-release.summary.title(fooBar, "foo.bar") -->

<!-- git-node-release.summary.start(fooBar) -->

## Support `foo.bar`

This pull request introduces `foo.bar`, which allows users to do bar with foo.

<!-- git-node-release.summary.end(fooBar) -->

(I am not sure whether this is too cryptic, but anyway just to kick off some discussion about how to actually specify an automatable format instead of continue leaving it open to interpretation).

@joyeecheung
Copy link
Member Author

cc @nodejs/releasers @nodejs/tsc

@marco-ippolito
Copy link
Member

marco-ippolito commented Dec 19, 2024

I'd rather have the bot provide a more detailed explanation on how to write the notable change:
Maybe we can ask people to create a block of code of type notable-change:
Use the markdown syntax

```notable-change
this PR does this and that
``` 

This can also be easy for automation to extract

@aduh95
Copy link
Contributor

aduh95 commented Dec 19, 2024

I would suggest instead:

<details open><summary>Notable change</summary>

This PR does this and that.

</details>

That way, GH will interpret the markdown as such, making it more likely to spot formatting mistakes, and making it more pleasing for humans looking at the PR.


Example:

Notable change

This PR does this and that.

@RafaelGSS
Copy link
Member

LGTM Antoine suggesiton.

@joyeecheung
Copy link
Member Author

joyeecheung commented Dec 19, 2024

I was reading some react PR which follows https://github.com/facebook/react/blob/main/.github/PULL_REQUEST_TEMPLATE.md and I wonder if we should just make it part of the pull request template so that all PRs, not just the notable changes ones, should follow a template, and should be followed when the author opens the PR and edits the PR message before they push the submit button. Then we just need designate a block in the template to be the part that'll be used in the release announcement if it's a notable change. So that can be something like:

## Summary

<!-- If this is a notable change, this part will go into the release announcement. -->

## Background

<!-- Additional background provided to the reviewer, which won't go into the release announcement -->

## Additional information

<!-- Fixes and Refs links go here, which won't go into the release announcement -->

And when the notable change label is applied, the bot makes it extra clear that the author should follow the template and try to put whatever that goes into the release announcement in the summary section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants