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

Do you mean product or package? Products are inpendent in Launchpad - folk often *cannot* set priority milestone etc in product A when they can in product B.

could you please describe the problem rather than propose a solution in your bug reports - its easier to understand problems than solutions

For instance, in this one I'm going to guess 'compiz upstream are not taking the priority of the bug for unity into account when they do their own triage'. Which has a related 'when engineering work requires two bugs to be fixed to solve a single problem both bugs need to be clamped to the priority of the problem or the problem is effectively downgraded to the lowest priority'.

Since the latter case can turn up after initial filing, I think it would be better to see if we can solve the problem - particularly with bug relationships (such as dependencies) coming down the track. Further, as phrased this bug asks for a change which would be incompatible with the way upstreams treat launchpad - as their personal bug tracker. In fact its conceptually at odds with the design - we have separate priority etc so that different communities *can* disagree on the severity of an issue.

So, to triage this bug we need to know:
 - do you mean packages (if so we're not crossing ownership boundaries)
 - if you do mean products, what is the actual problem thats occuring.

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://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-04-15

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.

Rob, tying the two statuses together would indeed run counter to Launchpad's conceptual design. Setting the priority and status by default does not, particularly if the person creating the task has permission to do so. This is true regardless of whether the new task crosses project boundaries.

I've tried to update the description to be more problem focused. It's hard to do this for convenience bugs.

Thanks for that Jono. I don't agree with the assertion that untriaged
(new + undecided) are effectively the lowest priority - in fact I
posted to the lp list a couple of years ago proposing that those very
bugs show at the front of the list *by default* because assessing them
is crucial to deciding if they should or should not jump the queue.

Now that the bug is more symptom focused I think we can move forward
on it; the first thing that comes to mind is the sort order I
proposed, which would immediately bring these bugs to the fore.

With the rephrased subject, I think this is arguably high - things shouldn't default to being dropped on the floor. I'm not convinced about the initial proposed solution; can we get some more bandwidth to talk about this?

There's the UDS session: <https://blueprints.launchpad.net/launchpad/+spec/other-o-bug-lifecycle>.

What are your objections to the proposed solution?

I'm concerned that its a point-fix rather than digging at the heart of the matter; there are multiple ways things (apport, direct filing, also-affects) and all would seem to suffer from dropping-on-the-floor problem.

I'm speculating here but perhaps an ajax also-affects that presented the new values *to be created* during the process would help as much or more, without running into the special casing issues we will with copying the importance and/or status without a UI. (For instance, if you have triage rights, but an existing task is new, what should we default to? And if there are 2 existing tasks, which should we copy from? Should we prefer same-package different series (of the new target) or same-series different package (of the new target), and what if the existing tasks are not visible, or same-package different distro? How wide should the heuristic be?).

Or we could help more bugs get triaged, so that driving-to-zero becomes a common default not something requiring special consideration.

Or ... this is why I'd like some more bandwidth with Kate to understand the problem more.

On a purely minimal technical level, as long as we don't break folk in different contexts doing their own triage, we can certainly tolerate the directly proposed thing, but I *suspect* either of the other things I've touched on would be higher leverage and address the problem.

No, it's not Fix Committed.

Robert, I think the idea of making driving-to-zero a common default would be awesome.

The common theme in Kate's bug reports is that the rate of incoming bug reports to Ubuntu is so high it is not possible to stay on top of them, and important things are getting lost in the noise. Anything that can be done to help filter signal from noise is going to help address the core needs and decrease the chance things will drop on the floor. (I am particularly favoring bug #777861; in my own experiments separating bugs by series and then focusing on just one series at a time has been extremely effective).

I like the idea of having new targets inherit importance and maybe status, but thinking about how it'd need implemented in launchpad, I am little concerned it could require a lot of misc. UI to handle various corner cases (like what if the filer has permission to set to New but not to say Triaged, or what if the original target is marked Invalid or In Progress, we wouldn't want to inherit those...) If there's higher leverage ways of solving the lost-in-the-noise problem, those may well be better to focus on first.

@bryce I think one reason that staying on top of bug reports is hard is the disconnect between triage (move far enough to decide if it looks like it is critical/high/other) and what Ubuntu *calls* triage : making bugs ready for a developer to work on them.

The former is lightweight and scalable, the latter is extremely hard. We only need to do the latter for bugs we're going to actually get to.