[rfc] bug handling priorities

[Martin Pool]

2009/5/28 Robert Collins <robert.collins at canonical.com>:
> I think the heuristic you list makes sense project wide; I think though
> that it fails to scale as the community scales: fewer people choose to
> develop than choose to help support other users. So we should as
> individuals be biasing our own heuristics to accomodate that - and
> training folk that are interested to help in the areas they are
> interested in helping out on.

I think we can grow the list of people who triage bugs a bit, and it's
common sense that if you plausibly expect someone better suited to do
a particular task to do it soon, you might as well let them.  However,
the queues have been growing beyond this.

> Anyhow, I like having a semi-formal heuristic we can recommend to
> contributors, but I do think that we should be clear that its a project
> heuristic, and as such doesn't fit everyone - e.g. someone that can't do
> the release ;)

Specifically, for core and/or Canonical-employed contributors, I think
they should less often be starting new work while there's outstanding
reviews to do, and almost never start new work when they have an
approved patch waiting to be merged.  (I know I break this pretty
often myself, but I think we should get better at it.)  At least a
heuristic to help answer "hm what do I do now?" may be good.

-- 
Martin <http://launchpad.net/~mbp/>