Help us make Fuel even better!
Fuel is developed using a community approach and we encourage participation by our community. Got an idea for a feature? Spotted a bug and solved it? Fork the repo on Github, commit your changes and make a pull request. We'll check them and either accept or explain when we reject. But of course we also take bugreports and feature requests. A really long list of people have done so, making Fuel better on a daily basis!
Less sure of yourself yet when it comes to core programming? There's lots of other ways to help: document yet undocumented functionality, correct mistakes in docblocks or verify reported bugs by trying to replicate a bugreport and telling us about the success of failure. (both are equally important!)
Repositories on Github
There is a basic tutorial on Github about forking. Pull-requests are only accepted on either the develop branch or a specific feature branch, pull-requests on master are denied out of hand. (the master branch is the last release and only the project lead pushes new releases)
It is important that you keep to our coding standards and contribution guidelines, which can be found in the docs. Any pull-request that's not up to our coding standards or comes without proper explanation will not even be considered. Also always check the diff resulting from your pull request: Are you merging with the right branch (always a develop branch, never on a master branch) and are only changes included that are directly related to your pull-request?
The only place we accept bugreports is in the issuetrackers of the repositories mentioned above. Bugreports transmitted via Twitter, the Forums or IRC are not considered bugreports.
When reporting a bug it is always important that you give at least the following information:
- what are you trying to do? (what were you coding up when you came across this bug)
- what were you expecting? (what should have happened but didn't happen)
- what are you getting instead? (unexpected PHP exception, error message, white screen of death, wrong output)
Without this information any proper followup is often impossible, and you'll be asked to provide this information anyway.
Making feature requests
Like bugreports these are also only accepted in the issuetrackers, and require similar information:
- What is the use case? (why do you want it, why does it belong in the core instead of your application?)
- Is it impossible with the current functionality? (ensure you're not proposing duplicate functionality, or very little new)
- How do you solve it now / how would you solve it? (not always required, but makes acceptance far more likely)