launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

On Mon, Jan 11, 2010 at 8:07 AM, Martin Albisetti <argentina@xxxxxxxxx> wrote:
> 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.

Right, I do understand that.  I just want to acknowledge prior
conversations both for the sake of people on the list not aware of
those conversations and to try to build on what was said before,
rather than start from scratch.

I prefer iterative design to starting over. :-)  Perhaps the start and
stop rhythm we've had on the bugs team the last 2-3 months as we've
had these kinds of discussions has me a little sensitive to this.  I
meant no offense in my constant reminder of UDS. :-)

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

Fair enough.

>
>
>>>    - 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?
>

I assumed there would be X different icons/indicators representing
varying degrees of hotness.  So as a simple example, let's say there
are 3 icons (I think in practice 5-7 is more appropriate) --
low_heat_icon.png, med_heat_icon.png, and high_heat_icon.png.  The
total group of hot bugs would be split into these categories based on
the heat numbers for that project.  A heat of 500 might be low for an
active project with 1000 bugs having some heat value but high in a
project with only 20 bugs with a heat value.

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

I do understand the concern.  I would prefer we find programmatic ways
to achieve this -- reacting to status or importance changes, for
example -- rather than a manual "get this bug out of my face" button.
:-)


Cheers,
deryck


-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/