CONTRIBUTING.md
In delta-rho/trelliscope: Create and Navigate Large Multi-Panel Visual Displays

How to contribute to DeltaRho / trelliscope

Thank you for sharing your code with the DeltaRho project. We appreciate your contribution!

Before you write too much code, check the open issues in the trelliscope issue tracker to see if someone else has already filed an issue related to your work or is already working on it. If not, go ahead and open a new issue.

Shoot us a quick note on gitter chat letting us know what you're working on. There will likely be people on there who can give you tips about where to find relevant source or alert you to other planned changes that might effect your work.

If the work you're proposing makes substantive changes to trelliscope, you may be asked to attach a design document to your issue in the issue tracker. This document should provide a high-level explanation of your design, clearly define the goal of the new design, etc. This document is meant to save you time as it allows the team a chance to provide feedback on the proposes changes. The document also allows the team to prepare for large changes to the code base. We welcome change but also want to ensure that code quality is kept high.

Github provides a nice overview on how to create a pull request.

Some general rules to follow:

Do your work in a fork of the trelliscope repo.
Create a branch for each feature/bug in trelliscope that you're working on. These branches are often called "feature" or "topic" branches.
Use your feature branch in the pull request. Any changes that you push to your feature branch will automatically be shown in the pull request. If your feature branch is not based off the latest master, you will be asked to rebase it before it is merged.
If your pull request fixes an issue, reference the issue so that it will be closed when your pull request is merged
Keep your pull requests as small as possible. Large pull requests are hard to review. Try to break up your changes into self-contained and incremental pull requests, if need be, and reference dependent pull requests, e.g. "This pull request builds on request #92. Please review #92 first."
The first line of commit messages should be a short (<80 character) summary, followed by an empty line and then, optionally, any details that you want to share about the commit.
Include unit tests with your pull request. We love tests and use Travis CI to check every pull request and commit. We use the testthat R package for running unit tests. See code in the tests/testthat for examples.