| 2006-03-22 19:59:36 |
Brad Bollenbach |
bug |
|
|
added bug |
| 2006-03-22 20:00:50 |
Brad Bollenbach |
description |
Our Rejected status insufficiently communicates the nature of the rejection.
We should split this into the two types of rejections we want to communicate:
1. Invalid -- i.e. not a bug, or a bug report with insufficient information, and from which no further clarification has been given by the bug reporter
2. Wontfix -- a bug, but not something we want to fix. particularly useful for things like release management. |
Our Rejected status insufficiently communicates the nature of the rejection.
We should split this into the two types of rejections we want to communicate:
1. Invalid -- i.e. not a bug, or a bug report with insufficient information, and from which no further clarification has been given by the bug reporter
2. Wontfix -- a bug, but not something we want to fix. particularly useful for things like release management.
There's an obvious data migration issue here, but we'll (have to) find some way to work around it. |
|
| 2006-03-30 05:20:41 |
Matthew Paul Thomas |
malone: status |
Unconfirmed |
Confirmed |
|
| 2006-03-30 05:20:41 |
Matthew Paul Thomas |
malone: assignee |
|
mpt |
|
| 2006-03-30 05:20:41 |
Matthew Paul Thomas |
malone: statusexplanation |
|
|
|
| 2006-05-10 05:44:10 |
Matthew Paul Thomas |
description |
Our Rejected status insufficiently communicates the nature of the rejection.
We should split this into the two types of rejections we want to communicate:
1. Invalid -- i.e. not a bug, or a bug report with insufficient information, and from which no further clarification has been given by the bug reporter
2. Wontfix -- a bug, but not something we want to fix. particularly useful for things like release management.
There's an obvious data migration issue here, but we'll (have to) find some way to work around it. |
Malone's "Rejected" status insufficiently communicates the nature of the rejection, and can antagonize bug reporters.
Discussion with Malone users has concluded that Rejected should be split into two statuses.
* Not a Bug -- the report does not describe a reproducible bug affecting the software (for example, there is not enough information, or the reported behavior is by design)
* Not For Us -- the report does describe a reproducible bug affecting the software, but fixing it in this context is inappropriate (for example, it should be fixed in a toolkit or kernel instead, or the bug is not important enough to backport the fix this release).
There's an obvious data migration issue here, but we'll (have to) find some way to work around it. |
|
| 2006-05-10 05:44:10 |
Matthew Paul Thomas |
title |
Rejected status should be split into Invalid and Wontfix |
"Rejected" should be split into "Not a Bug" and "Not For Us" |
|
| 2006-06-30 11:21:51 |
Matthew Paul Thomas |
description |
Malone's "Rejected" status insufficiently communicates the nature of the rejection, and can antagonize bug reporters.
Discussion with Malone users has concluded that Rejected should be split into two statuses.
* Not a Bug -- the report does not describe a reproducible bug affecting the software (for example, there is not enough information, or the reported behavior is by design)
* Not For Us -- the report does describe a reproducible bug affecting the software, but fixing it in this context is inappropriate (for example, it should be fixed in a toolkit or kernel instead, or the bug is not important enough to backport the fix this release).
There's an obvious data migration issue here, but we'll (have to) find some way to work around it. |
Malone's "Rejected" status insufficiently communicates the nature of the rejection, and can antagonize bug reporters.
Discussion with Malone users has concluded that Rejected should be split into two statuses.
* Not a Bug -- the report does not describe a reproducible bug affecting the software (for example, there is not enough information, or the reported behavior is by design)
* Not For Us -- the report does describe a reproducible bug affecting the software, but fixing it in this context is inappropriate (for example, it should be fixed in a toolkit or kernel instead, or the bug is not important enough to backport the fix this release).
(Other names considered for "Not For Us" included "Won't Fix Here", rejected by mdz and Keybuk because it was too similar to "Won't Fix"; "Forwarded", rejected because the bug report hasn't necessarily been forwarded; "Escalated", rejected for the same reason, and also because it seemed like a priority marking; and "blocked", rejected because the bug's still entirely fixable. <https://lists.ubuntu.com/archives/ubuntu-devel/2006-April/017545.html>)
There's an obvious data migration issue here, but we'll (have to) find some way to work around it. |
|
| 2007-06-04 07:42:21 |
Björn Tillenius |
malone: status |
Confirmed |
Rejected |
|
| 2007-06-04 07:42:21 |
Björn Tillenius |
malone: statusexplanation |
|
I'm rejecting this since it's been decided that Rejected should be split into "Invalid" and "Won't Fix". This work is tracked in the BugWorkflow spec. |
|
