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..

[arthurmccray]

@cophus @smribet @cedriclim1 @nwvlahakis @ehrhardtkm as discussed at dev meeting, let's get some other folks to weigh in on this. Don't know how to tag Toma and other people but feel free to add them as well

[smribet]

Thanks @bobleesj and @gvarnavi for putting this together! I suggest a hybrid approach between the two version proposed. In George's example, I think we can merge summary and description of changes. Especially for small PRs this is a bit redundant. I am ok to keep the reviewer checklist, and perhaps we can remove the contributor checklist?

[cedriclim1]

Agree with @smribet's comments. Re: my pr, I think it would have been nice to have the example section and review guidance split up in the PR template.

[bobleesj]

@gvarnavi @arthurmccray @smribet

Combined what I presented earlier and the reviewer's checklist to balance as suggested by @smribet

Please review below and if it looks alright, I will make a commit:

---

### What does this PR do?

<!-- Provide a brief overview and link to the issue. Attach outputs, including screenshots (before/after), if helpful for the reviewer(s). -->

### What should the reviewer(s) do?

<!-- Merge the code, provide feedback, initiate a discussion, etc. -->

<!--
Use the following checklist items when applicable (select only what applies):
- [ ] This PR introduces a public-facing change (e.g., API, CLI input/output).
    - [ ] For functional and algorithmic changes, tests are written or updated.
    - [ ] Documentation (e.g., tutorials, examples, README) has been updated.
    - [ ] A tracking issue or plan to update documentation exists.
- [ ] This PR affects internal functionality only (no user-facing change).
-->

### Reviewer checklist

<!-- Please leave as it is below -->

- [ ] 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

Rendered as:

What does this PR do?

What should the reviewer(s) do?

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