Repository navigation
Release notes should mention contributor GitHub handles #736
Description
Summary
The latest release credits contributors by display/name text, but does not tag their GitHub handles. That means contributors are credited visually, but GitHub does not notify them and the release notes do not link back to their profiles.
Evidence
The published v9.1.0 release has a Notes for contributors section that says:
Thanks to FF (Today/Sleep/Health refactors, GATT family detection), digitalerdude (workout backfill, journal fix, sleep consistency, SpO2 instrumentation, steps stepper, alarm diagnostic), Pipiche (Oura IBI fix, feature-status probe, protocol docs), Kaveman (Gradle supply chain), and Jonas Bergler (bundle ID prefix, development team config, build fix) — and to everyone who filed the reports behind these fixes.
Those names are not GitHub mentions. The release includes merged PRs from these handles:
@tigercraft4: Add diagnostic WHOOP GATT family detection #713, Refactor Today pure logic helpers #686, Refactor Sleep pure helper logic #711, Refactor Health pure helper logic #712@digitalerdude: v18 @82: decode the SpO2 candidate as instrumentation (#103) #709, Workouts: backfill HR/calories on a manual entry from its detected bout (#510) #708, Journal import: recognize the real WHOOP "Answered yes" header (#631) #706, Sleep Schedule card: bridge night-tail fragments into one night (#699) #703, Steps calibration: replace the manual slider with a stepper (#698) #704@pipiche38: Oura: read-only SpO2 / real-steps feature-status probe (confirm the server-flag gate) #710, Oura: stamp banked IBIs at their real ring-time, not the drain-arrival time #677, docs(oura): reconcile protocol spec with decode fixes, wear/charge signal, observed tags #678@kavemang: Harden the Android Gradle supply chain #683@jbergler: build(ios): Make the bundle id prefix configurable via a project-level xcconfig #701, Allow configuring DEVELOPMENT_TEAM via BundleIdSecrets.xcconfig #722, Fix iOS build break introduced in #720 (missing diag call) #723
So the release credits contributors, but not in a way that tags/notifies them. Older release/changelog entries do use handles in some places, for example Thanks @sunny-noop, Thanks @ruedigermunz, etc., so this looks like process drift rather than an intentional no-mentions policy.
Suggested fix
- In GitHub release notes, use GitHub handles for contributor credits, e.g.
Thanks to @tigercraft4, @digitalerdude, @pipiche38, @kavemang, and @jbergler .... - If release notes are generated manually, add this to the release checklist.
- If release notes are generated from merged PRs, collect each merged PR author login and emit
@loginin the contributors section. - Keep display names optional, but include the handle somewhere so the credit is clickable and sends a notification.
Why it matters
Contributor credit is part of community hygiene. The current text is easy to miss, cannot notify contributors, and is inconsistent with older release notes that did mention people by handle.
Activity
tools: collect third-party release credit handles (#736)
tools: fix five defects in the release-credit collector (#736)
tools: make the credit collector portable and its guards honest (#736)
tools: drop bot accounts, and realign CLAUDE.md with the script (#736)
tools: reject an unparseable since-argument, trim MAINTAINERS (#736)
docs+tools: credit release contributors by GitHub handle (#736) (#790)
ryanbr commentedon Jul 25, 2026
Thanks for the report, and for the handle mapping — it was accurate, including #677.
#790 has landed the convention and the tooling:
@handle.docs/releases/v9.1.0.mdnow uses handle links, and since the release workflow builds the GitHub release body from that file, the convention applies from the next release onward.Tools/release-contributors.sh <since-date|since-tag>collects the third-party handles for a release range, so the handles no longer have to be gathered by hand.Reopening, because your diagnosis was incomplete in a way that matters — through no fault of the report, since the cause is not visible from the release page.
This is not only hand-written drift. The release workflow post-processes GitHub's generated notes and strips every
by @authorcredit, then deletes theNew Contributorsblock outright. Measured against v9.1.0's real generated notes, that removed 66 credits covering 7 distinct third-party contributors, plus the block. So the four suggested fixes, implemented exactly as written, would still have left your handle off the next release.The stated reason in the workflow was that this is a solo fork. That is no longer true: 16 people have landed merged PRs here, 7 of them in v9.1.0 alone.
The fix is written and verified — strip only the maintainer's own credit, which is noise on nearly every line and notifies nobody, and keep everyone else's. On v9.1.0's notes it keeps 35 third-party credits, removes all 31 maintainer ones, and restores
New Contributors. It is waiting on a token scope to push, so this issue stays open until that lands.One deliberate exception: the already-published v9.1.0 release body keeps its original text. The workflow only builds a body when creating a release, so it will not refresh an existing one, and rewriting published pages is out of scope here.
ci(release): keep third-party @Handles in the auto notes (#736)
ci(release): keep third-party @Handles in the auto release notes (#736)…
ryanbr commentedon Jul 25, 2026
#792 has landed, so this is now genuinely resolved rather than only half of it.
The release workflow no longer strips contributor handles. It removes only the maintainer's own
by @…credit — noise on nearly every line, and a self-mention notifies nobody — and keeps everyone else's. TheNew Contributorsblock is no longer deleted either. Checked against v9.1.0's real generated notes: 35 third-party credits kept where 0 survived before, all 31 maintainer ones removed, block restored.Combined with #790, from the next release onward:
@handlelinks, fromdocs/releases/<TAG>.md, which is what the release body is built fromNew Contributorssection againTools/release-contributors.sh <since-date|since-tag>collects the handles, so the credit line is not assembled by handThanks for filing this with the handle mapping and the evidence — the report is what turned up the workflow scrub, which was not visible from the release page and would not have been found by fixing the prose alone.
The already-published v9.1.0 body keeps its original text: the workflow only builds a body when it creates a release, so it will not refresh an existing one, and rewriting published pages is out of scope here.
Release notes for v9.2.0
fix(sleep): Asleep/Woke row + hypnogram axis span the whole split nig…
2 remaining items
release(9.3.2): version identity, release notes, What's New
fix(sleep): don't let a minor pre-onset fragment hijack the displayed…
Instrument the WHOOP 4.0 sleep-onset decision (ryanbr#271) (ryanbr#337)
release: cut 10.1.0 as a release, not a beta
fix(sleep): don't let a minor pre-onset fragment hijack the displayed…
Instrument the WHOOP 4.0 sleep-onset decision (ryanbr#271) (ryanbr#337)
fix(sleep): Asleep/Woke row + hypnogram axis span the whole split nig…
fix(sleep): headline "Asleep" reflects the whole bridged night, not j…
docs+tools: credit release contributors by GitHub handle (ryanbr#736) (…
ci(release): keep third-party @Handles in the auto release notes (rya…
Release notes for v9.2.0
docs: relocate the rules unique to CLAUDE.md into the reference docs
Release notes for v10.5.0, and ship the Polish What's New card
docs(sleep): say how the fallback window differs from the hero's onset
sleep: date the browsed night, not the newest one, in the nav header (#…