Thanks for your interest in contributing to OracleTrace.
OracleTrace is focused on practical Python performance regression detection: lightweight tracing, clear comparison output, and useful CLI workflows.
Contributions are welcome for:
- Performance regression detection improvements
- Trace comparison quality
- CLI usability
- Output clarity and visualization
- Documentation and examples
- Read README.md
- Check docs under https://kaykcaputo.github.io/oracletrace/
- Browse open issues, especially good first issues: https://github.com/KaykCaputo/oracletrace/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
git clone https://github.com/<Your-User>/oracletrace.git
cd oracletracepython -m venv .venv
source .venv/bin/activatepip install -e .oracletrace --help- oracletrace/cli.py: CLI arguments and command flow
- oracletrace/tracer.py: tracing engine and output rendering
- oracletrace/compare.py: baseline vs current comparison logic
- docs/docs: documentation pages
- docs/mkdocs.yml: docs configuration
git checkout -b feature/short-descriptionKeep PRs small and scoped to one clear objective.
Run the checks in the Validation section.
Use clear commit messages and push your branch.
Explain the motivation, what changed, and expected impact.
- Prefer simple, readable solutions over complex abstractions
- Keep behavior changes explicit and documented
- Preserve existing CLI behavior unless the PR is intentionally changing it
- Follow existing style and naming patterns
- Avoid new dependencies unless clearly justified
This repository has automated CLI tests with pytest. Run tests before opening a PR.
pytestoracletrace --helporacletrace your_script.pyoracletrace your_script.py --json baseline.json
oracletrace your_script.py --json current.json --compare baseline.jsonoracletrace your_script.py --csv trace.csv
oracletrace your_script.py --ignore "helper_function,debug_*"
oracletrace your_script.py --top 10mkdocs build -f docs/mkdocs.yml- mkdocs
- the packages listed in
mkdocs -f docs/mkdocs.yml get-depsmust be installed in your python environment
If your PR changes flags, behavior, output format, or workflows:
- Update the relevant page in docs/docs
- Keep examples executable and aligned with real CLI behavior
- Ensure docs build succeeds
Use the GitHub templates when opening issues and pull requests. They keep reports consistent and speed up review.
- Bug report:
.github/ISSUE_TEMPLATE/bug_report.md - Feature request:
.github/ISSUE_TEMPLATE/feature_request.md - Question or discussion:
.github/ISSUE_TEMPLATE/question_or_discussion.md
When opening an issue, provide enough detail for maintainers to reproduce or evaluate quickly:
- Expected behavior and actual behavior (for bugs)
- Minimal reproduction steps
- Python version and OS/environment details
- Exact commands and output when relevant
All pull requests should follow:
The template includes:
- Required validation commands
- Checklist items for style, tests, CI status, and docs updates
- Before/after output section for behavior changes
Please complete all relevant sections before requesting review.
- Keep PRs small and focused
- Link related issues (for example: Closes #123)
- Add before/after output snippets when changing CLI behavior
- Highlight any backward-incompatible changes
If anything is unclear, open an issue.
Discussion is welcome and encouraged.