I'm always surprised to see bugs like this where an extremely easy to test part of the spec just seemingly isn't tested and ends up as a bug that never gets fixed until many years later.
I'm always surprised to see bugs like this where an extremely easy to test part of the spec just seemingly isn't tested and ends up as a bug that never gets fixed until many years later.
The way I've seen it implemented at a small company I worked at before was to explicitly endorse the "20% time" idea that Google made famous, where you may choose your own priorities for a fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
But in general, I do believe that teams should be split on the priority issue in some way. If all you are doing is chasing the highest priority stuff, you're going to miss important things because priority isn't an exact science either.