Comment 5 for bug 194647

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.