I'm beginning a series of short (trying to keep them in that 800-1000 word range) Bugzilla articles. The first few will be covering the new features we've recently gained in our latest Bugzilla upgrade. After that, I'd like to start doing "tips and tricks from a Bugzilla power user" (or some more catch title) articles. I'm posting the first installment of this new series here at the blog for your feedback before I try to get it run at mozillaZine and maybe other outlets. I'd appreciate any feedback you have (especially if it helps me trim a couple hundred words :-)
As most of you know, mozilla.org upgraded Bugzilla last month bringing us up to version 2.17.6 (and maybe a little bit more). It had been about a year since the previous upgrade and so there's lots new to love about this latest rev. While I'm sure there are scores of bug fixes and changes that make Bugzilla more robust, secure, and easier to set up and administer, this series isn't about all that wonderful backend work, it's is about a few of the new end-user features I think that b.m.o users will want to try out.
The first new feature, and I think the most exciting, is the new "Find a Specific Bug" interface. I regularly run two basic types of queries. The first is when I'm looking for a group of bugs like "all bugs with driver approval requests" or "bookmarks crasher bugs assigned to ben". These queries are about isolating a category of bugs, getting bug lists or bug counts. The second type of query I do is when I'm looking for a specific bug. Maybe I've seen the bug before and I'm trying to find it again, or maybe I'm about to report a new bug and want to make sure it isn't already reported. In those cases, it's a particular bug I'm looking for, not a category of bugs. The new "Find a Specific Bug" search feature makes this task much, much easier.
"Find a Specific Bug" uses MySQL "full-text search" functionality to match and sort on what it calls "relevance". The magic behind this "relevance" indexing and searching is available to any of you who want to ask the MySQL documentation or investigate the Bugzilla code that uses it. The important bit of information here is that the results of this "Find a Specific Bug" search are sorted with the most relevant matches at the top, just like Google! No more sorts on bug number or Component, or other not very helpful ordering. Now Bugzilla just puts the most likely match at the top of the list.
The interface to this feature is quite simple but the results are amazing. The first field you can set is the Status and the choices there are "open", "closed", and "all". Open bugs include the Unconfirmed, New, Assigned, and Reopened states. Closed includes Resolved and Verified. The second field is the Product select and that list should already be familiar to most of you, though it's nicely grouped by product categories in this interface. The last field, "Words", is where the magic happens. Punch a few words into this field and Bugzilla searches through the database of bug reports and returns a buglist of the top 200 most relevant results. 200 may sound like a long list of bugs to return, but I almost never have to move down past the first page of the buglist because my bug is almost always in the top few spots on the list.
This tool is designed to be simple to use and I would like to see all bug reporters doing at least one query here before submitting new bugs so I hope the interface doesn't get any more complex (I could actually see it getting simpler). But don't let it's simple interface fool you. The results are a big improvement over the standard buglist when your goal is to find one specific bug report
For the power users, I have two sets of tips. The first is for use in the "Find a Specific Bug" interface and it's called boolean full-text search. The "Words" field will accept a set of boolean operators, +, -, < >, ( ), ~, *, and ". The + operator, added to the front of a search term, says that word must be present in any bugs that make the results listing. The - flag appended to the front of the term excludes any bugs that contain that word. The < > are used to decrease and increase the relevance value that word adds to the overall relevance value of the phrase. The ( ) operators group words into subexpressions. The ~ is a negator which can be used to make a word's relevance contribution negative, pushing any matches on this word down the list some. The * can be appended to the end of a word to match all words starting with that string. Finally, " can be used to wrap a phrase so it matches only exactly as you typed it. When limiting your searches using the boolean operators, your results list may have fewer than 200 bugs.
The second, and even more powerful use of the full-text searching is in the " Advanced Querying Using Boolean Charts" interface located at the bottom of the "Advanced Search" page. Selecting "content" from the first select list, and "matches" from the second select gives you the same basic functionality you get from the search field on the "Find a Specific Bug" interface. The beauty of this "Advanced Search" is that you can combine the power of the full-text searching and relevance sorting with all of the other fields available to you in the "Advanced Search" interface. You could, for example, limit the results to a particular Status or Resolution, limit to one OS, or get specific with a single Component search.
The full-text searching is still in development and will hopefully provide even more accurate results as it is fine-tuned but it's already a big leap forward in ease of use. This new feature should really help us cut down the number of duplicate reports as well as make it a lot easier for the teams of contributors doing bug triage to weed out duplicate reports. For the next installment of my "Bugzilla Improvements" series, I'll be describing some of the new "Reporting and Charting" tools, so stay tuned to this space if you'd like to learn more about our improved bug graphs, tables, and charts.
typo 1st paragraph, last sentence: [... work, it's is about...]
p3, s1 - pucntuation usually goes inside closing quotes [...it calls "relevance."], also [... assigned to ben."] in p2
you might not need to keep using quotes on "Find a Specific Bug" after the first time; capitalization should be enough. likewise with a few other phrases throughout.
p5. last sent. - no period [...specific bug report]
p6, s6 - [...the relevance value that word adds to the overall relevance value of the phrase.] could be condensed, or the sentence reworked.
in p4, sometimes you quote the the field name, other times you quote the choices.
p7 - extra space inside quote [...in the " Advanced Querying...]
several spots are a little wordy/redundant and could probably be tightened up a little, but not sure if it's a couple hundred words' worth: [200 may sound like a long list(( of bugs to return)), but I almost never have to move down past the first page(( of the buglist)) because my bug is almost always in the top few spots(( on the list)).]
i also might expect to see a link to b.m.o at the front, in addition to/instead of 4 paragraphs in.
anyway, informative article - learned some new things. looking forward to the charting one.
Posted by: miahz on March 11, 2004 01:46 PM