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.
