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.
Which one is it when the answer is unclear?
Most of the time the honest 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.
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 honest 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 ours they are all real rather than advice.
The first is a tag. In our 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 one takes on our 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.
Our 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.
