Bug 74133 - BUGZILLAASSISTANT: Can't select versions older than "4.1.0.4"
Summary: BUGZILLAASSISTANT: Can't select versions older than "4.1.0.4"
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: WWW (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-28 02:33 UTC by Tin Man
Modified: 2014-06-07 06:47 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tin Man 2014-01-28 02:33:30 UTC
The Bug Submission Assistant only lets you select versions 4.1.0.4 and higher for when a bug has first appeared, which is a problem when a bug has always been present in LibreOffice or it has appeared in a version older than 4.1.0.4.
Why not provide all the choices Bugzilla provides here? Having limited choice only makes the bug report inaccurate. Or at least provide an "unspecified" option.
Operating System: All
Version: 4.1.0.4 release
Comment 1 Joel Madero 2014-01-28 02:36:11 UTC
This is actually by design because most people reporting on BSA (the vast majority) are reporting for the first time and don't even know the policy about version being oldest version (plus it forces them to make sure they are seeing the bug on a later release). There was an extended discussion about this and QA agreed that BSA should be aimed at users and set in a very simple way (not showing 50 versions). Marking as WONTFIX
Comment 2 Tin Man 2014-01-28 02:40:26 UTC
Then at least add an "unspecified" option (perhaps labeled "Other/I don't know").

Not being able to choose the correct option doesn't make things simple for a newbie -- it makes things incredibly frustrating, as no matter what they choose, they will choose wrong.
Comment 3 Joel Madero 2014-01-28 02:47:23 UTC
Well they have the option to choose "older version" and then gives a hint that you should be testing on the latest release - again this was discussed and documented extensively over the period of months within QA.
Comment 4 Tin Man 2014-01-28 02:55:28 UTC
Proceeding with a choice of "older version" returns an error message.
The version you're testing with is irrelevant when the assistant asks for the "Version the bug appeared", which one would interpret as the "first version in which the bug appeared".
If you instead mean the version that the user is working with, please rephrase the label to say just "Version" or "LibreOffice Version".
Comment 5 Joel Madero 2014-01-28 03:00:00 UTC
Ah - the label issue is something slightly different - perhaps for this we should change but then that conflicts with FDO policy. Tricky - adding Qubit to see his opinion
Comment 6 Robinson Tryon (qubit) 2014-01-29 02:57:31 UTC
(In reply to comment #5)
> Ah - the label issue is something slightly different - perhaps for this we
> should change but then that conflicts with FDO policy. Tricky - adding Qubit
> to see his opinion

Having trouble connecting to the BSA right now, so I'll punt on this until we get that all squared-away.
Comment 7 Robinson Tryon (qubit) 2014-01-29 03:36:03 UTC
(In reply to comment #4)
> Proceeding with a choice of "older version" returns an error message.

I can't get the BSA to throw an error by selecting 'older version' in either drop-down. Repro steps?

(In reply to comment #5)
> Ah - the label issue is something slightly different - perhaps for this we
> should change but then that conflicts with FDO policy. Tricky - adding Qubit
> to see his opinion

Short answer: The logic used in the BSA is crude, and does not completely reproduce the nuances of how we'd like the user-interaction to proceed.

Long answer: We decided that the BSA should only allow users to file bugs against recent (read: supported/future) versions of LibreOffice, but didn't have much dev time available to implement the new behavior.

After a while, I sat down and quickly hacked-in an approximate implementation of the behavior we desired. We haven't had time to refine the interface further, so (to pick one example) we're still using the same list of versions in the 'Version the bug appeared' field and the 'Latest known-working version' field.

One option would be for us just to ask for a single 'version' field. This might make a lot of sense, especially if we're targeting the BSA at users who might feel confused/intimidated by the regular Bugzilla interface.

OTOH, many have expressed support for Joel's idea of revamping the BSA so that it asks a series of questions, one at a time. In such a redesign, it would be helpful to ask the user to list version(s) in which the bug is present and (if known) older versions that did not exhibit the symptoms of the bug.  (Once we get our own instance of Bugzilla up and running, we can be even more clever about keeping track of which versions on which OSes had what behavior(s)).

To sum-up, the BSA interface needs some improvement, but we may need to punt on those changes until we have more dev time available.

Any interest in hacking on the BSA code?  :-)
Comment 8 retired 2014-02-01 08:51:36 UTC
Slightly offtopic, but for documentation and inspiration: this is how the nice Firefox Bugzilla does it:

Step 1: select component http://cl.ly/image/3e110D2n3u1j

Step 2: dupe check first http://cl.ly/image/3j461B1j3E1z

Step 3: details then http://cl.ly/image/0o100X2f0u24

By now I think QA knows I'm a fan of that bugzilla skin. The way they implemented this form is really nice. Also it would get rid of the separation between bugzilla and BSA (totally different look) and the issue that subsequently, users are dis-attached from the further bug triage followup process. Most get stuck at filing the bug in BSA and that's it.



https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm|Firefox (might require login)
Comment 9 tommy27 2014-06-07 03:55:55 UTC
I set status to RESOLVED WORKSFORME
as said by Joel that was a design choice to not include older versions in the dropdown menu and I do not receive any error while selecting "older version"
Comment 10 Joel Madero 2014-06-07 04:01:38 UTC
Dupe checks are really rough for our code - something that seems similar can be completely different. I get the occasional ping from developers after I close a dupe saying "no these are very different" - one developer went so far as to say he prefers QA not even findings dupes because we get it wrong sometimes (that being said I respectfully disagree with that, but leaving dupe checks to users might be a bit too much)
Comment 11 tommy27 2014-06-07 04:15:05 UTC
@Joel
this seems off-topic here... maybe you posted your message in the wrong report.
Comment 12 Joel Madero 2014-06-07 06:47:41 UTC
In response to comment 8 :) but you're right, best to avoid the rabbit hole :)