File size: 2,858 Bytes
ae40686 b9d7591 ae40686 b9d7591 ae40686 b9d7591 ae40686 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | # 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](https://github.com/tatopenn-cell/Dense-Evolution/blob/main/license.md) — 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](https://github.com/tatopenn-cell/Dense-Evolution/issues) 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](https://github.com/tatopenn-cell/Dense-Evolution/blob/main/SECURITY.md).
## Development setup
```bash
git clone https://github.com/tatopenn-cell/Dense-Evolution.git
cd Dense-Evolution
pip install -e .[full]
```
## Running tests
```bash
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.
|