Skip to contents

Contributing to agriDesignR

Source: CONTRIBUTING.md

Thanks for helping improve agriDesignR. Contributions should preserve statistical validity, reproducibility, and the package’s public API.

Before opening an issue

  • Search existing issues and documentation.
  • For statistical questions, include experimental design, response type, treatment structure, blocking structure, and a minimal reproducible example.
  • Remove confidential field, patient, and proprietary data.

Development setup

Clone the repository and install dependencies declared in DESCRIPTION. For local development, install devtools and pak, then run pak::local_install_dev_deps() to install suggested packages needed by tests and vignettes. Use devtools::load_all() to load the package during editing.

Code and statistical standards

  • Keep exported function signatures and S3 classes backward compatible unless a breaking change is explicitly documented.
  • Validate inputs before fitting models; errors must identify the problematic argument or column.
  • Use explicit namespaces where function names may be ambiguous.
  • Add or update testthat tests for behavior changes, including invalid-input and missing-data paths.
  • Keep randomization reproducible when a seed argument is provided, and avoid changing the caller’s global random-number state unnecessarily.
  • Document assumptions, estimands, and limitations. Automatic recommendations are guidance, not a substitute for design expertise.
  • Add roxygen comments for exported functions, then regenerate documentation; never edit NAMESPACE or generated .Rd files by hand.

Checks before pull request

Run devtools::test(), devtools::check(args = c("--as-cran", "--no-manual")), and covr::package_coverage(). For a built tarball, use R CMD check --as-cran --no-manual agriDesignR_*.tar.gz. Documentation changes must also be checked on a clean install, including vignette links and examples.

Pull requests

Use a focused branch. Describe the user problem and experimental context, the behavior and compatibility impact, and tests or checks run. Use Conventional Commits, for example fix(model): validate missing treatment levels or docs: clarify split-plot assumptions.

Maintainers may request additional simulations, methodological references, or cross-platform checks for changes affecting inference.