Closed Bug 532474 Opened 15 years ago Closed 14 years ago

Add an up/down vote option to bug comments

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P5)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: kainhart, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: 

I think it would be useful to have an up/down vote option to bug comments similar to how StackOverflow.com and Digg.com do. 

The idea is that each comment would start with a rating value of 0 (which may require no additional database storage if a side table is used) and would change it's value after each user votes it up or down. This value then could be use to week out chatter or abusive comments of which normally cannot be deleted/edited due to bugzilla's design. Each user could then have a preference to hide/collapse comments below a certain threshold. 

In order to ensure that important comments are not ignored or hidden, comments made either by certain users or users of a particular group could be seeded with a non-zero rating value such as 1 or 2 this way it would exceed a low threshold. Anonymous user's comments may start of with -1 and so on to give less priority to such comments.

Adding up/down voting on comments would enhance the relationship between a particular comment and other users/developers opinions rather than than the traditional method of just replying with a comment and would be less wasteful as far as storage in the database.

Also it has been discussed separately (bug#346370) but up/down voting could be an alternative solution for dealing with abusive comments as well. Once a comment is down voted to a certain level an email could be sent to an administrator/moderator who then may be able to either delete the comment or take other action.

Related Bugs:
bug#322086
bug#346370

Reproducible: Always




If this would be too expensive to save in the database then I think it would be acceptable to at least store it in the local browsers cookie. This won't help those who use multiple machines unless they use some kind of cookie sync utility but it would still add to the user experience and provide a way to manually cut out noisy comments which add no value to the issue being discussed.
Priority: -- → P2
please disregard the comment at the bottom of the bug description. It was included by accident and was meant for a different bug report submission.
This is probably more extension material than anything, if you wanted it. I don't think a bug-tracker is a social networking or Digg-like system.
Priority: P2 → P5
Hardware: x86 → All
I understand your point of view but if you look at how effective this system is with systems such as StackOverflow.com using elements learned from social networking can improve products which are not traditionally viewed as social in nature. 

Truthfully though, I believe Bugzilla and other issue tracking systems are social and collaborative in nature to the point where they don't have to be thought of as so differently than like Digg. This is already evident by the voting system that is in place in Bugzilla.

If this is better off as an extension then so be it. From my perspective however, the benefits offered by up/down voting individual comments or some other similar feature will become essential as Bugzilla installations grow larger and as more diverse sets of people such as developers, vendors, technical support, QA, and end users all start to make use of the system.

With regard to creating an extension, do you have any pointers on how one would go about creating such extensions? Must they be written in Perl? I'm a C# developer and big Bugzilla advocate and wouldn't mind developing extensions for use with Bugzilla such as this but I'm not sure how complicated it is or whether I can do so without learning a new language.
Ok, so I think I found the necessary documentation to understand what is available through Bugzilla extensions. Unfortunately in my case it would probably be easier to write a new front end in C# (at least for the pages that I need) that hits the database directly rather than try to learn perl to the level needed to know how to create an extension.
I agree that per-comment voting is unhelpful in a bug tracker. We won't implement it upstream.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Hey Jeff. Sorry that I didn't see your comments in response to mine--I wasn't on the CC list. 

Given that the Bugzilla frontend is somewhere around 50 thousand lines of code, and the required extension would probably be at most 2000 lines of code, I suspect that any amount of time spent learning the very little Perl required would be a good investment, particularly since Perl's syntax is basically C-like with some extra oddities. 

The documentation for extensions is here:

  http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Extension.html

We're very helpful on IRC and on the support list to people writing extensions, so we'd be glad to assist you with any questions you'd have.

The reason I don't think this would be useful in Bugzilla is that comments are a historical record of discussion of a bug. Adding voting here would be like adding voting to individual responses in a forum thread--not helpful unless you're looking for a single answer, like stackoverflow.
I would like to see this bug re-opened, in the following context: 

In popular projects, major bug reports often get filled with comments that, while not spam, are completely irrelevant to the process of report-triage-fix that they are intended for. These 'not-quite-spam' posts are time-consuming to read, break the flow of discussion about how a bug should be fixed, and the majority of the community would be better-off they were not shown by default. 

In particular, I refer you to the slashdot comment-folding method; I suggest something like this, where comments are never re-ordered and where un-useful comments are folded in, but available for viewing on request. 

I would suggest that 3+ downvotes from users, or 1 from the bug owner or devs would fold a useless comment, or something like this

I feel that this really should be default behaviour, and I would like to see it in 4.0 if possible (this thread alleges that it would be easy to implement ... )

Eg. https://bugs.freedesktop.org/show_bug.cgi?id=11227
James: The vast majority of Bugzilla installations are in-house systems at closed-source software companies with no public-facing interface. Thus, social features like comment voting wouldn't be useful to the vast majority of Bugzilla installations. Sure, it might be useful to public-facing installations, but for those, an extension for Bugzilla 3.6 and above can be written (which would allow people to use the feature right now, and not even have to wait for 4.0!).
Max (comment#8): I'm the one who proposed this feature and I would like to use it specifically for an in-house system at a close-sourced software company. Specifically, the need was realized when we started considering allowing our tech support group have access to our Bugzilla system to help contribute. The problem however is that some developers voiced worry that tech support personel may contribute irrelevant or erroneous comments to a bug by accident. Since turn-around with these employees is generally shorter than a typical developer proper training and supervision is always a problem. So the implementation of the voting system is really a less destructive and fair alternative to the ability to delete or retract comments.

I agree that this could probably be written as an extension however from what I've seen so far the available extensions for Bugzilla seems pretty sparse and there doesn't seem to be a whole lot of community support in creating these extensions. So when a feature is suggested as better off as an extension all I hear is "sorry this feature will never exist in Bugzilla". One way or the other I hope this feature will be introduced in some capacity since we would like to make use of it.
You need to log in before you can comment on or make changes to this bug.