Skip to content

Latest commit

 

History

History
74 lines (58 loc) · 5.34 KB

CONTRIBUTING.md

File metadata and controls

74 lines (58 loc) · 5.34 KB
Raw

How To Contribute To Rototiller

Getting Started

Making Changes

  • Create a topic branch from where you want to base your work.

    • This is the master branch in the case of rototiller
    • To quickly create a topic branch based on master use git checkout -b my_contribution master. Do not work directly on the master branch.

  • Make commits of logical working and functional units.

  • Check for unnecessary whitespace with git diff --check before committing.

  • Make sure your commit messages are in the proper format.

      (BKR-1234) Make the example in CONTRIBUTING imperative and concrete

  Without this patch applied the example commit message in the CONTRIBUTING
  document is not a concrete example.  This is a problem because the
  contributor is left to imagine what the commit message should look like
  based on a description rather than an example.  This patch fixes the
  problem by making the example concrete and imperative.

  The first line is a real life imperative statement with a ticket number
  from our issue tracker.  The body describes the behavior without the patch,
  why this is a problem, and how the patch fixes the problem when applied.

  • Make sure you have added RSpec tests that exercise your new code. These test should be located in the appropriate rototiller/spec/ subdirectory. The addition of new methods/classes or the addition of code paths to existing methods/classes requires additional RSpec coverage.

    • One should NOT USE the deprecated should/stub methods - USE expect/allow. Use of deprecated RSpec methods will result in your patch being rejected. See a nice blog post from 2013 on RSpec's new message expectation syntax.

  • Run the spec unit tests to assure nothing else was accidentally broken, using rake test

    • Bonus: if possible ensure that [bundle exec] rake test runs without failures for additional Ruby versions (1.9, 2.0, etc). Rototiller supports Ruby 1.9+, and breakage of support for other rubies will cause a patch to be rejected.

  • Make sure that if you have added new functionality of sufficiently high risk, and it can not be covered adequately via unit tests (mocking, requires disk, other classes, etc), you also include acceptance tests in your PR.

  • Make sure that you have added documentation using Yard, new methods/classes without appropriate documentation will be rejected.

    • Run the yardoc tool to ensure that your yard documentation is properly formatted and complete
    • [bundle exec] rake docs:gen

  • Yard docs are great for other developers, but often are difficult to read for users. If your change impacts user-facing functionality, please include changes to the human-readable markdown docs starting at README.md

  • During the time that you are working on your patch the master Rototiller branch may have changed - you'll want to rebase before you submit your PR with git rebase master. A successful rebase ensures that your patch will cleanly merge into Rototiller.

  • Submitted patches will be smoke tested through a series of acceptance level tests that ensures basic Rototiller functionality - the results of these tests will be evaluated by a Rototiller team member. Failures associated with the submitted patch will result in the patch being rejected.

Submitting Changes

Additional Resources

Submitting Changes

Additional Resources