Bugs and Suggestions Mini App: Community Feature Voting, Issue Reporting & Roadmap Tracking
There is a place to report a bug or ask for a feature that is not a support queue: an app with a searchable list of everything already reported, a vote on each one, and a status attached.
It is the right destination for a narrow set of problems and completely the wrong one for the problems people most often bring to it.
What you will be able to do
- check_circle Send a problem to the place that handles it.
- check_circle Search before submitting, and understand why that matters.
- check_circle Write a report somebody can act on.
- check_circle Read a status for what it is.
A list with votes and statuses — which is a different thing from a queue with your name in it.
search Search first, and mean it
The instruction to check for an existing report sounds like housekeeping and is actually the most useful thing you can do. A second entry for something already listed does not add weight to the request — it splits it, so the thing you want now has two half-sized piles of votes instead of one convincing one.
It also changes what you should do when you find one. Voting on the existing report is a smaller action than writing your own and a considerably more effective one, and adding a comment describing your particular version of the problem is more useful than either, because it gives whoever reads it a second set of circumstances to reproduce.
The searching itself takes a little practice. Reports get filed under the words their author used, which are rarely the words you would have used, so it is worth trying the feature's name, the symptom, and the thing you were doing when it happened before concluding that nobody has mentioned it.
Four problems, four different destinations
Sending one to the wrong place is mostly a way of waiting longer.
| What it is for | What happens | What it will not do | |
|---|---|---|---|
| Bugs and suggestions | The app doing the wrong thing, or not doing something you want it to. | It joins a public list, gathers votes, and may acquire a status. | Nothing about your account. No reply addressed to you, and no timetable. |
| Support questions | Something wrong with your account — access, restrictions, a payment, something lost. | A message to a human queue, answered eventually and privately. | It will not fix a bug for everybody, and it is slow for anything that is not personal to you. |
| The automated restriction route | The specific case of limits on sending messages, joining, or writing to strangers. | An automated exchange that can lift or explain the limit. | It handles one narrow problem, and it is not where anything else gets read. |
| Asking in a group | Finding out whether it is you, your phone, or actually broken. | Somebody who has met it before tells you in five minutes. | It reaches nobody who can change anything. It is diagnosis, not reporting. |
Ask whether the problem is with the app or with your account. That single question routes almost everything correctly.
construction What a usable report contains
Four things, and almost nothing else: what you did, what happened, what you expected instead, and which platform and version you are on. A report with those can be tried by somebody else; a report saying that something is broken cannot be acted on by anybody, however true it is.
The most valuable addition is a way to make it happen again. "Every time, if the chat has more than one pinned message" is worth more than any amount of description, because the entire difficulty of fixing anything is meeting it. If you cannot reproduce it reliably, say that too — it is information rather than a failure.
Feature requests follow the same rule in a different form. "Make it like the other app" is a preference and goes nowhere. "I cannot do this specific thing, and here is what I do instead" describes a problem somebody could solve, possibly in a way you had not thought of, which is the point of asking rather than specifying.
psychology_alt What to expect afterwards
Mostly silence, and that is the normal outcome rather than a sign of being ignored. A public list of requests is a thermometer rather than a ticketing system: it shows what people want, in aggregate, and the useful thing you contributed was a data point.
Which suggests the right amount of effort. Search, vote, and add the specific circumstances if yours differ — that is ten minutes well spent. Writing a long argument for why your request matters, or resubmitting it in different words when nothing happens, is effort spent on a surface that does not read arguments.
settings Reporting something
- Decide whether it is the app or your account That picks the destination.
- Update first, and note your version Many reports are already fixed.
- Search with several different wordings Reports are filed under other people's words.
- Vote on an existing one rather than duplicating A duplicate splits the signal.
- Say what you did, what happened, what you expected Plus how to repeat it.
- Expect silence It is a thermometer, not a queue.
This page is for problems with the app. The curriculum step is the other queue: what causes an account to be limited, what the automated route can actually do, and how an appeal is handled.
Bugs and suggestions at a glance
Why a duplicate report splits the signal, where each kind of problem belongs, the four things a usable report contains, and what a status actually means, on one page. Tap to open it at full resolution.
