Contributing

Thanks for contributing! These guidelines are an attempt to keep the code consistent and the maintenance of the project easier. Feel free to add suggestions and more information.

What to work on

Take a look at the Request for Comments (RFCs) for some large ideas, or look at the issue tracker to find more suggestions and bugs to fix.

Code Style

Tabs are used for indenting code blocks.
{ and [ brackets are on the same line as statement.
} and ] brackets are on a new line.

Pull Requests

Create pull requests from a branch with a meaningful name, so that merge commits have useful information.

Each commit should encapsulate a single addition or change. Multiple commits should be squashed together where possible to ensure that the functionality change in the pull request is contained in atomic units. For example, if one commit adds whitespace errors and you then remove the whitespace errors in a future commit, both those commits should be combined into one.

Similarly, if a pull request makes two functional changes then each change should be made in its own commit where possible. If refactoring or code clean-up is performed as well as a functional change put these into separate commits.

In this way, it is easy to see when specific functionality is introduced, and easier to merge sections of a pull request that are useful even if the functional change is not appropriate.

For a useful guide on how to structure your commit message, see tpope's note on commit messages.