Skip to content

Latest commit

 

History

History
46 lines (32 loc) · 3.29 KB

CONTRIBUTING.md

File metadata and controls

46 lines (32 loc) · 3.29 KB
Raw

How to contribute to Tessera / docs-trelliscope

Thank you for sharing your work with the Tessera project. We appreciate your contribution!

Join the developer mailing list

If you're not already on the Tessera developers list, take a minute to join. This is as easy as sending an email to tessera-dev+subscribe@googlegroups.com. It would be great if you'd introduce yourself to the group but it's not required. You can just let your code do the talking for you if you like.

Check the issue tracker

Before you do too much work, check the open issues in the docs-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.

Announce your work on the mailing list

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

Tips for editing documentation

Our documentation goes through a special formatting procedure to provide a uniform look. Documentation is generated by editing markdown in .Rmd files, then processing the .Rmd files using the buildDocs package. Please see the "Usage" section in the README at that repository for tips on how build an index.html page from your .Rmd files.

buildDocs uses knitr so that output of code can be embedded into the documents. If this is not desired for your documentation, it is not necessary, you can put your code in plain markdown. Note that some of the code in our documentation depends on having a special environment set up, such as Hadoop and RHIPE.

Submit your pull request

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 docs-trelliscope repo.
  • Create a branch for each feature/bug in docs-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.