.github/CONTRIBUTING.md

In chris-prener/stldata: City of St. Louis Data

Contributing to stldata

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

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

Prerequisites

Before you do a pull request, you should always file an issue and make sure someone from the slu-openGIS team agrees that it’s a problem, and is happy with your basic proposal for fixing it. If you’ve found a bug, first create a minimal reprex.

If you are proposing an addition, please open an issue first and describe the type of data you would like to add. The data should be publicly available and should describe phenomena in the City of St. Louis or the St. Louis metro area.

PR process

Fork, clone, branch

The first thing you'll need to do is to fork the stldata 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 stldata 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 slu-openGIS 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.
• R packages by Hadley Wickham.
• Git and GitHub
• Automated checking
• Object documentation
• Testing
• dplyr’s 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.

Credits

This document is adopted from @jennybc's Contribution document for the usethis package.

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.

chris-prener/stldata documentation built on June 10, 2019, 7:42 a.m.