Roadmap and changelog
The roadmap shows which feedback is planned, in progress, or completed. The changelog records changes that have shipped. Both are public pages in the portal's top navigation, next to Feedback, so visitors can follow a request by checking feedback statuses and published changes.
The public roadmap
The roadmap at /roadmap displays feedback in three columns: Planned, In Progress, and Completed. Each card shows the title, a one-line excerpt, the board the post belongs to, and its vote and comment counts.
Which statuses appear
Feedback has four statuses, but the roadmap shows only Planned, In Progress, and Completed. New feedback starts as Open and does not appear on the roadmap.
Changing an Open post to one of the three roadmap statuses adds it to the public roadmap immediately. Changing it back to Open removes it from the roadmap without deleting the post.
Merged duplicates are not listed separately; only the post they were merged into appears. Each column initially loads its ten most recent posts, ordered by submission date rather than vote count. The header badge shows the column's total number of posts, and Load more retrieves the next page.
What visitors can do
Each card opens the feedback detail page, including the full description, comments, and vote button. Anyone can read the page, but voting and commenting require an account.
Voting and commenting remain available in every status, including Completed. Changing a post's roadmap status does not close either action.
Moving cards
Dashboard → Roadmap adds administrative controls to the same three-column view: drag and drop between columns, filtering by board, and a + button in each column header that creates a post in that status.
Moving a card by dragging it does not send email. To notify upvoters about a status change, open the feedback detail page, change the status there, and use the notification option. See How feedback works for the notification rules.
The changelog
The changelog at /changelog lists published entries in reverse chronological order. The first two entries are expanded and the rest are collapsed. Each entry also has a page at /changelog/<slug> that you can link to directly.
An entry has a title of up to 70 characters, a Markdown body, up to three category badges, and an optional cover image (1200 × 480 works best). You create entries under Dashboard → Changelog.
Draft, published, needs update
Each entry has an editable version and a published version. Selecting Publish copies the editable version to the published version. The status describes the relationship between these two versions.
Draft — the entry has never been published, so it is not available on the public changelog and does not have a public page.
Published — the editable and published versions match.
Needs update — changes have been saved after the last publication. Saving does not update the public page; the previously published version remains live until you select Publish again. Any saved change, including a title correction, moves a Published entry to Needs update.
Use the status filter above the changelog list to find all entries whose published version differs from the editable version.
Republishing moves the entry to today
Every publication sets the entry's publication time to the current time. Republishing an older entry therefore gives it today's date and moves it to the top of the timeline. Consider this effect before republishing a minor correction.
The URL is created when the entry is first saved, using the title and a short random suffix. Renaming the entry later does not change its URL. Deleting an entry also deletes its reactions.
New, Improved, Fixed
An entry can use any combination of the three categories, which appear as badges on the timeline:
- Use New for a capability that did not exist before.
- Use Improved for a change to an existing capability.
- Use Fixed for a bug fix.
If an entry covers more than one type of change, apply each relevant category.
Reactions
Signed-in readers can react to a published entry with six emoji: 👍 ❤️ 🎉 ✨ 👀 🤔. One person can add several different reactions to the same entry. Selecting an existing reaction again removes it. Signed-out readers are prompted to sign in. Only reactions with at least one response are displayed, so a new entry shows the add button instead of six zero counts.
Interpreting reactions
Reaction counts are a general engagement signal. An emoji alone does not explain why someone selected it, so use comments and feedback when you need more detail.
Drafting with AI
The AI Write button in the editor's toolbar opens a panel with three inputs.
Select related feedback (optional, up to 10 posts). The search uses semantic matching, as duplicate detection does, so you can search by the meaning of a request instead of its exact title. Before you enter a search, the picker lists recent feedback.
Style preset — four of them, described below.
Describe your updates (optional, up to 2,000 characters). Brief notes are enough, for example: added GitHub login, fixed the Markdown list bug. The generated draft is always in English, regardless of the input language.
You must provide related feedback, an update description, or both. The update description is the source of facts. Selected feedback helps confirm the request and suggest categories, but it is not a source of release facts. The generator is instructed not to reuse feedback wording or add benefits, reasons, or implementation details that are absent from the update description.
When a draft needs more detail, the generator may add where readers can find the change. It preserves explicit numbers from the update description. Verify these details before publishing, especially menu paths and other interface labels.
The presets differ in length and shape, not only in tone:
| Preset | What comes back | Reach for it when |
|---|---|---|
| Concise | 20–80 words. Two sentences: what readers can now do, followed by where to find it. No headings, bullets, or emoji. | A small update focused on one change. |
| Structured | 40–220 words. A short introduction followed by ✨ New, 💎 Improvements, and 🐞 Fixes sections with one-line bullets. Empty sections are omitted. | A release containing several changes. |
| Benefit-led | 60–170 words. Opens with a directly supported problem, states the outcome, and lists 3–4 available actions. The title contains one emoji. | A larger release whose user-facing outcome needs emphasis. |
| Witty | 30–80 words. One playful paragraph with no headings or bullets. It may omit specific feature names. | A short release where an informal tone fits your audience. |
Because the Witty preset may omit specific feature names, check that the final entry still communicates the information your readers need.
Generate before you write, not after
Applying a generated draft replaces the title, body, and categories currently in the editor. The cover image is preserved, but existing title and body text are not.
Self-hosted instances require OPENAI_API_KEY for AI drafting. Without it, the button reports that AI generation is not configured; the rest of the editor continues to work. See Configuring external services.
Review every generated draft before publishing. Check that it includes all important changes and that names, numbers, categories, and interface paths are accurate.
