diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index e1fd9e0dee..a7ebf48e0f 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -25,3 +25,14 @@ Before creating a PR, run through this checklist and mark each as complete.
 - [ ] I have updated necessary documentation
 - [ ] I have rebased my branch onto main
 - [ ] I will ensure my PR is targeting the main branch and pulling from my branch from my own fork
+
+### Release notes
+
+If this PR introduces a change that affects users and needs to be mentioned in the [release notes](../CHANGELOG.md),
+please add a brief note that summarizes the change.
+
+<!-- If this PR does not require a release note, you can just write NONE in the release-note block below. -->
+
+```release-note
+
+```
diff --git a/docs/developer/pull-request.md b/docs/developer/pull-request.md
index ce2d79cfa5..7297abc69f 100644
--- a/docs/developer/pull-request.md
+++ b/docs/developer/pull-request.md
@@ -2,9 +2,11 @@
 
 ## Submitter Guidelines
 
-- Title the PR using customer-focused language. The release notes are generated from PR titles, so the titles should
+- Title the PR using customer-focused language. The automatic release notes are generated from PR titles, so the titles should
   describe the feature from the user's perspective and avoid implementation details. For example, instead of "Add debug
-  boolean", write "Support configurable debug mode".
+  boolean", write "Support configurable debug mode". If the PR introduces a change that affects users and needs to be mentioned
+  in the curated [release notes](../CHANGELOG.md), add a brief note that summarizes the change in the `release-note` block
+  in the PR description.
 - Fill in [our pull request template](/.github/PULL_REQUEST_TEMPLATE.md).
 - Make sure to include the issue number in the PR description to automatically close the issue when the PR mergers.
   See [Closing Issues via Pull Requests](https://github.blog/2013-05-14-closing-issues-via-pull-requests/) for details.
@@ -28,7 +30,7 @@
   guidelines to follow:
   - Commit each code review change individually.
   - Use descriptive commit messages that accurately describe the change made, making it easy for the reviewer to
-      understand the purpose of the change.
+    understand the purpose of the change.
 - When approved, and all review comments have been resolved; squash commits to a single commit. Follow
   the [Commit Message Format](#commit-message-format) guidelines when writing the final commit.
 
@@ -47,10 +49,10 @@
     - Have internal workflow and informational docs been impacted?
   - Are there unit tests for the change?
     - If the change is a bug fix, has a unit test been added or modified that catches the bug? All bug fixes should
-          be reproduced with a unit test before submitting any code. Then the code should be fixed so that the unit test
-          passes.
+      be reproduced with a unit test before submitting any code. Then the code should be fixed so that the unit test
+      passes.
     - If the change is a feature or new functionality. The expectation is to include a reasonable set of unit tests
-          which exercise positive and negative cases.
+      which exercise positive and negative cases.
   - Is this change backwards compatible? Is it causing breaking behavior?
   - Are there any [Comment Tags](#comment-tags) in the change?