2009/5/8 richardvoigt@gmail.com richardvoigt@gmail.com:
2009/5/7 Austin English austinenglish@gmail.com
2009/5/3 Nicklas Börjesson Nicklas.Borjesson@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.