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



Wiki > Main > FeatureRequests (compare)

Difference: FeatureRequests (r7 vs. r6)

How to Get a Feature Into Rockbox



If You Can Code

The easiest way to get a feature into Rockbox is to code it up, put it in the patch tracker, work with the dev team to ensure portability and consistency with Rockbox style and have it committed. Obviously, the less work the team needs to do to make your patch work, the more likely it is to get included.

Providing a patch does not, however, guarantee inclusion. A feature might not be wanted at all, no matter how well it is implemented. The dev team are also concerned about code quality, and doing things the right way. Before you go ahead and implement, it's probably a good idea to pop onto our IRC channel and discuss potential approaches with dev team members. This is actually the way that most people with access to the Rockbox source tend to work when writing code ourselves, and we think it works quite well.

Be aware that our policy is to refuse code from anonymous contributors, so you must be prepared to give your real name in order for your code to even be considered for inclusion.

Another useful read is the "Submitting a patch" part of the FlySprayHowto page.



If You Can't Code

Not everyone can code, however. Of course we'd like to hear your ideas for features. That's why there's a forum section called "Feature Ideas". If you think you have a good idea, that's the place to put it.

Sadly all the active developers have a to do list as long as several people's arms. They're also writing Rockbox unpaid in their own time. Most such feature requests will therefore get one of two responses.

The first possible response is that we don't think your request is a good idea. Please don't take this personally. Rockbox is big and complex and there's a lot of stuff we'd like to do that simply won't work within the structure of the project. It's important to us that Rockbox remain useable, flexible and efficient, and we take an awful lot of factors into consideration when deciding whether a feature is plausible or not.

The second kind of response is "we'd love to implement this, but don't currently have the time". That tends to happen quite a lot.

This means that unless there is a specific developer who wants to work on a feature idea you've come up with, the chances of getting a particular feature implemented aren't terribly high unless you can find someone willing to write it.

So what can you do to improve your chances? An idea idea that will be of use to a large number of people tend to get priority over features specific to a small group of users. Asking people you know who can write software to work on coding Rockbox is also a good idea. Obviously the more developers we have who can work as part of the team, the faster things get implemented. Donations are also very useful, but it's hard for us to turn money into features, since we really don't get enough donations to employ someone to work on Rockbox full time or even part time.

If there's one "must have" feature for you that falls into the "nice idea but we don't have time" category, you might finally want to consider the idea of offering a 'bounty'. The idea is that you, and possibly others too, offer to pay a certain amount of money for a feature being developed. If the incentive is high enough, someone (not necessarily from the dev team) will probably do what you want. And then everyone gets to share the benefit. Think of it as a type of social service. (Sorry if you feel that the world shouldn't work this way, but I'm afraid it's a bit late to change it now - the barter economy has been around for a long time.)

We'll write Rockbox whatever happens. Please bear in mind that because we donate our time and brainpower we get to decide our priorities, and they may not be the same as yours.


r8 - 03 Jul 2008 - 20:57:46 - MarcGuay

Revision r7 - 03 Jul 2008 - 20:27 - FrankGevaerts
Revision r6 - 03 Jul 2008 - 18:57 - MarcGuay
Copyright by the contributing authors.