Transition to new process for updating changelogs

.github/pull_request_template.md

@@ -23,33 +23,9 @@ For example:
 * Related to #67890
 -->
 
-## Changelog
-
-<!--
-If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide.
-
-(CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.)
-
-Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods).
-
-If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes.
-
-Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None".
--->
-
-### `@metamask/package-a`
-
-- **<CATEGORY>**: Your change here
-- **<CATEGORY>**: Your change here
-
-### `@metamask/package-b`
-
-- **<CATEGORY>**: Your change here
-- **<CATEGORY>**: Your change here
-
 ## Checklist
 
 - [ ] I've updated the test suite for new or updated code as appropriate
 - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
-- [ ] I've highlighted breaking changes using the "BREAKING" category above as appropriate
+- [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary
 - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

docs/contributing.md

@@ -62,20 +62,20 @@ Built files show up in the `dist/` directory in each package. These are the file
 - Run `yarn build` to build all packages in the monorepo.
 - Run `yarn workspace <workspaceName> run build` to build a single package.
 
+## Updating changelogs
+
+Each package in this repo has a file called `CHANGELOG.md` which is used to record consumer-facing changes that have been published over time. This file is useful for other engineers who are upgrading to new versions of packages so that they know how to use new features they are expecting, they know when bugs have been addressed, and they understand how to adapt to breaking changes (if any).
+
+As you make changes to packages, make sure to update their changelogs in the same branch, placing new entries in the "Unreleased" section. If you need help, read the [Guide to Maintaining Changelogs](https://github.com/MetaMask/contributor-docs/tree/main/docs/changelogs.md).
+
 ## Creating pull requests
 
-When submitting a pull request for this repo, take some a bit of extra time to fill out its description. Use the provided template as a guide, paying particular attention to two sections:
-
-- **Explanation**: This section is targeted toward maintainers and is intended for you to explain the purpose and scope of your changes and share knowledge that they might not be able to see from reading the PR alone. Some questions you should seek to answer are:
-  - What is the motivator for these changes? What need are the changes satisfying? Is there a ticket you can share or can you provide some more context for people who might not be familiar with the domain?
-  - Are there any changes in particular whose purpose might not be obvious or whose implementation might be difficult to decipher? How do they work?
-  - If your primary goal was to update one package but you found you had to update another one along the way, why did you do so?
-  - If you had to upgrade a dependency, why did you do so?
-- **Changelog:** This section is targeted toward consumers — internal developers of the extension or mobile app in addition to external dapp developers — and is intended to be a list of your changes from the perspective of each package in the monorepo. Questions you should seek to answer are:
-  - Which packages are being updated?
-  - What are the _exact_ changes to the API (types, interfaces, functions, methods) that are being changed?
-  - What are the anticipated effects to whichever platform might want to make use of these changes?
-  - If there are breaking changes to the API, what do consumers need to do in order to adapt to those changes upon upgrading to them?
+When submitting a pull request for this repo, take some a bit of extra time to fill out its description. Use the provided template as a guide, paying particular attention to the **Explanation** section. This section is intended for you to explain the purpose and scope of your changes and share knowledge that other engineers might not be able to see from reading the PR alone. Some questions you should seek to answer are:
+
+- What is the motivator for these changes? What need are the changes satisfying? Is there a ticket you can share or can you provide some more context for people who might not be familiar with the domain?
+- Are there any changes in particular whose purpose might not be obvious or whose implementation might be difficult to decipher? How do they work?
+- If your primary goal was to update one package but you found you had to update another one along the way, why did you do so?
+- If you had to upgrade a dependency, why did you do so?
 
 ## Testing changes to packages in another project