docs: add pull request template

[abhi-14gyan]

Description

Add .github/pull_request_template.md to provide a consistent structure for all pull requests. The template includes sections for description, related issue linking, type of change, affected components, testing details, and a pre-merge checklist.

This aligns with the existing issue templates (bug report, feature request, description) and references the project's tooling (uv, ruff, pytest) and CONTRIBUTING.md guide.

Related Issue

Closes #148

Type of Change

• New feature (non-breaking change that adds functionality)

Component(s) Affected

• CI / GitHub Actions (.github/)

How Has This Been Tested?

Verified that the template renders correctly on GitHub by previewing the markdown. No code logic changes — this is a documentation/workflow addition only.

Checklist

• I have read the CONTRIBUTING.md guide.
• My changes follow the existing code style.
• I have updated documentation if needed.

[bassosimone]

How would you characterize this change in conventional commits terms? Would you mind elaborating on this and also please updating the pull request title to reflect that? Also, and more importantly, there is more than one way of adding pull request templates, and this should probably be discussed with the maintainers, to understand the kind of information that they would like to be covered when someone opens a pull request. Maybe I missed it, and in which case apologies, but, is there a place where you and I discussed this? Is your intention that we discuss this as part of this pull request? If so, can you please elaborate on your intention in creating a PR template as opposed to just describing what you did (which, I understand, is adding a PR template). I think this is a valid improvement but I would like to hear from you about what a PR template should achieve before providing you with my comments.

[abhi-14gyan]

@bassosimone Thank you for the detailed feedback these are great points.

Conventional commit type: This would be docs: add pull request template, since it adds a documentation/workflow file that doesn't affect code, CI, or build logic. I'll update the PR title to reflect that.

On discussing this first: You're right while I did open an issue (#148 ) for this, I jumped straight into the implementation without waiting for any discussion from the maintainers on what the template should look like. I'm fairly new to open-source contribution, and I'm still learning the proper workflow I appreciate your patience and guidance on this.

What I think a PR template should achieve:

1. Context for reviewers - Every PR should clearly describe what changed and why, so reviewers don't have to reverse-engineer intent from the diff.
2. Traceability - Linking PRs to related issues (e.g., Closes #123) to maintain a clear connection between discussions and code changes.
3. Scope awareness - Identifying which component(s) are affected (library/, prototype/, data/, etc.) helps route reviews to the right people.
4. Testing confidence - A section describing how changes were validated gives reviewers confidence that the contribution was tested.
5. Consistency - A lightweight checklist (tests pass, lint clean, docs updated) ensures contributors follow the same baseline before requesting review.

I understand there are multiple approaches to this - a single .github/pull_request_template.md, multiple templates under .github/PULL_REQUEST_TEMPLATE/, or even a more minimal format. The current template I've proposed is just a starting point.

I'd love to hear your thoughts on what information you'd like covered. I'm happy to iterate on this PR based on your feedback, or if you'd prefer to discuss the scope more thoroughly on the issue first, I can close this PR in the meantime and resubmit once we've aligned. Whatever works best for the project!

[bassosimone]

After listing our project for GSoC, we received a large amount of pull requests across several repositories. We are dealing with the backlog, but this would take time. We will get back to this pull request eventually. In the meanwhile, if you are a GSoC applicant, please read our updated GSoC policy: https://github.com/m-lab/gsoc/.