[Bugsquad] New Bug Reporting Tool needs wider testing

[Myriam Schweingruber]

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?

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.

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.

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

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.

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?

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.

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

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.

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

I hope you can use my input. Thanks for the great 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)