Rockbox mail archiveSubject: RFC: Rockbox Flyspray policy
RFC: Rockbox Flyspray policy
From: Jonas H <rasher_at_rasher.dk>
Date: Sat, 30 Sep 2006 13:00:26 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Here are my suggestion for a Flyspray policy. I have written comments in
the text below as such: [comment].
I suggest everyone pick this suggestion to bits, and when some sort of
consensus is found, it should be put in the wiki and linked somewhere
prominent on the Flyspray page.
* ROCKBOX FLYSPRAY POLICY *
When submitting a task, please include as much information as you can
think of. Be honest when you set the severity level, see explanation in
the section below.
If you're submitting a bug, please explain:
- What behavior you are seeing
- What behavior you expected
- How to reproduce the bug
If you're submitting a feature request, please include:
- A detailed description of the feature you want added
- If you want current behavior changed, an explanation of why your
suggestion is better
If you're submitting a patch:
- Explain in as much detail as possible what the patch does
- Mention any related existing Flyspray tasks
Critical - Potential damage to equipment or user (hearing, mostly),
leaving Rockbox unbootable, all playback no longer working
High - Core features (voice, individual codecs, menus, etc) no
Medium - Non-essential features (bookmarking) not usable. Core
features periodically slightly broken.
Low - Any bugs (except typos or cosmetic errors) in plugins.
Non-essential features periodically or slightly broken.
Very low - Typos, cosmetic errors
If a patch fixes a bug or feature request, its severity level should
match that of that task.
Critical - Use only for fixing critical (as described above) bugs.
High - Use only for fixing critical (as described above) bugs
Medium - Adds or fixes a feature that will make Rockbox more usable to
a majority of users
Low - Adds or fixes a feature that will make Rockbox more usable to
a minority of users
Very low - Adds or fixes a feature that will make Rockbox most users
will probably not notice
* Feature requests
Critical - Do not use
High - Do not use
Medium - The feature requested would make Rockbox more usable to a
majority of users
Low - The feature requested would make Rockbox more usable to a
minority of users
Very low - The feature requested would make Rockbox most users will
probably not notice
When dealing with reporters, please be polite. We need reporters, and
even if we don't care about an individual reporter, other potential
reporters might be put off if we act rude towards a submitter. Even if
he deserved it.
Closing a report without giving a useful comment is not acceptable. The
reporter should be told why his report got closed. For people following
the tracker by email, not giving a useful comment can also be quite
Use the related tasks feature if you see a task that is related to
another. [should duplicates be marked as related? At least if the report
has information not mentioned in the open report, that could be useful]
[Should the status be used at all? If it should, it needs to be used
more. As it stands, most tasks are unconfirmed, simply because no one
This is a list of suggested comments for each close reason and should
also serve as a description of when to use them.
Patches: Your patch has been included in Rockbox. Thank you for your
Feature requests, Bugs: This report is a duplicate of FS#xxxx. In the
future, please use the search feature to check if your issue has already
Feature requests, Bugs: The issue has been fixed in Rockbox CVS and will
appear in the CVS build shortly as well as the next daily build.
Feature requests: This feature can not be added to Rockbox for technical
Bugs: This bug does not exist in Rockbox.
[I'm not entirely sure why you'd use this? At least not with the
(relatively) small amount of tasks in Rockbox. I guess you could close
it as "Later" and then search for closed tasks marked Later and reopen
as appropriate, but I think that'd be overkill for this project.]
* Out of date
Patches: This patch is very outdated and isn't close to applying cleanly
anymore. If you decide to work on this patch, either reopen this task or
open a new task and mention this task in your comment.
Bugs: This bug no longer exists in Rockbox.
Feature requests: This or a similar feature has been included in Rockbox
or the feature is no longer necessary/feasible.
Bugs: This bug does not exist in Rockbox
[Same comment here as "Later".]
* Won't fix
Bugs: Your bug report details wanted and expected behavior. If you wish
to have Rockbox' behavior changed, file a feature request and explain
why you want the behavior changed.
Patches: Your patch adds functionality that is not wanted in Rockbox.
[You should always add a reason here]
Feature requests: Your feature request has been rejected by the Rockbox
developers. The feature or behavior you suggest is not wanted in
Rockbox. [You should always add a reason here]
* Works for me
Bugs: I can't reproduce this bug. [Should only be used after asking
reporter for clarification and still not being able to reproduce or if
reporter doesn't respond.]
Feature requests: The feature you suggested already exists in Rockbox.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Received on 2006-09-30