launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #08416
Re: Bug list ordering
On 15 November 2011 23:51, Martin Pool <mbp@xxxxxxxxxxxxxx> wrote:
> Unifying the top-level page with +bugs has value in itself, just so
> that you can start searching and sorting without doing anything else.
>
> We ought to consider what people are trying to do when they visit that
> page. One likely thing is to file a new bug; I wish they could start
> typing and at least kick off the dupefinder, without a separate page
> load.
This is why I see Dashboards and Activity Walls as two sides of the
same coin: what we're really attempting to do with those two projects
is to make pages such as bugs.launchpad.net/bazaar more useful, both
in terms of getting a view of what's happening in those bugs and in
terms of kicking off the thing you want to do.
> For projects I work on, I think the views I typically want to see are,
> in rough order:
>
> * inprogress bugs, including the assignee
> * new bugs, needing triage
> * recently changed bugs
> * bugs affecting me
> * critical bugs
> * highest-impact/highest-heat bugs
> * recently closed bugs
>
> For projects where I am just a user I would like to:
>
> * see the ~hottest bugs, to know if the thing I'm hitting is already known
> * report a new bug
> * get a feeling for what the project is doing and what they're working on
Thanks for this.
> Across Launchpad generally closed bugs are very hard to find, but
> recently closed bugs are often very interesting.
>
> I wish we would use some metrics to infer what people are actually
> trying to do. Which bug sort orders are most common? Which portal
> links do they click? I wonder if we can make the bugs home page
> remember what the user wants to see, then consider making the most
> popular ones the default.
With Custom Bug Listings, you'll be able to save your chosen bug
ordering and the info you want to see in a bug listing. So, that's a
start towards that.
> Perhaps changes we make to the bugs home page can be done with a view
> to eventually having just one product-wide home page.
So, I think a project activity wall with a filter for
bugs/code/blueprint/whatever info is where we want to go. And then
somehow (my hands are waving in between words) we have a project
dashboard that shows you what you can do next.
> Something like heat, as a gestalt metric of 'impact' of bugs, has
> potential value as an ordering between bugs (especially if the inputs
> and their weightings are improved), to give you a gestalt of which
> bugs have the most impact. However, showing it as a number or on a
> scale seems pointless: "four flames" never consistently means anything
> other than that the context for the bug probably has few bugs in it.
> I agree the heat is both skewed by overweighting was-once-private
> bugs, and also boring in that bugs eventually get stuck there.
I'm replying not only to you here but to everyone who has spoken about
bug heat: just like our other controversial and, to most people,
arbitrary number, we need to fix this. We need to better understand
what value bug heat can bring to people and what they understand it to
mean. We have, I think, pretty vague and different answers to these
and we can't hope to fix bug heat until we actually know what people
want from it.
While we're not fixing bug heat right now, it's something I think we
could do as a bit of a guerilla operation. Dan and I can start looking
at what people need from bug heat.
--
Matthew Revell
Launchpad Product Manager
Canonical
https://launchpad.net/~matthew.revell
References