Roadmap requests and votes

Anyone who can read the project can upvote a request and add a comment; changing the request itself needs editor access. That split is the point: the case for a request is built by the people who want it, and the record is kept by the people who own it.

Upvoting counts your support once however often you press it, and pressing again removes your own vote. A comment holds up to 4,000 characters and is stored with your name and the time.

Request type, product area and progress are always required, and a feature is required as soon as the type is improvement. An improvement has to name a feature the chosen product area actually lists, which is what stops a request about one part of the product being filed under another.

Leave the feature empty for a new feature. Naming the closest existing thing there would quietly turn a bet into a refinement in every later reading of the record. The quarter is optional, and a request without one reads as unscheduled rather than as late.

Nothing computes progress. It is the whole number somebody typed, from 0 to 100, kept in the record's history like any other field, so a jump from 20 to 90 is visible in the revisions rather than lost in an average.

Bets and experiments reads a new feature as a bet, because it is committed before it can be tested, and an improvement as refining something that already exists. A request with no type cannot be placed as work at all.

A declined request keeps its votes, comments and revisions, so the case that was made for it stays readable.