Contributing
------------

This project would not exist without all of its users and [contributors][1].

If you have ideas on how to make the configuration easier to maintain or
improve its performance, do not hesitate to fork and send pull requests.

### Issue Reporting

   - Check that the issue has not already been reported.
   - Check that the issue has not already been fixed in the latest code.
   - Open an issue with a clear title and description in grammatically correct,
     complete sentences.

### Pull Request

   - Read [how to properly contribute to open source projects on GitHub][2].
   - Use a topic branch to easily amend a pull request later, if necessary.
   - Write [good commit messages][3].
   - Squash commits on the topic branch before opening a pull request.
   - Use the same coding style and spacing.
   - Open a [pull request][4] that relates to but one subject with a clear
     title and description in grammatically correct, complete sentences.

#### Code Style

   - Indent using 2 spaces. No tabs.
   - Put `; do` and `; then` on the same line as the `while`, `for` or `if`.
   - Local variables should be used whenever possible.
   - Use `snake_case` for variable and function naming.
   - Local variables should be lower cased.
   - Global variables should be upper cased.
   - Use `$(command)` instead of backticks.
   - Avoid `eval` if possible.

#### Modules

   - A *README.md* must be present.
   - Large functions must be placed in a *functions* directory.
   - Functions that take arguments must have completion.

#### Themes

   - A screenshots section must be present in the file header.
   - The pull request description must have [embedded screenshots][5].

[1]: https://github.com/sorin-ionescu/prezto/contributors
[2]: http://gun.io/blog/how-to-github-fork-branch-and-pull-request
[3]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[4]: https://help.github.com/articles/using-pull-requests
[5]: http://daringfireball.net/projects/markdown/syntax#img