add pull request template (tutorial/tests check)

[bobleesj]

What problem does this PR address?

For each PR, we want to ensure there is a tutorial notebook, tests written.

What should the reviewer(s) do?

Please review the content of the template. This template is currently used at https://github.com/scikit-package/scikit-package and has worked pretty well.

• This PR affects internal functionality only (no user-facing change).

[bobleesj]

@gvarnavi @cophus ready for review.

[arthurmccray]

maybe i'm missing something, but does the template mention writing tests?

[bobleesj]

@arthurmccray

maybe i'm missing something, but does the template mention writing tests?

yup, added per your feedback.

I realized that we have a quite diverse range of people contributing to this project and also maybe first-timers, so mentioning tests here can be useful while keeping the checklsit minimla. (of course writing tests is assumed amongst core contributors and this checklist is used as a mental "list" to go thru)

[bobleesj]

@cophus @gvarnavi, if you have time, please take about 10s to look at this PR template.

The motivation for using <!-- --!>:

• we don't want to overwhelm new users and core developers with too many checklists, just to make a simple PR:
• only use the checklists where appropriate

conda-forge also uses <!-- --> as well in making PRs

[gvarnavi]

Thanks for putting this together @bobleesj!

This is good, but I don't love the informal tone, and i think we should add some more clarity re: reproducible examples / imported code etc. Perhaps something like the following (loosely inspired from the LiberTEM one)?

## Summary

<!--
Brief description of the motivation and scope of this pull request.
Link to a relevant issue if applicable.
-->

---

## Description of changes

<!--
Describe the main technical, algorithmic, or structural changes introduced here.
-->

---

## Example / reproduction

<!--
Provide a minimal example demonstrating the contribution.

This may be:
- a short code snippet in this PR,
- a notebook or script attached to the PR, or
- a link to an external example.

The goal is to allow reviewers to understand and reproduce the result.
-->

---

## Review guidance

<!--
Indicate any specific aspects that reviewers should focus on
(e.g. correctness, numerical behavior, API design, performance, documentation).
-->

---

## Contributor checklist

- [ ] Tests have been added or updated as appropriate
- [ ] Documentation (docstrings, examples, or tutorials) has been added or updated
- [ ] A minimal working example is provided
- [ ] Any imported or adapted code is compatible with the project license

---

## Reviewer checklist

- [ ] Tests pass and are appropriate for the changes
- [ ] Documentation and examples are sufficient and clear
- [ ] Imported or adapted code has a compatible license
- [ ] The implementation matches the stated intent of the contribution

[gvarnavi]

PS, you should merge dev into the PR to trigger the required tests.

[bobleesj]

To me, it’s a balance and a cultural choice. I’ve contributed to projects where seeing a PR template with five or more sections makes the barrier feel unnecessarily high, and filling it out can feel robotic, though I understand the intent behind the checklist.

I'd suggest we keep Summary, Description of changes, and Example / reproduction in a single stack - one sentence describing what the change does, and one sentence linking to a demo or API example.

That would make it much easier for me (will be a core contributor) to submit a quick PR, iterative quickly on feature branches.

[bobleesj]

Forgot to mention - in GitHub workflows, as natively designed, we should encourage people to create GitHub issues and PR is meant to close that GitHub issues. Then, the first sentence of the PR can be as simple as "Close #xyz`, followed by demo.

[gvarnavi]

Forgot to mention - in GitHub workflows, as natively designed, we should encourage people to create GitHub issues and PR is meant to close that GitHub issues. Then, the first sentence of the PR can be as simple as "Close #xyz`, followed by demo.

I don't disagree this is a clean workflow (especially for new contributors!), however I'll be honest and admit that opening an issue for every PR (especially new feature ones) will add burden on core devs..