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.

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?

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.

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.

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.

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.