** Description changed:

  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).
+    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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/777853

Title:
  Bugs assigned to new targets are easily missed (their default values
  sort at the end of bug lists)

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to