CONTRIBUTING.md
Contributing to Schlepp
========================
First of all, thanks for your interest in contributing to Schlepp!
Below are a list of guidelines to help keep this project sane in the face of open source entropy.
How To Submit A Patch
---------------------
Any patch you feel would make this a better project is welcome, including but not limited to: bug fixes, new features, refactoring, and better documentation.
Make a fork of this project, and hack to your heart's content. Once you have something you think would be great to include into master, feel free to open a pull request. Please keep in mind the following guidelines, which will make it more likely for your pull request to be accepted:
1. Please have test cases, both in the unit suite and the integration suite, that fail when your code is not present.
1. Please open a topic branch in your fork, and create your pull request against that.
* Use a separate topic for each feature and/or bug fix you want to submit.
1. Be logically consistent in your commits. Make them as small as possible, so they can tell a story the maintainer can understand.
1. Keeping a consistent style in the codebase is important for maintainability. When possible, please stick to the guidelines within [this guide](https://github.com/bbatsov/ruby-style-guide).
1. Pay attention to things like code climate and test coverage. A drop in these metrics will not necessarily preclude a patch from being accepted, but we'd much prefer to keep these numbers high.
Please keep in mind your contributions will be licensed the same as the rest of Schlepp, under the MIT license.
It may take the developer a day or two to get to your pull request. If your request has not been responded to in a few days, though, feel free to ping the developer team, preferably through a comment on the pull.
How To Report An Issue
----------------------
Issue reports are welcome, even if not accompanied by a pull request. Keep in mind that submitting a pull request will mean your issue likely gets resolved sooner, because less work will be left to do.
The most important thing an issue can do is get a developer as close as possible to seeing what you are seeing, in the case of a bug report. In the case of a feature request, you want to get them to the point where they don't see what you want to see, so they can make a decision about whether and how to include the proposed feature.
More about good bug reports [here](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html).