Publish an Update

Boarbs does not use a separate changelog screen as the main way to publish progress inside the feedback workflow.

Today, the practical Boarbs approach is to update the original request itself and let the roadmap, post page, and subscriber notifications carry the message.

What Counts as an Update in Boarbs

The main update surfaces are:

• the post status
• the post ETA
• public comments on the post
• the roadmap column the post appears in
• email updates for subscribers

This keeps the update attached to the original request instead of splitting the conversation across multiple places.

What Triggers Email Updates

Boarbs can notify subscribers when important changes happen on a post.

A few key details matter:

• the person who creates a post is subscribed automatically
• other people can subscribe from the post page
• moving a post to a new status can trigger a status email
• moving a post into a Completed status can trigger a completion email
• merging posts can trigger a merge email to creators and subscribers of both posts

That means status changes are not just internal workflow moves. They can also be the public signal that something changed.

Recommended Update Workflow

When you want to publish progress on a request:

1. open the post in the app
2. move it to the right status
3. set or update the ETA if you have real confidence
4. add a public comment if the update needs context
5. check that the roadmap placement still matches the message

This gives subscribers, roadmap visitors, and future readers the same story.

When to Use a Public Comment

Use a public comment when the status alone is too thin.

Good examples:

• rollout is starting gradually
• the feature shipped with limits or caveats
• you want to explain a delay or dependency
• the request is done, but users need a pointer to where it lives

Keep the comment customer-facing. Put internal discussion into team notes instead.

When the Roadmap Should Change Too

If the update changes customer expectations, the roadmap should reflect it.

Examples:

• a request moved from backlog into active work
• a public ETA became reliable enough to share
• the feature shipped and belongs in Done

Status, roadmap, and post comment should reinforce each other instead of telling three different stories.

If You Need Full Release Notes

If you need a broader release announcement, open Changelog in the workspace (nav or Settings) and create a standalone entry. Save it as Draft until it is ready. Publish when it should appear on Portal, Widget, and Embed.

You can add an image or video on the entry and optionally link one or more feedback posts. Those links are references. Public surfaces show the changelog post itself.

Create-from-Complete and AI draft on a Complete post remain optional shortcuts. They are not the only way to create an entry.

A Good Default Rule

Use the original post for:

• request-level progress
• customer follow-up on a specific idea
• roadmap visibility

Use the Changelog module for:

• multi-feature launches
• marketing-style announcements
• narrative product updates across several requests

Do not keep a second marketing-only changelog or a repo CHANGELOG.md next to the module.

Next Steps

• Plan Your Roadmap — Make sure updates also appear in the right roadmap column
• Deep Link Into Feedback — Send people directly to the relevant post or roadmap
• Portal — See where updates are visible on the public portal