Thank you for taking the time to contribute! This document outlines the process for reporting issues and submitting code changes.
Code of Conduct
Please review and follow our Code of Conduct.
Reporting bugs
Use the bug report template and include:
- A minimal reproducible example (ideally using
reprex::reprex()) - The ENTSO-E API endpoint involved and the query parameters used
- Your OS, R version, and
entsoeapiversion (packageVersion("entsoeapi"))
Do not include your ENTSO-E security token in the report.
Requesting features
Open a feature request describing the ENTSO-E endpoint or data domain you would like covered and a brief use case.
Submitting a pull request
Fork the repository and create a branch from
main.Install development dependencies:
devtools::install_dev_deps().Make your changes. Keep each PR focused on a single concern.
Add or update tests — the package targets 100% test coverage.
-
Run the full check suite locally before pushing:
lintr::lint_package() devtools::document() devtools::test() devtools::check() covr::package_coverage() Open the pull request against
mainand describe what changed and why.
Conventions
- Follow the existing code style (snake_case,
cli::for user-facing messages,checkmate::for input validation). - New user-facing functions must have
@examplesIfblocks (see existing functions for the pattern). - All exported functions need a
@returntag in their roxygen documentation. - ENTSO-E security tokens must never appear in code, tests, or fixtures — use the
ENTSOE_PATenvironment variable.
Questions
For general usage questions, open a GitHub Discussion rather than an issue.