"Remote bug watches" box is unnecessary
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
Symptoms
========
If someone makes a comment in a Launchpad bug report, including the URL to an external bug report, Launchpad will create a bug watch for the external bug report. The bug watch, and its status and importance, are shown in a "Remote bug watches" box.
Diagnosis
=========
* This box adds complexity to the UI
* The split status between tasks and watches requires looking in two different places to see if the bug is being tracked elsewhere - the tasks table and the watches list.
Solutions
=========
* Show bugwatches in the tasks table (even if no appropriate upstream product exists in LP: just pick a close enough format to represent what is going on)
* Show bugwatches inline in the place the url was referenced on the bug (comment, description etc) -> this implies a way to control them that is also inline, or perhaps tied to editing/updating that comment (bug 1734, bug 80895).
| tags: | added: bugwatch |
| tags: | added: ui |
| Changed in malone: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| Robert Collins (lifeless) wrote | #1 |
| description: | updated |
So when we don't have a linked upstream, the affects table won't show the bugwatch; the portlet while as you say isn't strictly needed is actually very useful on a bug with 100's of comments - one can see (and garden because watches can be removed) the relationships to other bugs. So, I disagree with the portlet being unnecessary - and I think removing it would make managing the relevance of the bug harder (even with bug gardening, there are still threads of discussion to preserve). We could say 'always show bug watches as task rows, even if there is no appropriate project to link the task on', which would fit the general model LP has of structuring data.