CONTRIBUTING.md

In ptaconet/opendapr: Fast and Efficient Access to MODIS Earth Observation Data

Contributing to modisfast

First off, thanks for taking the time to contribute!

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
• Style guide
• Commit messages
• Asking questions
• Reporting bugs
• Requesting features
• Contributing code

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 [e-mail].

Style guide

We use as much as possible the Tidyverse style guide for writing R code - except for line length. Functions are documented with the roxygen2 syntax. modifast uses the lower_snake_case.

Commit messages

If you want to contribute by commiting changes, please try to use 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.
• 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 modisfast.
• 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.
• 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 modisfast.
• Read the documentation carefully 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.
• 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 modisfast users.

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

Contributing code

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/articles/ folder.

If you want to contribute by adding a new vignette, create a new Rmd in the vignettes/articles/ 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 tag 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()

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().

ptaconet/opendapr documentation built on Nov. 20, 2024, 10:04 p.m.