176469 - Query should select UNCONFIRMED by default

Status: RESOLVED DUPLICATE of bug 194116

(bugzilla.mozilla.org :: General, defect)

Description

[Aaron Lawrence]

This arose out of using the quick query (which incidentally seems broken using
Moz 1.2b :) on the bugzilla home page.

The Query page defaults to filtering NEW, ASSIGNED and REOPENED but not
UNCONFIRMED. This seems a bit strange since certainly, you want people to find
UNCONFIRMED and confirm them! This could help reduce dups.

Comment 1

[Dave Miller [:justdave]]

This is a param change I believe....

Comment 2

[timeless]

fwiw @see bug 28357 (bugzilla product), @see bug 71404 (mozilla.org config).

the problem with this suggestion is that there are different kinds of users, and
while bugzilla is an open product the most important audience for us is our
developer base. the developers don't want to see the unconfirmed bugs and would
get really annoyed by them (the unconfirmed bug state was created to hide them
from developers).

[To readers: Asa is most likely to wontfix this bug as filed based on the above.]

A better solution IMO would be to change the query to include UNCO unless you
have EDITBUGS. (I don't believe that can be done using the param.)

Note that the default query really can't work for everyone, someone without
CANCONFIRM probably should use a search approximating the one for which i filed
bug 177004 because it doesn't work.

Comment 3

[Gervase Markham [:gerv]]

Well...

If we do this, all the engineers will have to define their own default query -
but random bug-filers coming along are more likely to find their dupe. 

If we don't do it, the engineers can keep on as they are, but we probably get
more dupe bugs filed.

It's a difficult choice; I'd actually go for the former. We need to cut the
incoming bug rate. asa?

Gerv

Comment 4

[Ross Boylan]

I ran into a related issue with a bug marked as RESOLVED.  The standard system
query does not include that status, but it seems to me if you want to avoid
duplicates it should be included (171441 was the bug).

I can see a couple of problems with including RESOLVED.  First, the volume of
responses to queries may be so large that people just give up.  Second, if a bug
is a regression (something was fixed and is now broken again), you actually want
someone to file a bug report, or reopen an old one.  If someone sees a
duplicate, they will probably just drop the issue.

Another way of looking at the problem is that bugzilla's current model of status
is too crude because it does not provide enough info on what version the status
applies to (as far as I can see).  If this were carried along it would be
possible to tell, for example, that you were seeing a bug that had been fixed
after the version you were running (ordinary lag between the source tree and the
binaries people run) or that it was fixed long ago (and hence a regression has
occurred).

I was inspired to add this report by bug 176939, which in turn was inspired by
176858, if you want to see some history.

You will notice this comment expands the scope of this bug to "Query should
select additional statuses".

Comment 5

[Aaron Lawrence]

I see what everyone is saying and I appreciate the need to make developers' jobs
easy. I'll just add this:
- developers are likely to be playing with Bugzilla often and therefore will
quickly customise their query if they find the default too broad
- occasional users will not likely learn to change their default query (I hadn't
noticed it) because they will be doing most queries without being logged in, in
which case you can't save a new default query.
- generally speaking, it's better to be too broad and allow people to refine
things, than default to a narrow filter. Otherwise people may not realise the
other options are there.

Cheers

Comment 6

[Frank Wein [:mcsmurf]]

I don't think this will be changed, there had to be searched over 5300
UNCONFIRMED bugs which
1. costs much CPU load, MB of RAM
2. and doesn't make so much sense because most of the UNCONFIRMED are still
dupes or other bugs, that arent really bugs.

Ok, the above would be a more general Bugzilla problem, but I think something
_has_ to be done (only people with canconfirm can create new bugs or create a
complete new , probably 2nd bugzilla database, where only permissioned users can
do anything like creating bugs, adding comments...; the 1st database would then
be for write+read for the public, the 2nd only for permissioned users)

Comment 7

[Aaron Lawrence]

I have a suggestion for how to reduce incoming bugs, unrelated to this. Where
should I discuss?

Comment 8

[Gervase Markham [:gerv]]

Aaron: either file a new bug, or mail me. Probably mail is best to start with.
But do read the archives of netscape.public.mozilla.general to see if your idea
was proposed in the two threads we had about this in the last couple of weeks.

Gerv

Comment 9

[Frank Wein [:mcsmurf]]

http://groups.google.com/groups?dq=&hl=de&lr=&ie=UTF-8&threadm=aplr9c%246m1%40ripley.netscape.com&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26group%3Dnetscape.public.mozilla.general%26start%3D25
would be some thread

Comment 10

[Asa Dotzler [:asa]]

fixing component.

Comment 11

[Gervase Markham [:gerv]]

That's great, Asa, but how about giving us your opinions on this bug also? :-)

Gerv

Comment 12

[Frank Wein [:mcsmurf]]

esspecially to comment 6 :-)

Comment 13

[timeless]

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

Comment 14

[Christian Schweer]

I see that there are some common points here and in bug 181276.

Nevertheless bug 181276 was related to the search directly in the "submit a
bug"-page.

That I filed 181276 is IMHO a prove, that the parameters of that search (and
only that) should be changed to include also RESOLVED, etc. 
I.e. I don't suggest to change the search on bugzilla.mozilla.org, neither the
selected status on the query form. Only asking a bug-reporter to use a given
search in order to avoid dups and the search doesn't find resolved bugs, doesn't
make any sense to me. (Sorry)

Comment 15

[Jesse Ruderman]

I agree with this bug.  UNCOs are usually valid, but just more likely to be dups
than NEW bugs.  It doesn't make sense to exclude them from the default search
unless there's a team keeping the UNCO count low.

Comment 16

[Gervase Markham [:gerv]]

Bug 194116 is about finding out the best default query for b.m.o.

Gerv

*** This bug has been marked as a duplicate of 194116 ***