Improve PR template to encourage appropriate context in descriptions

.github/pull_request_template.md

@@ -1,27 +1,23 @@
 # Objective
 
-- Describe the objective or issue this PR addresses.
-- If you're fixing a specific issue, say "Fixes #X".
+Why are you making these changes?
+Link any associated issues with "Fixes #X" so they can be automatically closed.
+If this is a complex PR, please add a list of the changes made.
 
-## Solution
+If you're new to Bevy, consider checking out our [Contributing Guide](https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md) for information about our development practices :)
 
-- Describe the solution used to achieve the objective above.
+Provide any background information that may be needed for other reviewers to understand the changes you've made.
+This may include related issues, previous discussion, or links to documentation.
 
----
+## Feedback wanted
 
-## Changelog
+> This section is optional. If there are no particularly tricky or controversial changes, you can delete this section.
 
-> This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.
-
-- What changed as a result of this PR?
-- If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
-- Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
-  - If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!
+Which parts of this PR were you unsure about? Which parts were particularly tricky?
 
 ## Migration Guide
 
 > This section is optional. If there are no breaking changes, you can delete this section.
 
-- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
-- Simply adding new functionality is not a breaking change.
-- Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.
+If this PR is a breaking change, describe how a user might need to migrate their code to support these changes.
+Adding new functionality or fixing bugs is not a breaking change.