Closed Bug 194116 Opened 22 years ago Closed 13 years ago

Decide best default query for b.m.o.

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: gerv, Assigned: gerv)

References

Details

Attachments

(2 files, 1 obsolete file)

script v2: removes private fields and most conditions appearing once or twice
5.29 KB, text/plain
Details
report from script
31.98 KB, text/html
Details
We need to decide what the best default query is for b.m.o. We also need to work out the best rationale for making that decision - who the default should be aimed at, and what will they be most likely to be trying to find. Queries with their hats in the ring: 1) status=NEW/ASSIGNED/REOPENED (the current default) 2) resolution=--- (all open bugs) 3) resolution=DUPLICATE/--- (all open bugs and all dupes) (This bug should not cover whether we should default to a particular set of Products. That has separate technical issues involved.) Please add a comment saying: - Who you think the default query should be aimed at - What sort of things you think they will be searching for - What default query makes it most likely that they will find it Gerv
I should add that the choice is not restricted to the above three queries: feel free to propose another alternative. For ease of reference, please give it the next available number. Gerv
Status: NEW → ASSIGNED
Since you can change your own default query, and developers are likely to already have a Bugzilla account and can therefore change theirs, the global default query should be aimed at new users who have just obtained a Bugzilla account. The idea being that the general public is probably more concerned with discovering whether the bug they're about to file has already been reported. I'd vote for #3 on that basis. The unfortunate side effect of that is you'll get bugs that were resolved duplicate of bugs that were fixed 2 or 3 years ago, but there's not much else we can do about that until the "end of the dupe chain" bug is fixed, and we can make it only show bugs that are eventual duplicates of a bug that's still open.
One way to mitigate the problem that Dave points out is to set the default to be sorting by bug number, descending - that way, the more recently filed bugs are at the top, and the older, irrelevant ones are further down. Gerv
I didn't know reverse sorting on any buglist column was possible. I certainly don't know how to do that (although myk says that he thinks you can hack the URL to get the reverse sort). I support adding dupes to the default search. I don't even consider it a newbie approach. I almost never search for a bug without including dupes because I find it's the fastest way to get at a bug in bmo (and I don't consider myself a newbie). Power users will find this a more effective default query too.
I second (third?) Dave's comment. This argument has been had many times in this form and regarding the My Bugs link. It's my belief that these should be configured in a way that is most useful to new users. Developers (eg, those most familiar with Bugzilla) who don't want to see UNCONFIRMED bugs can set their own default query/saved query. In fact, I'd be suprised if the majority of developers haven't modified their default query and set up at least one query in the footer. I know I set my default to be option 3 with the addition of selecting the Bugzilla product. I also have specialized saved queries like "My ASSIGNED Bugs", "Bugzilla UNCONFIRMED", "Bugzilla Docs", etc. We should probably also re-evaluate this in the default Bugzilla distribution, as well.
> In fact, I'd be suprised if the majority of developers haven't modified their > default query and set up at least one query in the footer. http://www.gerv.net/presentations/fosdem2003/slide03.html - Stored queries (usage: 2.5%, 2165 of 85493 accounts) - Change default query (usage: 0.67%, 580 of 85493 accounts) But I don't know what percentage of _active_ accounts those two represent. However, on a sample of 1, I haven't changed my default query. > We should probably also re-evaluate this in the default Bugzilla distribution, > as well. I want to publicise this bug further (a news posting problem has prevented me doing that yet) so that Mozilla contributors can have their say. If we decide to change to somethind different, we can evaluate that feedback and see if we want to make the change in the base. Gerv
Reverse sorts involve changing the url to add ' desc' after the sort order - our security code accepts that sort of stuff as valid before passing the string into the db.
Indeed. And if it turns out (as I suspect it might) that adding "sort=bug_id+desc" to the default query string doesn't in fact produce the right result, we can just add another option to the sort dropdown so that it will. Descending bug number would be quite popular, I suspect - for reasons already discussed. Gerv
Well I think Dave has got it right in comment 2. From Gerv's numbers it appears that many people haven't changed their default query, but I'm not sure that takes away from Dave's point about experienced vs new users. I'm an experienced user and I haven't changed by default query - I do frequently change the query to be something like #2 or #3, but I also use the default #1. That is, I'm still making the choice even if I haven't set a default. If the new default is inconvenient for experienced users, they will know to change it (or they will correct it manually), if it's not good for new users, they will just run the wrong query. (I didn't know about the reverse sort thing either - that's useful to know. There should be some 'UI' for that with the column headings or something - is there a bug filed?)
I also think #3 (all open/dupes) is the best default, but would add that sorting by "last changed" is often much more effective than bug number. That way, older bugs that are relevant would show up along with the newer ones. Old dead bugs would still be separate. the default should really be targetted at the newbies and they're not going to think of searching dupes.
Last changed sort is a very wise idea. Gerv
Does Bugzilla or its server keep track of queries used (could be determined from a refererl list to show_bug.cgi maybe)? That could tell what types of queries are used most often.
The webserver logs would probably tell us; but converting those URLs into useful information is hard. Anyway, there's a world of difference between the queries people did and the queries they _wanted_ to do - hence this bug. Any analysis of the logs would, I suspect, show a big peak at "NEW/ASSIGNED/REOPENED" and something in the Summary box. Gerbv
Before we decide what the default query should be, we need to figure out who we're targeting. Focusing on new users sounds nice--after all, they need the most help, right? In reality, though, it's not a good idea for a variety of reasons: 1. Although the ratio of new to experienced user accounts may be high, the ratio of new to experienced use is much lower. In other words, the majority of user accounts may be new, but experienced users use Bugzilla the most. We should optimize the interface for the majority of use, not users, since that makes Bugzilla useful as much of the time as possible. 2. New users don't want to stay new, and optimizing the interface for them makes it harder for them to understand it better and insults them once they do. 3. A preference is not an excuse for a bad default. Setting a preference is a pain, and most users--even experienced ones--don't do it until it is absolutely necessary and after avoiding it for a while. Making people change their default query once they understand how to use Bugzilla is punishing them for doing something right. 4. Our most productive community members (developers, QA, managers, etc.) are experienced users, and we have an obligation to keep them as productive as possible. Instead of optimizing for new users, we should optimize for experienced users and provide assistance (guided tours, contextual help, etc.) to help new users develop into experienced users. We should also note that Bugzilla wears two fairly distinct hats and define interfaces appropriately. On the one hand Bugzilla is a productivity application--project contributors use it all day every day to manage their bugs and communicate with their collaborators. On the other hand Bugzilla is an itinerant application--end-users come to it once in a while to complain about a bug that's bugging them. The interface for the productivity group should be as efficient as possible, and the interface for the itinerant group should be as understandable. These two goals are somewhat contradictory, and we can only satisfy them fully with two interfaces and good mechanisms for directing users to one or the other. Fortunately, that's what we already have: a complex query interface for productivity users and a simple query interface built into the Bugzilla Helper for itinerant users. The latter interface is where we should focus the query to work best for new users. Note that I'm not saying we shouldn't change the default query on the regular query page; evaluating and optimizing that query is a great idea. I'm also not saying we should optimize it for rank experts; the handful of users who are Bugzilla whizzes (like Asa) can fend for themselves well enough. What I'm saying is that when we evaluate the default we need to keep the right audience in mind, and that audience for the standard query page is experienced productivity users.
That's all well and good once we actually have two separate query interfaces that can be used (there's a bug for that, and it's pretty easily possible now with our current infrastructure, but it's not there yet). In the mean time, the quantity of duplicates is going up like a rocket because the default query doesn't search for the bugs that the itinerant users need to find in order to avoid creating dupes.
I personally believe that query 3), modified to sort either by reverse bug number or last_changed, is the best default, both for new and experienced users. In as much as there is a "query most people do", that query is "Find the bug about X", for both classes of users, where X is a couple of words they remember, which they stuff into the summary line. The current default query attempts to help people making such a query - "type into the Summary line and hit search, and you'll find the bug if it's still open." However, sometimes the bug isn't still open, or your words are slightly wrong - in that case, query 3) achieves the same job better. I would point out, though, that I suspect the simple query interface built into the Bugzilla Helper is not used all that much (although I agree that fixing it along the same lines is a good idea.) Unlike the guided enter_bug page, which we linked in loads of places and now force newbies to use, all the search links throughout Bugzilla all point to the standard form. As Myk says, Bugzilla has a wide variety of users, whose focus is different - project management, hacking, QA. The only way we can keep them all happy is to tell them they should define the default which works for them (something many people don't get around to, but might if prodded.) That's why it's configurable. I'm sure we all agree that any change should be preceded by announcements etc. to tell people it's coming. Gerv
Dave: >In the mean time, the quantity of duplicates is going up like a rocket because >the default query doesn't search for the bugs that the itinerant users need to >find in order to avoid creating dupes. The default query can't be to blame for any recent acceleration in duplicates since it hasn't changed for years, but in any case we should be directing itinerant users to the Bugzilla Helper for querying and bug entry. Itinerant users stumbling upon the regular query page is a bug in our guiding mechanisms. Gerv: >I personally believe that query 3), modified to sort either by reverse bug >number or last_changed, is the best default, both for new and experienced >users. I suspect you may be right--your analysis sounds reasonable--but I'd like to hear from more of our experienced users (or see some data analysis) before making the change. >The only way we can keep them all happy is to tell them they should define the >default which works for them (something many people don't get around to, but >might if prodded.) That's why it's configurable. I don't think there's any way to make all our users happy, especially not by telling them to do more configuration work, but I agree with your general point: if we decide to change the query we should tell users in advance and let them know they can opt out of it by setting their default query.
> but I'd like to hear from more of our experienced users (or see some data > analysis) before making the change. I'm not sure how we can do any meaningful data analysis without making the change for a period and seeing what happens to the DUP filing rate (see my previous comment.) I have invited newsgroup users to comment in this bug; let's leave it a couple of days and see if anyone else has a useful contribution. Gerv
One thing we could do is analyze changes users have made to their default query to see if there are patterns to those modifications. This approach has limitations but would provide some useful info.
We could do that. However, what that would tell us is the preferred default query of the 0.67% of elite Bugzilla users who have bothered to change it - and it is precisely these people that the standard default is not necessarily aimed at. Also, writing some tool to analyse 580 query strings and characterise them would, I suspect, be a fairly significant investment of time. Gerv
My guess is common changes in default queries are good candidates for experienced users too while uncommon ones aren't, and I don't think an analyzer would be that hard to write since it's just a matter of counting occurrences of single and matching parameter/value combinations. It might take a long time to run, but that's ok since it only needs to be run once.
Another data point: MozillaNews' Bugzilla Search page gives you three options for the set of bugs to search: - Open Bugs (our option 2) - Open Bugs + Dupes (our option 3) - All Bugs Open and All are radio buttons, but dupes is a checkbox associated with open, which might suggest that it's a common modification to an "All open bugs" search. http://www.mozillanews.org/search_bugzilla.php3 Regarding the stored query analysis: I have no objection to it being done, if someone has the time in the near future, but if it's going to take a month before anyone does have time, I don't think it's a requirement to wait before making any change this discussion might think desirable. Gerv
I am against resolution=dupe/--- A new user would not know that resolution=--- means open bugs and will likely be confused. Having three buttons [all open bugs], [all open bugs & duplicates], and [all bugs] might be better. However, that would assume that people already know the reasons that they should search for duplicates, and there are no such reason. That duplicates are a problem does not mean search should default to include duplicates. Just ask yourself this question "do I default my search to include duplicates, or is search for duplicates useful `sometimes'?" A better solution would be, at each search result page, having a line saying "can't find what you want to find, try <a>include duplicates</a>" My take: resolve this bug as WONTFIX
Yes, the search page at MozillaNews does indeed use the "dupes" checkbox as a modifier. Although I've requested in our next update to that part of the site (currently we're working on improvments/bugfixes to the Bonsai Watch tool) is the ability to also add an UNCO modifier. I might suggest adding UNCO to the default search at least as an option (like a checkbox). This will be good for new users, as Myk pointed out, as they're the ones who file a lot of bugs. If they see someone else has reported it, even if it's UNCO (they're not going to know/care about the difference between NEW and UNCO), they won't file dupes, and maybe offer additional info.
I think we've already established that the query shouldn't be optimized for new users (or at least no one has disagreed with me about it yet). It doesn't matter that duplicate searches are only sometimes useful, since no default query option can always be right (since needs differ and cannot always be anticipated). A default query option is one that satisfies the most common user goals. The question for this bug to answer is what those are.
> I think we've already established that the query shouldn't be optimized for new > users (or at least no one has disagreed with me about it yet). Well, I mostly disagree, but I wasn't going to repeat myself. I think it should not be optimized ONLY for new users, but I think the optimal search query default is not experience-dependent (open/dupe is what I always do, and I think it would also be the best for new users). IMO, the open/dupe default is bad only for people that are not really "searching", but rather trying to get a list of bugs to operate on (triage, work on, etc). But optimizing for that is not that useful because those queries are going to have to be customized anyway (I have saved queries for stuff like that).
your call, of course, but as I said back in comment 9, I do think aiming at new users (and probably anyone else trying to find a specific bug rather than pulling up a list of some kind) is a good idea, which is why I think including dupes is a good idea. Doing triaging stuff, I'm either pulling up a list of UNCO bugs in a certain date range (or some other list that needs triaging), or I'm looking for a specific bug...
My take is that we should either aim the default query toward new users or provide a much simplier search page for new users.
> (or at least no one has disagreed with me about it yet). Er... I disagree :-). If you search Bugzilla when not logged in, the default search is what you get. Anyone who does that, and is scared by the complexity of the form, may well enter some words in the summary box and hit search (after all, that's the point.) I believe this is a good argument for having the search optimised for a) general "bug finding" (in a QA/bug filer context) b) searches where people just type stuff into the summary box If we can find a search which works well in this context, it is good for newbies, because it's simple, but it's also good for more experienced people, because it lets them be lazy. I think there's a strong argument that ---/dup is the best simple search for these criteria. > Having three buttons [all open bugs], > [all open bugs & duplicates], and [all bugs] might be better. and > I might suggest adding UNCO to the default search at least as an option (like > a checkbox). This bug's scope does not include changing the UI of the query page. Also, we are looking for a _default_, not another set of options to add :-) > a much simplier search page for new users. There is a bug opened on that as well. Gerv
Although I'm in the 0.67% with a default query, I often query from public computers and from that point of view would prefer a default query that could be undone in the least amount of clicks (right now it's click, ctrl-click in the status field to reset that), and thus would be opposed against setting a resolution for the default query (as it'd add the same amount of clicks) :) However, realitistically I _do_ think DUP/-- would be the most useful option for the largest amount of users. (btw, an issue for some other bug no doubt, but I never even knew -- existed before last month due to it being at the end of the list.) Sorting by last changed decending is what I always do, and I think this would be most useful both for regular users ("what happened to that bug I looked at two days ago?") and for new users due to high profile bugs drifting near the top of the list most of the time. Hmm, maybe cut out the UNCO's though, to remove the clutter from the top of the list. So I'd go for status=NEW/ASSIGNED/REOPENED/RESOLVED/VERIFIED + resolution=DUPLICATE/-- (all confirmed open bugs and all dupes)
> thus would be opposed against setting a > resolution for the default query (as it'd add the same amount of clicks) :) I don't think this should be a factor but, regardless of that, it would not add clicks. Selecting ---/DUP in Resolution (and nothing in Status) is the same number of clicks as now. Gerv
Ok, so people disagree, but I still think they don't address my points. That may be irrelevant, however, if the best default query for experienced users is also good for new users, as it appears might be the case. >If you search Bugzilla when not logged in, the default search is what you get. >Anyone who does that, and is scared by the complexity of the form, may well >enter some words in the summary box and hit search This sounds more like an argument for a slim search line at the top of the query page with a few basic fields for finding most bugs, f.e.: _______ ________ __________________ ________ |------V| |-------V| | | | | Product: | | Status: | | Summary: | | | Search | |_______| |________| |__________________| |________| (Where product is a single-select drop-down menu with the list of products, status is a single-select drop-down menu with "open + dupes", "open", "closed", or "all" options, and summary does a "contains all the words/strings" search). >This bug's scope does not include changing the UI of the query page. Also, we >are looking for a _default_, not another set of options to add :-) Why not? The problem is not the default query per se, it's not being able to find bugs, so the solution should be whatever helps them.
> >This bug's scope does not include changing the UI of the query page. Also, we > >are looking for a _default_, not another set of options to add :-) > > Why not? The problem is not the default query per se, it's not being able to > find bugs, so the solution should be whatever helps them. The query page needs a default query. This bug is about deciding what that is, given the situation we are in now. If, later, someone goes away and implements natural language search, or an intermediate level search page, or whatever, then perhaps there'll be a case for changing it to something different (or perhaps not; it depends what's done.) But we are where we are now, and I think there's a strong body of opinion which thinks that the current default query should be ---/DUP, for a number of reasons enumerated here. The thing is, if we could prove that this default was also good for experienced users, then we'd all agree and everyone would be happy. But how do we provide that proof? What's the downside of changing it (with notice etc. etc.)? If it really is _worse_ than the current one, then we'll get complaints ("I can never find anything any more.") If that happens, we'll have to think again. But I really think it's very unlikely that this change will make things worse, and a lot of people think it'll make things better. Gerv
It makes no sense to limit the scope of this bug to a single solution to the problem when some solutions may influence decisions about others. I'm particularly concerned about changing the default before adding a simpler search form, since that form may mean we need a new default, and we shouldn't change the default twice unnecessarily. We should instead address the problem itself, identify its solutions, prioritize them, and implement them. >The thing is, if we could prove that this default was also good for experienced >users, then we'd all agree and everyone would be happy. But how do we provide >that proof? You don't need proof, just intuition and evidence (when available). You've already provided some intuition, but I don't understand why you don't want to provide any evidence when some can be obtained relatively easily. At the very least, we should take the following two steps: 1. Change the default query on the Bugzilla helper and see if it changes the rate of duplicates being filed. 2. Generate a report of default query customizations and analyze it for clues to useful default query modifications. And maybe a third: 3. Post a message requesting feedback from users on the specific queries under consideration. None of these methods provides absolute proof. The first one targets only new users; the second is a limited sample and may be weighted towards experts; and the third tells us what squeaky users think is good for them, which may be different from what's actually good for them or what's good for non-squeaky users. Still, it's worth taking these steps to help us make a good decision. I took a stab at the second step with a simple script (attached) that counts occurrences of conditions in default queries on b.m.o. I'll post the results as soon as I sanitize them. >What's the downside of changing it (with notice etc. etc.)? The downside is disgruntling users unnecessarily. Disgruntling users is fine if the new way is better, but we should do what we can to determine that first.
> 1. Change the default query on the Bugzilla helper and see if it changes the > rate of duplicates being filed. There are two possible outcomes here: - The rate changes. How do we know the improvement was down to this change? - The rate doesn't change. How do we know if enough people use that form to make a difference? I'm not adverse to this change, but I can't see how we can get useful data out of it for solving this problem. > 3. Post a message requesting feedback from users on the specific queries under > consideration. I have - that's what this bug is. I posted a newsgroup message in several groups inviting people to come and give their views on the queries under consideration. Looking forward to the results of your script :-) Gerv
This version excludes fields containing private data and conditions that only appear once or twice (except for bug_status and resolution, the fields of greatestt interest).
Attachment #116234 - Attachment is obsolete: true
Attached file report from script —
Here's the report. >There are two possible outcomes here: >- The rate changes. How do we know the improvement was down to this change? >- The rate doesn't change. How do we know if enough people use that form to >make a difference? > >I'm not adverse to this change, but I can't see how we can get useful data out >of it for solving this problem. Useful data is relative, since no data is perfect. If the rate change is great enough, and no other factors present themselves, we can reasonably induce that the default query change was the cause. If the rate doesn't change, then the data won't tell us much unless we measure how many queries were done to make sure it's a large enough sample, which shouldn't be hard since we can flag those queries with something bizarre in the URL. > 3. Post a message requesting feedback from users on the specific queries under > consideration. >I have - that's what this bug is. I mean a message that says what the queries are instead of just inviting people to the bug.
Here are some thoughts from me: > Fields > > product 194 It seems that the most common change is to restrict by product. There is an argument for us doing this by default (another bug), but we can't do it until we can order Browser and MailNews at the top of the list, so people can see that they are selected. > Conditions > > resolution=---,DUPLICATE 6 So not many people choose this as their default. But it's certainly not the most obvious choice for a default - it took us a while, and some analysis of the way people find bugs and what they are looking for, to even suggest it. > rep_platform=All 36 > op_sys=All 42 This and other entries seem to indicate a level of confusion about the "All" status. It's unlikely that someone would actually want a default query which only showed os=All bugs; I postulate that they meant "All OSes". Should we be looking for better wording for "All"? "Every"? "Multiple"? order=%27Importance%27 77 The common-ness of this alternative sort shows that people often prefer a more intelligent sort to one by bug number (increasing). It would be interesting to see what would happen if bug number (decreasing), i.e. filing date, were available. > resolution=--- 11 > bug_status=ASSIGNED,NEW,REOPENED,UNCONFIRMED 94 This is the most common alternative to the current default for status. It means "all open bugs". The resolution=--- means the same thing. > bug_status=ASSIGNED,CLOSED,NEW,REOPENED,RESOLVED,UNCONFIRMED,VERIFIED 137 This and other entries seem to indicate that some people don't realise that selecting all entries is the same as selecting none. > bug_status=ASSIGNED,NEW,REOPENED 195 This is the most common setting for bug_status. But if people are focussing on some other aspect, such as the reporter or the OS, for their default query, they might well leave bug_status alone; we can't count this as 195 positive choices for the status quo. > emailqa_contact2=1 120 > emailassigned_to2=1 123 > emailreporter2=1 518 emailassigned_to2 and emailqa_contact2 seem to have been cleared on a lot of queries - are people putting themselves in the email2 slot as "emailreporter2"? The filled or unfilled-ness of email1 and email2 not present in results, so it's hard to tell. Most people are leaving emailtype2 as substring; if the above hypothesis is true, it confirms the correctness of the change of this to "exact" by default, because it shows people don't bother to change it even when they mean "exact". Gerv
responding to a couple of Gerv's thoughts... > It seems that the most common change is to restrict by product. There is an > argument for us doing this by default (another bug), but we can't do it until we > can order Browser and MailNews at the top of the list, so people can see that > they are selected. indeed. the only times I don't restrict by product are when I can't be bothered to scroll down the list looking for MailNews... > It's unlikely that someone would actually want a default query which > only showed os=All bugs I may be reading the results wrong, but does that mean they've select only "All"? I often use queries where OS=All,Win2000,WinXP. If you want all the bugs for a given OS, you'll want the cross-platform bugs too. > This and other entries seem to indicate that some people don't realise that > selecting all entries is the same as selecting none. I'd guess that's right - I must confess that it took me a couple of months of using bugzilla before I thought of that. But it may also just be a UI thing - seems this happens most with resolution, which has several items selected by default, and in that case it's as easy to select a couple more (or selecting everything which is click, shift-click) as it is to deselect the multiple defaults. > ost people are leaving emailtype2 as substring; if the above hypothesis is > true, it confirms the correctness of the change of this to "exact" by default, > because it shows people don't bother to change it even when they mean "exact" I hadn't noticed the change, but I certainly admit to pasting a complete email address in there and not changing the dropdown. > The common-ness of this alternative sort shows that people often prefer a more > intelligent sort to one by bug number (increasing). indeed. of course people want intelligent searches - good search engines enable you to do a wide query that's guaranteed to have what you want, but ordered with the most likely things first. like I can search "mozilla" on google, and get 6 million hits, but the mozilla.org site is the first one. the lack of an "intelligent" order means you have to either do a limited query first, and then try further wider queries if you don't get what you want, or just use a wide query and trawl through 500 results looking for the one you want. filing order would be good, but ultimately an order that takes into account bug status, last changed, numbers of ccs/votes/dupes would be best, so that "popular" bugs appear first. but that's outside the scope of this bug...
So, what's the situation here? Myk, have you had time to do some analysis? Gerv
*** Bug 176469 has been marked as a duplicate of this bug. ***
How about, as default, "All bugs changed in the past week" -- no other filtering. I suspect the most common reason for doing a search, at least outside of the guru community, is in the hopes of avoiding filing a duplicate. And it is unlikely the user wants to study how to do clever SQL in bugzilla when she is interested in having her browser/mailer work better.
It's generally accepted that dupes are a problem for b.m.o, but does anyone have a reasonable feel for how bad it is? A report showing ratio of dupes submitted to real bugs submitted would be handy. Is it 1 dupe for every real bug? 10 ? Also, I would submit that the full search form is simply TOO COMPLEX for any new user to use it effectively. I've been trying to use it for a while now and it still intimidates. The quick search on the front page is OK, and that is the one that I think should include (by default) all bugs, with a dropdown to select "only open bugs" and perhaps as someone suggested, a product as well. (But the product list can only be a short simple list like browser, mailnews, common).
(In reply to comment #43) > does anyone have > a reasonable feel for how bad it is? Look e.g. at http://bugzilla.mozilla.org/reports.cgi?product=-All-&output=show_chart&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=UNCONFIRMED%3A&datasets=FIXED%3A&datasets=DUPLICATE%3A&datasets=WORKSFORME%3A Out of the quarter million bugs almost one third has been resolved as duplicate. A good bit less have been fixed and therefore are real bugs. About 50000-60000 bugs are open, the rest otherwise resolved (might also contain unrecognized dups, WFM maybe 20%, INVALID much less). My experience from years of bugzilla work tells me most of the open bugs are not real bugs (mostly the UNCONFIRMED, but also many NEW bugs). My estimate is 60-80 percent should be resolved one way or another. But I'm not so sure about the number of dups contained... probably not more than maybe 20 percent. As a result I'd say there are about 90,000 duplicates in bugzilla and a bit less duplicates. The rest is worthless/WFM bug reports. This is all open/resolved bugs combined. So there is about one dup for each real bug, but the dups are not equally distributed: maybe 80% of the real bugs don't have dups, but many also have dozens.
Re: (especially) Comment#43 I respectfully disagree -- I use the full query all the time. But it is a bit of a pain. For default -- how about "everything changed in the past two weeks" that ought to catch many of the newly surfaced bugs that everyone wants to duplicate. This, of course, excepts the ICAL bug that has been collecting duplicates for over a year. <sigh> I get my share, and I don't expect we can make the problem go away.
Who are you respectfully disagreeing with? I think you're talking to my comment that the full query form is too complex for any *new user*. You don't sound like a new user.
True, but you're both rather jumping ahead of where the discussion has got to... We haven't yet reached agreement on whether the default query should be aimed at new users or experienced users or both. It seems to be agreed that a separate interface for new users would be good, and that's apparently (comment 15) a different bug. I think it'd make sense to change the query in favour of new users now, even if that means a bunch of people have to change their own queries and a second change at some point in the future. Others think it makes sense to leave things as they are for now (or maybe change to something that's a better default for new and experienced users, if such a thing exists), until the situation is addressed with improved interfaces.
The "new bug" pages have a prototype default query that would be a good place for the "newbie/simplified" query. The full query page should still be around. A really "clever hack" for the simplified query would let a prospective reporter enter what s/he proposes as "Summary" and do a search on open bugs which share non-noise words with the proposed. Search google-style (?): the more words in common the more likely it is relevant. Again, I'm thinking of this in terms of reducing the number of duplicates reported.
The latest development version of Bugzilla defaults query.cgi to the "find a specific bug" page, which is designed to make it as easy as possible for all users (but particularly novice users) to find a specific bug. This is the interface to which we should be directing anyone looking for an existing bug before filing a potential duplicate. The "advanced search" page should continue to cater to the needs of intermediate to advanced users and users not searching for specific bugs.
This might not be directly related to this bug (and if it's not, i'll gladly refile as a new one). I strongly think that the query on the bugzilla helper search needs to include DUPLICATE (as dave pointed out a few comments back), even if the overall default query is something else. With highly dup'd bugs, it's much more likely that someone will find their particular search phrase amongst one of the bugs that got resolved as a duplicate than to match the one bug that's recieving all the dups.
> I strongly think that the query on the bugzilla helper search needs to include > DUPLICATE On the next version, it does :-) Gerv
Hello, I think that you should add at least "Unconfirmed" to the default query. People who don't want to see unconfirmed bugs are just bug maintainers and developers, very experienced users, while the major use of bugzilla is to search for bugs already reported before filing another one. For this use you need to search into unconfirmeds too, because either a bug could still not have been accurately checked, and left "unconfirmed" for this reason, or the assignee could have not succeeded in reproducing the bug due to different conditions, while you happen to have the right conditions and experience the bug, and finding the bug reporting you could confirm it.
Myk's comment #49 is important - new users now get the "Find a specific bug" page. I've been using option 3) on the original list for a few years now, without realising it's not the default - it turns out that 1) is still the default. And I often find myself changing it to option 2) by removing the selection of DUPLICATE. So from a sample of 1, and bearing in mind we no longer have to cater for novices with this setting, I'd now vote for 2) being the default - which is the equivalent of adding UNCONFIRMED to the current default. What do others think? Gerv
QA Contact: myk → reed
Is there still any interest in changing this? Gerv
gerv: i agree with your comment #53 and still think we should default to including UNCONFIRMED bugs
Component: Bugzilla: Other b.m.o Issues → Bugzilla: Keywords & Components
QA Contact: reed → timeless
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
There seems relatively little interest in this, and it's been open for ages. So closing. Gerv
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: