launchpad-dev team mailing list archive

[Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>]

Hello Launchpaderos and Launchpaderas,

I've been thinking about the bug page. I've had a few attempts at creating 
wireframes of what it could look like, but no matter how much I try, I always 
get taken down a path that requires radical changes. Considering this is the 
most used page in Launchpad, radical changes need to be made sensibly and 
ensure that they are verifiable better.
So, I will start working on different layouts while I discuss it with different 
people and through the list, and we can slowly produce something that works 
well for everybody.
Problems I'm trying to solve:

- Show the relationship between bugtasks better. Where did the bug originate? 
Where was it fixed? What is it blocked on?  In general, if a bug has a bugtask 
on a package and on upstream, it's pretty safe to say that it depends on 
upstream fixing it first. If it was first reported in the package, we have origin.
Some of this may require data model changes, some of them don't. Lets explore 
what we want to do first.

- "Also affects..." is a mess. You can create another bugtask with 3 different 
options (Also affects project, Also affects distribution and Target to 
release). Target to release doesn't do what most people expect, because it 
targets it to a series. A release comes from a milestone.
We need to improve the flow there, maybe collapse the "Also affects..." into 
one picker that selects packages or products.

- Descriptions should be more prominent. They describe the bug, they should be 
more visible.

- Related branches is too vague. If there's a branch linked to a bug, what 
you're really saying is "this probably fixes it". We probably want to show if 
there are any merge proposals attached to that branch, when it was last 
updated, and maybe even let you subscribe to it from the bug.

- The subscribers portlet is too long. We have a mockup from a previous sprint 
on a way to fix that, collapsing all the sections, giving you the description 
on why they are subscribed in a tooltip and cutting it off after a number of 
subscribers. Maybe you don't need to show my name on there if there's already 
an unsubscribe button?

- Adding attachments workflow needs to be finished off. Ajaxified, show them in 
a better way than squished in small a box on the bottom right, attached patches 
should be shown in the same place as linked branches, and images, in a perfect 
world, should show a thumbnail.

- You should be able to specify that a new tag is an official one, if you have 
permissions on the project.

- Tell me how much the bug affects users. Show me the number, show be a flame, 
but show me something.

- Maybe h1's should be a bit smaller in general, so we don't have so many 
titles that wrap?

- Being on a roll here, how about highlighting the reporters' comments?  His 
comments will most likely be very important.


Phew, having gotten all of that out of my head, here's what I think we should 
do for the immediate future:

1) Collapse activity information and comments like we do for emails. It's way 
too noisy today.

2) Tweak the bugtask table so the status and importance don't use so much width 
of it unnecessarily, add   between all edit buttons and it's object

3) Add more whitespace between the links below the table and the description 
and whitespace between tags and related branches



Apologies for the long email, and the people who got to the end, you are now my 
friends.


--
Martin