getting first comment from longdescs for RSS support

[Christopher Hicks]

On Sun, 13 Feb 2005, Gervase Markham wrote:
> Stuart Donaldson wrote:
>> Actually, this reminds me of a question I was going to ask.  Is it really 
>> best to have the Long description be the first comment?  Wouldn't it be 
>> better to have a separate field for this, and then allow editing the long 
>> description (with change tracking of course) so it can be revised?  I have 
>> often questioned the fact that you must always read through a rather long 
>> list of comments to understand the bug because sometimes comments will 
>> clarify the initial description.
>
> There's a request for enhancement on this. Myself, I'm not convinced. If the 
> bug changes purpose enough that the description is out of date, a new one 
> should be opened. Allowing people to edit the description means that some 
> comments based on the original description may then not make sense.
> The status whiteboard is useful for short changeable notes.

I agree that the status whiteboard is very handy.  But to say that a bug 
has changed purpose because it has been clarified doesn't make sense to 
me.  Its pretty common for an initial bug report to be incomplete and need 
to be clarified.  The historical initial report is still in the database 
and could be displayed to provide context so there's no case here for 
confusion being created.  Having the "current bug description" be a real 
field (with version tracking if desired) so that people new to a bug could 
read what it is currently about without dredging though all of the history 
of comments.  Having the current description reference certain comments 
might even help tie it all together.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)