Skip to contents

Contributing to MiscMetabar

Source: CONTRIBUTING.md

First off, thanks for taking the time to contribute to MiscMetabar!

This contributing guide is heavily based on the contributing guide from rcompendium.

All types of contributions are encouraged and valued. See the Table of contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved.

Table of contents

Code of conduct

This project is released with a Contributor Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to .

Style guide

We use the Tidyverse style guide for writing R code. Functions are documented with the roxygen2 syntax.

MiscMetabar uses the lower_snake_case except when we want to integrate names from other packages.

Commit messages

If you want to contribute by commiting changes, please try to use (at least more than me) the Conventional commits specification.

Asking questions

Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue.

If you then still feel the need to ask a question and need clarification, we recommend the following:

  • Open a new Issue.
  • Use the template other_issue.md.
  • Provide as much context as you can about what you’re running into.
  • Provide project and platform versions (paste the output of sessionInfo()).

We will then take care of the issue as soon as possible.

Reporting bugs

Before submitting a bug report

A good bug report shouldn’t leave others needing to chase you up for more information. Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report. Please complete the following steps in advance to help us fix any potential bug as fast as possible.

  • Make sure that you are using the latest version of MiscMetabar.
  • Determine if your bug is really a bug and not an error on your side.
  • To see if other users have experienced (and potentially already solved) the same issue you are having, check if there is not already a bug report existing for your bug or error in the bug tracker.

How do I submit a bug report?

We use GitHub Issues to track bugs and errors. If you run into an issue with the project:

  • Open a new Issue.
  • Use the template bug_report.md.
  • Explain the behavior you would expect and the actual behavior.
  • Please provide as much context as possible and describe the reproduction steps that someone else can follow to recreate the issue on their own. This usually includes your code with a reproducible example.

We will then take care of the issue as soon as possible.

Requesting features

Before requesting a feature

  • Make sure that you are using the latest version of MiscMetabar.
  • Read the documentationcarefully and find out if the functionality is already covered.
  • Perform a search to see if this enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.

How do I submit a feature request?

Feature requests are tracked as GitHub Issues.

  • Open a new Issue.
  • Use the template feature_request.md.
  • Provide a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Explain why this enhancement would be useful to most MiscMetabar users.

We will then take care of the issue as soon as possible.

Contributing code

I add some rules for the package development in the pkgdown site here. In short :

  • Always indicate required params (required)

  • Indicate default values only when (i) a set of values is possible (e.g “bray” for the parameter method in [vegan::vegdist()]) or (ii) when this value is well thought out and a good default value for most users (e.g. the number of permutation or processors, or the level of identity to cluster at 97%).

  • Indicate the type for logical and integer params.

  • Homogenize the params names across function.

  • Prefer ASVs to OTUs denomination, even thought both are almost interchangeable in the MiscMetabar package. #### Lifecycle

  • Experimental: First status for a function

  • Maturing: Some tests and/or analyses make stronger these functions

  • Stable: Good level of confidence

General workflow

We use the GitHub flow to collaborate on this project:

  1. Fork this repository using the GitHub interface.
  2. Clone your fork using git clone fork-url (replace fork-url by the URL of your fork). Alternatively, open RStudio IDE and create a New Project from Version Control.
  3. Create a new branch w/ git checkout -b branch-name (replace branch-name by the name of your new branch).
  4. Make your contribution (see below for examples).
  5. Stage (git add) and commit (git commit) your changes as often as necessary
  6. Push your changes to GitHub w/ git push origin branch-name.
  7. Submit a Pull Request on the original repo.

We will then review the PR as soon as possible.

Improve documentation

Editing the README

If you want to contribute by improving the README, please edit the README.Rmd (not the README.md). Do not forget to update the README.md by running:

rmarkdown::render("README.Rmd")

Editing vignettes

If you want to contribute by editing an existing vignette, just edit the corresponding Rmd file stored in the vignettes/ folder. If you want to contribute by adding a new vignette, create a new Rmd file in the vignettes/ folder and add the following header:

---
title: "Vignette Title"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Vignette Title}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---

If you use a new external dependency, do not forget to add it in the DESCRIPTION file under the section Suggests (only if this package is not already listed under the section Imports).

Check the integrity of the package with:

devtools::check()

Editing function documentation

If you want to contribute by improving the documentation of a function, open the corresponding file in the R/ folder and edit lines starting with #' (roxygen2 syntax).

Update the documentation (Rd files in the man/ folder) by running:

devtools::document()

If you use a new external dependency in the example section, do not forget to add it in the DESCRIPTION file under the section Imports (only if this package is not already listed).

Check the integrity of the package with:

devtools::check()

Fix bug

If you want to contribute by improving the code of a function, open and edit the corresponding file in the R/ folder.

Check the integrity of the package with:

devtools::check()

Do not forget to adapt the unit tests for the function by editing the corresponding file stored in the tests/testthat/ folder. We use the package testthat to implement unit tests.

Check your tests by running:

devtools::test()

Warning, test are time-consuming. Feel free to improve the speed of the tests!

New feature

If you want to contribute by submitting a new feature, please follow this workflow:

  1. Create a new R file in the folder R/.
  2. Implement the code of the function.
  3. Document your function w/ the roxygen2 syntax.
  4. If necessary, add additional dependencies in the DESCRIPTION file.
  5. Update the package documentation w/ devtools::document().
  6. Create a new R file in the folder tests/testthat/.
  7. Implement unit tests for the new function.
  8. Check the integrity of the package w/ devtools::check().

Thanks for your contribution!