qmk · tzarc · Aug 29, 2023 · Aug 27, 2023 · Aug 27, 2023 · Aug 27, 2023
diff --git a/docs/ChangeLog/20230827.md b/docs/ChangeLog/20230827.md
diff --git a/docs/_summary.md b/docs/_summary.md
@@ -139,7 +139,7 @@
   * Breaking Changes
     * [Overview](breaking_changes.md)
     * [My Pull Request Was Flagged](breaking_changes_instructions.md)
-    * [Most Recent ChangeLog](ChangeLog/20230528.md "QMK v0.21.0 - 2023 May 28")
+    * [Most Recent ChangeLog](ChangeLog/20230827.md "QMK v0.22.0 - 2023 Aug 27")
     * [Past Breaking Changes](breaking_changes_history.md)
 
   * C Development

diff --git a/docs/breaking_changes.md b/docs/breaking_changes.md
@@ -10,25 +10,25 @@ Practically, this means QMK merges the `develop` branch into the `master` branch
 
 ## What has been included in past Breaking Changes?
 
+* [2023 Aug 27](ChangeLog/20230827.md)
 * [2023 May 28](ChangeLog/20230528.md)
 * [2023 Feb 26](ChangeLog/20230226.md)
-* [2022 Nov 26](ChangeLog/20221126.md)
 * [Older Breaking Changes](breaking_changes_history.md)
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for August 27, 2023.
+The next Breaking Change is scheduled for November 26, 2023.
 
 ### Important Dates
 
-* 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.
+* 2023 Aug 27 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
+* 2023 Oct 29 - `develop` closed to new PRs.
+* 2023 Oct 29 - Call for testers.
+* 2023 Nov 5 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
+* 2023 Nov 19 - `develop` is locked, only critical bugfix PRs merged.
+* 2023 Nov 23 - `master` is locked, no PRs merged.
+* 2023 Nov 26 - Merge `develop` to `master`.
+* 2023 Nov 26 - `master` is unlocked. PRs can be merged again.
 
 ## What changes will be included?
 
@@ -48,7 +48,7 @@ Criteria for acceptance:
 
 Strongly suggested:
 
-* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20230827`.
+* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20231126`.
     * 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.
 

diff --git a/docs/breaking_changes_history.md b/docs/breaking_changes_history.md
@@ -2,6 +2,7 @@
 
 This page links to all previous changelogs from the QMK Breaking Changes process.
 
+* [2023 Aug 27](ChangeLog/20230827.md) - version 0.22.0
 * [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

diff --git a/docs/contributing.md b/docs/contributing.md
@@ -36,7 +36,7 @@ If you need help you can [open an issue](https://github.com/qmk/qmk_firmware/iss
 Never made an open source contribution before? Wondering how contributions work in QMK? Here's a quick rundown!
 
 0. Sign up for a [GitHub](https://github.com) account.
-1. Put together a keymap to contribute, [find an issue](https://github.com/qmk/qmk_firmware/issues) you are interested in addressing, or [a feature](https://github.com/qmk/qmk_firmware/issues?q=is%3Aopen+is%3Aissue+label%3Afeature) you would like to add.
+1. [Find an issue](https://github.com/qmk/qmk_firmware/issues) you are interested in addressing, or [a feature](https://github.com/qmk/qmk_firmware/issues?q=is%3Aopen+is%3Aissue+label%3Afeature) you would like to add.
 2. Fork the repository associated with the issue to your GitHub account. This means that you will have a copy of the repository under `your-GitHub-username/qmk_firmware`.
 3. Clone the repository to your local machine using `git clone https://github.com/github-username/repository-name.git`.
 4. If you're working on a new feature consider opening an issue to talk with us about the work you're about to undertake.
@@ -67,7 +67,7 @@ We have a few different types of changes in QMK, each requiring a different leve
 * Separate PRs into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature.
 * Check for unnecessary whitespace with `git diff --check` before committing.
 * Make sure your code change actually compiles.
-  * Keymaps: Make sure that `make keyboard:your_new_keymap` does not return any errors.
+  * Keymaps: Make sure that `make keyboard:keymap` does not return any errors.
   * Keyboards: Make sure that `make keyboard:all` does not return any errors.
   * Core: Make sure that `make all` does not return any errors.
 * Make sure commit messages are understandable on their own. You should put a short description (no more than 70 characters) on the first line, the second line should be empty, and on the 3rd and later lines you should describe your commit in detail, if required. Example:
@@ -114,24 +114,14 @@ or if you only have Python 3 installed:
 
 and navigating to `http://localhost:8936/`.
 
-## Keymaps
-
-Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap.
-
-* Write a `readme.md` using [the template](documentation_templates.md).
-* All Keymap PRs are squashed, so if you care about how your commits are squashed you should do it yourself
-* Do not lump features in with keymap PRs. Submit the feature first and then a second PR for the keymap.
-* Do not include `Makefile`s in your keymap folder (they're no longer used)
-* Update copyrights in file headers (look for `%YOUR_NAME%`)
-
 ## Keyboards
 
 Keyboards are the raison d'être for QMK. Some keyboards are community maintained, while others are maintained by the people responsible for making a particular keyboard. The `readme.md` should tell you who maintains a particular keyboard. If you have questions relating to a particular keyboard you can [Open An Issue](https://github.com/qmk/qmk_firmware/issues) and tag the maintainer in your question.
 
 We also ask that you follow these guidelines:
 
 * Write a `readme.md` using [the template](documentation_templates.md).
-* Keep the number of commits reasonable or we will squash your PR
+* Include a `default` keymap that provides a clean slate for users to start with when creating their own keymaps.
 * Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
 * Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
 * Do not include `Makefile`s in your keyboard folder (they're no longer used)

diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md
@@ -11,7 +11,6 @@ If there are any inconsistencies with these recommendations, you're best off [cr
     - if submitter _does_ use their own `master` branch, they'll be given a link to the ["how to git"](newbs_git_using_your_master_branch.md) page after merging -- (end of this document will contain the contents of the message)
 - PRs should contain the smallest amount of modifications required for a single change to the codebase
     - multiple keyboards at the same time is not acceptable
-        - exception: keymaps for a single user targeting multiple keyboards and/or userspace is acceptable
     - **the smaller the PR, the higher likelihood of a quicker review, higher likelihood of quicker merge, and less chance of conflicts**
 - newly-added directories and filenames must be lowercase
     - the lowercase requirement may be relaxed if upstream sources originally had uppercase characters (e.g. LUFA, ChibiOS, or imported files from other repositories etc.)
@@ -40,6 +39,8 @@ If there are any inconsistencies with these recommendations, you're best off [cr
 
 ## Keymap PRs
 
+Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps.
+
 - `#include QMK_KEYBOARD_H` preferred to including specific board files
 - prefer layer `enum`s to `#define`s
 - custom keycode `enum`s must have first entry `= SAFE_RANGE`

diff --git a/docs/reference_glossary.md b/docs/reference_glossary.md
@@ -113,7 +113,7 @@ A modifier that acts as if it is held down until another key is released, so you
 A low cost AVR development board. Clones of this device are often found on ebay very inexpensively (under $5) but people often struggle with flashing their pro micros.
 
 ## Pull Request
-A request to submit code to QMK. We encourage all users to submit Pull Requests for their personal keymaps.
+A request to submit code to QMK. We encourage all users to submit Pull Requests for bugfixes and new features.
 
 ## QWERTY
 The standard English keyboard layout, and often a shortcut for other language's standard layouts. Named for the first 6 letters on the keyboard.