| 2006-11-24 11:09:47 |
Matthew Paul Thomas |
bug |
|
|
added bug |
| 2007-08-22 03:58:25 |
Matthew Paul Thomas |
description |
In bug 1 it's interesting to see the many different opinions people have about achieving world domination, but things are starting to get a little out of control. There have already been multiple inappropriate invocations of the "Also Affects..." command, 235 comments, one "Can anyone teach me how to use this site?" comment, and one reference to Hitler.
It is also likely that in future, highly controversial decisions will occasionally appear in other bug reports, and these bug reports will attract so many comments that they become unusable.
We should choose which is the appropriate way (or ways) of handling this problem, and implement it *before* it's needed. There are perhaps four possible approaches.
1. 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.)
2. 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.)
3. 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.
4. Let any assignee or bug contact lock down a bug report so that it can be altered only by the reporter, relevant assignees, bug contacts, drivers, or registrants. |
In bug 1 it's interesting to see the many different opinions people have about achieving world domination, but things are starting to get a little out of control. There have already been multiple inappropriate invocations of the "Also Affects..." command, 235 comments, one "Can anyone teach me how to use this site?" comment, and one reference to Hitler.
It is also likely that in future, highly controversial decisions will occasionally appear in other bug reports, and these bug reports will attract so many comments that they become unusable.
We should choose which is the appropriate way (or ways) of handling this problem, and implement it *before* it's needed. There are perhaps four possible approaches.
1. 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.)
2. 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.)
3. 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.
4. 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. |
|
| 2008-08-26 13:20:40 |
Björn Tillenius |
malone: status |
New |
Triaged |
|
| 2008-08-26 13:20:40 |
Björn Tillenius |
malone: importance |
Undecided |
Medium |
|
| 2008-08-26 13:20:40 |
Björn Tillenius |
malone: statusexplanation |
|
|
|
| 2009-05-08 10:09:53 |
Matthew Paul Thomas |
description |
In bug 1 it's interesting to see the many different opinions people have about achieving world domination, but things are starting to get a little out of control. There have already been multiple inappropriate invocations of the "Also Affects..." command, 235 comments, one "Can anyone teach me how to use this site?" comment, and one reference to Hitler.
It is also likely that in future, highly controversial decisions will occasionally appear in other bug reports, and these bug reports will attract so many comments that they become unusable.
We should choose which is the appropriate way (or ways) of handling this problem, and implement it *before* it's needed. There are perhaps four possible approaches.
1. 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.)
2. 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.)
3. 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.
4. 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. |
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. |
|
| 2010-09-07 09:41:51 |
era |
bug |
|
|
added subscriber era |
| 2010-12-07 17:44:26 |
Jonathan Lange |
tags |
|
ubuntu-platform |
|
| 2011-03-23 23:33:41 |
Robert Collins |
launchpad: importance |
Medium |
Low |
|
| 2011-03-23 23:34:24 |
Robert Collins |
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 |
|
| 2011-05-30 02:17:09 |
Robert Collins |
removed subscriber Launchpad Bug Contacts |
|
|
|
| 2012-07-09 20:57:19 |
Curtis Hovey |
tags |
lp-bugs ubuntu-platform |
bug-links lp-bugs ubuntu-platform |
|
| 2012-12-19 18:04:45 |
Curtis Hovey |
tags |
bug-links lp-bugs ubuntu-platform |
bug-links comments lp-bugs ubuntu-platform |
|
| 2014-03-13 12:58:54 |
Curtis Hovey |
removed subscriber Registry Administrators |
|
|
|
| 2014-03-13 13:03:41 |
Curtis Hovey |
removed subscriber Registry Administrators |
|
|
|
| 2014-03-13 16:08:50 |
Curtis Hovey |
removed subscriber Registry Administrators |
|
|
|
| 2014-03-13 16:08:58 |
Curtis Hovey |
removed subscriber Registry Administrators |
|
|
|
| 2014-03-13 16:09:09 |
Curtis Hovey |
removed subscriber Registry Administrators |
|
|
|
| 2018-01-19 21:19:11 |
Chris Jones |
removed subscriber Chris Jones |
|
|
|
