136310 - RFE: "relevant comments" field for long bugs

Status: RESOLVED DUPLICATE of bug 322086

(Bugzilla :: User Interface, enhancement, P4)

Description

[Dan Mellem]

Popular bugs tend to get SPAMed with a lot of useless comments and duplicate
notices. It'd be nice to have a field up top that would link to the most
relevant comments or even have an "executive summary" link that would show only
these comments.

Comment 1

[mental]

Really close to bug 99242 and bug 99240.  If you don't dupe it, please clarify
the what is really wanted here apart from those.

Comment 2

[Dan Mellem]

I'm thinking of something very like the "depends on" on "blocks" lists but
instead of showing other bugs, it's a list of the most relevant comments. Then,
instead of "Show dependancy tree" or whatever for that line it would be more
like "show executive summary" which only shows the most relivant comments (or
shows them first).

Bug 123456's most relevant comments: [___________] Show executive summary

or something like this.

Comment 3

[Dan Mellem]

Correcting severity
->Enhancement

Comment 4

[Andreas Franke (gone)]

So this is different from bug 99240 (because you don't want an editable field),
but maybe a generalization of one solution of bug 99242 which calls for just
_one_ link to an important comment:
 
  <a href=#29>Jump to most recent detailed summary comment</a>
   |   Comment 1                                                  
   |   ...
   --> Comment 29
       Comment 30 

If this is correct, then I support your proposal because it's more general and
flexible. Once this is implemented, bug 99242 can be resolved.

Comment 5

[Andreas Franke (gone)]

Note that bug 99240 is still an alternative solution. An editable long summary
would have the advantage that you can copy&paste _parts_ of an existing comment.
(You can't do that with complete comments.) Another problem with an "executive
summary" defined as a sequence of "important" comments is that the comments
would be displayed out of context, which may lead to "funny" or confusing
combinations.
If you had an editable long summary, you would refer to comments in the bug with
the usual "comment 123" syntax, thus you could add some explanatory or
introductory words before the reader is pointed to the original comment.

One possible problem with both the "editable long summary" and this "list of
important comments" is who has the final say if there is disagreement about
which comments are important, or what should be in the summary. This issue will
be more important to solve in the "editable summary" case because altering an
existing text will take more time than just adding a comment no. to a list, so
people will get angry more easily if someone reverts their changes, or changes
them "inappropriately". On the other hand, this is not so much different from
the "Summary" and "Status Whiteboard" fields, and it can be solved the same way:
by granting the bug assignee the authority to decide about the content of these
new fields, should disagreement arise.

Comment 6

[Matthew Cline]

Kinda looks like a dup of bug 73173

Comment 7

[Dan Mellem]

I don't think it's quite like bug 73173 since that is dealing more with bug
changes (changing a milestone, etc.) and sending/blocking related e-mail
updates. This request deals more with a list of the most relevant comments to
get a new person up to speed on the bug without having to wade through the "me
to"'s and other less-relevant comments. The field would probably be modifiable
by the reporter, owner, or by permissions.

I agree with the concern of altering a "long comment" field (comment 5) since it
is frustrating when "my" well-thought summary line gets changed. Perhaps a table
could be used to have both:

Comment  Reason/notes
  2        Clarification of proposal
  4        Generalized version of 99242

But then it would use up more space than just a list of comments or a summary
page that has most comments hidden.

Comment 8

[Andreas Franke (gone)]

> Comment  Reason/notes

If you do it this way (Comment no. + short title for each link), then it could
be realized as an instance of a generalized "links" feature, see "FeatureZilla"
bug 75172 comment 1, which suggests a set of (link_type + link_url) pairs for
each bug, which could be extended with a short text to be used as link title, so
that you have (link_type + link_url + link_title). And of course it's plausible
to have an ordered list of links instead of a set, for each bug. For this
special case, the comment id could serve as a sortkey determining the order,
but in the general case you'd want to have a sequence no. that is per (bug_id,
link_type) pair. Anyway, just brainstorming...

> I agree with the concern of altering a "long comment" field (comment 5) since
> it is frustrating when "my" well-thought summary line gets changed.

Well, you always have the history, and hopefully people will be reasonable
enough to not overwrite your words just for the sake of it. :-)

Comment 9

[Matthew Tuck [:CodeMachine]]

This would have the potential to incite holy wars on bugs about what is
considered "relevant".  Having security on this could lessen the problems, though.

Comment 10

[Dave Miller [:justdave]]

The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.

Comment 11

[Dave Miller [:justdave]]

Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.

Comment 12

[Rolf Leggewie]

No activity in four years.  I'd close this as wontfix.  

(In reply to comment #9)
> This would have the potential to incite holy wars on bugs about what is
> considered "relevant".  Having security on this could lessen the problems, though.

But I just stumbled across bug 322086 which has a proposal with the same effect.  I hope you will agree that a rating system is a better, more scalable and fairer system and thus do not minde me duping it to 322086.