As a developer, I generally find having a distinction between bugs and features useful.
If I'm going to do a big refactoring of some component, I find it useful to look for related open bugs (even if they're low severity) because sometimes it's low or zero extra effort to fix them at the same time. This only works if you have good quality tickets though (proper tags, alias words, etc), which is a whole different topic.
I think it also reduces cognitive load while looking at tickets to have them categorized that way too. Of nothing else being visually distinct (via icon or something) just makes it easier to process.
Above all though, it's important not to argue about bug vs feature. Ideally any bug can link to the feature ticket that isn't working, but either way it's more important to make things better for the customer, so if that means considering a what is really a feature request a "bug" because it'll cause a big argument otherwise, then do that.
If I'm going to do a big refactoring of some component, I find it useful to look for related open bugs (even if they're low severity) because sometimes it's low or zero extra effort to fix them at the same time. This only works if you have good quality tickets though (proper tags, alias words, etc), which is a whole different topic.
I think it also reduces cognitive load while looking at tickets to have them categorized that way too. Of nothing else being visually distinct (via icon or something) just makes it easier to process.
Above all though, it's important not to argue about bug vs feature. Ideally any bug can link to the feature ticket that isn't working, but either way it's more important to make things better for the customer, so if that means considering a what is really a feature request a "bug" because it'll cause a big argument otherwise, then do that.