Bugzilla tickets, severity, and common courtesy

Bugzilla tickets, severity, and common courtesy

[Kris Van Hees]

I would appreciate it if you would actually talk to me before changing
significant fields on a bugzilla ticket that I reported and that is
assigned to me.  The conclusion of our much-too-lengthy discussion on
#frysk was *not* that you could just change the severity on this ticket
at your whim.  Perhaps frysk does not use 'critical' but I do.  For your
information, there is no rule to be found on the frysk bugzilla FAQ
concerning not being allowed to use 'critical'.

Until e.g. http://sourceware.org/frysk/bugzilla/index.html#faq states
the rules you desire to dictate upon developers in how to use bugzilla, I
would appreciate it if you would respect people's way of working with
bugzilla.

Bug 4585 is in my book a critical bug and given that it was reported by
me, assigned to me, worked on by me, and resolved by me, I do believe I
have the right (at this point in time) to make a decision about whether I
consider this bug critical or not.  If the develop community of this open
project decides to outlaw the use of 'critical' in the future, you can
always come back to change it.

        Cheers,
	Kris

Re: Bugzilla tickets, severity, and common courtesy

[Stan Cox]

Severity level definitions leave room for interpretation (sort of like
the C standard, heh heh), but these are the severity definitions that
the Red Hat support team uses.

severity 4 (enhancement in bugzilla) General usage questions,
recommendations for future product enhancements or modifications. There
is no impact on the quality, performance or functionality of the
product.

severity 3 (minor in bugzilla) - Medium-to-low impact problem which
involves partial, non-critical
functionality loss. One which impairs some operations but allows the
customer to continue to function. This may be a minor issue with limited
loss or no loss of functionality or impact to the customer's operation
and issues in which there is an easy circumvention or avoidance by the
end user. This includes documentation errors.

severity 2 (normal in bugzilla) High-impact problem in which the
customer's operation is disrupted but there is capacity to remain
productive and maintain necessary business-level operations.

severity 1 (critical in bugzilla) Catastrophic problems which severely
impact the Customer's ability to conduct business. This may mean that
the customer's systems and/or product are down or not functioning and no
procedural work-around exists. Severity 1 also applies for issues that
result in an emergency condition that cause a serious security breach.