Organize changelog guidance

.github/pull_request_template.md

@@ -11,6 +11,27 @@ Addresses #*PR# HERE*
 ### Before/after screenshots
 <!-- Insert images here if applicable -->
 
+## Changelog
+
+<!--
+  - Fill in the changelog item(s) below. If there are more groups of closely
+    related changes, prepare more changelog items for each one of them.
+    At a minimum, always separete non-breaking changes from breaking changes.
+  - This needs to be pasted to CHANGELOG.md before merging a PR.
+  - See changelog guidelines https://www.notion.so/learningequality/DRAFT-Changelog-Guidelines-106b6ebbdeda4ba5b3b3e7c490c5a4fe and existing
+    items in CHANGELOG.md as examples
+ -->
+
+- [#PR no]
+  - **Description:** Summary of change(s)
+  - **Products impact:** Choose from - none (for internal updates) / bugfix / new API / updated API / removed API. If it's 'none', use "-" for all items below to indicate they are not relevant.
+  - **Addresses:** Link(s) to GH issue(s) addressed. Include KDS links as well as links to related issues in a consumer product repository too.
+  - **Components:** Affected public KDS component. Do not include internal sub-components or documentation components.
+  - **Breaking:** Will this change break something in a consumer? Choose from: yes / no
+  - **Impacts a11y:** Does this change improve a11y or adds new features that can be used to improve it? Choose from: yes / no
+  - **Guidance:** Why and how to introduce this update to a consumer? Required for breaking changes, appreciated for changes with a11y impact, and welcomed for non-breaking changes when relevant.
+
+[#PR no]: [PR link]
 
 ## Steps to test
 
@@ -32,7 +53,7 @@ Addresses #*PR# HERE*
 - [ ] Contributor has fully tested the PR manually
 - [ ] If there are any front-end changes, before/after screenshots are included
 - [ ] Critical and brittle code paths are covered by unit tests
-- [ ] The change has been added to the `changelog`
+- [ ] The change is described in the changelog section above
 
 ## Reviewer guidance
 <!-- Delete anything that doesn't apply so your reviewer knows what to check for -->
@@ -42,5 +63,9 @@ Addresses #*PR# HERE*
 - [ ] Are all UI components LTR and RTL compliant (if applicable)?
 - [ ] _Add other things to check for here_
 
+## After review
+
+- [ ] The changelog item has been pasted to the `CHANGELOG.md`
+
 ## Comments
 <!-- Any additional notes you'd like to add -->

CHANGELOG.md

@@ -1,42 +1,3 @@
-<!--
-
-Changelog Guidelines
-
-- In contrast to release notes, changelog is detailed and contains all pull requests
-- Add the newest item to the top
-- If there are more groups of closely related changes in a pull request,
-  write more changelog items for each one of them. At a minimum, always separete
-  non-breaking changes from breaking changes
-- Copy-paste and fill in the template below for each changelog item. When doing so, please
-  pay attention to the following:
-  - Be explicit and include all affected areas (e.g. if you update `KIcon`,
-    all other components built on top of that, like `KLabeledIcon` or `KIconButton`,
-    might be affected too)
-  - Breaking updates are not only updates literally breaking a consumer but also updates
-    causing major, unexpected UI changes
-  - Focus on 'what', not 'how'  (you can mention how you solved a problem if it feels important,
-    however always emphasize what problem you solved and what impact it will have on consumers)
-  - Formulate information so that it can be easily understood even by a person who is not
-    familiar with the change in detail
-  - Consistency (see existing items)
-
-****************************
-
-- [PR no]
-  - **Description:** Summary of change(s)
-  - **Products impact:** Choose from - none (for internal updates) / bugfix / new API / updated API / removed API. If it's 'none', use "-" for all items below to indicate they are not relevant.
-  - **Addresses:** Link(s) to GH issue(s) addressed. Include KDS links as well as links to related issues in a consumer product repository too.
-  - **Components:** Affected public KDS component. Do not include internal sub-components or documentation components.
-  - **Breaking:** Will this change break something in a consumer? Choose from: yes / no
-  - **Impacts a11y:** Does this change improve a11y or adds new features that can be used to improve it? Choose from: yes / no
-  - **Guidance:** Why and how to introduce this update to a consumer? Required for breaking changes, appreciated for changes with a11y impact, and welcomed for non-breaking changes when relevant.
-
-[PR no]: [PR ref]
-
-****************************
-
--->
-
 # Changelog
 
 Changelog is rather internal in nature. See release notes for the public overview and guidelines. Releases are recorded as git tags in the [Github releases](https://github.com/learningequality/kolibri-design-system/releases) page.