bugs get cluttered with "me too" comments

Pasting my part of suggestion (from the discussion thread) here.
------------------
May be the button suggested by Martin can have different label depending on the status of bug ex. If the bug is unconfirmed then the label should be 'Confirm the bug'.
I have observed that many times people can't figure out how to confirm a bug and they just keep adding comments. Thus an important bugs is ignored even if it experienced by many people.
------------------

Another suggestion: add a notice requesting users to subscribe to the bug instead of posting "me too"

Confirmation of the bug is definitely separate from it being reproducible in general. I agree with the general feature though -- it's been discussed many times.

I'd like to object to this bug ...

"Me too" comments are actually very useful; they give a good sense of how many people are affected by a bug *and* give you people you can ask for more information when the primary submitter goes AWOL.

The comment instead should say what information "me too"ers should supply; e.g. similar crash reports, or files from their system -- through the comparison, the bug may be found.

Yeah, it's definitely useful to capture the fact that many users are affected. However, I don't think that simply adding comments is the best way to capture this (in particular because it's pretty unstructured). We've been thinking about ways of doing this that also avoid the annoyance factor in a whiny "fix this plz" comment.

One idea we've tried to develop is that of a specific button, displayed in the main bug page, to say "This bug affects me too". We could even provide a follow-up form that allowed the end-user to continue and provide more information related to the environment in which he is experiencing the error.

We might also be able to use the lesson of the answer tracker in which we allow people to use the submit button to indicate what they are doing together with the comment box. I'm not entirely sure this would work, but it might be worth a mockup.

I do not believe this to be a bug at this stage. Having a 'me to' to prove a bug can be reproduced by someone else using the same release and hardware proves that this is a real bug. Recently i reported a show-stopper than turned out to me local to my machine.

I do encorurage development in a 'me too' button - but i think there should be a section to add notes regarding hardware / software and versions of packages.

OMG this bug is effecting me right now. Ive tried all of the workarounds in the comments but none of them work.

What would be raelly awsome is if you could filter bug comments based on "points", alot like the GNOME bugzilla you could say "I only want to read reporter and people highr then 15pts" and all the other comments would be hidden.

Help pls!

I'd agree that the noise generated by "me too"s can make it hard to follow the flow of a bug (and in particular see if it eventually got resolved, for historical ones). Could there just be a web interface option to filter out "non-helpful" suggestions? The metric for helpfulness is debatable, but as a start it could include reporter/flag-changer/maintainer etc?

Can we close this bug now that we have the "me too" feature?

> Can we close this bug now that we have the "me too" feature?

Yes, I think this bug is no longer relevant.

I don't think this bug is no longer relevant. Even with the "me too" feature, people still constantly add useless comments. Even a few simple regular expressions to block such messages would go an extremely long way.

dobey, I agree, let's reopen it. There is a problem here, and Launchpad can do more to cut through the noise. Having 'affects me too' has helped but not solved the problem.

We can do various things including:
 * flagging down low-content comments
 * highlighting useful comments or comments by people important in this context
 * encouraging people to click "affects me" rather than adding a comment - perhaps making it more prominent, perhaps just making it more satisfying to click
 * allowing developers to lock a bug which is attracting noise
 * matching regexps and suggesting something better people can do

There are separate bugs for some of these.

We are pleased to see this. We think the necessity of locking a bug is an extreme rarity though, and of very low importance compared to other plausible solutions to this issue.

I think the first thing to decide is: how would we tell whether this bug is fixed?

Perhaps one way of deciding that would be to take a random sample of comments from bug reports, posted either while the report is open or after it was closed. (Assuming that if a report is closed, me-too comments posted before it was closed no longer matter, but me-too comments posted afterward are still disruptive to subscribers.) Then for each comment, measure its age, and whether it's a me-too comment. That would help you decide on a target for reduction. Some measures -- like after-the-fact moderation -- could work better on old comments than new ones, or vice versa.

Good question, mpt. We need to be clear about just which aspect of
the problem we care (most) about solving:

 * 'me too' comments in mail to developers (would not be fixed by eg
after-the-fact moderation)
 * 'me too' comments cluttering up the bug page and making it hard to
find the important comments
 * users only adding a 'me too' comment, when there is something more
useful they could do such as providing debug information

As Scott noted a long time ago, to some extent 'me too' comments are
useful as they give a sense of the amount of pain caused by a bug.

One surmountable issue in sampling existing bugs is that only a
relatively small fraction exhibit the problem behaviour (perhaps
1-2%).

Martin

On 6 October 2011 02:47, Matthew Paul Thomas <email address hidden> wrote:
> I think the first thing to decide is: how would we tell whether this bug
> is fixed?
>
> Perhaps one way of deciding that would be to take a random sample of
> comments from bug reports, posted either while the report is open or
> after it was closed. (Assuming that if a report is closed, me-too
> comments posted before it was closed no longer matter, but me-too
> comments posted afterward are still disruptive to subscribers.) Then for
> each comment, measure its age, and whether it's a me-too comment. That
> would help you decide on a target for reduction. Some measures -- like
> after-the-fact moderation -- could work better on old comments than new
> ones, or vice versa.
>
> --
> You received this bug notification because you are subscribed to
> Launchpad itself.
> https://bugs.launchpad.net/bugs/93285
>
> Title:
>  bugs get cluttered with "me too" comments
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/launchpad/+bug/93285/+subscriptions
>
>