Bug mail with full copy of the bug says the bug is NEW when it's not

Bug #194647 reported by Scott Kitterman
6
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

I assign bug 144490 to myself and make a comment that I'm going to try and fix it.

I get a copy of the original bug that screams [NEW] in the subject line. This is wrong. The bug is not new. It's 5 months old. It's also shouting at me.

1. No where did I request a copy of the bug. It's not needed and it's not related to the action that's just been taken.

2. Please don't shout at me. [NEW] is really overkill. If you want people to be able to key off of the first mail they get for a bug, stuff it in an x-header in the message. There's no need to be in my face about it.

(This bug originally also described bug 548 and bug 97633.)

description: updated
description: updated
Changed in launchpad:
importance: Undecided → High
Revision history for this message
Björn Tillenius (bjornt) wrote : Re: [Bug 194647] Re: Bug mail with full copy of the bug says the bug is NEW when it's not

On Sun, Feb 24, 2008 at 10:44:05PM -0000, Matthew Paul Thomas wrote:
> ** Changed in: malone
> Product: Launchpad itself => Launchpad Bugs
> Importance: Undecided => High

Why is this high? Please provide a rationale when you set bugs to be
high priority.

BTW, it could also be argued for that the bug is in fact new. It's new
for you; you haven't seen the bug before. Well, in this case you have,
since you assign the bug to yourself. But how about the case where
you assign the bug to someone else? That person hasn't seen the bug
before.

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

Also, it's not clear what you're arguing for. Should no notification be sent when assigning a bug to yourself? No notification should be sent when assigning a bug to someone else? [NEW] shouldn't be used in 'you have been subscribed' notification? [NEW] shouldn't be used at all?

Changed in malone:
importance: High → Undecided
status: New → Incomplete
Revision history for this message
Scott Kitterman (kitterman) wrote :

1. Subject line tags like [NEW] should not be used. Use an x-header instead. These subject line tags just add to jumble and confusion in the MUA. If you must have a subject tag, please don't make it all caps. All caps is harder to read and is distracting.

2. Definitely don't send me a copy of a bug I assign myself. I already read it.

3. I'd prefer you don't send me a copy of a bug someone else assigns me. Personally, if people are assigning me to work, we should have discussed it already. I can see this one is arguable though.

So I guess the answer is all of the above.

Changed in malone:
status: Incomplete → New
Revision history for this message
Björn Tillenius (bjornt) wrote :

On Mon, Feb 25, 2008 at 04:16:19AM -0000, Scott Kitterman wrote:
> 1. Subject line tags like [NEW] should not be used. Use an x-header
> instead. These subject line tags just add to jumble and confusion in
> the MUA. If you must have a subject tag, please don't make it all caps.
> All caps is harder to read and is distracting.

When the [NEW] tag as added, it was explicitly asked for to have it in
the subject, to make it easier to see when scanning your inbox. You
could file a bug about this, but it's not likely to get fixed anytime
soon. Changing [NEW] to something else would be doable, but not
something we're going to do because one person complains. No matter what
we use, people will argue for that something else should be used.

> 2. Definitely don't send me a copy of a bug I assign myself. I already
> read it.

This I can agree on.

> 3. I'd prefer you don't send me a copy of a bug someone else assigns
> me. Personally, if people are assigning me to work, we should have
> discussed it already. I can see this one is arguable though.

Right, this is not something we want to change. People often assign bugs
to me without discussing it with me first, and I think that's perfectly
reasonably. Not getting the bug context when someone assigns something
to me would mean more work for me.

> So I guess the answer is all of the above.

If it's all of above, this bug report is not likely to get fixed. Please
keep the bug reports as focused as possible. Of the things you listed,
only 2. is likely to get fixed.

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 194647] Re: Bug mail with full copy of the bug says the bug is NEW when it's not

On Mon, 25 Feb 2008 04:52:45 -0000 Björn Tillenius <email address hidden> wrote:
>On Mon, Feb 25, 2008 at 04:16:19AM -0000, Scott Kitterman wrote:
>> 1. Subject line tags like [NEW] should not be used. Use an x-header
>> instead. These subject line tags just add to jumble and confusion in
>> the MUA. If you must have a subject tag, please don't make it all caps.
>> All caps is harder to read and is distracting.
>
>When the [NEW] tag as added, it was explicitly asked for to have it in
>the subject, to make it easier to see when scanning your inbox. You
>could file a bug about this, but it's not likely to get fixed anytime
>soon. Changing [NEW] to something else would be doable, but not
>something we're going to do because one person complains. No matter what
>we use, people will argue for that something else should be used.

Subject line tags in general provide a poor user experience and are bad design IMO. It's not my system so whatever. The current tag is excessivly obtrusive and semantically wrong. 5 months old bugs aren't new. If you insist on tagging at least pick an accurate one.

>
>> 2. Definitely don't send me a copy of a bug I assign myself. I already
>> read it.
>
>This I can agree on.

Great.
>
>> 3. I'd prefer you don't send me a copy of a bug someone else assigns
>> me. Personally, if people are assigning me to work, we should have
>> discussed it already. I can see this one is arguable though.
>
>Right, this is not something we want to change. People often assign bugs
>to me without discussing it with me first, and I think that's perfectly
>reasonably. Not getting the bug context when someone assigns something
>to me would mean more work for me.
>
Well you're a paid developer so that's reasonable. I'm a volunteer so it's rude. I can see why this would be not what I prefer, but overall desireable.

>> So I guess the answer is all of the above.
>
>If it's all of above, this bug report is not likely to get fixed. Please
>keep the bug reports as focused as possible. Of the things you listed,
>only 2. is likely to get fixed.

You're welcome to parse it out into as many bugs as you want. The amount of effort I'm willing to expend on proprietary development projects is limited.

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

When Launchpad says something that isn't true, I mark the bug as High importance, because it makes Launchpad less trustworthy, and that bad reputation persists after the bug is fixed. If the false statement is rare, the bug may be less important. But this particular false statement is extremely common, happening every time someone assigns or reassigns a bug.

Curtis Hovey (sinzui)
Changed in malone:
status: New → Triaged
importance: Undecided → Low
tags: added: email
tags: added: story-better-bug-notification
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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