Hacker News Reader

Like I said in my other comment, because it makes the difference between controlled and uncontrolled.

Eg "the color is wrong because we specified it wrong" and "the color is wrong because the app doesn't respect what we ask it to display" both ends up with the same bug (wrong color), same priority, but not the same severity because the second case is uncontrolled.

Severity is a dev tool, priority is a business tool.

View on HN

How does setting a higher severity for one bug over the other help devs?

How would you signal the difference between:

1. We have the wrong .png asset in the database

2. Our entire rendering infrastructure is suspect

That would be extremely obvious from the bug title and description, which are presumably being read by the person who sets priority.

So instead of a severity rating, you are saying severity is encoded in the language of the description? Using descriptors a potentially non-technical PM can understand unambiguously?

I'm not saying this is the wrong approach by the way, it's just interesting how people approach this differently.

If the PM doesn't have enough expertise to understand how severe a bug is, how are they supposed to accurately assess the business impact?

Reply on news.ycombinator.com