Contributing#
Use this sequence to take a change from a local checkout to a pull request. Run commands from the repository root in your development environment.
Set up and make the change#
Follow Development environment to install the contributor tools. Keep the change focused on one problem so its behavior and tests are easy to review. The repository map in Development can help you find the relevant code.
Add or update tests when changing preprocessing, filtering, or radiomics logic. Preserve IBSI validation coverage when modifying feature calculations; see IBSI validation for reference handling.
Check the change locally#
Before opening a pull request:
Run relevant tests during development, then the unit suite and any integration tests affected by the change. Review coverage as described in Testing.
Run the formatting and lint checks in Code quality.
Update the documentation for changed behavior, public APIs, and examples, then build it using Building and editing the docs. That page explains where each kind of documentation belongs.
If the change targets performance, compare measurements using Performance benchmarking and retain the reference and candidate results.
Open the pull request#
Explain the problem, what changes for users or developers, and how you checked it. Mention any relevant limitations or checks that you could not run.
After opening the pull request, inspect its CI results and address failures before requesting review. Repeat the affected checks after revisions. The documentation workflow does not run on pull requests, so build changed documentation locally even when the other CI checks pass.