On 15 November 2011 23:51, Martin Pool <m...@sourcefrog.net> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
