chore: add pull request templates

[liamnwhite1]

Summary

Add a repository pull request template that guides contributors to provide consistent context, testing details, validation evidence, and regression-risk notes when opening PRs.

Related issues

• Closes chore: add pull request templates #145

Details

This change adds a standardized pull request template for the repository so contributors can describe their changes in a consistent, review-friendly format.

The template is structured to support several PR categories, including bug fixes, features, performance work, refactors, and chores. It also prompts authors to document testing, validation evidence, attachments, and regression risk, which should make reviews easier and reduce back-and-forth on missing context.

Impact

• Overall risk level of changes (High / Medium / Low) and why: Low

This change adds documentation/workflow scaffolding only and does not modify application logic.

It improves the contributor workflow by making pull requests more consistent and by encouraging authors to include the information reviewers need to evaluate changes efficiently.

Testing strategy

• The CI test suite covers this change.
• Manual testing performed for this change. If so, please describe.

Notes: No code paths or runtime behavior were changed, so automated or workflow-based testing was not applicable for this commit.

[gemini-code-assist]

Summary of Changes

Hello @liamnwhite1, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request streamlines the development workflow by introducing a set of predefined pull request templates for different types of changes, such as bug fixes, new features, refactors, and general maintenance tasks. Additionally, it establishes clear code ownership for various sections of the repository, which will help in automating review assignments and clarifying responsibilities.

Highlights

• Standardized Pull Request Templates: Introduced predefined pull request templates for bugfix, chore, feature, and refactor changes to standardize PR submissions.
• Code Ownership Defined: Established code ownership for various repository paths by adding a CODEOWNERS file, aiming to streamline review assignments.
• Improved Workflow: The changes are intended to improve the overall development workflow and ensure consistency across different types of contributions.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• .github/CODEOWNERS
  • Added a CODEOWNERS file to define default and specific owners for different parts of the repository.
• .github/PULL_REQUEST_TEMPLATE/bugfix_pull_request.md
  • Created a new template for bugfix pull requests, including sections for summary, related issues, changes, testing, documentation, reviewer focus, and a checklist.
• .github/PULL_REQUEST_TEMPLATE/chore_pull_request.md
  • Created a new template for chore pull requests, including sections for summary, related issues, changes, testing, documentation, reviewer focus, and a checklist.
• .github/PULL_REQUEST_TEMPLATE/feature_pull_request.md
  • Created a new template for feature pull requests, including sections for summary, related issues, changes, testing, documentation, reviewer focus, and a checklist.
• .github/PULL_REQUEST_TEMPLATE/refactor_pull_request.md
  • Created a new template for refactor pull requests, including sections for summary, related issues, changes, testing, documentation, and a checklist.

Activity

• The author linked issue chore: add pull request templates #145 to be closed upon merge and indicated a dependency on PR chore: add CODEOWNERS file #144.
• The author provided a summary of changes, noted that testing can only occur post-merge, and stated no additional documentation is needed.
• The author requested reviewers to focus on confirming template structure, wording, and checklist completeness.
• The author completed the checklist items for linked issues/PRs, documentation, and reviewer focus areas.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a set of standardized templates for pull requests and a CODEOWNERS file. The changes are well-structured and will help improve the consistency of PR submissions. I've left a few minor suggestions on the PR templates to improve their formatting and usability.

[gknapp1]

All of the documents are pretty much the same template, and they might be able to be merged into one document, per Sam's comment in the issue. But I understand the benefit from keeping them separate for automatic labeling. Given that these templates shouldn't be updated very frequently, I'm fine with leaving them separate from a maintenance standpoint.

[gknapp1]

@liamnwhite1, I pushed some tweaks to the wording and moved some clutter in the attachment section to the comments, since most of the entries would be N/A for any given PR.

[streeve]

LGTM - I updated the PR description with the updated template.

On gitlab you can mark a checkbox as not applicable with a ~, but I guess not here..

[liamnwhite1]

The changes you made look good to me. I made a few minor adjustments to formatting and indentation for consistency.

I also uncommented the Attachments section and added a comment + checkbox (similar to Related issues) to indicate that it’s optional. My reasoning is that agents rely heavily on the hierarchical structure of Markdown. When the entire section is commented out, it effectively becomes nested under Testing strategy, which isn’t accurate and can make its intent ambiguous.

This is admittedly a minor/defensive change, but it reduces the amount of interpretation required by the agent and lowers the risk of incorrect reasoning.

If you feel strongly otherwise, I’m fine reverting it.

[gknapp1]

The changes you made look good to me. I made a few minor adjustments to formatting and indentation for consistency.

I also uncommented the Attachments section and added a comment + checkbox (similar to Related issues) to indicate that it’s optional. My reasoning is that agents rely heavily on the hierarchical structure of Markdown. When the entire section is commented out, it effectively becomes nested under Testing strategy, which isn’t accurate and can make its intent ambiguous.

This is admittedly a minor/defensive change, but it reduces the amount of interpretation required by the agent and lowers the risk of incorrect reasoning.

If you feel strongly otherwise, I’m fine reverting it.

If a commented optional section is potentially confusing to an agent, then I would prefer removing the attachments section completely as opposed to making it visible. After discussion with @streeve yesterday, it is somewhat ambiguous what the attachment section is for. Logs and figures should be included within the relevant sections if they are needed, not listed separately as an attachment.

[liamnwhite1]

@gknapp1 Yeah that makes sense! The source of the section came from a different repo where it makes it more sense. I just removed the section though so if it's good, I can merge it!