A bug is the product failing a promise it already made. A feature request is somebody asking it to make a new one.
Every other way of telling them apart falls over somewhere. Severity does not work, because a trivial bug is still a bug and a missing feature can be an emergency. Effort does not work, because some bugs take a month and some features take an hour. Who reported it does not work either.
What is the difference between a bug and a feature request?
Ask one question. Was this ever supposed to work?
If it was, the report is a bug, and you owe the customer a fix rather than a decision. If it was never supposed to work, the report is a feature request, and what you owe them is an honest answer about whether it ever will.
That test holds up because it points at the only thing that actually separates the two, which is the promise. A bug is a gap between what your product says it does and what it does. A feature request is a gap between what your product does and what somebody wants.
Notice what the test does not ask about. Not how angry the customer is, not how many people reported it, not how hard it is to fix. Those all matter enormously to what you do next, and none of them tells you which kind of thing you are holding.
If the definition is easier to see than to read, the demo board is open with no account and no email.
How does the test apply to one ticket?
Take two tickets that read almost the same. "Export to CSV stops at ten thousand rows" and "export to CSV takes forty seconds."
If the product's own documentation says it handles up to fifty thousand rows, the first ticket is a bug, because the product broke a promise it already made. If the documentation never mentioned a row limit, the same ticket is a feature request for a bigger one.
The second ticket settles the same way whatever the number is. Forty seconds is slow, but slow is not broken unless something on your side said the export would be fast. A speed complaint is almost always a feature request wearing a bug's urgency.
There is one case where the written promise stops mattering, and it is worth knowing before the test flips on you. If the export ran in two seconds yesterday and takes forty today, the product broke a promise it made by behaving that way before. That ticket is a bug even with no documentation anywhere, because a regression is a promise made by precedent rather than by a page.
Which one is it when the answer is unclear?
Most of the time the answer to was this supposed to work is that you never said, and that is the interesting case rather than the annoying one.
Sorting is a good example. A customer wants a list sorted newest first. You never wrote down which order that list should be in, so nobody can point at a broken promise.
It is not a bug by the test above. It also does not feel like a feature request, because the customer is not asking for something new, they are telling you the obvious behaviour is missing.
The move here is not to argue about the label. It is to notice that you have just been told where your product's implied promises are, and to decide, on purpose, what you are promising.
Once you have decided, the label follows in one second. If sorting newest first is the promise, every list that does not is now a bug. If it is not the promise, this is a request and it goes on the board with everything else.
Undefined behaviour is the biggest source of disagreement about this word in most teams, and the disagreement is almost never really about the word.
Bug, defect, glitch or issue?
Four words that get used for the same ticket, and only three of them describe a failure.
| Word | What it usually means | Does it pass the test as a bug? |
|---|---|---|
| Bug | The product does something other than what it promised | Yes, by definition |
| Defect | The same gap in testing and quality language, usually measured against a written requirement | Yes, and the requirement is the promise |
| Glitch | A brief or intermittent fault, often visual, that clears on a retry | Yes, if it happens often enough to reproduce |
| Issue | Any tracked item: a bug, a request, a question or a task | Not on its own; the word is a container, which is why trackers use it |
A tracker calls everything an issue so it does not have to decide. The decision still has to be made by somebody, and the test above is the quickest way to make it.
What does "it's not a bug, it's a feature" mean?
Said as a joke, it means a fault is being renamed so nobody has to fix it. Said in earnest, it means the behaviour was intended, and the report is really a request for a different promise.
It becomes true in a third way, without anybody deciding it. When people come to rely on an accidental behaviour, it turns into a promise made by precedent, the same way a regression does. Fixing the bug then breaks something people use, and they report the fix as a bug.
Users rate a removal the way they rate a breakage. Of 168,034 of the newest App Store reviews on 4,875 top chart iPhone apps, read on 3 October 2026, the ones asking for a feature back, or saying they used to be able to do something, averaged 2.3 stars, close to the 2.0 of reviews naming a crash or bug and far from the 3.9 of reviews asking for something new. In the same reviews, 8.7 percent mention a crash, bug or something not working, and at least 1.4 percent ask for something new.
Should customers vote on bugs?
Usually not, and this is a company that sells a voting board saying so.
Voting measures how many people want a thing and, if you weight it, how much those people are worth to you. A bug is not a want.
Its cost is how many people hit it, how often, and how badly it hurts when they do, and none of those three things is what a vote counts. Ten votes on a broken export tells you ten people noticed. It does not tell you that four hundred more silently gave up.
There is a second, worse effect. Bugs on a public board attract votes easily, because agreeing that something is broken costs nothing and needs no imagination.
So a board that mixes them ranks its bugs above its requests almost every time, and then the roadmap stops being a roadmap and becomes a defect list with a nicer font.
The exception is a small product with a quiet board. If you get twelve reports a month, a single list with everything in it is fine, and the ranking is doing no harm because you are reading all of them anyway. The failure arrives with volume.
How do you keep them apart on one board?
Three mechanisms, and on VoteFirst they are all real rather than advice.
The first is a tag. In VoteFirst's data model there is no bug field and no kind column. A request and a bug are the same row, and the only thing that separates them is a tag, which is a name the project owner creates.
That is worth knowing before you shop for a tool that promises a bug type, because a tag with a filter does the same work.
The second is hiding. A hidden item cannot be voted on from any public surface, so a bug that belongs on the board for your own tracking does not have to sit there collecting votes.
The third is a private board. A feature on a custom board is public exactly when that board is, so you can run a bugs board privately and keep the roadmap open, with the same tags, the same statuses and one place to look.
There is a fourth thing worth knowing if your board takes public submissions. A suggestion arrives unapproved and cannot be voted on until somebody approves it, so triage happens before anything gets a score rather than after. That is how the board handles what arrives.
Labelling is only half of the sorting work, and the other half is noticing that two items are the same item.
That one resists automation for the same reason this one does, because a person has to read them. What a merge does to the votes, and what it does not do is worth knowing before you start tidying.
Once it is labelled and it is a request rather than a bug, there is a whole path in front of it that most tools leave undescribed. Every step a request takes on a VoteFirst board, and who can see it at each point, is written out end to end.
Why does the distinction change what you build next?
Because the two are ranked by different instruments, and using one instrument for both is how a roadmap goes wrong quietly.
A feature request is ranked by value. Who wants it, how many of them, and what they pay you. That last part is the one most boards leave out, and it is why a vote can carry the weight of the customer who cast it rather than counting everyone the same.
A bug is ranked by cost. How many people hit it, how often, how bad it is when they do, and whether there is a way around it. Revenue weighting has no business anywhere near that list.
If your billing system is broken, it is broken for the free trial user too, and the fact that they pay you nothing today does not make the bug smaller.
Keeping the two lists separate is what lets you use the right instrument on each. Mixing them means one of the two is always being judged by the wrong measure, and the usual casualty is the quiet paying customer whose request loses to a louder crowd.
If you are separating the two queues for the first time, the fields are the place to start, and there is a feature request template on this site in Markdown and as a GitHub issue form.
VoteFirst's board does the request half of that job for nine dollars a month, with weighting included rather than sold as an upgrade, and a card is required for the fourteen day trial.
14 days, a card at signup, then $9 or $39 a month.
What this costs
Lite
$9 /mo
Pro
$39 /mo
Lifetime
$999 once
Fourteen day trial of Pro, card asked for at signup. Nothing here counts the people who vote, so the bill does not move when the board starts working. The long version, with what happens if you stop paying.