[rfc] bug handling priorities

[Robert Collins]

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.

For instance, one un-mentioned thing is the machinery in getting a bug
triaged. For us that broadly means figuring out whether it is:
 - misfiled or really not related to bzr
 - a ui confusion issue [nothing strictly wrong but we should consider
it as we try to improve things]
 - a dataloss/corruption issue or regression
 - missing functionality
 - blue sky concepts
 - [maybe] a duplicate of another bug (but this is really tricky to get
right).

These don't map precisely to launchpad bug flags, but I think thats
ok... the main thing is that this assessment can be done by folk that
know the UI without knowing the guts.

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 ;)

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090528/d75f0fc6/attachment.pgp