clean up github PR form template

[Sevans711]

Closes #1595

Overview

Fixes/improves a variety of outdated/confusing aspects of the default PR form, as noted in #1595:

1. Comment at the top now properly states how to link multiple issues being closed (cannot just do "closes #XXX, #YYY" as previously implied; must repeat the keyword each time, such as "closes #XXX, closes #YYY").
2. Comment at the top now clarifies it is not necessary for PRs to fully close an issue, can instead write something like "Related to #XXX", or "Fixes part of #YYY but does not fully close it."
3. In "Expected Usage" comment, changed "If you are adding a feature into the Internal API, please produce a short example of it in action." to "If this PR adds a new feature, please provide a short example of it in action."
4. Clarified "(if you have label edit permissions)" on the "Added appropriate labels" checklist item
5. Removed reference to nonexistent "docs/interal_api/index.rst"; the checklist item now reads: "Internal (private) function names start with an underscore (_)"
6. Replaced reference to nonexistent "docs/user_api/index.rst"; the checklist item now reads: "User (public) functions have been added to docs/api.rst"
7. Clarified that new example notebooks are not limited to "docs/examples/", they should instead be added to one of the following, depending on example type: "gallery: docs/examples/; guide: docs/user-guide/; quickstart: docs/getting-started/". Also clarified that adding entries to "gallery.yml" only applies for gallery-type examples.
8. Replaced reference to nonexistent "examples.rst". The relevant checklist item now reads: "New notebook examples referenced in appropriate .rst file (gallery: docs/gallery.rst; guide: docs/userguide.rst; quickstart: docs/quickstart.rst)"
9. Rephrased final comment (in "PR Etiquette Reminders") to avoid implying PR submitter needs to request reviewers.
10. Fixed minor typos (e.g., "An issue is linked created and linked")

PR Checklist

General

• An issue is linked created and linked
• Add appropriate labels
• Filled out Overview and Expected Usage (if applicable) sections

[Sevans711]

Should we take this opportunity to add something to the "Testing" part of the PR checklist like "If this PR should improve memory usage or runtime efficiency, at least one benchmark demonstrates expected improvements (add a new benchmark if necessary)"?

[dylannelson]

Interesting and helpful finds. Some I didn't even notice when reading through before this, ha
One thing I'm curious about, the note
- [ ] Added appropriate labels (if you have label edit permissions)
does the "if" part mean that some users can't add labels (including existing ones) or they can't make new labels from scratch?
If it's the first, why might some users not be able to add labels at all (I imagine this isn't the case). If it's the second, is this simply a reference to the case where they may not be able to add an "appropriate" label but also can't make one of their own?

[Sevans711]

Thank you for taking a look!

One thing I'm curious about, the note - [ ] Added appropriate labels (if you have label edit permissions) does the "if" part mean that some users can't add labels (including existing ones) or they can't make new labels from scratch?

It is the former! I believe you need to be granted some nonzero level of permissions for directly editing the uxarray repository in order to actually assign labels to your PR. But, you can certainly open a PR from a fork, even without any permissions at all. For my first uxarray PR I didn't have permissions and opened it from a fork, and I remember being a bit confused about whether I should check this box, and whether I was supposed to be able to add labels somehow but just couldn't figure it out, when in fact you need some edit permissions for it.

Maybe we can workshop the phrasing a bit to come up with something that clarifies this, while also not being too vague? Perhaps something like "Added appropriate labels (if you have uxarray edit permissions)" would be clearer?

[dylannelson]

Oh that's interesting, I would have been confused too. Since some of the other checks have much more added context now, it may help to also add this context too (while also covering the case where they want to check the box but couldn't add labels):

- [] Added appropriate labels, or were unable to add labels (users can't add labels by default)

A bit wordy but may cover all the points of confusion? I avoided the word "edit" because that sounds like a higher level of permission that "using"/"adding", but it seems like the user can either do all or none so it may not matter much either way.

[erogluorhan]

Looks great overall, just a few inline comments

[erogluorhan]

Maybe add something about this section can/should be removed if no work on examples was conducted in this PR?

[erogluorhan]

Maybe add something about this section can/should be removed if no work on testing suite was conducted in this PR?

[erogluorhan]

Not only new actually, Any notebooks that the PR's owner played with in their local might need this. Please rephrase accordingly