Improved changelog procedure
Currently the changelog is written by running git log on each folder and copying out important-looking commits, while verifying that other commits are
It would be nice if the changelog were easier to automatically compile. The person best suited for writing a changelog entry is the PR author (for authors who are contributors), but having many people edit the same file at once is undesirable.
Clippy has a nice procedure where there is a CI task that enforces changelog: ... in the PR body. By default all PRs are seeded with changelog:, and if a PR does not go into the changelog we say changelog: none to silence the CI.
In our case we'd probably want something like
changelog (icu_calendar): Added HijriFoo
changelog (icu_datetime): Fixed Hijri formatting across calendars
so a single PR may generate multiple changelog entries.
Reviewers would have to verify that the changelog entry in the PR body is correct. Reviewers are encouraged to edit it directly and improve it, or add one to contributor PRs.
A thing we can do is even occasionally compile these into a partial changelog mid-release-cycle (similar to what I did for 2.1, I left a comment saying the changelog was accurate up to $githash). Really helpful for release planning to just have an early idea of what the release will look like.
cc @sffc @robertbastian @zbraniecki
An example of a case that a process must catch, or else the process is insufficient: valid APIs that smell internal but are not internal being changed to doc(hidden), such as https://github.com/unicode-org/icu4x/pull/7147#discussion_r2500972062. I'm highlighting this because it seems like something likely to fall through the cracks if it relies on only human review.
I don't know why you are highlighting that on this issue?
Did you mean to post this on #7153?