[.github] Add PR templates

[root-hbx]

No description provided.

[root-hbx]

@CodiumAI-Agent /describe

[CodiumAI-Agent]

Title

[.github] Add PR templates

---

PR Type

• Documentation

---

Description

• Add standardized PR template

• Include change rationale section

• Provide testing instructions section

• Add evaluation/impact notes section

---

Diagram Walkthrough

flowchart LR
  TPL["PR Template"] --> DESC["Change Description"]
  TPL --> REASON["Reason for Changes"]
  TPL --> TEST["How to Test"]
  TPL --> EVAL["Evaluation / Impact"]

Loading

File Walkthrough

	Relevant files
Documentation	pull_request_template.md Introduce PR template with key sections                                    .github/pull_request_template.md Introduce new PR template structure. Sections for description, reason, testing. Add evaluation/impact context area. Provide example bullet guidance. +21/-0

---

[root-hbx]

@CodiumAI-Agent /ask "hi, could u please take this PR for a whole review"

[CodiumAI-Agent]

Ask❓

hi, could u please take this PR for a whole review

Answer:

Here’s a full review of the newly added PR template file (.github/pull_request_template.md).

What’s added

• A clear, minimal structure for PR authors:
  • Brief description
  • Reason for changes
  • How to test
  • Evaluation (impact/benchmarks)
  • Additional context/screenshots

Strengths

• Encourages authors to include motivation and testing steps, which improves review efficiency.
• Simple and non-prescriptive; easy to adopt across different teams.
• Includes an example list to guide authors on what to write.

Gaps and Suggestions

1. Make sections actionable with checklists/placeholders

• People are more likely to fill out required info if prompted clearly.
• Example:
  • Linked Issues: Closes #123, Relates to #456
  • Type of Change: [ ] Bug fix [ ] Feature [ ] Refactor [ ] Docs [ ] Chore [ ] CI/CD
  • Breaking Changes: [ ] Yes [ ] No
  • Migration Steps: If breaking, describe here

2. Improve “How to Test”

• Encourage reproducible steps and environments.
• Example prompts:
  • Prerequisites (env vars, seeds, feature flags)
  • Steps to run (commands)
  • Test cases covered
  • Manual QA steps
  • Expected vs actual results
  • Screenshots/video for UI

3. Strengthen “Evaluation”

• Make performance/impact more structured.
• Example prompts:
  • Risk/Impact: User-facing? Backward compatible? Security implications?
  • Performance: Before/After metrics, datasets, tools used
  • Rollout: Feature flag, phased rollout, monitoring plan
  • Observability: Logs/metrics/dashboards/alerts added or updated

4. Add “Checklist” to reduce back-and-forth

• Example checklist:
  • Tests added/updated
  • Documentation updated
  • Linting/formatting pass
  • Security/privacy reviewed
  • Backward compatibility considered
  • Screenshots/recordings for UI
  • Linked issues referenced

5. Encourage concise diffs and context

• Add a “Screenshots/Recording” section for UI changes specifically.
• Add “Alternative approaches considered” to capture design reasoning.

6. Minor copy/format suggestions

• Fix spacing in “Resolves issue# XXX” to “Resolves issue #XXX.”
• Ensure a newline at end of file (currently missing).
• Use headings consistently; consider H2s for major sections and H3s for subsections.

Proposed revised template
You can replace the file contents with something like this:

Title

• Concise summary of the change

Linked Issues

• Closes #123
• Relates to #456

Type of Change

• Feature
• Bug fix
• Refactor
• Performance
• Docs
• CI/CD
• Chore

Description

• What changed and why. Include any alternative approaches considered.

Breaking Changes

• Yes
• No
  If yes, describe the impact and migration steps.

How to Test

• Prerequisites: env vars, feature flags, sample data
• Steps:
  1. ...
  2. ...
• Commands:
  • ...
• Expected results:
  • ...
• Screenshots/recordings (if UI):

Evaluation

• Risk/Impact: user-facing, security/privacy, backward compatibility
• Performance: before/after metrics, methodology
• Rollout plan: feature flags, phased rollout, monitoring/rollback plan
• Observability: logs/metrics/dashboards/alerts

Checklist

• Tests added/updated
• Docs updated
• Lint/format pass
• Security/privacy review (if applicable)
• Backward compatibility reviewed
• Screenshots/recordings for UI (if applicable)
• Issue(s) linked

Rationale

• This structure makes expectations explicit, improves reproducibility of testing, and reduces review and QA time.
• Checklists and explicit prompts help prevent missing critical context (security, performance, breaking changes).

If you prefer to keep it minimal, at least add:

• Linked issues, Type of change, Breaking changes, Checklist, and a newline at EOF.

[root-hbx]

This PR is ready to go.

It's also a verification of #14 .

[CodiumAI-Agent]

Ask❓

hi, could u please take this PR for a whole review

Answer:

Here’s a focused review of the added PR template.

What’s good:

• Clear, minimal structure that prompts authors for the essentials: description, reason, testing steps, and evaluation/impact.
• Encourages reproducibility via “How to Test” and performance via “Evaluation.”
• Concise and easy for contributors to follow.

Suggestions to improve clarity, consistency, and usefulness:

1. Clarify examples and formatting

• Replace “For example” bullet with a checklist for common PR types to guide categorization.
• Encourage linking issues properly (e.g., “Closes #123”) to auto-close on merge.

2. Add sections commonly needed in reviews

• Checklist for readiness and quality gates.
• “Scope/Changes” to list major changes.
• “Screenshots/Recordings” for UI or CLI changes.
• “Breaking Changes” and “Migration Notes.”
• “Risk/Impact” plus “Rollout/Backout Plan.”
• “Security/Privacy” and “Docs/Changelog” reminders.

3. Make “How to Test” actionable

• Include environment, dependencies, commands, expected outcomes.
• Encourage both manual and automated test notes.

4. Standardize headings and prompts

• Use imperative phrasing and examples under each section to reduce blank/low-effort submissions.

5. Minor nits

• Add a trailing newline to the file.
• Fix “issue#” to proper linking syntax.

Proposed revised template (drop-in):

Title: [Type] Short summary (e.g., feat: add X, fix: resolve Y)

Summary

• What changed? One or two sentences.

Related Issues

• Closes #123
• Relates to #456

Scope of Changes

• New feature
• Bug fix
• Refactor
• Docs
• CI/CD
• Other:
  Details
• Key changes:
  • …
  • …
• Any alternatives considered:

Reason for Changes

• Why is this needed? Link to context, specs, or discussions.

How to Test

• Prerequisites: env, versions, flags
• Steps:
  1. …
  2. …
• Commands:
  • …
• Expected results:
  • …
• Automated tests:
  • Areas covered/not covered:

Screenshots/Recordings

• Before/After (if UI/CLI):
  • …

Evaluation

• Performance/Impact:
  • Benchmarks or rough estimates
• Risk:
  • Potential side effects
• Rollout plan:
  • How to enable/monitor
• Backout plan:
  • How to revert and mitigate

Breaking Changes

• Yes (describe migration)
• No

Security/Privacy

• Data, permissions, secrets, PII implications:
  • …
• Threat considerations:
  • …

Documentation

• User docs updated
• Dev docs updated
• Changelog entry added
• Links:

Checklist

• Tests added/updated
• CI passes
• Code follows style/lint
• Issue linked with “Closes #…”
• Reviewed locally (self-QA)

Additional Context

• Anything else reviewers should know.

If you prefer to keep it minimal, at least:

• Change “Resolves issue# XXX” to “Closes #123”
• Add “Breaking Changes,” “Screenshots,” and a small “Checklist” with tests/CI/docs
• Add a trailing newline

This will make PRs more consistent, reduce review back-and-forth, and improve traceability.

[root-hbx]

@gemini-code-assist review

[gemini-code-assist]

Important

Installation incomplete: to start using Gemini Code Assist, please ask the organization owner(s) to visit the Gemini Code Assist Admin Console and sign the Terms of Services.