[Bugsquad] New Bug Reporting Tool needs wider testing

[Matt Rogers]

On Sun, 2009-12-06 at 09:40 -0300, Darío Andrés wrote:
> On Sat, Dec 5, 2009 at 11:10 PM, 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?
> >
> > I'm hoping to have the thing finalized around Christmas time, but it
> > needs a few more eyes looking at it.
> >
> > Please CC me on any replies, I'm not subscribed.
> >
> 
> Hi Matt: first of all: nice work!
> I like the new layout and how you show the "most duplicated reports"
> (too bad it doesn't work on bugstest because the DB is old)
> I also like the bad/good examples.. specially the one about "konqueror
> sucks"... we should encourage the user to not write shit nor insults
> 
> Some nitpicks and minor improvements I could mention:
> 
> - In the manual duplicates search (keywords lineedit), I wasn't really
> expecting to see the search results in the iframe above the keyword
> input itself.. (I was expecting a new window to be opened).
>   I prefer that user doesn't need to change the page to check the
> search results, but looking above wasn't really intuitive.. may be the
> keywords input should appear on top (but if we do that we need to
> modify the workflow or something...)
>   It could be discussed
> 
> - In the manual duplicate search, it seems that the results are shown
> with plain HTML (I guess this is caused because you are stripping the
> header/sidebar or fetching the buglist with a special format) (This is
> a really a small nitpick.....)
> 

I can't say that i'm really impressed with the duplicate search either.
I wonder if moving that text box to the top would help with that.


> - The help for keywords may include some more accurate examples ("copy
> paste" will generate too much results I think :) ) (may be some
> examples like "kmail composer copy paste", "plasma notes big font" ).
> You could also use the "Bad/Good example (with red and green; I really
> like that)
> 

Done


> - About the component select, should a small text added saying "If you
> don't know what to choose, leave "general" " , or something like that
> ?
> 

Done

> - About the app and KDE versions, may be it is the time to add some
> link to "Which version am I using?" (may be to a techbase page or
> someplace where we explain the users how to check their versions...
> ("Help.. About KDE" or "kde4-config --version" ....))
> 

bug 218070

> - Software distribution method could also get some minor help like
> ("What is your operating system or GNU/Linux distribution")
> 

bug 218072

> - Reproducibility's default should be "haven't tried to reproduce it"
> (I think) as this is the common case... we could also add some help or
> a link saying *why is it important for the bug to be reproducible" and
> briefly explaining how to proceed.
> 

bug 218073

> - Could "Steps to reproduce" appear only if the reproducibility option
> is "sometimes"/"always" ... (using JS?)
> 

bug 218074

> - Should the page have a main title "Enter new bug report form" (or
> whatever text you prefer), to be above "Step 1/3 ..." (mh, it seems
> that is already included below the KDE logo.. I'm used to the
> "classic" bugzilla style")
> 

I think I'll address this when I change the current layout of
bugs.kde.org

> Sorry about so much tiny complains, but I think if we are going to
> improve the things we could also implement some other little things to
> *make it perfect*
> 
> Hope it helps
> I'm going to analyze it a bit more and try to get more feedback
> 
> Thanks!
> 
> Cheers
> Darío A.
> 
> > Thanks

Thanks for the feedback!.

Did you try to submit a bug using this form at all? Was it easy? fun?
useful? and/or non-time wasting?
--
Matt