https://bugs.winehq.org/show_bug.cgi?id=37875
Bug ID: 37875 Summary: Wine Bugzilla Interface doesn't inform enough users about logs Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs@winehq.org Reporter: scrimekiler@yahoo.fr Distribution: ---
I would like to focus your attention about this : it seems a lot of bug reports don't have logs provided.
I suggest a change in the interface of Wine Bugzilla, i.e. a warning to the users when a bug is posted without a bug report, explaining them the importance of logs and refering them to a page explaining them how to add logs.
Without that, bugzilla maintainers will spend half of their time answering "please attach a log file".
I'm not a bugzilla maintainer myself but I see this kind of problem happening so much time !
I hope this will help.
https://bugs.winehq.org/show_bug.cgi?id=37875
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- This can probably also be a bit generalized, I think bugzilla should warn also about other fields, when they are not filled out properly. For example wine version, download link, ...
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #2 from Someone scrimekiler@yahoo.fr --- Sorry I I wrote :
"I suggest a change in the interface of Wine Bugzilla, i.e. a warning to the users when a bug is posted without a bug report"
I meant :
"I suggest a change in the interface of Wine Bugzilla, i.e. a warning to the users when a bug is posted without a log file"
https://bugs.winehq.org/show_bug.cgi?id=37875
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com, | |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=37875
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #3 from Anastasius Focht focht@gmx.net --- Hello folks,
although emphasizing on logs is fine there are indeed other important aspects that should be given even higher priority.
Wine version -> proper selection should be much more emphasized, also a hint how to get this information (taking possibility of users with multiple active Wine versions into account).
A short descriptive summary, containing the application/game name(!), version/release and the symptom: "installer doesn't work", "crashes on startup", "<feature> doesn't work", "installer hangs/freezes" ...
A download link is also preferable and indeed the best option for guys like me.
Logs are nice but many times don't tell the real story, requiring in-depth tracing with dedicated debug channels and actual debugging. Yes, there are exceptions when logs are the only way to get information: no access to the software, OP's Linux/Wine/prefix is broken.
From my experience, the time I spend on the first iteration/ping-pong: "which
version, app name", "did you try X?", "please provide information X", <response>, "ok, please try X", "generate log X" could have already been used to work out the actual problem if the minimal set of information would have given when the report was created: app name+version, download and a short description of the problem and how to reproduce.
It's not very hard to provide this information with the benefit of much less triager time wasted and less frustration on both sides.
Regards
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #4 from Rosanne DiMesio dimesio@earthlink.net --- IMO, the most useless bug reports are the "drive-by" ones from the extreme newbies who actually do post the log captured from Wine's crash dialog, but little else, and are never heard from again. They are, however, doing exactly what Wine's crash dialog invited them to do.
We already have detailed instructions on how to file bugs at http://wiki.winehq.org/Bugs. That page is linked to in step 2 ("Read our Guide on filing bugs.") on the Bugzilla home page, and it is also the page Wine's crash dialog links to.
Since it's on the wiki, if there is anything anyone thinks should be added and/or rewritten, all they have to do is create a wiki account and make the changes. Just keep in mind that no matter what you do, there will always be users who either don't read the instructions, or don't understand them.
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #5 from Anastasius Focht focht@gmx.net --- Hello Rosanne,
--- quote --- http://wiki.winehq.org/Bugs. That page is linked to in step 2 ("Read our Guide on filing bugs.") on the Bugzilla home page, and it is also the page Wine's crash dialog links to. --- quote ---
the bug information page is already pretty good but it seems the average user and 99% of the "drive-by" people won't bother visiting the links presented on the form and even read them thoroughly - especially when they need to scroll down.
What could really help if the bug report form itself could be redesigned in a way that the essence of http://wiki.winehq.org/Bugs is somehow present in that single form. This is the single entry point/form most people will ever use.
Summary line (app name, version, symptom): Maybe some examples could be directly displayed in a listbox/textfield above of the field or below. Alternatively: see my last paragraph about the "mini-form" in the description field.
Wine version: It might be feasible to warn users that "unspecified" is a very bad choice and the selection of this value can lead to bug reports being dismissed as "invalid" or just being ignored (why not tell the harsh truth to lazy people?). The "version" field description could be directly linked to a page which actually tells people how to determine the Wine version used (instead of generic description from Bugzilla).
Severity the same. Many users still think their app/game deserves special treatment and "crash" means "major" or "critical". A warning should be displayed when selecting these values. To be frank, I would not expose values > "normal" at all to normal users and leave it to Bugzilla admins and triagers with special permissions.
It might be feasible to pre-fill the description field with a small text the user is forced to read (emphasizing key points/essence of some values in the bug report). It shouldn't be that annoying and everyone can CTRL+A and CTRL+X the content anyway, if not applicable.
Maybe
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #6 from Henri Verbeet hverbeet@gmail.com --- (In reply to Anastasius Focht from comment #5)
Severity the same. Many users still think their app/game deserves special treatment and "crash" means "major" or "critical".
For what it's worth, I don't think that's the issue so much as people misinterpreting the meaning of the field. I.e. interpreting it as meaning "How does this bug affect my ability to use the application?" instead of "How does this bug affect Wine?". (Which arguably wouldn't even be an unreasonble way to use the field.)
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello Henri,
yes, I meant it the way you phrased ... "special treatment" was rather bad wording :)
If the app/game crashes it's obviously a serious/critical/blocking thing for the end user - expressed in the severity level setting (not original meaning in scope of Wine).
Regards
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #8 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Anastasius Focht from comment #5)
What could really help if the bug report form itself could be redesigned in a way that the essence of http://wiki.winehq.org/Bugs is somehow present in that single form. This is the single entry point/form most people will ever use.
I agree, but my understanding is that the policy is to keep this bugzilla as close to upstream as possible to avoid having to reapply a lot of custom patches whenever the version is upgraded. I'm not sure how much "redesigning" can be done within that constraint.
The "version" field description could be directly linked to a page which actually tells people how to determine the Wine version used (instead of generic description from Bugzilla).
If they don't read the current info, they're not likely to follow a link to a version page, either. And they might respond to a warning by arbitrarily choosing a version from the list. That's a chronic problem in the AppDB.
To be frank, I would not expose values > "normal" at all to normal users and leave it to Bugzilla admins and triagers with special permissions.
I made a similar suggestion a few years ago. I don't think anyone disagrees with the idea; my understanding is that there's no way to do that (or at least that no one's figured out how to do it). But perhaps the permissions can be changed so that ordinary users can't change that field at all? Admins and triagers would have to take over lowering severity in cases that warrant it, but we already do a lot of that anyway (few people think their problem is minor), and the extra work will be more than offset by no longer having to lower the severity to normal or argue with people who keep raising it even after being told not to.
It might be feasible to pre-fill the description field with a small text the user is forced to read (emphasizing key points/essence of some values in the bug report). It shouldn't be that annoying and everyone can CTRL+A and CTRL+X the content anyway, if not applicable.
Or they could just click "Submit" with the pre-filled text that they haven't actually read intact.
https://bugs.winehq.org/show_bug.cgi?id=37875
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jnewman@codeweavers.com
--- Comment #9 from Austin English austinenglish@gmail.com --- (In reply to Rosanne DiMesio from comment #8)
(In reply to Anastasius Focht from comment #5)
What could really help if the bug report form itself could be redesigned in a way that the essence of http://wiki.winehq.org/Bugs is somehow present in that single form. This is the single entry point/form most people will ever use.
I agree, but my understanding is that the policy is to keep this bugzilla as close to upstream as possible to avoid having to reapply a lot of custom patches whenever the version is upgraded. I'm not sure how much "redesigning" can be done within that constraint.
That's my understanding as well, though that's up to Jeremy Newman and Alexandre.
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #10 from Someone scrimekiler@yahoo.fr --- I think the information is not displayed correctly to users.
Why some users dont select a version ? I think there are two cases that often happen : 1) The user have no idea how to check his wine version 2) The user thinks it's not important so he doesn't try to check
The documentation is too long about that and may be too technical for some users.
There should be a link like "How to check wine version" or directly "type wine --version" shown when user doesn't select a version.
The same thing could be applied to logs. I don't think users want to see array of debug channels...They only want to know how to type (or copy/paste) a simple command that creates a log they can send. Wouldn't that be better if users who currently don't send logs would send default output log ? It would at least give the main "err:" message or clues to ask users to use more specific debug channels, right ?
Users aren't all developpers, don't forget that, they must be guided with simple things like highlighted texts, with essential informations, not 2 or 3 pages to read...
An idea could be a dialog box with something like "your report require your wine version or developpers will not be able to fix it", and two choices like "Continue Anyway" or "Cancel".
Even if there will still be people not selecting version and not sending logs, there should be less of them with that kind of precautions. It can only be an improvement.
I think that problem doesn't come only from users, but the current design of the Bugzilla and the way the information is displayed, and what information is displayed is in cause.
I hope something will be done, the time spent on that matter will be less time to spend to answer users.
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #11 from Rosanne DiMesio dimesio@earthlink.net --- I don't think the problem with the version field is that users don't know what Wine version they're using or how to find out.
I think the problem is that it's not clear that that field is for the Wine version. If you hover your mouse over "Version," the tooltip that pops up says "This version field defines the version of the software the bug was found in." Is "the software" supposed to be Wine, or the app they're trying to run? What's visible in the box for the Version field when first submitting a bug is:
20050628 20052725 20050830 20050930 unspecified
None of that matches the current versioning scheme for Wine, and it's unlikely to match the versioning scheme for their app, so it's hardly surprising that many users decide "unspecified" is the safest choice.
Renaming the field to "Wine Version" might help, but having current versions displayed on the bug entry form rather than ancient ones would help much more.
https://bugs.winehq.org/show_bug.cgi?id=37875
--- Comment #12 from Austin English austinenglish@gmail.com --- (In reply to Rosanne DiMesio from comment #11)
I don't think the problem with the version field is that users don't know what Wine version they're using or how to find out.
I think the problem is that it's not clear that that field is for the Wine version. If you hover your mouse over "Version," the tooltip that pops up says "This version field defines the version of the software the bug was found in." Is "the software" supposed to be Wine, or the app they're trying to run? What's visible in the box for the Version field when first submitting a bug is:
20050628 20052725 20050830 20050930 unspecified
None of that matches the current versioning scheme for Wine, and it's unlikely to match the versioning scheme for their app, so it's hardly surprising that many users decide "unspecified" is the safest choice.
I agree, but there's not currently an option for that. I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1122933
upstream. Note that it may be easy to workaround, see: https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/n5L6fmY4joo
but I haven't tested it.
-
wine-bugs＠winehq.org