[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-documentation
Subject:    Re: Make it easier to find bugs in Bugzilla
From:       "Simon P. Lucy" <slucy () objectivesw ! co ! uk>
Date:       2001-02-21 16:36:56
[Download RAW message or body]

At 16:10 21/02/2001 +0100, Andreas Franke wrote:
> > I've voted for it.
>
>Thanks.
>
> > I have some reservations about using substrings when
> > looking for bugs, unless the user uses the same terms they are unlikely to
> > hit on substrings
>
>Sorry, I don't understand. If you search for substrings, you only get _more_
>hits than a search for "all words" would give you. E.g. if you search for
>"wheel mouse", you get hits for "wheel mouse", "wheelmouse" and "mousewheel".
>What's the problem with this? Too many hits? If that's the problem you can 
>use
>"#mouse #wheel" to search for these _words_. Ok, that's not documented, maybe
>I should do it?

Oh you should definitely document the '#' as it isn't :-).  Substrings are 
bad if people use phrases and those phrases are searched for because its 
unlikely that people will use the same phraseology (I think this is the 
main reason for Bugzilla general searches failing for users).   That's how 
the current Bugzilla search works, if yours doesn't then its an even 
greater reason for using it.


>Replacing "substring" with "allwords" everywhere would be easy, but I'm not
>sure if that's what you want. Let me quote from bug 65190:
>
> >Both "(case-insensitive) substring" and "all words" comparison types are not
> >optimal solutions if you want to query for several words:
> >
> >>> The problem with the Simple one ["(case-insensitive) substring"]
> >>> is that, if people put in a few words relevant to their bug, it's
> >>> reasonably unlikely that those words will appear in that exact order
> >>> in the summary. Could we do "all words" instead?
> >>
> >>i've never found "all words" to be useful, because it won't let you type
> >>"bookmarklet" and get hits for both "bookmarklet" and "bookmarklets".
> >
> >C.Begle's SimpleSearch 
> <http://www.mozilla.org/quality/help/simplesearch.html>
> >solves this problem by generating boolean charts on the fly.
>
> > even if they use stems of words (itself not user friendly).
>
>That's true. Solution: For a lecture about information retrieval, I had to
>implement a "porter-stemmer", a program that computes stems automatically
>using the "Porter-Algorithm" - a standard procedure. Actually, I did not
>implement it but downloaded an implementation from the web. It's a C program,
>and it's very fast. As soon as someone ports the tool to perl (from
>javascript) and thus turns it into a server-side program, it should be 
>easy to
>integrate this stemmer and do it automatically (at least on the default,
>non-Hackers page).

Yes if I remember rightly Porter works well with nouns, adverbs and 
adjectives but less well with passively tensed verbs.  Have you raised a 
Help Wanted bug with the C source as an attachment?  If you do that I might 
even be moved myself to do it :-)


> > I find that using all words is easier for novices (and for
> > myself if truth be told).
>
>Maybe then you prefer a simple "all words in summary" form? That's a
>one-liner, well, almost. Would it be ok for you if there was an "all words in
>summary" quicksearch box on the bugzilla front page, with an "[Help]" link
>pointing to the QuickSearch page mainly as it is now (but noting the
>difference between the two)?

Hmmm, actually the summary field (if that's what you mean), is almost 
useless for searching, other than maybe filtering by component if that 
applies I tend to search the description field it generally repeats what is 
in the summary anyway.


> > What I'd really like is a proper Search pane for
> > Bugzilla with the main elements of your quick search in it.
>
>Something like the "Medium Form" link at the bottom of the Quicksearch Page?
>Or something like 
>http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4482
>  from bug 16775?

Perhaps something in between the two :-).  But really your quicksearch is 
fine together with some persistent switches for +DUP ALL/FIXED as well as a 
component filter would suit me down to the ground.

Oh there is my continual bugbear of american spelling :-), a transposer 
that searched for s|z and l|ll would help a lot.

Simon



>Cheers,
>Andreas

===================================================
If I'd known I would spend so much time sorting and rearranging boxes
I'd have paid more attention at kindergarten

S.P. Lucy

[prev in list] [next in list] [prev in thread] [next in thread]