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

Status: RESOLVED WORKSFORME

(Bugzilla :: Creating/Changing Bugs, enhancement, P4)

Description

[Vincent Deconinck]

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 
dups.
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

[xyzzy]

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.

Comment 2

[Andreas Franke (gone)]

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. [...] 

Comment 3

[Andreas Franke (gone)]

Though this may be specific for "bug" issues. See bug 9412 comment 28 for a list
of proposed issue types.

Comment 4

[Frédéric Buclin]

This is doable with custom fields.

Comment 5

[HagguDas]

Comment is Comment..but comment is not comment..lekin mere hisaab se comment is comment..mujhe - marks mat dena...