individual bug reports can become very noisy and confused when unrelated comments, tasks and other links are created

Bug #73122 reported by Matthew Paul Thomas on 2006-11-24
82
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

In some situations a bug report gets out of hand, such that everyone would benefit if commenting and other changes were restricted.

One situation is bug 1, a phenomenon all to itself: as of May 2009 it contains 51 inappropriate contexts or release nominations, and 1014 comments, including one "Can anyone teach me how to use this site?" comment and one reference to Hitler. In this case, the report should perhaps be closed to new comments and new nominations.

A second situation is where many people begin replying to disruptive comments: for example, in bug 300023 a subscriber's laptop was stolen and inappropriate messages were sent from his account to the bug report, and multiple people responded by e-mail, causing a cavalcade of irrelevant comments. In cases like this, the report should perhaps be closed to new comments temporarily (in the same way that Wikipedia articles are sometimes temporarily locked down).

A third situation is where a controversial decision appears in a bug report, and the report attracts so many comments that it becomes unusable for development. For example, if bug 332945 was still open, the sheer number of comments would make it rather impractical for tracking development work.

We should choose appropriate ways of handling these problems, and implement them before they are needed further. Other possible approaches include:
* Recommend marking bugs private if they're getting out of control. If so, we should suggest that in the interface. (That approach would kind of defeat the point of bug 1, though.)
* Recommend marking out-of-control bug reports as duplicates of new bug reports. (This is the approach used in bugzilla.mozilla.org.) If so, we should suggest that in the interface. (This approach would ruin the poetry of bug 1.)
* Let sufficiently qualified people delete inappropriate "Affects" lines (an extension of bug 1342 and bug 3140) and comments (bug 1734). We will probably have to do this anyway, so admins can handle highly offensive comments (or Affects lines for highly offensive products) when the DBA is asleep.
* Let any assignee or bug contact lock down a bug report (a superset of bug 73419) so that it can be altered only by the reporter, relevant assignees, bug contacts, drivers, or registrants.

Matthew Paul Thomas (mpt) wrote :

After I posted this bug report, bug 1 attracted a persistent vandal until it was manually converted to a static page. This approach was not included in my original list, because it won't scale.

towsonu2003 (towsonu2003) wrote :

I'd prefer choice #4 personally as an ordinary user

Martin Pool (mbp) wrote :

I'd like #4 too, comparing it to what's done on wikipedia. It might be good to allow an explanation to be shown, set when the bug is locked.

description: updated
Changed in malone:
importance: Undecided → Medium
status: New → Triaged
description: updated
Martin Pool (mbp) wrote :

https://bugs.edge.launchpad.net/ubunet/+bug/375272/comments/13 is another case

http://blog.sourcefrog.net/2009/05/soap-opera-bugs.html - it occurs to me when we do lock a bug, we should point people to some other place where they *are* encouraged to talk about it, otherwise they'll just file dupes or something similar. This could be as simple as allowing the person instituting the lock to specify a linkified message.

Jonathan Lange (jml) on 2010-12-07
tags: added: ubuntu-platform
Changed in launchpad:
importance: Medium → Low
summary: - Need strategy for stopping pandemonium in individual bug reports
+ individual bug reports can become very noisy and confused when unrelated
+ comments, tasks and other links are created
Curtis Hovey (sinzui) on 2012-07-09
tags: added: bug-links
Curtis Hovey (sinzui) on 2012-12-19
tags: added: comments
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers