We need more awesome!

Help us make Fuel even better!

• Help out
• Repositories on Github
• Making pull-requests
• Reporting bugs
• Making feature requests

Help out

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

• fuel/fuel - the basic setup for a new installation of FuelPHP
• fuel/core - the core package containing FuelPHP
• fuel/oil - the command line utility
• fuel/orm - the ORM package
• fuel/auth - the Authentication and Authorization package
• fuel/email - the Email package
• fuel/parser - the Parser package
• fuel/docs - Documentation

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)

Making pull-requests

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?

Reporting bugs

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)