Files
anki/.github/pull_request_template.md
Fernando Lins c7679305a4 Add a standardized pull request template (#4655)
This PR introduces a standardized pull request template setup to improve
review quality and consistency.

## Summary
- Adds a new default PR template at `.github/pull_request_template.md`.
- Standardizes PR submissions with consistent sections for context and
validation.
- Establishes a single source of truth for PR guidance.

## Why
- A unified template improves review quality and consistency.
- It reduces ambiguity for contributors when describing changes and test
coverage.
- Centralizing guidance makes future maintenance simpler.
2026-04-06 12:05:44 -03:00

62 lines
1.7 KiB
Markdown

<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes #123 / Closes #123 / Refs #123 -->
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context for reviewers. -->
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the "before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
1.
2.
3.
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests, manual steps, edge cases — the "after" or general validation). --->
### Checklist (minimum)
- [ ] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs -->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [ ] This PR is focused on one change (no unrelated edits).