What if users warned about critical bugs?

[Alberto Salvia Novella]

Thomas Ward:
> We need to be really careful with how we define 'data corruption'.
> There are cases, such as in the nginx package, where data is
> overwritten by the package because it ships defaults.  If the
> configuration files, and/or included default file directories, get
> overwritten, this can cause 'data corruption via overwriting', but
> that's not a Critical bug, that's a case where the user used the
> default location controlled by the package manager, not necessarily a
> bug in the package itself.

If the warned bug is not a critical one, the team can simply set it with 
another priority.

And I think the "data corruption" meaning is easily understood taking 
into account the communicative context, or overwriting configuration is 
not data corruption.


Brendan Perrine:
 > If this gets to all users how can we make sure there are not people
 > that think this bug affects me therefore it is critical which could
 > make lots of mistakes. Or a user that is like I want this fixed badly
 > therefore it is critical.

In the last term the Bug Control team is who sets the importance, not 
the reported.


Brendan Perrine:
 > How would this be any different than a bug that ends up in red on the
 > bug tracker that makes an install fail.

Nothing, as the bug would be tracked in Launchpad equally.


Brendan Perrine:
 > A bug tag on launchpad like iso-testing-critical for bugs that caused
 > a failed testcase could be something to make triaging easier and
 > would encourage people to use the tracker and would work on top of
 > the already existing infrastructre.

Why putting "critical" to a tag when there's already a field for priorities?

How can adding a new tag to the list of 123 we have encourage people to 
use the tracker?