Files
openhuman/.github/PULL_REQUEST_TEMPLATE.md
T
Steven EnamakelandGitHub 6aeea8ba49 Docs: issue/PR templates, CLAUDE workflow notes, PR template filename (#83)
* chore: uppercase PR template (summary, problem, solution)

Made-with: Cursor

* chore: uppercase PR template (testing, impact)

Made-with: Cursor

* chore: uppercase PR template (breaking changes, related)

Made-with: Cursor

* chore: intermediate rename for pull request template path

Made-with: Cursor

* chore: use uppercase PULL_REQUEST_TEMPLATE.md

Made-with: Cursor

* docs: point agent docs at PULL_REQUEST_TEMPLATE.md

Made-with: Cursor

* chore: update pull request and feature issue templates for clarity and consistency

- Standardized section headings to title case for uniformity.
- Enhanced descriptions for each section to improve guidance for contributors.
- Introduced a new feature issue template to streamline feature proposals and documentation requirements.

* docs: enhance issue and pull request templates for better guidance

- Added a new bug issue template to standardize bug reporting.
- Updated the feature issue template to clarify the problem and solution sections.
- Revised the pull request template to include a submission checklist for testing and documentation requirements.

* chore: comment out E2E macOS workflow steps in test.yml

- Temporarily disabled the E2E (macOS / Appium) job in the GitHub Actions workflow by commenting out all related steps for future reference.
2026-03-30 10:32:42 -07:00

35 lines
1.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## Summary
- What changed and why.
- Keep this to 3-6 bullets focused on user-visible or architecture-impacting changes.
## Problem
- What issue or risk this PR addresses.
- Include context needed for reviewers to evaluate correctness quickly.
## Solution
- How the implementation solves the problem.
- Note important design decisions and tradeoffs.
## Submission Checklist
- [ ] **Unit tests** — Vitest (`app/`) and/or `cargo test` (core) for logic you add or change
- [ ] **E2E / integration** — Where behavior is user-visible or crosses UI → Tauri → sidecar → JSON-RPC; use existing harnesses (`app/test/e2e`, mock backend, `tests/json_rpc_e2e.rs` as appropriate)
- [ ] **N/A** — If truly not applicable, say why (e.g. change is documentation-only)
- [ ] **Doc comments**`///` / `//!` (Rust), JSDoc or brief file/module headers (TS) on public APIs and non-obvious modules
- [ ] **Inline comments** — Where logic, invariants, or edge cases arent clear from names alone (keep them grep-friendly; avoid restating the code)
(Any feature related checklist can go in here)
## Impact
- Runtime/platform impact (desktop/mobile/web/CLI), if any.
- Performance, security, migration, or compatibility implications.
## Related
- Issue(s):
- Follow-up PR(s)/TODOs: