RubyCritic is open source and contributions from the community are encouraged! No contribution is too small. Please consider:
If you want to squash a bug or add a new feature, please:
-
Fork the project.
-
Create a feature branch (
git checkout -b my-new-feature
). -
Make your changes. Include tests for your changes, otherwise I may accidentally break them in the future.
-
Run the tests with the
rake
command. Make sure that they are still passing. -
Stage partial-file changesets (
git add -p
). -
Commit your changes (
git commit
). Make exactly as many commits as you need. Each commit should do one thing and one thing only. For example, all whitespace fixes should be relegated to a single commit. -
Write descriptive commit messages.
-
Push the branch to GitHub (
git push origin my-new-feature
). -
Create a Pull Request and send it to be merged with the master branch.
-
After your code is reviewed, hide the sausage making. We follow the "one commit per pull request" principle since this allows for a clean git history, easy handling of features and convenient rollbacks when things go wrong. Or in one sentence: You can have as many commits as you want in your pull request, but after the final review and before the merge you need to squash all of those in one single commit. For a more in-depth look at interactive rebasing, be sure to check how to rewrite history as well.
You are welcome to clarify how something works or simply fix a typo. Please include [ci skip]
on a new line in each of your commit messages. This will signal Travis that running the test suite is not necessary for these changes.
If you are experiencing unexpected behavior and, after having read the documentation, you are convinced this behavior is a bug, please:
-
Search the issues tracker to see if it was already reported / fixed.
-
Include the Ruby and RubyCritic versions in your report. Here's a little table to help you out:
| | Version |
|------------|---------|
| Ruby | 2.1.2 |
| RubyCritic | 1.0.0 |
The more information you provide, the easier it will be to track down the issue and fix it. If you have never written a bug report before, or if you want to brush up on your bug reporting skills, read Simon Tatham's essay How to Report Bugs Effectively.