A public roadmap status should tell someone what is happening to their request. It should not require them to guess whether “planned” means tomorrow or whether “shipped” covers their original use case. Pair each status with a short explanation of the current scope and the next step.
VoteWant's request model includes open, under review, planned, in progress, shipped, and declined. These labels provide a vocabulary. The team still needs to explain its decisions. The wording below is a suggested communication practice, not a guarantee about how quickly any team responds.
Open means the request can be discussed
Use open for requests that have not received a decision. Acknowledge the problem and ask for missing context where necessary. “We have received this request and are collecting examples” is clearer than implying that the team is already implementing it.
Do not promise that every open request will reach the roadmap. Some will remain uncertain, overlap with another discussion, or fall outside the product's purpose. Tell contributors what would help the team understand the task, such as a recent example or a description of the workaround.
Under review means there is a question to answer
Name the uncertainty you are investigating. “We are checking whether the reporting issue affects weekly summaries or all exports” tells users more than “Looking into it.” It also gives the team a way to decide when the investigation is complete.
Keep investigation and delivery separate. Reviewing feasibility does not mean implementation is committed. A finding might lead to a small bug fix, a different solution, or a decision not to proceed. Explain the outcome when the status changes.
Planned and in progress need scope
For planned work, say what the team intends to solve and what remains undecided. For in-progress work, describe the current scope without exposing internal details that users do not need. Avoid dates unless the team is prepared to treat them as an actual commitment.
A hypothetical update might say: “We plan to add a weekly summary export. Custom report layouts are outside this first version.” That wording helps people determine whether the plan addresses their need. If the scope changes, update the explanation rather than leaving an old promise attached to a new status.
Shipped should identify the available result
When work is delivered, link the instructions or release note and explain how users can try it. State relevant limitations. A request for offline search is not fully answered by a search improvement that still requires connectivity. The shipped explanation should make that distinction visible.
Ask whether the original task is now possible. A delivery label reports what the team released; it does not prove that every participant's problem is solved. Comments can reveal missing cases and help define a separate follow-up request.
Declined deserves a reason
Explain the tradeoff in terms of product purpose, constraints, or a supported alternative. Avoid a dismissive one-word response. “We are keeping this product focused on individual workflows, so team administration is outside its current scope” is specific while leaving the future direction open.
Read feature voting and prioritization for the decision process behind these updates. Explore VoteWant and its API documentation for current request and owner workflows. Do not assume a status change automatically emails participants; notification behavior should be verified separately before promising it.