Implement support for bug "description"

RESOLVED WONTFIX

Status

()

Bugzilla
Creating/Changing Bugs
--
enhancement
RESOLVED WONTFIX
13 years ago
4 years ago

People

(Reporter: Vlad Dascalu, Unassigned)

Tracking

Details

(Reporter)

Description

13 years ago
We should implement support in the back-end and at the UI level for designating
a reply item as an official "bug summary" or "bug status update".

By default, this will be item0, but often, bugs emerge into something different
from what the reporter specified in item0. Also, design of the solution is
agreed upon, without any code been written. Also, noise appear now and then, so
for a bug with 100+ replies, it's difficult to grasp the big picture in a nutshell.

So someone could write an item in which to specify the current status, what's
needed to complete the bug and what needs to be done. We need an UI in order to
specify the reply number that contains this information.

Some bugs have "See item 33 for details before posting in this bug". This could
also be done better with the new system.

Optionally, the designated item could be copied, read-only, at the beginning of
the bug, right before item0 is, but this would make sense only if it is
different from item0 (and item0 would be the default).

Not completely sure about this, just an idea.
Rather than designating an comment for this (and creating a new comment when the
description needs changing), I think we should have an editable "description"
field that gets the contents of the initial comment by default but can be
updated as necessary.  This spares bugs from getting a new comment every time
someone wants to make an update to the field, and it makes updating the field
easier.  It's also conceptually closer to what people think of when they say
"description" and "comments".  See bug 99240 for more info.

Updated

12 years ago
QA Contact: mattyt-bugzilla → default-qa

Updated

11 years ago
Assignee: myk → create-and-change

Comment 2

7 years ago
I truely support this. Many times, when looking into an issue, our QA people will be able to create a more descriptive text for the issue. Being able to edit the case description would be great.

Comment 3

7 years ago
This would be handy ... bug reporters could easily collapse/summarize the valid points of hundreds of comments and keep Comment 0 pertinent.

Comment 4

4 years ago
With the addition of tagging in Bugzilla 5.0 (bug 283695), it should be easy to mark a specific comment (rather than the 0 comment) as the true description.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → Bugzilla 5.0

Updated

4 years ago
Target Milestone: Bugzilla 5.0 → ---

Comment 5

4 years ago
(In reply to Ryan Wilson [:f1sh] from comment #4)
> With the addition of tagging in Bugzilla 5.0 (bug 283695), it should be easy
> to mark a specific comment (rather than the 0 comment) as the true
> description.

...which means you'd have to manually scroll down to somewhere, after maybe spotting that "tag" field somewhere among a bunch of other UI fields? Sounds like a crude enough workaround to avoid.

In Phabricator, the initial comment does not "belong" to the bug reporter but can be edited and updated by others, to use it as a summary of the bug report (and reflecting how discussion evolved).
I must say that I like that concept and would like to see the WONTFIX reverted here.
(In reply to Andre Klapper from comment #5)
> (In reply to Ryan Wilson [:f1sh] from comment #4)
> > With the addition of tagging in Bugzilla 5.0 (bug 283695), it should be easy
> > to mark a specific comment (rather than the 0 comment) as the true
> > description.
> 
> ...which means you'd have to manually scroll down to somewhere, after maybe
> spotting that "tag" field somewhere among a bunch of other UI fields? Sounds
> like a crude enough workaround to avoid.
> 
> In Phabricator, the initial comment does not "belong" to the bug reporter
> but can be edited and updated by others, to use it as a summary of the bug
> report (and reflecting how discussion evolved).
> I must say that I like that concept and would like to see the WONTFIX
> reverted here.

This is what BMO uses:
http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=tree;f=extensions/UserStory;hb=HEAD [github]

Comment 7

4 years ago
(In reply to David Lawrence [:dkl] from comment #6)
> This is what BMO uses:
> http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=tree;f=extensions [github]/
> UserStory;hb=HEAD

Ah, nice. Now is that an upstreamed extension? :)
(In reply to Andre Klapper from comment #7)
> (In reply to David Lawrence [:dkl] from comment #6)
> > This is what BMO uses:
> > http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=tree;f=extensions [github]/
> > UserStory;hb=HEAD
> 
> Ah, nice. Now is that an upstreamed extension? :)

Well it is publicly available from our git repo for anyone to grab :) One day when we have the spare cycles, we can start copying over some of our extensions into the upstream repos but low priority at the moment.

dkl
You need to log in before you can comment on or make changes to this bug.