CONTRIBUTING.md

In BruceZhaoR/mypkg:

Contributing to mypkg

• Prerequisites
• PR Process
  • Fork, clone, branch
  • Check
  • Style
  • Document
  • Test
  • NEWS
  • Re-check
  • Commit
  • Push and pull
  • Review, revise, repeat
• Resources
• Code of Conduct

This explains how to propose a change to mypkg via a pull request using Git and GitHub.

For more general info about contributing to the tidyverse, see the Resources at the end of this document.

Prerequisites

Before you do a pull request, you should always file an issue and make sure someone from the tidyverse team agrees that it鈥檚 a problem, and is happy with your basic proposal for fixing it. If you鈥檝e found a bug, first create a minimal reprex.

PR process

Fork, clone, branch

The first thing you'll need to do is to fork the mypkg GitHub repo, and then clone it locally. We recommend that you create a branch for each PR.

Check

Before changing anything, make sure the package still passes R CMD check locally for you. When in doubt, compare your R CMD check results with current results for mypkg on Travis (checks on Linux and/or MacOS) and, if applicable, AppVeyor (checks on Windows). You'll do this again before you finalize your pull request, but this baseline will make it easier to pinpoint any problems introduced by your changes.

devtools::check()

Style

Match the existing code style. This means you should follow the tidyverse style guide. Use the styler package to apply the style guide automatically.

Be careful to only make style changes to the code you are contributing. If you find that there is a lot of code that doesn't meet the style guide, it would be better to file an issue or a separate PR to fix that first.

Document

We use roxygen2, specifically with the Markdown syntax, to create NAMESPACE and all .Rd files. All edits to documentation should be done in roxygen comments above the associated function or object. Then, run devtools::document() to rebuild the NAMESPACE and .Rd files.

See the RoxygenNote in DESCRIPTION for the version of roxygen2 being used.

Test

We use testthat. Contributions with test cases are easier to accept. If you are not sure what parts of your code are covered by tests, run the following to get a local coverage report of the package so you can see exactly what lines are not covered in the project.

devtools::test_coverage()

NEWS

For user-facing changes, add a bullet to NEWS.md that concisely describes the change. Small tweaks to the documentation do not need a bullet. The format should include your GitHub username, and links to relevant issue(s)/PR(s), as seen below.

* `function_name()` followed by brief description of change (#issue-num, @your-github-user-name)

Re-check

Before submitting your changes, make sure that the package either still passes R CMD check, or that the warnings and/or notes have not changed as a result of your edits.

Commit

When you've made your changes, write a clear commit message describing what you've done. If you've fixed or closed an issue, make sure to include keywords (e.g. fixes #101) at the end of your commit message (not in its title) to automatically close the issue when the PR is merged.

Push and pull

Once you've pushed your commit(s) to a branch in your fork, you're ready to make the pull request. Pull requests should have descriptive titles to remind reviewers/maintainers what the PR is about. You can easily view what exact changes you are proposing using either the Git diff view in RStudio, or the branch comparison view you'll be taken to when you go to create a new PR. If the PR is related to an issue, provide the issue number and slug in the description using auto-linking syntax (e.g. #15).

Review, revise, repeat

Since tidyverse development happens in waves, the latency period between submitting your PR and its review may vary. When a maintainer does review your contribution, be sure to use the same conventions described here with any revision commits.

Resources

• Happy Git and GitHub for the useR by Jenny Bryan.
• Contribute to the tidyverse covers several ways to contribute that don't involve writing code.
• Contributing Code to the Tidyverse by Jim Hester.
• R packages by Hadley Wickham.
• Git and GitHub
• Automated checking
• Object documentation
• Testing
• dplyr鈥檚 NEWS.md is a good source of examples for both content and styling.
• Closing issues using keywords on GitHub.
• Autolinked references and URLs on GitHub.
• GitHub Guides: Forking Projects.

Code of Conduct

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

BruceZhaoR/mypkg documentation built on May 14, 2019, 6:04 a.m.