30978 - guide to screening duplicate bugs

Status: VERIFIED FIXED

(Developer Documentation Graveyard :: General, defect, P3)

Description

[Sean Richardson]

At the URL above is a rough and incomplete initial draft of a
"guide to screening duplicate bugs" intended to help new prescreeners and
confirmers get more efficient at that task faster. It's not done, and
it isn't necessarily organized the best way at present.

HELP WANTED. I'm sure that the collective experience on the Cc: list here
can whip this into shape in short order.

It's being written to appear at http://www.mozilla.org/quality/help/ -
I'm sure Christine Begle would appreciate help creating some of the
other documentation desired there.

It's a companion to a "beginner's guide to searching for previously reported 
bugs" - http://www.mozilla.org/quality/help/beginning-duplicate-finding.html -
aimed at people new to bug reporting, which could also use some help in
being more concise without seeming demanding or imperative.

Thanks for anything you can contribute.

Comment 1

[Matthew T (active 1999-2002)]

* In `The first field, Status, is already set to find NEW, ASSIGNED, and REOPENED
  bugs', change `already set' to `normally preset'. Some Bugzilla users may have
  different default queries.

* Change `(use ctrl-click on MS-Windows)' to `(use Ctrl-click in Windows,
  Command-click in MacOS, or just click in Motif or GTK)'. (Disclaimer: I'm not
  sure about GTK.)

* Change `The same will apply to Keywords' to `The same applies to the Keywords
  field'.

* After `"all words"', add a comma.

* 13 HTML errors to fix. (Yeah, I know, it's a draft.)

That's all I can think of for now ...

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think it might be worth mentioning the issues of which bug to mark as a
duplicate of which.  In other words, you shouldn't always mark the newer bug as
a duplicate of the older one.  It's better that a bug stays open if:
 * it's been analyzed by developers, and the duplicate hasn't
 * it's assigned to the right Component/person, and the duplicate isn't
 * it's given a higher priority (e.g., [PDT+]), and the duplicate hasn't
 * probably something else here...

Comment 3

[John Morrison]

* probably something else here...

* it has a explanation of how to reliably reproduce the bug and/or it
  has a simplified testcase, and the duplicate hasn't

* and probably another something else here...

Comment 4

[Sean Richardson]

A revised version of the duplicate-screening guide is available at
http://www.albedo.net/~sidr/mozilla/docs/screening-duplicates.draft-02.html .

All of the issues raised in the previous round of comments have been attended
to - thanks, those were all good comments. Some of the HTML errors are mandated
by the Mozilla style guide, though - http://www.mozilla.org/README-style.html

This guide is meant to impart the core of the Best Current Practices for
screening duplicate bugs, so if there is any addition or change in presentation
that would help get the essentials across better, please speak up. I've tried
to present what I've learned by observation so that new contributors can get
up to speed faster; the current draft comes close to exhausting what I know.

An addendum on less-common search strategies that are better suited to some
situations than the generic strategies outlined already might be useful -
any such?

Comment 5

[Sean Richardson]

A somewhat reorganized, more complete, version of this duplicate screening
tutorial is now available at
http://www.albedo.net/~sidr/mozilla/docs/screening-duplicates.draft-04.html
It is probably polished enough now to put into use so that additional feedback
can come from those who use it.

The target audience is members of the Mozilla community who have become
interested in helping out ( http://www.mozilla.org/quality/help/ )
but who have not fully learned the ropes. This tutorial is intended to
come close to describing best current practice in identifying and handling 
duplicate bug reports for "unofficial" QA helpers.

Most of that audience are people with the "Can confirm a bug" permission but
not the "Can edit all aspects of any bug" permission, which makes bug 28422,
"CONFIRM-priviliges don't grant mark-as-verified-priviliges", annoying. Those 
with the ability to confirm unconfirmed bug reports were originally meant to 
also be able to mark bugs as DUPs, but that hasn't been implemented yet. 
As a consequence, the *Matching* section is more complex than it should be. 

Removing those who have not added anything from the Cc: list to reduce spammage;
add yourself back, of course, if you want.

Gerv, I think the best place for this is probably the "QA Howto Guides" section
of http://www.mozilla.org/quality/help/ with link text resembling
"How to screen out duplicate bug reports".

The URL on line 33 points to 
http://www.mozilla.org/quality/help/finding-duplicate-bugs.html
 -- if you don't take that update, you'll want to change that URL back to
http://www.mozilla.org/quality/help/beginning-duplicate-finding.html

Additional suggestions for improvement welcomed, of course.

Comment 6

[Gervase Markham [:gerv]]

Fab :-) I've been thinking about writing a "DeDupeAThon" for a while, now, but 
forgot about what you were doing.

Note that the number of people who can confirm, but not edit bugs (according to 
[e-mail] in the status update on 2000-05-17) is 5. Therefore this 
shouldn't be too much of an issue. I normally set both (or neither) permission 
bits.

Top tip; Bugzilla searches as <A> HREFs are made much easier to read if you 
remove all the "empty" fields from the parameters - this doesn't affect their 
functionality. I've done this for some of them, but want to discuss the others, 
so didn't bother for a moment (see below).

Top Tip 2: You really want to be using relative links. Checking out the HTML 
tree via anon CVS helps here ;-) For more info, read the mozilla.org style 
guide; it's at http://www.mozilla.org/README-style.html

I've made a few changes, so I've attached the file to this bug for your review 
before I check it in. One thing to think about:

The way Bugzilla works, it only remembers one list of bugs at a time. This makes 
it very hard to have one list of "bugs which may be dupes" and another load of 
lists which are the results of searches to find things they may be dupes of.

The solution to this problem is to create the list of bugs you are de-duping, 
and then "Open In New Window" them one at a time, using Bugzilla's search 
facility to search for the dupes. This way you keep your original list. Is this 
worth mentioning, either in this file or another one? QA Tips And Tricks? ;-)

Also, I was wondering why you felt the need to separate the lists of bugs where 
dupes lurk into "Unchanged for more than a week" and "Unchanged for less than a 
week"? 

Gerv

Comment 7

[Gervase Markham [:gerv]]

Attachment: draft-05 ;-)

Comment 8

[Sean Richardson]

Thanks for the lookover, Gerv, and the hints. Update at 
http://www.albedo.net/~sidr/mozilla/docs/screening-duplicates.draft-06.html

Not sure what to do about the talk about permissions in the *Matching* section;
given what you said about the two permissions going hand-in-hand, it would
probably be cleaner to just say "this isn't for you if you can't edit all
aspects of any bug", more politely, at the top... except that a comment from 
anyone at all, anyone, about possible duplication is worth hearing. Use your 
best judgement or bounce your thoughts back to me and I'll rework it combining 
your judgement with mine.

Bugzilla buglist.cgi and query.cgi URLs condensed. HREFs on www.mozilla.org
made relative. Bit about opening bugs in new windows added just above the
prebuilt lists, as well as in the *Matching* section where it was already.

The lists are split into "changed in the last week" and "not changed in the last 
week" for two reasons: 
(1) each list is long enough as it is; combined, they'd be too long to handle.
(2) as a group, bug reports that have fallen inactive for a week or more have a 
    different character from those that haven't; many have no comments at all
    or are deficient in some way; among them, those that are DUPs are more 
    likely to be described in a different fashion than those the bugs they
    are DUPs of. All in all, it's a different experience working with them.

For good measure, some sentences got tweaked. Time to unveil?

Comment 9

[Gervase Markham [:gerv]]

I'd say that given that there are only 5 people (maybe only one of which is 
active) I'd put a note at the top saying "if you have trouble with any of these 
operations because you don't have all the relevant permissions, add a comment to 
the bug and CC: <A HREF="mailto:...">[e-mail]</A>"

BTW, I think there's something screwy with the links at the bottom. The "Today" 
ones don't just do today, and some of the MailNews ones return Zarro Bugs, which 
is probably wrong. Do you want to check the params? I seem to remember that it's 
hard/impossible to create a link which always gives "bugs filed today", but I 
could be wrong. We may need Javascript for that one.

After you've looked at the above, unveiling will happen :-)

Gerv

Comment 10

[Sean Richardson]

Ok, the *Matching* section has been simplified, and the caution moved to
the top, in the paragraph beginning at line 50. If you want comments added
to this bug, you'll get email anyway as the owner, but I'm not sure that's
necessary. There are two options in the file, one hidden in an HTML comment,
so go with what you prefer (either lines 55-56 or 57-59). Clearing out the 
Cc: list as a precaution to reduce spammage if you do want comments added to 
this bug.

About the 'Today' links: we both forgot something. You cut a bit too much out:
"&changedin=1&chfield=%5BBug+creation%5D&chfieldfrom=&chfieldto=Now" is
the bit that does it. I forgot to mention bug 37749, "query for changes in last 
n days doesn't work", which makes the links for Today's bugs a bit fragile.

The query string actually shouldn't work ... it is only working now because
&chfieldfrom= is incorrectly working as if it were defaulting to "now",
and it was only working previously because &changedin= was interacting
with &chfield=, which it shouldn't have and no longer does.

But since the "Today's Bugs" link on http://bugzilla.mozilla.org/ can't
stop working, the fix for bug 37749 will guide what needs to be done to
keep the equivalent links working here. Setting a dependency so we'll be 
notified when it does get fixed.

Actually, for DUP-hunting, it would be better to have links for "Today's and
yesterday's ..." -- there's roughly a ten-hour period between midnight Pacific
time and when the next morning's nightly binaries appear, during which anyone
using nightlies is using yesterday's. That period includes waking hours for
most of the rest of the globe. Normally, though, only a handful of bugs are
reported during those hours, compared to 100+ in the rest of the day, so for
those awake during those hours, a "Today's bugs" link isn't much use.

I'm no javascript whiz, but if someone wants to whip up js to do date 
arithmetic subtracting "n" from today's date to fill in &chfieldfrom=,
I'd use it, especially if bug 37749 takes a while to fix.

As for the "Zarro Boogs" MailNews lists... these are naturally-occurring
phenomena, some of the time.

http://www.albedo.net/~sidr/mozilla/docs/screening-duplicates.draft-07.html
should be ready to go.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Readding self to cc: list.  Why was everybody removed (in two steps)?

Comment 12

[Sean Richardson]

The reasoning for removing names from the Cc: list was given in the comment
that accompanied each step. The only reason I did so was that nobody had
added themselves to the Cc: list here, and after creating a long list from
the start, I thought it best to avoid spamming people more than necessary. 
Sorry if I trampled...

Comment 13

[Gervase Markham [:gerv]]

Any JS gurus about want to hack at the "dates" problem? The ideal thing would be 
a separate JS file which could be used in all sorts of Bugzilla date-related URL 
generations...

> If you want comments added to this bug, you'll get email anyway as the owner, 
> but I'm not sure that's necessary.

You were right in your guess; the above is not what I meant :-)

This is now cool; however, I'll hold back until the other issue has been 
resolved.

Gerv

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think either:
 * the query for Browser-General bugs should be changed to those owned by Asa
Dotzler.
or
 * someone should move the Browser-General bugs that are dealt with to an
appropriate component (often, but not always, XPApps).

Comment 15

[Gervase Markham [:gerv]]

> the query for Browser-General bugs should be changed to those owned by Asa
> Dotzler.

A bit dangerous, given that he's just started at Netscape and so may not be in 
charge of BG for much longer...

> someone should move the Browser-General bugs that are dealt with to an
> appropriate component (often, but not always, XPApps).

Don't they anyway? If you know where it goes, put it there. Otherwise it stays 
in BG until someone does know ;-) I've lost your point...

Gerv

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There are a lot of Browser-General bugs that are assigned to the right person
and being worked on.  Should I change these (when I see them) to the right
component?  (If it were called "Browser-Unsorted" that would happen a bit less,
I think...)  Only about half the bugs returned by the all Browser-General bugs
query are owned by Asa.

Comment 17

[Sean Richardson]

Regarding B-G bugs, I understand the points made by both David and Gerv; 
B-G bugs assigned to an engineer don't need any more triage, but it would be
better not to have to change the query any time the default B-G owner changed.

The simple and permanent solution would be to narrow the query, in some way, 
to limit the list to only those bugs where the owner (assigned_to) has *not* 
changed; that way, bugs handed to or taken by an engineer without being moved 
to a different component would drop off the triage list. That way it wouldn't
be necessary to keep on top of changes to the default B-G ownership (there have
been at least 6 in the last 6 months, and with respect to Asa, without the
UNCONFIRMED status, the Bugzilla Helper, and the Netscape 6 feedback form,
I don't think anyone could have stood up to the barrage in the last two months).

Unfortunately, there does not seem to be any way to limit a bug list to
only those bugs where a specific field has not changed. I've filed an RFE,
bug 40966, "RFE: negation of all boolean chart operators OR expressions",
that suggests a straightforward way of making a search term like
  [assigned_to] [unchanged]
possible (Option 1). 

David, there is currently some discussion in n.p.m.qa.general about
splitting up XPApps, so right now is probably not the best time to try
to move unsorted bugs to their proper home.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, there are times when engineers send things *to* Browser-General to be
handled because they don't want to figure it out themselves.

Comment 19

[John Morrison]

function yesterday() {
  // returns yesterday's date as mm/dd/yyyy
  var now  = new Date();
  var yst  = new Date(now.getTime() - (24*60*60*1000));
  var str  = (yst.getMonth() + 1) + '/' + 
              yst.getDate() + '/' + 
              yst.getFullYear();
  return str;
}
document.write('yesterday was ' + yesterday());

Comment 20

[Gervase Markham [:gerv]]

Thanks, John :-) I'll incorporate that into the file soon, if no-one else does.

If bugs are assigned to person != [e-mail], yet are in Browser 
General, that normally means (unless person == [e-mail]) that is has 
been reassigned to a new engineer without the component being updated. These 
bugs should, in general and obvious cases, be moved to the component owned by 
the person it is assigned to.

Remember, though, that some bugs which are being worked on legitimately stay in 
BG.

Gerv

Comment 21

[Gervase Markham [:gerv]]

Attachment: draft-08 (added JS date creation)

Comment 22

[Gervase Markham [:gerv]]

Sean - I've incorporated jrgm's JS, generalised a tad, and we are in business. 
Draft 08 added for your review. I think we are nearly ready to rock...

Gerv

Comment 23

[Sean Richardson]

We both had the same idea, Gerv, but you missed a detail: timezones.
It's still yesterday in California up to 8 a.m. in Oxford, so your backdays()
function would count back from "tomorrow" from the point of view of Mountain
View, where the bugzilla.mozilla.org server resides, (partially ) defeating its 
intended "reach" for 1/3 of each day.

The pastdate() function in 
http://www.albedo.net/~sidr/mozilla/docs/screening-duplicates.draft-09.html
corrects for time zone differences. 

I've also limited the "Browser-General" queries to the last week; almost all
of those are assigned to Asa, and at any given time there are probably more
DUPs in the last week's worth than in all the rest of the B-G bugs. That should
(mostly) address David's concerns while avoiding a future maintenance task...
it's not the work of updating the links that's an issue, it's not knowing when,
and the potential for forgetting that this document needs updating too.

Comment 24

[Gervase Markham [:gerv]]

Cool... waiting on your say-so to upload it.

Gerv

Comment 25

[Sean Richardson]

With a lawyer now involved in fixing bug 28228, "Need license for 
documentation", an open content license for Mozilla documentation should 
(crossing fingers) be available soon. In the meantime, as a stopgap, to get 
this off the side burner, I've concocted a special license to give The Mozilla 
Organization and Netscape Communications Corporation all rights needed while
retaining the right to release it under an open content license (useable by 
anyone) when mozilla.org has one ready. It's essentially a dual license with 
one of the licenses missing (as yet).

Gerv, I'm about to email Steve Rudman and Mitchell Baker about this;
you may commit draft-10 (same as -09 except for the license) now or wait
for a reply as you think prudent.

http://www.albedo.net/~sidr/mozilla/docs/screening-duplicates.draft-10.html

Comment 26

[Gervase Markham [:gerv]]

If bug 28828 ( ;-) ) isn't fixed by the end of next week, I'll check this in 
with the temp. license. Or, if M16 is released ;-)

Gerv

Comment 27

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to 
[e-mail])

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 28

[Gervase Markham [:gerv]]

Well reminded - I fixed this :-)

Gerv

Comment 29

[Blake Ross]

vrfy fixed