Severity levels

[Ben Klein]

2009/5/8 richardvoigt at gmail.com <richardvoigt at gmail.com>:
> 2009/5/7 Austin English <austinenglish at gmail.com>
>>
>> 2009/5/3 Nicklas Börjesson <Nicklas.Borjesson at ws.se>:
>> > Explained to me?? ...this is just incredible.
>> > Regardless of what I have said, you have repeated almost the same
>> > things,
>> > it's like you haven't been reading my posts!

Or that you're not reading other people's posts, like every time they
mention the phrase "developers, not users", you assume the entire post
is irrelevant to the discussion.

>> > Leave me alone, I want to talk to someone else.

I've said it before, you're one man against the world in this argument.

>> Bugzilla is a developer's tool, with bugs reported by users. Severity
>> levels are there for how they affect Wine *overall*, not the user
>> experience. Such things belong in the AppDB/etc., not bugzilla.
>
> Having it in a field in bugzilla with a list of options is potentially a lot
> better than expecting users to enter the information in the description
> without being prompted.  I'd suggest:
> Application can't start.
> (default) Something I need to do is broken, but enough of the app still
> works to be useful for other tasks (e.g. a word processor with broken
> equation editor).
> The app is totally useless (e.g. a word processor with broken Open & Save
> dialogs).
> Part of the app is broken but I can work around the problems.

This is not very useful to the people who matter on bugzilla
(developers). "Something is broken" is too close to "The app is
useless" (at best these would be Minor and Normal bugs, at worst both
Normal) and "Part of the app is broken" is exactly the same as
"Something is broken" except a workaround is present (this is
guaranteed to be Minor).

Users need to provide much more detail to their bug descriptions than
this. Adding a field that describes the problem in a vague way will
encourage users to minimise their descriptions (BAD). Imagine:
"I already said that something is broken, why are you asking for more
information? FIX IT! It's really important! I need it to live!"

If any improvement can be made to the bug submission system, it would
be to encourage users to provide *more* descriptive detail (especially
for steps taken to reproduce the bug) in their initial report. Any
suggestion for adding or modifying a field to indicate "Impact on user
experience" will not affect that.

> along with instructions to file installer bugs under "Installer for XYZ"
> because installers have the same potential for partial breakage (can't
> select install directory vs shows negative free space and refuses to install
> at all)
> This was already suggested, but the options addressed multiple orthogonal
> issues (how usable is the app vs what kind of breakage) which someone
> pointed out would be even more confusing.  Keep the what broke in the
> description where users will naturally report it, and provide only an impact
> (hey that might not be a bad name for the field -- "impact") level in a new
> dropdown list.

It's been said before: bugzilla is not the place for this type of
thing. The "impact on user experience" is not a factor in determining
bug priorities, nor will it ever be. Remember, WineHQ is not a
company, Wine is not proprietary, so Wine does not have to behave like
a commercial product. If someone is willing to work on a bug, then
patches will get submitted and reviewed. If the patches are
well-formed and functional, and don't cause obvious regressions, then
the patches are committed and the bug fixed. That's how collaborative
open-source development works, especially in such massive projects as
Wine.