Launchpad itself

"Rejected" should be split into "Not a Bug" and "Not For Us"

Bug #36059 reported by Brad Bollenbach
38
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
Medium
Matthew Paul Thomas

Bug 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).

(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.

See original description
Tags: lp-bugs
Brad Bollenbach (bradb)
description: updated
Matthew Paul Thomas (mpt)
Changed in malone:
assignee: nobody → mpt
status: Unconfirmed → Confirmed
Matthew Paul Thomas (mpt)
description: updated
Revision history for this message
Christian Reis (kiko) wrote :

Does Not a bug cover, well, things which are already fixed (and were fixed in some other bug or in an unrelated commit or upload)?

Matthew Paul Thomas (mpt)
description: updated
Revision history for this message
Brad Bollenbach (bradb) wrote :

To me that would be either Fix *'d or a dupe of the other bug.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Ubuntu's Mozilla Team uses "In Progress" to mean Not For Us. Interesting rationale:

<asac> if one can fix firefox bugs et al they go upstream
<asac> so ... "in progress" for us :)
<asac> which means: mozilla team members should regularaly take care that upstream doesn't forget
<asac> but move the bug from confirmed radar
<asac> which means: "This needs work ... and info on what work is needed is available"
...
<mpt> so you'd be able to use "Not For Us" instead of "In Progress" for bugs that you weren't actually ever going to fix yourself
<asac> yeah ... but "not for us" means (as you said about in progress" we don't care
<asac> which is not true
<asac> we want to help users to get a point upstream
<asac> so we should take care that it gets attention ... from time to time

Revision history for this message
Björn Tillenius (bjornt) wrote :

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.

Changed in malone:
status: Confirmed → Rejected
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.