Closed
Bug 136310
Opened 22 years ago
Closed 17 years ago
RFE: "relevant comments" field for long bugs
Categories
(Bugzilla :: User Interface, enhancement, P4)
Bugzilla
User Interface
Tracking
()
RESOLVED
DUPLICATE
of bug 322086
People
(Reporter: dsmutil, Unassigned)
Details
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.
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.
Reporter | ||
Comment 2•22 years ago
|
||
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 4•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 7•22 years ago
|
||
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•22 years ago
|
||
> 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•22 years ago
|
||
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.
Priority: -- → P4
Target Milestone: --- → Future
Comment 10•21 years ago
|
||
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.
Assignee: myk → gerv
Comment 11•21 years ago
|
||
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.
Assignee: gerv → myk
Updated•21 years ago
|
OS: Windows 98 → All
Hardware: PC → All
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Target Milestone: Future → ---
Updated•18 years ago
|
Assignee: myk → ui
Comment 12•17 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•