4 ms·
The > and < comparisons have no meaning for complex numbers. If you don't have a way to determine which (P + iS) is bigger, then you can't sort your bugs. In o
by dilippkumar 7y ago
The > and < comparisons have no meaning for complex numbers. If you don't have a way to determine which (P + iS) is bigger, then you can't sort your bugs.
In other words, by adding a severity dimension, you lost your ability to order your bugs in any ascending or descending order. That defeats the whole point of having a priority field in the bug in the first place. Now you need to have a person decide if your [P1 S2] bug should be solved before your [P2 S1] bug by some arbitrary mechanism. And once you've made that decision, you'll communicate it with "Do this first" - which is essentially a priority field that now exists outside your system of [P S] classification.
Get rid of severity - or treat it like an enum that will help inform you what your priority of each bug is and bring sanity to your system.
- yunruse 7y agoI think this is a feature more than a bug. For the most part, sorting by priority then severity seems like the best way to approach things, unless something is extremely obviously a quick fix. That said, the P-spectrum may have some crossover, especially at P1-P2, depending on the release cycle. For example, crashes should be focussed on a little more for always-online software, whereas for more glacial, manually-updated software, prioritising incorrect behaviour or functional issues may be more important.