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 comments".

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 text. One way to retain this functionality, is a comment type field (e.g. 'SUMMARY', 'COMMENT', 'ATTACH', 'ONATTACH' (or 'REVIEW'), 'CHANGE', 'BULKCHANGE', ..) in 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 easier.

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.