launchpad-dev team mailing list archive

[Martin Albisetti <argentina@xxxxxxxxx>]

First of all, I've continued to think about this since UDS, so if
there are contradictions or new things here, it's because they are  :)
I'm not saying they are better, it's just things have evolved from
conversations and thinking about the problem.


On Sat, Jan 9, 2010 at 1:46 AM, Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx> wrote:
>> 1) New page: a list of bugs ordered by bug heat.
>
> Why a new page?  Why not just use the existing hot bugs section of a
> project's home page?  This is what we talked about when you, Tom, and
> I talked about bug heat at UDS.  Granted we should show more bugs or
> click through to a complete list of bugs with any heat, but why think
> of this as a new page?  It's really just a bug list like any other bug
> list, no?

My use of "new page" is very flexible here. It's mostly to keep our
minds open on what's best to do with this particular listing.


>>    - how to show relative values well (ie, bug 123 is 10 times hotter than
>> 122, which comes right after 123 on the list). One idea would be to color
>> code the background
>
> Citing our talks at UDS again, I thought we talked about some kind of
> heat icon like the flame icon for affected users.  Could we just steal
> the current flame icon since 1) affected users shows the number now,
> and 2) affected users will factor into heat?  We could have differing
> shades of red/orange for levels of heat and/or have slightly larger
> flames for hotter levels.

This is one way of showing it, yes. We need to figure out how it looks
on the listing, and if it's clear enough. The question on how to
distinguish a bug with 1000 heat and another one with 10 is still on
the table, no?


>>    - How do we allow dropping bugs from the list by developers who really
>> don't want it there?  There should probably be a manual knob to do this.
>
-snip-
> I remember discussions about this at UDS with you, and I was never
> fully convinced.  After thinking some more about it, it just seems
> like a bad idea.  I know you're concerned about a bug that a team may
> want to put off working on indefinitely and yet it's still in the list
> annoying them, but I think we need to get the algorithm right so this
> doesn't happen or the project should use Won't Fix or Invalid to be
> honest about intent.

I'm not so much concerned about 1 bug that's up there all the time,
I'm concerned about 20. The purpose of this feature, AIUI, is to bring
to developers' attention bugs that need to be looked at and/or solved.
If developers already have looked at bugs, and decided that they are
not important enough to fix today, then this feature may end up being
useless to them because more people want feature X implemented than
people who's kernel crashes and have managed to file the bug on a
different computer.
I'm worried that with no manual knob, the feature will be rendered
useless in not-too-few cases.


-- 
Martin