Tweak PR template (#16460)

<!--
Thank you for improving Nushell!
Please, read our contributing guide:
https://github.com/nushell/nushell/blob/main/CONTRIBUTING.md
-->

Based on core team feedback, this tweaks the PR template again. Instead
of having an explicit "Motivation and technical details", we can leave
the PR template more free-form. Leaving the template more free form lets
people write the PR how they want; for example, @sholderbach likes to
let `gh pr open` fill in the description from the commit messages,
whereas @NotTheDr01ds likes to fill in the "Release notes summary
section" first, then provide more details below.

I tried to make the comment for the release notes summary section more
clear while not blowing up the amount of comment lines in the PR
template. I've also added more information about the release notes
summary section to CONTRIBUTING.md, including re-emphasizing the fact
that this can be left blank until the PR is finalized and information
about how to structure the section.

I'm open to suggestions on the phrasing of the comments, this should be
as clear as possible ideally!

## Release notes summary - What our users need to know
N/A

---------

Co-authored-by: Douglas <32344964+NotTheDr01ds@users.noreply.github.com>
Co-authored-by: Ecorous <ecorous@outlook.com>
This commit is contained in:
rose
2025-08-18 16:43:52 -04:00
committed by GitHub
parent bed0c99909
commit 3fccd51e54
2 changed files with 32 additions and 7 deletions

View File

@@ -2,12 +2,13 @@
Thank you for improving Nushell!
Please, read our contributing guide: https://github.com/nushell/nushell/blob/main/CONTRIBUTING.md
-->
## Motivation and technical details
## Release notes summary - What our users need to know
<!--
This section will be included as part of our release notes. See the contributing guide for more details.
If you're not confident about this, a core team member would be glad to help!
Please include only details relevant for users here. Motivation and technical details can be added above or below this section.
You may leave this section blank until your PR is finalized. Ask a core team member if you need help filling this section.
-->
## Tasks after submitting

View File

@@ -23,21 +23,45 @@ More resources can be found in the nascent [developer documentation](devdocs/REA
## Tips for submitting PRs
Thank you for improving Nushell! We are always glad to see contributions, and we are absolutely willing to talk through the design or implementation of your PR. Come talk with us in [Discord](https://discordapp.com/invite/NtAbbGn), or create a GitHub discussion or draft PR and we can help you work out the details from there.
Thank you for improving Nushell! We love to see other folks enthusiastic about Nushell, and we can help you work through the design or implementation of your PR. Come talk with us in [Discord](https://discordapp.com/invite/NtAbbGn), or create a GitHub discussion or draft PR and we can help you work out the details from there.
**Please talk to the core team before making major changes!** See the [proposing design changes](#proposing-design-changes) for more details.
### Release notes section
In our PR template, we have a "Release notes summary" section which will be included in our release notes for our blog.
In our PR template, we have a "Release notes summary" section which will be included in our release notes for our blog. This section should include all information about your change which is relevant to a user of Nushell.
This section should include all information about your change which is relevant to a user of Nushell. You should try to keep it **brief and simple to understand**, and focus on the ways your change directly impacts the user experience. We highly encourage adding examples and, when relevant, screenshots in this section.
You should try to keep it **brief and simple to understand**, and focus on the ways your change directly impacts the user experience. Motivation, technical details, and any other **information which isn't directly relevant to users should be put somewhere else** -- either above or below the release notes section is fine.
The release notes summary section doesn't need to be filled until your PR is finalized. Feel free to leave it blank until the PR has undergone review already. Of course, this section can also be useful to demonstrate to reviewers how your proposed changed will work, so don't hesitate to fill in the section if it helps you explain your PR.
Please make sure to consider both the *intended changes*, such as additions or deliberate breaking changes **and** possible *side effects* that might change how users interact with a command or feature. It's important to think carefully about the ways that your PR might affect any aspect of the user experience, and to document these changes even if they seem minor or aren't directly related to the main purpose of the PR.
This section might not be relevant for all PRs. If your PR is a work in progress, feel free to write "WIP"/"TODO"/etc in this section. You can also write "N/A" if this is a technical change which doesn't impact the user experience.
If you're not sure what to put here, or need some help, **a core team member would be glad to help you out**. We may also make some tweaks to your release notes section. Please don't take it personally, we just want to make sure our release notes are polished and easy to understand. Once the release notes section is finalized, we'll add the `notes:ready` label to indicate that your summary section is ready to be included in the actual release notes.
If you're not sure what to put here, or need some help, **a core team member would be glad to help you out**. We may also makes some tweaks to your release notes section. Please don't take it personally, we just want to make sure our release notes are polished and easy to understand. Once the release notes section is ready, we'll add the (TODO label name) label to indicate that the release notes section is ready to be included in the actual release notes.
#### Structuring your summary
For smaller changes, **a simple one to two sentence explanation** is sufficient. If that's all you need to explain the impact of the change, keep any further details out of the release notes summary. Summaries which are a single line will appear as a bullet point in our release notes.
For larger changes, you can use multiple lines to fully explain your change. We highly encourage adding examples and/or screenshots if this is the case.
Summaries which are multiple lines will appear under their own heading in the release notes. By default, the title for the heading will be the title of your PR. If you'd like to add a more user-friendly title, or your PR encompasses multiple changes that should appear in their own sections, you can manually add one or more third-level headings to your release notes summary section. For example:
````md
## Release notes summary - What our users need to know
### Cool command
This change adds a cool new feature. Here's how you use it:
```nushell
my-cool-command
```
````
In the release notes, this will appear under a heading titled simply "Cool command". A concise title like this might be more appropriate than the PR title, which may have more info than is necessary for the release notes.
This section might not be relevant for all PRs. If your PR is a work in progress, feel free to write "WIP"/"TODO"/etc in this section. You can also write "N/A" or simply leave this section blank if this is a purely technical change which doesn't impact the user experience.
### Tests and formatting checks