pkgdown/mathjax-config.html

Skip to contents

Contribution Guidelines

Source: CONTRIBUTING.md

Thank you for taking the time to contribute to BORG.

This document provides guidelines for contributing to BORG’s codebase and documentation. These guidelines are meant to help, not restrict. If in doubt, use your best judgment and feel free to propose improvements through an issue or pull request.

Table Of Contents

Code of Conduct

This project and everyone participating in it is governed by our Code of Conduct (CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code and maintain a respectful, inclusive environment.

Installation

This installation guide is focused on development. For regular installation, please see the README.

Obtaining the source

Clone the BORG repository:

git clone https://github.com/gcol33/BORG.git
cd BORG

If you work on a development branch:

git checkout dev
git pull origin dev

Setting up your R environment

BORG is an R package that uses C++ code via Rcpp.

  1. Install required tools

    • R (>= 4.0)
    • Rtools (Windows) or Xcode Command Line Tools (macOS)
    • Git
    • An editor or IDE (RStudio, VS Code, etc.)

  2. Install development dependencies

    install.packages(c("devtools", "roxygen2", "testthat", "rmarkdown", "knitr", "pkgdown"))

  3. Load the development build

    devtools::load_all()

Installing from source

Build and install the package locally:

devtools::install()

If you modify C++ code, rebuild the DLL before reinstalling:

devtools::clean_dll()
devtools::install()

Regenerate documentation with:

devtools::document()

Testing

BORG uses testthat for testing. All tests are located in tests/testthat/.

Run the full test suite:

devtools::test()

Run a complete package check:

devtools::check()

Run a subset of tests during development:

testthat::test_dir("tests/testthat")
testthat::test_file("tests/testthat/test-borg_inspect.R")

Guidelines: - Keep tests fast and reproducible. - Use set.seed() for random data. - Include edge cases and expected failures. - Prefer small examples to large datasets.

Documentation

Install dependencies

install.packages(c("rmarkdown", "knitr", "pkgdown"))

Building the documentation

Build vignettes:

devtools::build_vignettes()

Build the pkgdown site locally:

pkgdown::build_site()

The generated site is saved in the docs/ directory. Open docs/index.html in your browser to view it.

Design of the docs

  • Function documentation: man/ (generated by roxygen2)
  • Tutorials and examples: vignettes/
  • Website configuration: _pkgdown.yml
  • Package overview: README.md
  • Changelog: NEWS.md

Project organization

BORG/
├── .github/                <- Continuous integration workflows
├── .gitignore
├── .Rbuildignore
├── BORG.Rproj
├── DESCRIPTION             <- Package metadata
├── NAMESPACE               <- Function exports and imports
├── LICENSE
├── LICENSE.md
├── NEWS.md
├── README.md
├── _pkgdown.yml
├── R/                      <- R source files
├── src/                    <- C++ source files (Rcpp)
├── man/                    <- Generated documentation
├── inst/                   <- Installed files (e.g., CITATION)
├── vignettes/              <- Long-form documentation and usage examples
├── tests/
│   └── testthat/           <- Unit tests
├── docs/                   <- pkgdown website (generated)
└── doc/                    <- Built vignettes for local preview (ignored)

Contributing workflow

  1. Create a feature branch

    git checkout -b feature/my-feature

  2. Make focused commits with clear messages.

  3. Run tests and checks before committing:

    devtools::test()
devtools::check()

  4. Update documentation with roxygen2 and NEWS.md.

  5. Update vignettes/examples if user-facing behavior changes.

  6. Open a pull request with a short description of your change.

  7. Respond to review feedback constructively.

Style guidelines

R code

  • Use descriptive names and consistent indentation.
  • Prefer vectorized operations over loops.
  • Validate inputs early with clear error messages.
  • Document all exported functions with roxygen2.

C++ code

  • Keep headers minimal and separate interface from implementation.
  • Use RAII where possible.
  • Comment on algorithmic details or numerical behavior.
  • Avoid unnecessary memory allocations.

Tests

  • Add or update tests when functionality changes.
  • Keep tests minimal and reproducible.
  • Avoid external dependencies unless essential.

Pull request checklist

Reporting bugs

When reporting an issue, please include: - A minimal reproducible example (reprex) - Output of sessionInfo() - Expected vs. actual results - Which BORG function was called and with what arguments - R and operating system version

By contributing to BORG, you agree that your code is released under the same license as the package.