260856 - "Find a specific bug" is confusing and not very useful because of its secret use of probability-based relevance and allowing disjunctions

Status: RESOLVED WONTFIX

(Bugzilla :: Query/Bug List, enhancement)

Description

[Péter Pallos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

The search engine of BugZilla doesn't allow to use more than one keywords in AND
relation. Nevertheless if it's possible, it isn't documented at all.
You should also mention the feature of connecting keywords by quotation marks.
It could significantly raise the efficiency of the search engine and decrease
the number of duplicate bug reports.

Reproducible: Always
Steps to Reproduce:

Comment 1

[timeless]

please include steps to reproduce, i can only think of 5 or maybe 10 entrypoints
to search bugzilla, you don't want me to guess which one you used.

Comment 2

[Péter Pallos]

Steps to reproduce:

1. Open bugzilla.mozilla.org
2. Select "Report a bug"
3. Select "Browser"
4. Search for "SMTP" - there are some hits in the list
5. Search for "SMTP XML" without quotes - much more items are found
6. Search for "SMTP+XML" without quotes - approximately the same number of hits
7. Search for "SMTP XML" with quotes - Zarro Boogs found

My conclusion is the following
- there is always OR relation between the searching keywords
- terms can be connected by quotes, but it's an undocumented feature of the
search engine

Comment 3

[Dave Miller [:justdave]]

ok, that's the search embedded in the guided bug entry form, which is Gerv's
baby.  CCing him for comment.

Comment 4

[Gervase Markham [:gerv]]

The Helper appears to now use Myk's "find a specific bug" enhancement. CCing him
for a comment.

Gerv

Comment 5

[Myk Melez [:myk] [@mykmelez]]

It's a fulltext search, not a boolean search, and thus neither a union (AND) nor
an intersection (OR) (or perhaps you might say it's the probability-ordered
intersection of the union and the intersection of the search terms).  Per the
example in comment two, it means bugs with both "SMTP" and "XML" terms appear
first in the list, although bugs with either term appear.  This is as it should
be, since it orders bugs in order of likelihood of being the one being sought out.

Literal phrase searches aren't a magic bullet for improving search results, as
far as I know, and I'm not keen to explain operators to the relatively
inexperienced users using the Bugzilla helper, so I don't think we want to do
this for that page, but it could make sense to let the more experienced users
accessing the "find a specific bug" page know about them.

Comment 6

[Stephen Lee]

Just the inclusion of something like "(XX% Relevance)" next to each bug found 
this way would do a lot to educate a user about what is happening here IMHO.

At present, it throws up 200 bugs with no indication to the user that most of 
these are likely to be irrelevant, apart from an easy-to-miss comment on the 
previous page.

Is there a RFE about adding a relevance column? I'm sure I saw one before but 
can't seem to find it now.

Comment 7

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 8

[Frédéric Buclin]

*** Bug 241409 has been marked as a duplicate of this bug. ***

Comment 9

[A. Karl Kornel]

Suggest confirming with a summary change to reflect relevance instead of boolean operators.  Also, 
this is probably a Future idea; not a major problem.

Comment 10

[A. Karl Kornel]

It seems we already have a relevance column (see bug 237176), but it's not publicly accessible.  That 
should probably change.

Comment 12

[l_v_brienen]

If the relevance column is made public, it should also contain a snippet indicating WHY a bug in the list is considered relevant. Could help with finding flaws in the search algorithm as well.

Comment 15

[Mark Clements]

Note that bug 864283 has been marked as a duplicate of this, but it is reporting a very different symptom.  From reading between the lines, it may be that they may stem from the same underlying cause (use of a MySQL's FULLTEXT index, and the subsequent limitations of that) but that does not necessarily mean they are the same bug.  I would have preferred that this were made a dependency of that bug, but perhaps this way is easier for you to manage.

In particular, bug 864283 is clearly a bug in Bugzilla (simple search not finding things that it obviously should be finding) whereas this bug has been marked as an enhancement.

Also, as per bug 864283 comment 1, the solution to that bug is not necessarily to fix the underlying problem - it could simply be to report the limitation so that the user is clear what has happened (i.e. to display "The following search terms were too short so have been omitted" with the results, which makes it clear why a search for "rss" returns zero results despite having open bugs like "Implement rss feed"), which is another reason why this should not have been duped.

Comment 16

[Francesca Ciceri [:madamezou]]

Hi,

trying to reproduce this, but it's not clear to me if the reporter is speaking about the summary search or not (the steps to reproduce it are not the same anymore, apparently). If so, and the relevance column had been added as per Bug 237176, is there any chance to see it made public? It could help with the initial problem, as suggested in comment 6.

@myk: is this correct? and is possible to do it?

Cheers,
Francesca

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

I filed bug 1020388 to improve the documentation on how the summary search or "find a specific bug" works.

Comment 18

[:glob ✱]

every search engine uses "secret probability-based relevance".  exposing this to end-users would be  confusing.

if the issues is a lack of documentation, then bug 1020388 sounds like the right action here.

Comment 19

[l_v_brienen]

As it is now it's even more confusing as most attempts at finding a specific bug give ONLY false-positives. what is desired is a little preview of the bug reports that allow the end user to determine which have at least a chance of being truly relevant.

PS IMHO it's better to call it 'secret improbability-based relevance'.

Comment 20

[l_v_brienen]

(In reply to l_v_brienen from comment #19)
> As it is now it's even more confusing as most attempts at finding a specific
> bug give ONLY false-positives. what is desired is a little preview of the
> bug reports that allow the end user to determine which have at least a
> chance of being truly relevant.
> 
> PS IMHO it's better to call it 'secret improbability-based relevance'.

with preview i don't mean summary, but more a preview of what portion 'makes it relevant' in the search engines opinion.
PS at the moment I'm getting WAY better (and easier to optimize) results from searching the site through Google than through bugzilla's own search-engine.