Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions .github/ISSUE_TEMPLATE/bug_report.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
---
name: Bug report
about: Something is broken or a reconstruction behaves unexpectedly
labels: bug
---

## What happened

<!-- What you expected, what you got instead, and the full traceback if there is one.
For reconstruction problems, a figure of the result helps a lot. -->

## How to reproduce

<!-- A minimal script, the engine and its parameters, and the dataset if you can
share it (or a link to it). -->

## Environment

- PtyLab version: <!-- pip show ptylab or the git commit -->
- Python version:
- OS:
- CPU or GPU (and CuPy/CUDA version if GPU):
39 changes: 7 additions & 32 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,37 +1,12 @@
<!-- One or two lines: what this changes, and how it relates to what came before
(a series, an issue, an earlier PR). Bold the one thing a reviewer must not
miss — a breaking change, changed numerical output, "no runtime code is
touched". Delete any section below that does not apply. -->
## What and why

## Why
<!-- What this changes and why. Link the related issue or PR, if any. -->

<!-- The problem, stated concretely. A traceback, a measurement, or a file:line
beats a description of the problem. If it is a bug: what breaks, where, and
for whom. If it is performance: the number that justifies the work. -->
## How it was tested

## What changed
<!-- Tests added or run, or how you checked the change works.
If possible, add a demo figure or screenshot showing the result. -->

<!-- The change itself, in the order a reviewer would want to read it. Tables for
measurements. Before/after code only where the diff alone is not obvious. -->
## Notes

## Verification

<!-- Evidence the change does what it claims, and that the tests would have
caught the bug. Reverting the fix and showing the new tests fail is the
standard here — a test that passes on `main` proves nothing. -->

## Tests

<!-- New/changed test files and what each covers, then the suite count:
N → M passing. -->

## Notes and follow-ups

<!-- Anything deliberately left out, pre-existing problems this diff makes
visible but does not fix, and any decision a reviewer is being asked to
make. -->

## Version

<!-- `x.y.z` → `x.y.z`, and whether that publishes on merge. "No bump — nothing
ships from this" is a valid answer, but say it explicitly. -->
<!-- Optional: breaking changes, changed reconstruction results, follow-ups. -->
Loading