From: RaeNye <raenye_at_netvision.net.il>
Date: Tue, 17 Oct 2006 22:39:52 +0200

While we're at it, I suggest some changes to categories:

- rename categories using a two-level hierarchy, e.g., "Plugins-general",
"Plugins-video", "Plugins-games", "Env-building", "Env-simulator", "HW-LCD",
"HW-remote", "HW-fm tuner", "Audio-general", "Audio-codecs", "UI-fonts",
"UI-language", "OS-playlists", "OS-bootloader", "OS-ID3",
- "operating system/drivers" and "drivers" should be united into
"HW-general"
- "user interface" should be split to "UI-button assignment" and
"UI-general"
- "settings" and "configuration" should be united
- "HW-connectivity" should be added (suitable for all USB-related tasks as
well as ipod accessories, etc.)

And some little bits:
- Which category is suitable for tasks related to file-system issues?
- Is the "wps" category intended for themes or for code patches that change
WPS functionality? Why not call it "UI-wps enhancement" or something like
that?

R.
-----Original Message-----
From: rockbox-dev-bounces_at_cool.haxx.se
[mailto:rockbox-dev-bounces_at_cool.haxx.se] On Behalf Of Dominik Riebeling
Sent: Tuesday, October 17, 2006 9:49 PM
To: Rockbox development
Subject: Re: RFC: Rockbox Flyspray policy

It has been a while but I still want to post my thoughts. For easier
distinction I haven't trimmed the text but only added my extensions.
Comments are marked with square brackets.

On 9/30/06, Jonas H <rasher_at_rasher.dk> wrote:
> 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.

I think we should divide this into subpages, similar to the bugs page of the
Gimp project (http://www.gimp.net/bugs/ which has already mentioned on IRC
some time ago).
I suggest having a UsingFlyspray (or rework ReportingBugs?) page which is
the only page that is linked from the side menu for all types. From there we
have separate pages for reporters and for developers.

> ***************************
> * ROCKBOX FLYSPRAY POLICY *
> ***************************
>
> FOR REPORTERS
> =============

Flyspray is *not* a support channel. Our support channels are the mailing
lists, the forums and IRC. For support questions don't go to Flyspray as
you'll get way better responses there -- the tracker is a completely
different thing and used in a completely different way. You won't get any
support from the tracker, it is used to keep track of tasks *only*. Note
that support questions in the tracker will get closed without any comment!

It is *really* important that you follow the rules for our tracker: by
following these rules you make it easier for the devs to keep up with bugs,
feature requests and patches which in turn means you can expect the
development (and fixing of bugs) getting faster. Ignoring these rules only
adds extra work for the devs and wastes precious time that could be used
better for coding.

When signing up please make sure you provided a correct and *working* mail
address. Tasks you are involved with (as reporter or commenter) get
automatically notified to you when something changes. This is a
*really* important thing as it's useless to have a task which reporter can't
get reached anymore, especially on bug reports. Your mail address won't get
used for anything else than these notification.

> 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 are unsure about a task you want to submit please ask in the
aforementioned support channels first. This helps saving work for the devs
and can also avoid you quite some amount of frustration.

A really annoying issue are duplicates. Please make sure the task you are
about to submit isn't already present. If there is a similar task please
take into consideration if it would be sufficient to comment on that
existing task. Again, if you are unsure feel free to ask in our support
channels. Duplicates require quite some work, and that work is precious
developer time. You'll agree that wasting deveoper time isn't a good think,
don't you?

> If you're submitting a bug, please explain:
> - What behavior you are seeing
> - What behavior you expected
> - How to reproduce the bug

Please make sure you can reproduce the bug -- if it's not reproducable it's
unlikely to get fixed. Also, make sure you have tried the latest cvs build
and reset your settings (see the FAQ pages on how to do this). If you still
can reproduce the bug it's worth filing. You may want to ask on IRC before
filing, maybe some dev is already working on it.

> 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

Please also consider the following before filing a feature request:
- is the requested feature possible? Music players aren't PCs, so there are
quite some hardware limitations. If you are unsure please ask in the support
channels. You'll most probably get an answer quicker and can help the
tracker staying useable.
- is the requested feature compatible with the open source nature of
Rockbox? Rockbox is distributed as GPL which requires all work included to
be GPL. We can't add features that are incompatible, regardless if it's from
a source code point of view or any other.
- Don't file requests for new ports. They are completely pointless.
New ports will only happen if some dev is interested and owns the actual
device. Of course you are welcomed to start working on a new port. See the
NewPort wiki page if you are interested.

> If you're submitting a patch:
> - Explain in as much detail as possible what the patch does
> - Mention any related existing Flyspray tasks

- if your patch has issues that need to get adressed don't forget to note
them. Perhaps someone else is interested in your work and wants to help you
out.
- submitting a patch implies the assumption you want to get it included into
Rockbox. For that to happen your patch needs to work on all players
suppported by Rockbox (if it's specific to some series of players make sure
it doesn't break the other builds).

[Note: how to deal with patches the author doesn't intend to get included?
There is still a chance a user wants to share his work even if he don't
expects or implies it to get included. I propose adding a new category for
that, say, "snippets"]

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

[closing a bug with the reason "fixed" and a patch with the reason
"accepted" should be sufficient though.]

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

if there is a duplicate that has additional useful information one of the
two tasks should get closed but it also linked with the related task
feature. There is no reason having two open tasks for the same issue as it
only clutters Flyspray. Having the closed task linked makes it only one
click away for reference.

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

[Do we really need suggested comments? Wouldn't it be better telling the
users how a closed task has to be understood if there isn't a detailed
reason attached? Repeating the same reasons again and again is quite tedious
and requires additional work]

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

or this feature won't get implemented as we don't want it (for license
reasons, programming reasons, etc.) [An example would be support for
proprietary file formats. E.g. MS Office is nothing a music player is
intended for and nothing that is feasible to support.]

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

 - Dominik
Received on 2006-10-17