Comment 2 for bug 777853
Revision history for this message
| Kate Stewart (kate.stewart) wrote Re: Better defaults when adding a project to a bug task | #2 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
Sorry if my wording was unclear, by product I meant packages.
I wasn't advocating linking all packages with necessary tasks under the bug number with the same priority, they do need to stay separate. What I was requesting that the default upon creation would be the same as the existing other package - rather than "Undecided".
Developers are NOT going in and doing the "housekeeping" as they phrase it, to give it the right importance when they identify another package is impacted, the pattern is that they get it off their radar, and consider themselves done. The system defaults though, mean that bugs get overlooked, due the the manual nature of classifying and the fact that the other team is relying on a bug to have an importance to get them to focus on it.
The following list was generated by extracting bugs found by key searches (release nominated and milestoned high/critical bugs - ie. key to fix to release Ubuntu), and then sorted into teams, so that there is some way for teams to balance workloads. https:/
The expectation when I talked to managers initially was that all high/critical bugs should be assigned to engineers, and have been looked at or about to be. What I find, when looking at the data is that I was seeing bugs without priorities, that weren't assigned, and weren't being looked at. By digging into why some of these showed up on my list, it turned out to be projects that were added after the initial triage work, and no one went in and set the importance, so the other team didn't know its importance to the release.