Closed Bug 99240 Opened 18 years ago Closed 12 years ago

Add an editable "long summary" field (useful for long bugs)


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






(Reporter: afranke, Unassigned)



This bug has been split off from bug 540, see my 2001-02-19 23:38 comments
there, especially the paragraph starting with "Other possibilities that may be
worth thinking about, especially useful for long bugs:"

Introduce a new "long summary" field with the original bug description as the
initial value, and make it editable by everyone with the editbugs permission
(and maybe the reporter). In a bug view, this field should only be shown if its
value is different from the original bug description, or alternatively it should
always be shown, replacing the initial bug description field (with a clear
visual indication that it serves a different purpose than the additional
comments). The history of the changes to the bug description field should be
stored as a sequence of diffs, conceptually like CVS version files, and each
diff could show up as an additional comment. This way, the additional comments
would be more like a discussion log, whereas the "long summary" field would
always contain a detailed, up-to-date description. This would be a useful
feature for everyone who is short of time and wants to get the "details" of a
bug (like PDT) without having to scan through all the comments.

One example of a long bug where this would be useful is bug 29086.
An alternative is bug 99242 "Link to 'most recent summary comment', or hide old
Target Milestone: --- → Future
The installation I am administrating needs a 'customer viewable description' to
work similar to SGI's BugWorks, in order to bring the developers and support
team into a single issue tracking system.  The query page would need to make a
distinction between this field and developer comments, which should not be
visible to customers or support staff (a separate issue).  

Having the history stored as a sequence of diffs sounds great in theory, however
the descriptions are likely to vary greatly as they change from the
developers/reporters version to a accurate but brief (i.e. customer viewable)
version, meaning the diffs could end up taking more screen space than the actual

One way to retain this functionality, is a comment type field (e.g. 'SUMMARY',
longdescs.  The summary history could then be displayed as a sequence of diffs
on occasions when this is appropriate.  This field could then also be used to
filter out types of comments (both viewing and bugmail).
I think there is a "Comments should have a type" bug somewhere, but I can't find
it now. Bug 7415 is the only one I could find, but it seems it's only about a
"private" attribute. Bug 73173 is about "explanatory" comments. There is also
bug 11368 about displaying the bug activity along with explicit descriptions.
Maybe this bug could use the same mechanism for the new "diffs"?

I suggest you create a new bug for a general "comment type" field, and make some
existing bugs (including this one) depend on it.
After suffering through a couple events recently regarding exceptionally long
bug reports, I thought a grand idea would be to have an extended summary of a
bug, which I was thinking could be called simply "Description", which would just
describe, in detail, what the bug was about.

A lot of bug reports start with a symptom, go through an analysis (with lots of
intervening conjecture) and usually end up being split into several different
bugs before all is said and done.  This is very confusing to the otherwise
helpful bug reporter and wastes a lot of a lot of people's time.

Regarding the diffing and CVS stuff, I think that's overkill.  Simply setting a
pref "must comment when changing this field" should suffice.  Alternately, make
the new description also a new comment at the same time, but as the description
may change over time, I don't see how this is particularly helpful.  The other
suggestions (making it the same as the first or most recent comment) are unhelpful.

Now, I'm posting in support of the first comment only - in "prime example"
fasion, I really have no idea what the later posts are advocating, but it
doesn't sound much to me like what I'm asking for nor what the original bug
report is about ...

Now, while bug 29086 is a good example, try to figure out what bug 55690 is
about (or is that bug 69938?), or bug 57724 (or is it bug 136633 ... or bug
166786?)  Check out some of those dependency trees ... quite overwhelming if you
don't deal with this stuff every day.

But especailly make note of bug 57724 comment 115: "[...] read the whole bug,
not just the summary [...]" ... aka: "summaries are useless".  Bugzilla needs
something better.  A description - or a synopsis - preferrably immediately
before the first comment, possibly even before the "Additional Comments" box I'm
typing in right now... Comment 111 on bug 57724 illustrates the problem nicely -
``I commented on bug x bug maybe this is the bug I'm looking for''  Even after
reading 110 (!) comments, the bug reporter still doesn't know if he's in the
right place (and it turns out he wasn't).
This doesn't seem very active ... a natural extension to this feature would be
to make this the default search field instead of the "summary" line in bugzilla
queries.  ISTM that this would make finding bugs (and avoiding dupes) so much
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
Assignee: myk → create-and-change
Priority: -- → P4
Since Bugzilla 3.1.2, you can create a custom textarea and then paste the bug description in it. We won't implement a specific "long summary" field as you are free to create one yourself when you need it.
Closed: 12 years ago
Depends on: 357315
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.