[Bugsquad] New Bug Reporting Tool needs wider testing

[Matt Rogers]

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:
> > Hi,
> >
> > If you go to bugstest.kde.org/enter_bug.cgi?format=guided then you'll
> > able to see (after picking a product, of course) what the new bug
> > reporting tool is going to look like.
> >
> > Please give it a test, and provide any feedback that you can. Did I miss
> > something? Did it not work right, etc?
> 
> OK, here we go:
> 
> In step 1, it displays the last 2 days of bug reporting, right? I know
> that this can be a very tiny list for some projects, but the list can
> be quite huge for projects like Amarok or Plasma.  So I looked on
> where to enter th bug description or keywords and had a hell of a time
> to find the field: Shouldn't that field be above and have some bold
> letters to draw attention?
> 

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?

> Also, the version numbers for KDE and the application should be set
> before a query for duplicates is done, it would help narrowing down
> the list and we could filter out reports for outdated versions. I for
> now don't even consider reports in Amarok that are older than version
> 2.2, since there are so many changes and improvements between each
> release that it is pretty useless to get reports for anything older.
> Unfortunately the enter mask still lists *all* Amarok versions ever
> reported and still try to find out how I could narrow this down to the
> last two releases + git. I know that all the old bugs are still in the
> database, but couldn't at least the reports closed as unmaintained be
> filtered out by default so we have a smaller version list? I don't see
> why these have to stay in the database at all, especially over time.
> 

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.


> Step 2: I love the way the last version of KDE is on top in the drop
> down menu, but the last version in the application version is at the
> bottom, both on top would be much more consistent. Same thing as
> above: the bug description field should come in Step one, before the
> duplicate list is checked IMHO. Also, splitting of the website for the
> different steps narrows down the height. I know for sure people do not
> scroll, one of the reasons we almost never get Application version
> numbers with the current reports, they usually can't find it at the
> very bottom of the page as it is now.
> 

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.


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

thanks!

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

The validation on the page currently doesn't do anything with regards to
how long the details should be, but people aren't allowed to leave that
field blank.

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

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

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

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

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

> I hope you can use my input. Thanks for the great work!
> 
> 
> Regards, Myriam.

Thanks for the feedback!
--
Matt