<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>wpietri</author><text>&amp;gt; Because you, as a developer, are clueless regarding business needs&lt;p&gt;Then that&amp;#x27;s the problem we should fix. Instead of creating an extra database field to capture somebody&amp;#x27;s incorrect opinion, the people who understand priority should be helping developers know enough to have useful opinions.</text><parent_chain><item><author>rumanator</author><text>&amp;gt; basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe. Why?&lt;p&gt;Because you, as a developer, are clueless regarding business needs, and thus are unaware of why &amp;quot;cosmetic stuff&amp;quot; might be far more important than the risk of deleting someone&amp;#x27;s user profile. For example, perhaps the color scheme clashes with the one used by your client&amp;#x27;s main competitor and therefore might leave him vulnerable to lawsuits.</text></item><item><author>clarry</author><text>&amp;gt; &amp;quot;if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted&amp;quot; might be a very severe&amp;#x2F;critical bug, but if the client says &amp;quot;thats fine for me don&amp;#x27;t worry, but can you fix the wrong color on screen one where the logo is purple instead of fuschia that&amp;#x27;s not acceptable for my needs&amp;quot; then this one has a higher priority, even though it&amp;#x27;s much less severe.&lt;p&gt;The problem here is the made-up definition of severity.. basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe.  Why?&lt;p&gt;I could easily give it a different definition.  For example, a crash that nobody cares about is &lt;i&gt;not&lt;/i&gt; severe.  A small &amp;quot;cosmetic&amp;quot; slip up that can cause big damage to brand is very severe.&lt;p&gt;So I agree with the GP here; why do we need to have a definition of severity that does not align with the things that we care about when it comes to actually fixing things?</text></item><item><author>nolok</author><text>Because as the quote said, it depends on the client requirement.&lt;p&gt;&amp;quot;if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted&amp;quot; might be a very severe&amp;#x2F;critical bug, but if the client says &amp;quot;thats fine for me don&amp;#x27;t worry, but can you fix the wrong color on screen one where the logo is purple instead of fuschia that&amp;#x27;s not acceptable for my needs&amp;quot; then this one has a higher priority, even though it&amp;#x27;s much less severe.&lt;p&gt;Your job is not to build the perfect&amp;#x2F;best product, it&amp;#x27;s to build the one your client want and is willing to pay money for.&lt;p&gt;The mixup between priority and severity only comes from the modern era when so many product get made for internal consumption, or where the user is not not the buyer.</text></item><item><author>whack</author><text>&amp;gt; &lt;i&gt;a P0 (Blocker) bug is a ship-stopper which has to be fixed before the next release can happen. P1s (Critical) are important but not something we’d stop a release for, while P2s (Medium,Low) represent pretty much anything that will only be fixed when our development team has cleared all P0 and P1 bugs&lt;/i&gt;&lt;p&gt;&amp;gt; &lt;i&gt;It’s important to note that a bug’s priority shouldn’t be confused with its severity, which exists as an entirely different dimension... ‘Severity’ to represent a (somewhat) objective assessment of a bug’s impact to the functionality of the system. From Critical representing major crashes or hangs, to Minor functional issues or purely Cosmetic blemishes. While a QA engineer will classify a bug’s Severity at creation time, it’s the PM who assigns the Priority at the time of triage based on their knowledge of the client’s business and product requirements&lt;/i&gt;&lt;p&gt;I don&amp;#x27;t see the benefit in having severity and priority as 2 distinct dimensions. Given a specific priority, what additional benefit do you get from having a severity label as well? Based on the author&amp;#x27;s description, I can&amp;#x27;t think of any.&lt;p&gt;If the goal is to better communicate what &amp;quot;type&amp;quot; of bug it is, using an enum classification (eg, cosmetic vs crash vs data-corruption) would be more appropriate than a numeric scale.</text></item></parent_chain></comment><story><title>Don’t Confuse a Bug’s Priority with Its Severity</title><url>https://www.bluelabellabs.com/blog/dont-confuse-a-bugs-priority-with-its-severity/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>Chinjut</author><text>The person you are responding to is saying, yes, &amp;quot;cosmetic stuff&amp;quot; might be far more important. So it&amp;#x27;s more important! Why have another dimension of assessment where we label it less important? Why not only have the dimension of assessment that actually matches the clients&amp;#x27; needs?</text><parent_chain><item><author>rumanator</author><text>&amp;gt; basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe. Why?&lt;p&gt;Because you, as a developer, are clueless regarding business needs, and thus are unaware of why &amp;quot;cosmetic stuff&amp;quot; might be far more important than the risk of deleting someone&amp;#x27;s user profile. For example, perhaps the color scheme clashes with the one used by your client&amp;#x27;s main competitor and therefore might leave him vulnerable to lawsuits.</text></item><item><author>clarry</author><text>&amp;gt; &amp;quot;if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted&amp;quot; might be a very severe&amp;#x2F;critical bug, but if the client says &amp;quot;thats fine for me don&amp;#x27;t worry, but can you fix the wrong color on screen one where the logo is purple instead of fuschia that&amp;#x27;s not acceptable for my needs&amp;quot; then this one has a higher priority, even though it&amp;#x27;s much less severe.&lt;p&gt;The problem here is the made-up definition of severity.. basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe.  Why?&lt;p&gt;I could easily give it a different definition.  For example, a crash that nobody cares about is &lt;i&gt;not&lt;/i&gt; severe.  A small &amp;quot;cosmetic&amp;quot; slip up that can cause big damage to brand is very severe.&lt;p&gt;So I agree with the GP here; why do we need to have a definition of severity that does not align with the things that we care about when it comes to actually fixing things?</text></item><item><author>nolok</author><text>Because as the quote said, it depends on the client requirement.&lt;p&gt;&amp;quot;if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted&amp;quot; might be a very severe&amp;#x2F;critical bug, but if the client says &amp;quot;thats fine for me don&amp;#x27;t worry, but can you fix the wrong color on screen one where the logo is purple instead of fuschia that&amp;#x27;s not acceptable for my needs&amp;quot; then this one has a higher priority, even though it&amp;#x27;s much less severe.&lt;p&gt;Your job is not to build the perfect&amp;#x2F;best product, it&amp;#x27;s to build the one your client want and is willing to pay money for.&lt;p&gt;The mixup between priority and severity only comes from the modern era when so many product get made for internal consumption, or where the user is not not the buyer.</text></item><item><author>whack</author><text>&amp;gt; &lt;i&gt;a P0 (Blocker) bug is a ship-stopper which has to be fixed before the next release can happen. P1s (Critical) are important but not something we’d stop a release for, while P2s (Medium,Low) represent pretty much anything that will only be fixed when our development team has cleared all P0 and P1 bugs&lt;/i&gt;&lt;p&gt;&amp;gt; &lt;i&gt;It’s important to note that a bug’s priority shouldn’t be confused with its severity, which exists as an entirely different dimension... ‘Severity’ to represent a (somewhat) objective assessment of a bug’s impact to the functionality of the system. From Critical representing major crashes or hangs, to Minor functional issues or purely Cosmetic blemishes. While a QA engineer will classify a bug’s Severity at creation time, it’s the PM who assigns the Priority at the time of triage based on their knowledge of the client’s business and product requirements&lt;/i&gt;&lt;p&gt;I don&amp;#x27;t see the benefit in having severity and priority as 2 distinct dimensions. Given a specific priority, what additional benefit do you get from having a severity label as well? Based on the author&amp;#x27;s description, I can&amp;#x27;t think of any.&lt;p&gt;If the goal is to better communicate what &amp;quot;type&amp;quot; of bug it is, using an enum classification (eg, cosmetic vs crash vs data-corruption) would be more appropriate than a numeric scale.</text></item></parent_chain></comment><story><title>Don’t Confuse a Bug’s Priority with Its Severity</title><url>https://www.bluelabellabs.com/blog/dont-confuse-a-bugs-priority-with-its-severity/</url></story>