> In what way is that an issue of 'critical severity'? The quoted text contains an explanation of why it is not.
The only reason would be this: given a large enough enterprise you have one person categorizing a bug as a crash and another making the call on whether that crash is actually worth prioritizing, a decision made on another day at another pay grade in another time zone. In this case it might be clear, but in the next case it might be "the configuration page crashes if the region is France". I as a developer don't know and I don't care that we haven't even launched the product in France so I just want to mark the issue as a very severe crash. Somewhere above my head the can call this low prio because the product launch in France is still a year out. This is enterprise backlog massage for enterprise workflows.
This is flirting with redefining 'severe' as something it is not. Severity is about impact on the user.
In your scenario, you don't know whether it is severe or not, so you just want to provisionally mark it as severe, and have someone with the appropriate domain knowledge make the final call. Until that happens, decisions made on the basis of that provisional call could be bad decisions.
And what might those decisions be? Priority, for one! To say that the severity should stay at 'severe', and the adjustment should be made only in the priority, is to confuse the two distinct concepts. I see a lot of that going on wherever data are used.
If you want to characterize bugs by the sort of technical outcome they produce, then do just that, instead of trying to bend 'severity' to try and encompass it, while actually hiding the issue that you wanted to characterize on. Again, while technical outcome is an aspect of severity, they are not the same thing (and, FWIW, crashing is rarely the worst thing that could happen (unless the domain is vehicle control.))
No I have the Domain knowledge and know that it’s a crash that occurs on odd weeks in France. I noticed it while developing and I can confirm it in the code. This to me is exactly as severe as the same crash in the US (as far as I’m aware). I must assign a high severity.
However I have little to no knowledge of the business (markets, release schedule). I’m not even aware that we have zero users in this region. A manager I have never met assigns a low priority, two months later.
Domain and business overlaps, but for example if one doesn’t mark this “severe” because the business hasn’t launched for affected customers, then a year later when it is launched in France you have a low severity bug that should be high.
The priority can be constantly re-evaluated against business needs while the severity is fixed.
Yes this is a simple technical characterization. It’s not useless to separate the business-stopping bugs from the cosmetic. And importantly: It’s not my call to say what is important.
Someone might say that the font size is more important than a deadlock. I don’t care and I don’t want to care. But I’m rather sure that those that do make those decisions want to be able to sort the bugs I wrote by a severity.
There is no "severe to you" as a dev in this sense. Severe to you is when your IDE is not working and you can't work on the priority tasks.
The crash has no severity to you. It is either severe or not to the client. If you don't know whether it is severe to them, sure you can guess that a crash in france is severe, but that's an incorrect guess, not an independent dimension of severity.
There is no "techical measure of severity", everything is goal oriented. It's not severe unless it's important to the client, or is impeding something that is important to the client.
In that case, I don't see this as very relevant as a counter-example to my original point, though you haven't made it clear what your organization's concept of severity is, and why this example counts as such. Does your definition convey any information, to the person setting the priority, that is not redundant with respect to the other information about the bug that they must necessarily take into account when making that decision?
Do you call a bug that corrupts data more or less severe than a bug that crashes a program? In whichever order you put them, is the severity always necessarily in that order?
>I’m rather sure that those that do make those decisions want to be able to sort the bugs I wrote by a severity.
Why would they do that, if, as you say, "It’s not my call to say what is important"? In what way is this not you signalling that you suspect, provisionally, this has a severe impact, as I suggested in my previous post? I think you are being a bit inconsistent here.
The only reason would be this: given a large enough enterprise you have one person categorizing a bug as a crash and another making the call on whether that crash is actually worth prioritizing, a decision made on another day at another pay grade in another time zone. In this case it might be clear, but in the next case it might be "the configuration page crashes if the region is France". I as a developer don't know and I don't care that we haven't even launched the product in France so I just want to mark the issue as a very severe crash. Somewhere above my head the can call this low prio because the product launch in France is still a year out. This is enterprise backlog massage for enterprise workflows.