We have been refining how we announce changes and settled on this order for social posts:
- What changed, one plain sentence about the user-visible behaviour
- Who it affects, and who can ignore it
- One concrete example, a before/after or a single command
- Link to the full notes
Things we deliberately move to the bottom or drop: ticket numbers, internal codenames, version-number-first headlines, and thank-you paragraphs placed before the actual news.
The same structure scales: Bluesky gets sentence one plus a link, Mastodon gets all four parts, a blog or DEV article gets the full story.
For maintainers here: what makes you actually read another project’s release post? Anything you would add to the list?
Longer write-up for devrel teams: https://oraglegpt.org/use-cases/developer-relations/
You must log in or register to comment.
