My scattered thoughts:

>For reporters
Bug - If the bug doesn't appear when using the default settings, please
specify the non-default settings you're using.
(maybe add the .cfg?)

Feature, mostly for plugins - Note that providing a link to an open-source
implementation for the requested application elevates the chances of
fulfilling your request.

>Severity levels
High - add 'possible damage to data (e.g., filesystem)', 'crash due to a
non-predictable yet avoidable (e.g., by using some setting) action'
Medium - add 'crash due to a predictable action'

We need to define more carefully what constitutes a majority/minority of RB
users.
Are ipod users a majority? A minority? What about ondio sp users?
Moreover, most RB users wouldn't notice changes in codecs/plugins they don't
use.

>For admins
I link duplicate tasks (via related tasks) mostly because some useful
comments exist on either task, so that's my way of saving relevant
discussion while closing the redundant task.

Status - I usually change verified bug reports status to Researching and
outdated bug reports with a 'please check whether the problem persists'
comment to Waiting on Costumer.

>Closing reports
Maybe we should consider using the Later status for rather large yet
obviously needed feature reqs, e.g., "implement USB-OTG for supported HW" or
"optimize AAC codec".

R.
Received on 2006-09-30