| 2011-05-05 13:57:23 |
Kate Stewart |
bug |
|
|
added bug |
| 2011-05-06 05:07:43 |
Robert Collins |
launchpad: status |
New |
Incomplete |
|
| 2011-05-07 09:43:48 |
Kate Stewart |
launchpad: status |
Incomplete |
New |
|
| 2011-05-07 12:53:48 |
Jonathan Lange |
summary |
Better defaults when adding a project to a bug task |
Bugs assigned to new targets are easily missed |
|
| 2011-05-07 12:58:54 |
Jonathan Lange |
description |
Bugs for a specific package, may actually require fixes in another package as well to have a complete solution. This is a common task in certain subsystems (ie. compiz and unity tend to require pairs), as well as when a piece of plumbing is changed (set of projects needing recompiles, etc.).
for an existing bug #
to add a new product
inherit priority from existing product.
set status to confirmed by default (unless the existing product status is new).
This will help with the consistency of the bug database and get the priorities closer to being right by default, which will help with prioritization by developers and managers. |
Bugs for a specific package, may actually require fixes in another package as well to have a complete solution. This is a common task in certain subsystems (ie. compiz and unity tend to require pairs), as well as when a piece of plumbing is changed (set of projects needing recompiles, etc.).
When a bug is assigned to another package (or project, series etc.) it starts off as being "New" and "Undecided". These defaults, if unchanged, mean that the bug is effectively at the lowest possible priority for the new target. This makes it very easy for the bug to be ignored.
If the person adding the new target does not *want* the bug to be ignored, they have to set the priority and status on the new task. This is a little fiddly, and often feels redundant, since the new priority that they would set is probably going to be the same as the priority of the existing task, and the status is going to be something predictable.
One suggestion:
for an existing bug #
to add a new product
inherit priority from existing product.
set status to confirmed by default (unless the existing product status is new).
This will help with the consistency of the bug database and get the priorities closer to being right by default, which will help with prioritization by developers and managers. |
|
| 2011-05-07 13:02:39 |
Jonathan Lange |
tags |
|
ubuntu-platform ui |
|
| 2011-05-07 13:02:43 |
Jonathan Lange |
launchpad: status |
New |
Triaged |
|
| 2011-05-07 13:02:45 |
Jonathan Lange |
launchpad: importance |
Undecided |
Low |
|
| 2011-05-08 08:47:46 |
Kate Stewart |
bug task added |
|
ubuntu |
|
| 2011-05-08 08:48:00 |
Kate Stewart |
ubuntu: status |
New |
Triaged |
|
| 2011-05-08 08:48:11 |
Kate Stewart |
ubuntu: importance |
Undecided |
High |
|
| 2011-05-08 08:53:06 |
Kate Stewart |
bug |
|
|
added subscriber Michael Hope |
| 2011-05-09 00:56:27 |
Robert Collins |
summary |
Bugs assigned to new targets are easily missed |
Bugs assigned to new targets are easily missed (their default values sort at the end of bug lists) |
|
| 2011-05-09 00:56:36 |
Robert Collins |
launchpad: importance |
Low |
High |
|
| 2011-05-09 06:16:53 |
Robert Collins |
description |
Bugs for a specific package, may actually require fixes in another package as well to have a complete solution. This is a common task in certain subsystems (ie. compiz and unity tend to require pairs), as well as when a piece of plumbing is changed (set of projects needing recompiles, etc.).
When a bug is assigned to another package (or project, series etc.) it starts off as being "New" and "Undecided". These defaults, if unchanged, mean that the bug is effectively at the lowest possible priority for the new target. This makes it very easy for the bug to be ignored.
If the person adding the new target does not *want* the bug to be ignored, they have to set the priority and status on the new task. This is a little fiddly, and often feels redundant, since the new priority that they would set is probably going to be the same as the priority of the existing task, and the status is going to be something predictable.
One suggestion:
for an existing bug #
to add a new product
inherit priority from existing product.
set status to confirmed by default (unless the existing product status is new).
This will help with the consistency of the bug database and get the priorities closer to being right by default, which will help with prioritization by developers and managers. |
Bugs for a specific package, may actually require fixes in another package as well to have a complete solution. This is a common task in certain subsystems (ie. compiz and unity tend to require pairs), as well as when a piece of plumbing is changed (set of projects needing recompiles, etc.).
When a bug is assigned to another package (or project, series etc.) it starts off as being "New" and "Undecided". These defaults, if unchanged, mean that the bug is effectively at the lowest possible priority for the new target. This makes it very easy for the bug to be ignored.
If the person adding the new target does not *want* the bug to be ignored, they have to set the priority and status on the new task. This is a little fiddly, and often feels redundant, since the new priority that they would set is probably going to be the same as the priority of the existing task, and the status is going to be something predictable.
One suggestion:
for an existing bug #
to add a new package
inherit priority from existing package.
set status to confirmed by default (unless the existing package status is new).
This will help with the consistency of the bug database and get the priorities closer to being right by default, which will help with prioritization by developers and managers. |
|
| 2011-05-21 16:28:53 |
heere pomare |
launchpad: status |
Triaged |
Fix Committed |
|
| 2011-05-21 16:29:19 |
heere pomare |
ubuntu: status |
Triaged |
Fix Committed |
|
| 2011-05-23 11:58:54 |
Jonathan Lange |
launchpad: status |
Fix Committed |
Triaged |
|
| 2011-05-23 11:59:00 |
Jonathan Lange |
ubuntu: status |
Fix Committed |
Confirmed |
|
| 2011-06-20 09:35:13 |
Jonathan Lange |
tags |
ubuntu-platform ui |
bug-lifecycle ubuntu-platform ui |
|
