225751 - Separate comment section(s) for political/nontechnical comments.

Status: RESOLVED DUPLICATE of bug 283695

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[John A.]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916

Some bugs attract lots of ire about their being fixed/not fixed, and they
attract a lot of comments that don't pertain to how to fix the bug or work
around it until it's fixed. The comants may be about whether or not, for
non-technical reasons, the bug should be fixed. They may be about finding
someone to fix it. They may be personal attacks against the owner, the driver,
or other commenters.

What they all have in common is that they are counterproductive. It seems
sometimes the more people there are who are mad about a bug and commenting to
that effect, the less inclined programmers are to work on it. One cause of that
phenomenon is that it becomes hard to find useful info among the noise.

One solution: remove the noise. Let the bug owners remove off-topic comments and
things will be clearer.  But the sheer volume of comments can be indicative of a
bug itchin' to be fixed, so how to preserve that?  Split the comments into two
or more sections, letting commenters pick a section when entering the comment,
and letting the owner move (but not delete) comments after the fact.

I propose that the main comments, shown by default, be the constructive &
informative technical comments. Opinion/complaint/compliment comments will be in
another section, accessed only when one clicks on a link to that section. There
could also be another section just for works/doesn't work comments. The number
of comments in each section (and maybe the date of the last one) should be
displayed along with the links to the sctions.

I think such compartmentalization of comments could help make bug owners' jobs
less difficult, while maintaining the voice of the political side of things.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Aleksey Nogin]

Not sure this is the best way to handle the problem, but confirming this as a
valid RFE.

Comment 2

[Peter Lairo]

Although the newsgroups currently exist for this purpose, I think that there
should be a more immediate "link" between a bug and discussion on its merits.

The ability to "discuss" a bug may be a very powerful tool for bugzilla, but
only if it is implemented in a useful and non-obstructive way.

Since the poster didn't give specific specifications on how this should be
implemented, where should the discussion on how to best implement this take
place? ;-)

Nevertheless, i suspect a wontfix may be the fate of this bug.

Comment 3

[John A.]

I don't know enough about the guts or back-end of Bugzilla to say how it would
work entirely, but I can make suggestions from a UI point of view.

When viewing technical comments...
  Have a link to the discussion comments above the first technical comment
(below the description.)
  Instead of "Additional Comment #xxx" say "Technical Comment #xxx"

When viewing discussion comments...
  Have a link to the technical comments above the first discussion comment
(below the description.)
  Instead of "Additional Comment #xxx" say "Discussion Comment #xxx"

Keep a separate count for each comment section.

Link "comment xxx" to comment xxx of the same type.

Link "discussion comment xxx" and "tecnical comment xxx" (or "tech comment xxx")
to comment xxx of the specified type.

Comment 4

[Lewis Jardine]

How about a slashdot-style moderation system? +5 - technical, -1 - flamebait,
that sort of thing?

Comment 5

[Hixie (not reading bugmail)]

What I've proposed in the past is that comments should have a drop down next to
them that lets the user select the kind of comment:

  Steps to reproduce   -- the zeroth comment, and updates e.g. new testcases
  QA technical         -- discussion on the validity of the bug, testcases, etc
  Developer technical  -- discussion on finding the bug, patches, reviews, etc
  Solution discussion  -- discussion on how the bug should be fixed
  Advocacy             -- "me too", "i want this fixed", "why is it not fixed"
  Managerial           -- "P1", "mozilla2.3++", "ADT-"
  Process              -- "changing summary", "adding keywords"

When entering a comment you would pick the appropriate field; your user settings
would let you set the default setting; you could change the flag of existing
comments; you could change the view to show a subset of the above; you could
change your e-mail settings to include only certain types of comments.

Comment 6

[Andrew Sayman]

A slashdot style moderation seems like overkill. Bugzilla can easily
differentiate between owner and not-owner, but should it need to decide who can
moderate and who cannot? On bugs with lots of noise, the public clearly would be
moderating the off-topic stuff right to the top trying to get their favorite bug
fixed. In a system like this, the power to change a post's position really
should be in the hands of the owner. 

Comment 7

[Vidar Haarr (not reading bugmail)]

Hixie's system sounds great! You should also - ofcourse - be able to select
which comments to veiw when viewing the bug. For example next to the
comments-box (or below, whatever), there should be a multiple-select list that
when clicked would pour out the comments. It could be JS, with all the comments
stored in arrays. That way you don't have to reload the page.

Comment 8

[Aleksey Nogin]

I like Hixie's system too. Ideally, people should be able to select their
default category in the user prefs, so that the deafult category would
correspond to the kind of comments they make the most often. For the new users,
the default category may be set for Advocacy ;-)

Also, the categories may not necesserily be exclusive - I this it is reasonable
to allow comments to belong to more than one. And, of corse, the category marks
on a comment should be editable by people with sufficient permissins so that
comments inappropriately categorized by novice users could be moved into the
appropriate categories.

Comment 9

[John A.]

I like Hixie's proposal too.

A few additions to his categories, though:

  Owner's comments
  Original Poster's comments
  Patch submitters' comments

Those would be automatically flagged, and only offered in the UI as chioces for what comments to see or be emailed. The original poster won't change over time, so a comparison of existing fields will suffice. The owner might change over time, though, so comments should be flagged as owner/non-owner and have those flags persist so that past owners' comments will still be flagged as such.

Just brainstorming a couple more options: A less useful, and I imagine more complex to implement, option would be to see/recieve all comments from all current & past owners, whether they were posted when the user was an owner or not. I suppose it could be done by a combination of each user having per-bug commenter white/black lists and an option to automatically add the poster of any owner comment to the whitelist. Yeah, this might be too complex to be worthwhile. Just go with adding the Owner, Patcher & OP comments to Hixie's scheme. :)

I'd also add a line to emailed comments mentioning how many were skipped since the last was sent, and/or maybe a periodic skipped message count update every so many days/comments. It might be interesting to know when a brouhaha is boiling up.

Comment 10

[KLB]

The idea of being able to comment on or advocate for a bug without cluttering the technical discussion to fix a bug is an excellent idea. It would allow Joe Public (e.g. someone like me) to say hey this bug really does have an impact on my user expierence and maybe help Mozilla developers take notice of bugs that impact lots of users.  At the same time it would allow developers to filter out the "noise" so that they can focus on the issue.  It may have been suggested three years ago, but it is a great idea.

Comment 11

[Timwi]

As a programmer, to be honest, I would consider Hixie's system to be overkill. In the end the only differentiation that is really needed is "useful" and "useless", or "signal" and "noise" (but I'm sure you can all find better euphemisms). I would welcome a system in which every comment is "useless" by default, and only people with special access rights can mark a comment as useful (just like you need special access rights to change the keywords of a bug, say).

The implementation would be relatively trivial. The database table holding the comments would simply need an extra column. If you make that column an integer (as opposed to a boolean), then it is already extensible enough to cover Hixie's system should it turn out to be wanted or necessary in the future. But if the simple system is implemented first, you won't need to worry about the categories, nor about a UI to set up those categories, nor any complex UI for deciding what comments to display. There would be only two views: useful comments, or all comments.

Is anyone already interested in implementing this? If not, I might volunteer to have a quick look at the code and see if I can develop this. Hixie's system, however, I must truly admit I wouldn't be able to motivate myself enough for.

Comment 12

[KLB]

(In reply to comment #11)
> In the end the only differentiation that is really needed is "useful" and
> "useless", or "signal" and "noise" (but I'm sure you can all find better
> euphemisms).

I might suggest "Technical (bug fixing)" and "Non-technical (advocacy)". 

> The implementation would be relatively trivial. The database table holding the
> comments would simply need an extra column. If you make that column an integer
> (as opposed to a boolean), then it is already extensible enough to cover
> Hixie's system should it turn out to be wanted or necessary in the future. But
> if the simple system is implemented first, you won't need to worry about the
> categories, nor about a UI to set up those categories, nor any complex UI for
> deciding what comments to display. There would be only two views: useful
> comments, or all comments.

This is very simple and elegant solution. Instead of flagging all comments as "non-useful" by default, I might recommend a drop down "select" box to allow the commenter to flag their message in the proper fashion that defaulted to "non-technical".  Any inappropriately flagged messages could be reflagged.  Allowing comment submitters to flag their messages with a default of non-technical might help reduce the amount of comment administration required and would probably help prevent "useful" comments from getting lost as "non-useful."

The real beauty of the suggested solution is that it will provide for a "pressure relief" for users who are frustrated by a bug but can not provide a technical solution.  It would also allow developers to get a better feel for "popular" bugs that really impact on user experience more than developers realize (e.g. the long tooltip bug https://bugzilla.mozilla.org/show_bug.cgi?id=45375 ). 

Comment 13

[Gyozo PAPP]

(In reply to comment #10)
> ... At the same time it would allow developers to filter out
> the "noise" so that they can focus on the issue. 

"Closed source" companies using Bugzilla like the one I'm working for
can benefit from this feature a lot, too. Long debates how to fix a bug among programmers usually ends up in a simple "ask" flag to technical manager (or QA members) what to do/which solution to choose, etc.

However, these folks are overloaded by tons of mails day by day, so they are ignoring almost all non-personal e-mails (bad habit though) to less the mail flood. At the same time they are insisting the developers or their leaders to provide a more or less full *summary* about the bug status and the possible solutions along with the question/flag.

I think if everyone could controll how deep he wanted to look inside when visiting a bug, it could help our developers. The technical managers and directors should use a high (comment) level presenting only comments with the highest importance describing a solution or a different approach. This way developers don't have to duplicate comments to make summaries when they only want to ask their boss(es) what to do.

Additional benefit would be that false or invalid (and tainted) comments can be discarded simply by setting the level of those to a special value which means never show to anybody. (Of course, if someone is very interested in ...)

> It may have been suggested three years ago, but it is a great idea.
Yes, indeed.

Comment 14

[Daniel Mota Leite]

this bug is related to bug 180040, but not sure if enough for block/depend

Comment 15

[Frédéric Buclin]

I don't think we will differentiate comments besides "important/unimportant" (which is bug 283695). We had this discussion several times elsewhere (other bugs and on IRC) that Bugzilla is not and will never be a forum. Implementing this would encourage people to complain even more and add useless comments. So we will limit ourselves to what bug 283695 suggests.