Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: 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-----
Hash: SHA1

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 *
***************************

FOR REPORTERS
=============

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

SEVERITY LEVELS
===============

* Bugs

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
longer usable.
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

* Patches

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

FOR ADMINISTRATORS
==================

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
frustrating.

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
edits it.]

CLOSING REPORTS
===============

This is a list of suggested comments for each close reason and should
also serve as a description of when to use them.

* Accepted

Patches: Your patch has been included in Rockbox. Thank you for your
contribution.

* Duplicate

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
been reported.

* Fixed

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.

* Invalid

Feature requests: This feature can not be added to Rockbox for technical
reasons.
Bugs: This bug does not exist in Rockbox.

* Later

[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.

* Rejected

Bugs: This bug does not exist in Rockbox

* Remind

[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.

- --
Jonas H
rasher(at)rasher(dot)dk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFHk5KwjIPcvP1DCARAjsOAJ41alZX/9jRHh0TKIRbQbL+sUYxDQCgiiT6
hc4rC3TJHVJGzYB5oMpO7O0=
=iC/e
-----END PGP SIGNATURE-----
Received on 2006-09-30


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa