[Bugsquad] New Bug Reporting Tool needs wider testing

[Myriam Schweingruber]

Hi Matt,

On Thu, Dec 10, 2009 at 05:43, Matt Rogers <mattr at kde.org> wrote:
> On Mon, 2009-12-07 at 11:16 +0100, Myriam Schweingruber wrote:
>> Hi Matt,
>>
>> On Sun, Dec 6, 2009 at 03:10, Matt Rogers <mattr at kde.org> wrote:
>>
...
>
> It shows the top 100 duplicates for a particular product or the bugs
> getting the most duplicate churn over the last month. What was it about
> the field that kept you from finding it? Does the button need to be
> different to break up the black and white?

Well, it looks too small, and it is immediately below the big field
where the duplicates show. Especially with a big resolution, it can be
easily overlooked, so maybe some bold characters could help.
...
>
> The query for duplicates per product. It's the top 100 duplicates, or
> it's the bugs with the most change in duplicates over the last two
> weeks, depending on what the user picks. The default is top 100
> duplicates. If I really need to, I'll write something that adds more
> filtering, but I'm thinking that I'd like to get this version out before
> I do that.

No problem for me, we just need to find a way to get people actually
really look at the dupes, if there will be a list of 100 duplicates,
most will just skip that part, laziness again :(

...
> bug 218077 for the version ordering. I think the scrolling issue is
> mitigated somewhat by the fact that we explicitly list that there are
> three steps, so the user knows that they need to scroll down.

OK

>> I love the Good and Bad Examples, really great idea!
>
> thanks!

While I am at it: keep in mind that green/red are colors perfect for
women to see, but not so good for about 20% of all men, since they are
colorblind and will not be able to distinguish those colors, it
appears brownish for most of the colorblind people. So maybe an icon
could help to distinguish it even better. A green "+" and a red "x"
could help, and those Oxygen icons already exist :)
>
>> The Details filed should be made mandatory. I get 50% of the reports
>> with no details at all, and we loose time with requests for info
>> because of that.
>
> Ah-ha! I can tell that you didn't actually try to submit a bug
> report. :)

I did, but only after commenting on it, so I wasn't aware. Also, since
I did fill out all fields (as I always do) I wouldn't have seen that
:) I should have done like the average users, seems I am already
biased and have that "good girl" behaviour to always fill in all
fields ;)

>> Another thumbs up for Reproducibility: absolutely great! But it should
>> not be a drop down menu, people are lazy and will just skip that and
>> we will get the default, while they didn't even try to reproduce it
>> most of the time. How about a list with Radio buttons with a mandatory
>> entry?
>
> Bug 218078. I'm undecided on the radio buttons, partly because the text
> from the drop down goes into the initial description for the report.

Yes, that makes sense, so not really needed. I am just worried about
the average dumb user who will find a way to not fill in stuff
correctly...

>> Steps to reproduce: Great again, and should be a mandatory field, too.
>> We will still have lazy buggers who will just put a "Don't know" in
>> it, but at least the will enter something.
>
> it is mandatory. I need to add logic that makes it not mandatory for
> feature requests though, as there's really no way to reproduce those
> since they don't exist yet. ;)

I don't think that is a big problem. They can just add "none". Also,
some wishes need a bit more explanation, so it's not uncommon for
people to add a use case to explain their wish better.

>> Severity: again, I wouldn't make it a drop down but a radio button
>> mandatory filed. BTW, the description of Minor doesn't sound correct:
>> "Minor - it's a bug a trivial bug to find and fix". Ahem, since Major
>> is on top, we will get all bugs reported as major, how about inverting
>> the selection with Wish on top? Also, the "trivial to fix" is
>> disputable, "trivial to find" should be enough in the description.
>> While some bugs are obvious, this doesn't make them necessarily minor
>> or easy to fix. Trust me, we have a few of those in Amarok...
>
> Normal is the default option that I get here (Firefox 3.5). Do you get
> something different?

No, but since I selected  something explicitly I wouldn't have seen
it. Using Chromium from a Kubuntu PPA here.

Still, the description of Minor looks awkward to me and I really don't
like the "trivial to fix" it suggests.

>> I strongly support the idea for an additional option: Usability! We
>> often get reports that are not exactly coding bugs, but usability
>> issues, and instead of pushing those to the wishlist where most devs
>> will never ever look at again, it would be really nice to have a
>> Usability category.
>
> I've come around to the thinking that usability bugs should not be
> classified as wishlist items, but as bugs with a severity of 'normal'
> instead. Bad usability is a bug, IMHO.
>
> However, a category is not a bad idea either. Added bug 218079 to look
> into this.

Thanks, that would really help, and I also agree that a usability
problem is a bug, not a wish.

>> Step 3: it would be nice to tell them that they are automatically
>> subscribed to the bugs they report, I get an average 10 alerts in my
>> inbox just because the reporter subscribes to his own bug after
>> report. I know it is obvious for us, but think with the user...
>
> oh, good idea! I hate it when people do this. There's something like
> this already in the form of the following text just below the 'Submit
> Bug Report' button:
>
> "That's it! You'll be notified by email about any progress that is made
> on fixing your bug. Thanks for contributing to KDE!"
>
> Is that not enough?

Apparently not. Starting that sentence with "You are now subscribed to
the bug and will be notified by email.." seems necessary, I really
hate it when people subscribe again. The same also happens when bugs
are marked as duplicates and the subscriptions are moved to the main
bug, I still get people subscribing again *sigh*

Thanks again for that great piece of work :)


Regards, Myriam.

-- 
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)