3 ms·
I don't think, except for a direct regression, it's even possible to define a bug in a way that isn't the same as a feature request. They're identical: someone
by x0x0 11mo ago
I don't think, except for a direct regression, it's even possible to define a bug in a way that isn't the same as a feature request. They're identical: someone wants the software to do X, it doesn't do X, maybe we should make it do X. (Except, again, for it used to do X but now doesn't and that wasn't intentional.)
Treating bugs as different than features and automatically pushing them to the front of the line likely leads to a non-parsimonious expenditure of effort and sets up some nasty fights with other parts of the company which will definitely figure out that something being a "bug" gets it prioritized. Obviously this can be done poorly, and why even have engineers if you aren't listening to their prioritization as well.
- wavemode 11mo agoA bug report does not mean that someone "wants" the software to do X, but rather that they -expect- the software to do X. If that expectation is correct, it's a bug, and if it's not correct then it's a feature request. Most software is not formally specified, so it's not technically guaranteed that we can prove whether that expectation is correct or not. But, there is usually a collective understanding, reinforced by the software's own interface (e.g. "the button says Do X but I click it and X doesn't happen"), the documentation, and/or general technological norms (e.g. "it crashed" or "when I type text sometimes it disappears and I have to start over"). There are occasional ambiguous cases, but in practice these are uncommon in a well-run organization, and generally the job of a product manager is to have the final say on such matters via consultation with relevant stakeholders, contracts, etc.