Comment 6 for bug 231316

I think my original explanation tripped up a bit on terminology, because it's difficult to talk about bugs in a bug reporting tool without being confusing. In this message, I'll talk about bug^1s (ordinary bugs) and bug^2s (bugs in the bug reporting procedure).

The central question is the quantity and quality of bug^1s reported with reportbug. If we got a steady stream of repeatable, reliable bug^1 reports from people that responded to e-mail, it would be worth putting in the effort to make reportbug a viable bug^1 reporting channel. On the other hand, getting one bug^1 a year of the form "I downloaded Debian Ubuntu and now my Internet is acting kinda funny, kthxbye" isn't worth the hassle.

This report is about a bug^2 in the proper destination for bug^1 reports. I'm suggesting that we send bug^1 reports to the maintainers (ubuntu-motu) for a trial period, so that the maintainers can gather information about which of the above scenarios is closer to the truth, then provide an appropriate fix to the bug^2 based on the evidence. We could even have an explicit period - say, 10 bug^1s or 10 months, whichever comes first.

I completely agree that sending bug^1s to the ubuntu-motu list isn't an appropriate way of dealing with bug^1s, but it seems to me the best way of gathering enough data to make a proper determination about how to fix the bug^2.

Launchpad is designed to check that a user has an e-mail address that they respond to before allowing them to send bug^1s, whereas reportbug is designed to allow reports from anyone that can send an e-mail. This is a legitimate design difference in the amount the amount of signal you're prepared to lose in the fight against noise, and is not a bug^2 in either program. Although there are certainly things LP can do to make bug reporting easier for one-timers, and to some extent there are things that reportbug can do to dissuade drive-by bug reports, it's not worth the pain of finding a compromise until we know the quantity and quality of bug^1s we'd be getting.

In terms of name changes, I would prefer that either "report" or "bug" be removed from the package name. My assumption is that most incorrect uses of the package come from people not really paying attention, so it should be impossible for users to hunt through the repository, see "report" and "bug", then ignore the words they don't want to see. Of course, I'd prefer this assumption be backed up with evidence before any decision was made :)