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.
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.
- Starting from v1.3.1 Changes to the
README.md
file can be done in this file as no code is running in there anymore. - Prior to v1.3.1 Changes to the
README.md
file should be done in the flat fileREADME.Rmd
. However, this file is not built by{fusen}
but you need to usedevtools::build_readme()
.
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.
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.
-
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 runningdevtools::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")
orusethis::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 theattachment::att_amend_desc(...)
as presented there. This will update documentation and list of dependencies inDESCRIPTION
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 containFixes #issue-number
. -
Summarize your changes to the community by editing the
NEWS.md
. We follow the style described in the Common Changelog.
-
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.
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.