Keeping Bugs Concise

[Chris Wagner]

On Thu, 2006-06-22 at 09:20 +1200, Matthew Paul Thomas wrote:
> On Jun 22, 2006, at 7:21 AM, Chris Wagner wrote:
> > Furthermore, I was hoping to make some suggestions on the spec, but am
> > unable to edit the corresponding wiki page.  How might I offer these
> > ideas up?
> > ...
> 
> The best place to do that would be here on this mailing list.

Well, this kind of stinks; now I can't even access the spec's wiki page
( https://launchpad.canonical.com/KeepingBugsConcise ):
"The Launchpad development wiki is not available to the public."

I was going to look over that again, to, hopefully, remember some more
of the suggestions I was going to make.  Let's try anyway...

How do you intend to encourage users to update the "bug description",
rather than post comments?  I think there is a good idea here, though,
I'm not sure if "bug description" implies that you want as much solid
information in there as possible...

The way I see it, you want to have a main bug description/status that
tells the bug viewer as much solid information as is known about the
bug.  Then, comments are more for talking about the bug; once a
conversation (through the course of several comments) concludes
something, it should be placed in the "bug description".

Bugs need to be more like wiki pages.  The model used for specifications
seems to work very well: you've got an organized pile of information
that evolves; things are added, removed, and improved to make the
overall vision clearer.  You often have comments at the bottom, but once
they have served their purpose, they can be swept away.  Bugs work
differently: they're more like a conversation; the comments do not
"evolve".  Rather than become clearer, a bug report usually becomes less
clear and harder to decipher, as time goes on.  And, many bugs are
around as long as / longer than their counter-part wiki-based specs.  I
wouldn't strictly suggest a wiki page for each bug, though...

So, I guess I don't have any solid suggestion in the above.  I think
this is the direction you're headed in, but I'm curious to know how you
will encourage this type of collaborative evolution for bugs -- because
I don't think "comment folding" will do it alone (although it's a damned
good start).

I do have one solid suggestion, however.  I'm not sure if it's actually
a good one, but it's worth considering: If multiple-comments-in-a-row
are "folded", you could further fold those comments into a single "box";
example:
---------------------------------------------------
| 3 comments made from 2006-06-23 to 2006-07-07... |
---------------------------------------------------
Now, you probably wouldn't want to "fold the 3 folded comments" using
dynamic HTML / JavaScript; that might be a bit confusing.  But if you
fold them up like that upon refreshing the bug's page, it probably would
not cause much confusion and would help to keep things more tidy.  Upon
"expanding" that 3-comment-fold, the user would be presented with 3
still-folded, but separate, comments.

I'd also like to point out that, I think this specification is very
important for allowing "casual" bug reporters and volunteers to make a
difference.  I try to help out the community in any reasonable way I
can, but as far as bugs go, sometimes I feel like more of a burden than
a help; some of the bug reports I've made are completely littered with
junk, now, and, there's little I can do about it (I'll save you the
example, because you know what I mean).  It's as if I need a way to say
"ignore all of the comments below; they are rubbish.  just look at this
description", but I don't think that's the proper way to go about it.

Okay, that's all I've got for now.  Thanks.

Chris Wagner