develop 2023q2 changelog (qmk#21049)

Co-authored-by: Ryan <fauxpark@gmail.com>

docs/breaking_changes.md

@@ -10,27 +10,25 @@ Practically, this means QMK merges the `develop` branch into the `master` branch
 
 ## What has been included in past Breaking Changes?
 
+* [2023 May 28](ChangeLog/20230528.md)
 * [2023 Feb 26](ChangeLog/20230226.md)
 * [2022 Nov 26](ChangeLog/20221126.md)
-* [2022 Aug 27](ChangeLog/20220827.md)
-* [2022 May 28](ChangeLog/20220528.md)
-* [2022 Feb 26](ChangeLog/20220226.md)
 * [Older Breaking Changes](breaking_changes_history.md)
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for May 28, 2023.
+The next Breaking Change is scheduled for August 27, 2023.
 
 ### Important Dates
 
-* 2023 Feb 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
-* 2023 Apr 30 - `develop` closed to new PRs.
-* 2023 Apr 30 - Call for testers.
-* 2023 May 14 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
-* 2023 May 21 - `develop` is locked, only critical bugfix PRs merged.
-* 2023 May 26 - `master` is locked, no PRs merged.
-* 2023 May 28 - Merge `develop` to `master`.
-* 2023 May 28 - `master` is unlocked. PRs can be merged again.
+* 2023 May 28 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
+* 2023 Jul 30 - `develop` closed to new PRs.
+* 2023 Jul 30 - Call for testers.
+* 2023 Aug 13 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
+* 2023 Aug 20 - `develop` is locked, only critical bugfix PRs merged.
+* 2023 Aug 25 - `master` is locked, no PRs merged.
+* 2023 Aug 27 - Merge `develop` to `master`.
+* 2023 Aug 27 - `master` is unlocked. PRs can be merged again.
 
 ## What changes will be included?
 
@@ -50,7 +48,7 @@ Criteria for acceptance:
 
 Strongly suggested:
 
-* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20221126`.
+* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20230827`.
     * This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PRs ID.
     * One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
 

docs/breaking_changes_history.md

@@ -2,6 +2,7 @@
 
 This page links to all previous changelogs from the QMK Breaking Changes process.
 
+* [2023 May 28](ChangeLog/20230528.md) - version 0.21.0
 * [2023 Feb 26](ChangeLog/20230226.md) - version 0.20.0
 * [2022 Nov 26](ChangeLog/20221126.md) - version 0.19.0
 * [2022 Aug 27](ChangeLog/20220827.md) - version 0.18.0

docs/breaking_changes_instructions.md

@@ -23,14 +23,6 @@ If it is determined that your submission is a breaking change, there are a few t
 
 If you are contributing core code, and the only reason it needs to go through breaking changes is that you are updating keymaps to match your change, consider whether you can submit your feature in a way that the old keymaps continue to work. Then submit a separate PR that goes through the breaking changes process to remove the old code.
 
-### Contribute a ChangeLog Entry
-
-We require submissions that go through the Breaking Change process to include a changelog entry. The entry should be a short summary of the changes your pull request makes – [each section here started as a changelog](ChangeLog/20190830.md "n.b. This should link to the 2019 Aug 30 Breaking Changes doc  - @noroadsleft").
-
-Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch – usually named `develop` – will be merged into the `master` branch, and `####` is the number of your pull request.
-
-If your submission requires action on the part of users, your changelog should instruct users what action(s) must be taken, or link to a location that does so.
-
 ### Document Your Changes
 
 Understanding the purpose for your submission, and possible implications or actions it will require can make the review process more straightforward. A changelog may suffice for this purpose, but more extensive changes may require a level of detail that is ill-suited for a changelog.

docs/pr_checklist.md

@@ -62,7 +62,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
         - valid maintainer
         - valid USB VID/PID and device version
         - displays correctly in Configurator (press Ctrl+Shift+I to preview local file, turn on fast input to verify ordering)
-        - `layout` definitions should include matrix positions, so that `LAYOUT` macros can be generated at build time
+        - `layout` definitions must include matrix positions, so that `LAYOUT` macros can be generated at build time
             - should use standard definitions if applicable
             - use the Community Layout macro names where they apply (preferred above `LAYOUT`/`LAYOUT_all`)
             - If the keyboard only has a single electrical/switch layout:
@@ -124,7 +124,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
     - hardware that's enabled at the keyboard level and requires configuration such as OLED displays or encoders should have basic functionality implemented here
 - `<keyboard>.h`
     - `#include "quantum.h"` appears at the top
-    - `LAYOUT` macros should be moved to `info.json`
+    - `LAYOUT` macros are no longer accepted and should instead be moved to `info.json`
 - keymap `config.h`
     - no duplication of `rules.mk` or `config.h` from keyboard
 - `keymaps/default/keymap.c`