[Bugsquad] New Bug Reporting Tool needs wider testing

[Matt Rogers]

On Thursday 10 December 2009 03:40:29 Myriam Schweingruber wrote:
> 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 :)
> 

i'm glad I'm not in the 20% of men that are colorblind. bug 218119.

> >> 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 ;)
> 

yeah, i do the same thing. silly good behavior! :)

> >> 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.
> 

Indeed. There's a typo there and I think I may just take that whole 'minor' 
field out all together. this is bug 218118.

> >> 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*
> 

agreed. this is bug 218120.

> Thanks again for that great piece of work :)
> 
> 
> Regards, Myriam.
> 

Thanks even more for your feedback!
-- 
Matt