Contributing to Dense-Evolution
Thanks for considering a contribution. This is a single-maintainer project — response times may vary, but every issue and PR gets read.
Before you start
Dense-Evolution is released under the Business Source License 1.1 — free for non-commercial use, with commercial-production terms defined in the license itself (converting to Apache 2.0 on the Change Date stated there). By submitting a contribution, you agree it's licensed under the same terms as the rest of the project.
Reporting bugs
Open an issue with:
- A minimal circuit/script that reproduces the problem
- What you expected vs. what actually happened
python -c "import dense_evolution; print(dense_evolution.__version__)"output, plus your Python version and OS
If it's a correctness bug (wrong probabilities, wrong statevector, silently dropped gates), include a comparison against a known-correct reference if you have one — that's usually the fastest way to confirm and fix it.
Reporting security issues
Don't open a public issue for security vulnerabilities. See SECURITY.md.
Development setup
git clone https://github.com/tatopenn-cell/Dense-Evolution.git
cd Dense-Evolution
pip install -e .[full]
Running tests
pytest test_dense_evolution.py test_ia_healing.py test_dashboard_core.py test_ai_middleware.py test_interop.py test_autodiff.py test_quantum_scars.py test_mitigation.py test_mps.py test_mitigation_runner.py test_interactive_panel.py test_docs_examples.py -v
test_interop.py needs qiskit/pennylane installed (skips cleanly via pytest.importorskip if they aren't). CI (.github/workflows/ci.yml) runs the full suite on Python 3.10/3.11/3.12 on every push/PR to main — check it's green before asking for a review.
Making changes
- Match the existing code style — no comments explaining what code does (names should do that); comments only for non-obvious why (a workaround, an invariant, a hard-won bug fix).
- Add tests for anything you fix or add — especially anything numerical (statevector/probability outputs). A test that would have caught the bug you just fixed is worth more than a description of the fix.
- Update
README.md's changelog section if your change is user-visible. - Keep PRs focused — one fix or one feature per PR is easier to review than a bundle of unrelated changes.
Submitting a PR
Push to a branch on your fork, open a PR against main, and describe why the change is needed, not just what it does — the "why" is what a reviewer (and future you) actually needs.