The Requests Board
The requests board is where users and developers raise what the platform is missing: how a request is opened, what the states say and who sees which requests.
Overview
The board is a discussion surface rather than a wish list. Each request stands in one person's own words; readers support it, comment on it and the team gives it a state.
Requests are not translated. A request stays in the language it was written in, and that language is recorded with it; the team does not rewrite the text.
For a developer the board does two jobs: you report the extension points you find missing, and you read what customers are asking for before you plan your own product.
Prerequisites
Structure
A request sits in one of eight states. Everyone sees all but the first.
| State | What it says |
|---|---|
| Pending | Newly submitted; visible to its author and the team only |
| Under review | Published on the board, the team is reading it |
| Considered | The idea landed; its scope is being discussed |
| Planned | On the roadmap |
| In progress | Being worked on |
| Completed | Met by a published release |
| Declined | Will not be built; the reason sits under the request |
| Already possible | The need is met by the product as it is today |
The board sorts by state by default, so work in progress and planned items come first. Newest, oldest and top-rated sorting are available too.
Walkthrough
Open a request
- Search the board first; when the same need is already open, support it instead of opening a second one.
- Select New Request and write the need concretely: what you are trying to do and what stops you today.
- After submitting, the request waits for approval. Once the team publishes it, it appears on the board and starts collecting votes.
Support and discuss
- Vote on a request when you share the need; votes are read during prioritisation.
- Add something concrete in a comment: the scenario that needs it and your current workaround.
- Add a request to your favourites to keep following it.
Follow the outcome
- When the state changes the badge changes with it; the record keeps the same address.
- Declined and already-possible requests carry their reason under the record.
- A completed request closes together with the release that met it.
Reference
Example
A well-written request says three things: what you are trying to do, what stops you today and what it would solve.
Need : a hook that runs before a service is created
Today : I work from the post-create hook and cannot stop the order
Impact : I want to halt an order when the provider quota is fullThe distance between a general wish ("make it more flexible") and a concrete scenario decides how quickly a request is assessed.
Pitfalls
Duplicate requests split the votes and both stay under the threshold. Search first, and support the existing one when it is there.
Open a support ticket for a problem on your own installation. A record here discusses the product's future, not one installation.
What you submit waits for approval first. If you cannot find it on the board, the record is not lost; it is in the queue.
Related Articles
Thanks for your feedback!
Our support team is here around the clock for anything you can't find above.