Skip to contents

Contributing

Source: CONTRIBUTING.md

Development is a community effort, and we welcome participation.

Code of Conduct

Please note that the crew.aws.batch project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.

Discussions

At https://github.com/wlandau/crew.aws.batch/discussions, you can post general questions, brainstorm ideas, and ask for help.

Issues

https://github.com/wlandau/crew.aws.batch/issues is for bug reports, performance issues, maintenance tasks, and feature requests. When you post, please abide by the following guidelines.

  • Before posting a new issue or discussion topic, please take a moment to search for existing similar threads in order to avoid duplication.
  • For bug reports: if you can, please install the latest GitHub version of crew.aws.batch (i.e. remotes::install_github("wlandau/crew.aws.batch")) and verify that the issue still persists.
  • Describe your issue in prose as clearly and concisely as possible.
  • For any problem you identify, post a minimal reproducible example like this one so the maintainer can troubleshoot. A reproducible example is:
    • Runnable: post enough R code and data so any onlooker can create the error on their own computer.
    • Minimal: reduce runtime wherever possible and remove complicated details that are irrelevant to the issue at hand.
    • Readable: format your code according to the tidyverse style guide.

Development

External code contributions are extremely helpful in the right circumstances. Here are the recommended steps.

  1. Prior to contribution, please propose your idea in a discussion topic or issue thread so you and the maintainer can define the intent and scope of your work.
  2. Fork the repository.
  3. Follow the GitHub flow to create a new branch, add commits, and open a pull request.
  4. Discuss your code with the maintainer in the pull request thread.
  5. If everything looks good, the maintainer will merge your code into the project.

Please also follow these additional guidelines.

  • Respect the architecture and reasoning of the package. Depending on the scope of your work, you may want to read the design documents (package vignettes).
  • If possible, keep contributions small enough to easily review manually. It is okay to split up your work into multiple pull requests.
  • Format your code according to the tidyverse style guide and check your formatting with the lint_package() function from the lintr package.
  • For new features or functionality, add tests in tests. Tests that can be automated should go in tests/testthat/. Tests that cannot be automated should go in tests/interactive/. For features affecting performance, it is good practice to add profiling studies to tests/performance/.
  • Check code coverage with covr::package_coverage(). Automated tests should cover all the new or changed functionality in your pull request.
  • Run overall package checks with devtools::check() and goodpractice::gp()
  • Describe your contribution in the project’s NEWS.md file. Be sure to mention relevent GitHub issue numbers and your GitHub name as done in existing news entries.
  • If you feel contribution is substantial enough for official author or contributor status, please add yourself to the Authors@R field of the DESCRIPTION file.