Split 'Summary' into 'Symptoms summary' and 'Analysis summary'




17 years ago
4 months ago


(Reporter: vincent.deconinck, Unassigned, NeedInfo)





17 years ago
Symptoms : One of the things that uses much manpower is duplicate bugs :
1) As a reporter, I often spend lots of time trying to find if someone has 
already encountered the same behaviour. 
2) Many reporters can't find the bug they see and spend vcaluable time filing 
3) A lot of time is also needed to read those bugs, find the corresponding 
"master bug" and link them.

Analysis : I frequently see that the summary of the bug changes as the bug is 
analysed and fixed. For example, "Left column doesn't show up on Mozilla.org" 
could become "DIV alignment is broken when CSS forces negative width". From that 
moment on, the door is wide open to duplicates.

Resolution : The summary itself is not enough to reflect both the symptoms and 
the anlysis of the bug, and changing the summary often deletes the original 
reporter's observations. As with any scientific report, observations and 
analysis should be distinct fields and users should be able to query one or the 
other field.

Comment 1

17 years ago
I agree.  I had this bug in my list to file, but hadn't gotten to it yet.  Thank
you!  :)

I imagined this as a heirarchy of symptoms, added to as more technical
information is developed.  The initial report would almost always be a symptom.
 Once it was determined that the "cause" or "source" was found, the bug could
move from triage to implementation of a fix, or be "assigned".

This would prevent a lot of dups based on not finding searched-for terms (i.e.
the summary changed), and would also have the pleasant side effect of
associating an "open" bug status with the symptom (NEW, REOPENED, ASSIGNED),
rather than RESOLVED as a dup in many cases.
I support this. See also bug 26053:

> ------ Additional Comment #2 From Sean Richardson 2000-02-01 10:29 -------
> Ah, the old, "Is a bug report about a symptom or a problem or a fix?" 
> puzzler. [...] 
Though this may be specific for "bug" issues. See bug 9412 comment 28 for a list
of proposed issue types.
Priority: -- → P4
Target Milestone: --- → Future


13 years ago
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---


12 years ago
Assignee: myk → create-and-change

Comment 4

6 years ago
This is doable with custom fields.
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Comment 5

4 months ago
Comment is Comment..but comment is not comment..lekin mere hisaab se comment is comment..mujhe - marks mat dena...
Flags: needinfo?(entbehrliches)
You need to log in before you can comment on or make changes to this bug.