Skip to contents

Contributing to {maldipickr}

Source: CONTRIBUTING.md

The following is a set of guidelines for contributing to {maldipickr}1. These guidelines are not strict rules. Use your best judgment, and feel free to propose changes to this document in a pull request, as long as you are abiding to the Contributor Code of Conduct.

All contribution welcomed We are open to any contribution, from typos to new features. Thank you for taking this time! We will guide you throughout the process and make you in a safe position to contribute, whatever is your level in R programming.

{maldipickr} uses {fusen} with flat files (.Rmd)

A note on the structure of the R package. We use the {fusen} package to develop. This means that multiple files of the package in R/, tests/ and vignettes/ are issued from a flat file (e.g. a .Rmd file).

When this is the case, you will see the following warnings on top of the files:

  • % Generated by roxygen2: do not edit by hand
% Please edit documentation in R/delineate_with_similarity.R
  • # WARNING - Generated by {fusen} from dev/dereplicate-spectra.Rmd: do not edit by hand

This means that you will need to make your changes in the corresponding flat file, and then inflate() this same flat file. We recommend using fusen::inflate_all() directly so that it takes into account any modification.

This way of developing is what fusen is for, if you are new to it, the illustration on the {fusen} documentation is of great help.

The case of README

Changes to the README.md file should be done in the flat file README.Rmd. However, this file is not built by fusen but you need to use devtools::build_readme().

Fixing typos

You can fix typos, spelling mistakes, or grammatical errors in the documentation and vignettes directly using the GitHub web interface, as long as the changes are made in the source file. This generally means you’ll need to edit roxygen2 comments in the R code chunks of the vignettes flat files (.Rmd) in the dev/ directory. You can find the .R file that generates the .Rd by reading the comment in the first line.

Bigger changes

If you want to make a bigger change, it’s a good idea to first reach out with an issue using the “Feature request” template for instance.

If you have found a bug, please file an issue that illustrates the bug using the “Bug report” template with a minimal reprex. Small datasets are included in maldipickr that can be used to create the reprex.

Pull request process

  • Fork the package and clone onto your computer. If you haven’t done this before, we recommend using usethis::create_from_github("ClavelLab/maldipickr", fork = TRUE).

  • Install all development dependences with devtools::install_dev_deps(), and then make sure the package passes R CMD check by running devtools::check(). If R CMD check doesn’t pass cleanly, it’s a good idea to ask for help before continuing.

  • Create a Git branch for your pull request (PR). We recommend using usethis::pr_init("brief-description-of-change") or usethis::pr_init("fix-ISSUENUMBER-short-title") if you are aiming to fix a specific issue.

  • Make your changes

  • Open the dev/dev_history.R file: rstudioapi::navigateToFile("dev/dev_history.R") Find the “# Dependencies —-” part and run the attachment::att_amend_desc(...) as presented there. This will update documentation and list of dependencies in DESCRIPTION with the ones needed by maldipickr.

  • Commit to git, and then create a PR by running usethis::pr_push(), and following the prompts in your browser. The title of your PR should briefly describe the change. The body of your PR should contain Fixes #issue-number.

  • Summarize your changes to the community by editing the NEWS.md. We follow the style described in the Common Changelog.

Code style

  • Commit style. Commits should start whenever possible by a verb in lower case, as if the commit title continues the sentence: “Applying this commit will…”.

  • New code should follow the tidyverse style guide. You can use the styler package to apply these styles, but please don’t restyle code that has nothing to do with your PR.

  • We use roxygen2, with Markdown syntax, for documentation.

  • We use testthat for unit tests. Contributions with test cases included are easier to accept.

Code of Conduct

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