Notable change description text format
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- javascript
- 領域
- release
調査の方向性
リンクされた Release issue 1063 のコメントと、既存の notable-change bot の文言から始めます。提案されている Markdown マーカーを代替形式の git-node-release.summary と比較し、release-summary の自動化を追跡します。自動化がリリース告知と短いソーシャル投稿向けに一貫して抽出できる、合意済みで文書化された形式が決まれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Spinning off from https://github.com/nodejs/Release/issues/1063#issuecomment-2539972117 , 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
-
In the bluesky post draft generated for the release, it will be something like
Node.js v1.2.3 is out! - foo.bar -
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).
- 主要言語
- JavaScript
- スター
- 4.4k
- フォーク
- 675
- 平均マージ
- 22時間 29分
- マージ済み PR(30日)
- 1
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
nodejs/Release のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
Release-agenda
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
-
CitGM backlog オープン
難易度 4/5 3〜5日 初心者へのやさしさ 50/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 20/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 35/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
area-deployment area-integrations triage:bot-seen
難易度 2/5 半日 初心者へのやさしさ 86/100
-
Issue-Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
sugarlabs/musicblocks#8924 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
ArduPilot/ardupilot_wiki#8088 ·
-
[BUG] createTool tools cannot be registered with Mastra when exactOptionalPropertyTypes is enabled オープンcustomer-eng status: needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100