Ivaan · Ivaan · Aug 10, 2024 · Jan 27, 2022 · Feb 11, 2022 · Mar 1, 2022
diff --git a/docs/ChangeLog/20190830.md b/docs/ChangeLog/20190830.md
@@ -7,7 +7,7 @@ This document marks the inaugural Breaking Change merge. A list of changes follo
 ## Core code formatting with clang-format
 
 * All core files (`drivers/`, `quantum/`, `tests/`, and `tmk_core/`) have been formatted with clang-format
-* A travis process to reformat PR's on merge has been instituted
+* A travis process to reformat PRs on merge has been instituted
 * You can use the new CLI command `qmk cformat` to format before submitting your PR if you wish.
 
 ## LUFA USB descriptor cleanup
@@ -30,15 +30,15 @@ This document marks the inaugural Breaking Change merge. A list of changes follo
 ## Backport changes to keymap language files from ZSA fork
 
 * Fixes an issue in the `keymap_br_abnt2.h` file that includes the wrong source (`keymap_common.h` instead of `keymap.h`)
-* Updates the `keymap_swedish.h` file to be specific to swedish, and not just "nordic" in general. 
-* Any keymaps using this will need to remove `NO_*` and replace it with `SE_*`. 
+* Updates the `keymap_swedish.h` file to be specific to swedish, and not just "nordic" in general.
+* Any keymaps using this will need to remove `NO_*` and replace it with `SE_*`.
 
 ## Update repo to use LUFA as a git submodule
 
 * `/lib/LUFA` removed from the repo
 * LUFA set as a submodule, pointing to qmk/lufa
 * This should allow more flexibility with LUFA, and allow us to keep the sub-module up to date, a lot more easily.  It was ~2 years out of date with no easy path to fix that.  This prevents that from being an issue in the future
-  
+
 ## Migrating `ACTION_BACKLIGHT_*()` entries in `fn_actions` to `BL_` keycodes
 
 * `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`

diff --git a/docs/breaking_changes.md b/docs/breaking_changes.md
@@ -4,7 +4,9 @@ This document describes QMK's Breaking Change process. A Breaking Change is any
 
 This also includes any keyboard moves within the repository.
 
-The breaking change period is when we will merge PR's that change QMK in dangerous or unexpected ways. There is a built-in period of testing so we are confident that any problems caused are rare or unable to be predicted.
+The breaking change period is when we will merge PRs that change QMK in dangerous or unexpected ways. There is a built-in period of testing so we are confident that any problems caused are rare or unable to be predicted.
+
+Practically, this means QMK merges the `develop` branch into the `master` branch on a 3-month cadence.
 
 ## What has been included in past Breaking Changes?
 
@@ -29,25 +31,34 @@ The next Breaking Change is scheduled for February 26, 2023.
 ### Important Dates
 
 * 2022 Nov 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
-* 2023 Jan 29 - `develop` closed to new PR's.
+* 2023 Jan 29 - `develop` closed to new PRs.
 * 2023 Jan 29 - Call for testers.
 * 2023 Feb 12 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
-* 2023 Feb 19 - `develop` is locked, only critical bugfix PR's merged.
-* 2023 Feb 24 - `master` is locked, no PR's merged.
+* 2023 Feb 19 - `develop` is locked, only critical bugfix PRs merged.
+* 2023 Feb 24 - `master` is locked, no PRs merged.
 * 2023 Feb 26 - Merge `develop` to `master`.
-* 2023 Feb 26 - `master` is unlocked. PR's can be merged again.
+* 2023 Feb 26 - `master` is unlocked. PRs can be merged again.
 
 ## What changes will be included?
 
-To see a list of breaking change candidates you can look at the [`breaking_change` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). New changes might be added between now and when `develop` is closed, and a PR with that label applied is not guaranteed to be merged.
+To see a list of breaking changes merge candidates you can look at the [`core` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Acore+is%3Apr). This label is applied whenever a PR is raised or changed, but only if the PR includes changes to core areas of QMK Firmware. A PR with that label applied is not guaranteed to be merged in the current cycle. New changes might be added between now and when `develop` is closed, and it is generally the responsibility of the submitter to handle conflicts. There is also another label used by QMK Collaborators -- `breaking_change_YYYYqN` -- which signifies to maintainers that it is a strong candidate for inclusion, and should be prioritised for review.
+
+If you want your breaking change to be included in this round you need to create a PR and have it accepted by QMK Collaborators before `develop` closes. After `develop` closes, new submissions will be deferred to the next breaking changes cycle.
 
-If you want your breaking change to be included in this round you need to create a PR with the `breaking_change` label and have it accepted before `develop` closes. After `develop` closes no new breaking changes will be accepted.
+The simpler your PR is, the easier it is for maintainers to review, thus a higher likelihood of a faster merge. Large PRs tend to require a lot of attention, refactoring, and back-and-forth with subsequent reviews -- with other PRs getting merged in the meantime larger unmerged PRs are far more likely to be susceptible to conflicts.
 
 Criteria for acceptance:
 
 * The PR is complete and ready to merge
+* GitHub checks for the PR are green whenever possible
+    * A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
+        * Modifications to existing files should not need to add license headers to pass lint, for instance.
+        * If it's not directly related to your PR's functionality, prefer avoiding making a change.
+
+Strongly suggested:
+
 * The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20221126`.
-    * This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
+    * 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.
 
 ## Checklists
@@ -56,7 +67,7 @@ This section documents various processes we use when running the Breaking Change
 
 ### 4 Weeks Before Merge
 
-* `develop` is now closed to new PR's, only fixes for current PR's may be merged
+* `develop` is now closed to new PRs, only fixes for current PRs may be merged
 * Post call for testers: message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
     * `@Breaking Changes Updates -- Hey folks, last day for functional PRs to be raised against qmk_firmware for this breaking changes cycle is today.`
 

diff --git a/docs/contributing.md b/docs/contributing.md
@@ -118,8 +118,8 @@ and navigating to `http://localhost:8936/`.
 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 PR's are squashed, so if you care about how your commits are squashed you should do it yourself
-* Do not lump features in with keymap PR's. Submit the feature first and then a second PR for the keymap.
+* 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%`)
 
@@ -143,7 +143,7 @@ Before you put a lot of work into building your new feature you should make sure
 * [Chat on Discord](https://discord.gg/Uq7gcHh)
 * [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
 
-Feature and Bug Fix PR's affect all keyboards. We are also in the process of restructuring QMK. For this reason it is especially important for significant changes to be discussed before implementation has happened. If you open a PR without talking to us first please be prepared to do some significant rework if your choices do not mesh well with our planned direction.
+Feature and Bug Fix PRs affect all keyboards. We are also in the process of restructuring QMK. For this reason it is especially important for significant changes to be discussed before implementation has happened. If you open a PR without talking to us first please be prepared to do some significant rework if your choices do not mesh well with our planned direction.
 
 Here are some things to keep in mind when working on your feature or bug fix.
 

diff --git a/docs/feature_joystick.md b/docs/feature_joystick.md
@@ -40,7 +40,7 @@ When defining axes for your joystick, you must provide a definition array typica
 For instance, the below example configures two axes. The X axis is read from the `A4` pin. With the default axis resolution of 8 bits, the range of values between 900 and 575 are scaled to -127 through 0, and values 575 to 285 are scaled to 0 through 127. The Y axis is configured as a virtual axis, and its value is not read from any pin. Instead, the user must update the axis value programmatically.
 
 ```c
-joystick_config_t joystick_axes[JOYSTICK_AXES_COUNT] = {
+joystick_config_t joystick_axes[JOYSTICK_AXIS_COUNT] = {
     JOYSTICK_AXIS_IN(A4, 900, 575, 285),
     JOYSTICK_AXIS_VIRTUAL
 };
@@ -64,7 +64,7 @@ The `low` and `high` values can be swapped to effectively invert the axis.
 The following example adjusts two virtual axes (X and Y) based on keypad presses, with `KC_P0` as a precision modifier:
 
 ```c
-joystick_config_t joystick_axes[JOYSTICK_AXES_COUNT] = {
+joystick_config_t joystick_axes[JOYSTICK_AXIS_COUNT] = {
     JOYSTICK_AXIS_VIRTUAL, // x
     JOYSTICK_AXIS_VIRTUAL  // y
 };

diff --git a/docs/feature_layers.md b/docs/feature_layers.md
@@ -53,7 +53,7 @@ There are a number of functions (and variables) related to how you can use or ma
 
 |Function                                      |Description                                                                                              |
 |----------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| `layer_state_set(layer_mask)`                | Directly sets the layer state (recommended, do not use unless you know what you are doing).             |
+| `layer_state_set(layer_mask)`                | Directly sets the layer state (avoid unless you know what you are doing).                               |
 | `layer_clear()`                              | Clears all layers (turns them all off).                                                                 |
 | `layer_move(layer)`                          | Turns specified layer on, and all other layers off.                                                     |
 | `layer_on(layer)`                            | Turns specified layer on, leaves all other layers in existing state.                                    |
@@ -63,7 +63,7 @@ There are a number of functions (and variables) related to how you can use or ma
 | `layer_and(layer_mask)`                      | Turns on layers based on matching enabled bits between specifed layer and existing layer state.         |
 | `layer_xor(layer_mask)`                      | Turns on layers based on non-matching bits between specifed layer and existing layer state.             |
 | `layer_debug(layer_mask)`                    | Prints out the current bit mask and highest active layer to debugger console.                           |
-| `default_layer_set(layer_mask)`              | Directly sets the default layer state (recommended, do not use unless you know what you are doing).     |
+| `default_layer_set(layer_mask)`              | Directly sets the default layer state (avoid unless you know what you are doing).                       |
 | `default_layer_or(layer_mask)`               | Turns on layers based on matching bits between specifed layer and existing default layer state.         |
 | `default_layer_and(layer_mask)`              | Turns on layers based on matching enabled bits between specifed layer and existing default layer state. |
 | `default_layer_xor(layer_mask)`              | Turns on layers based on non-matching bits between specifed layer and existing default layer state.     |

diff --git a/docs/feature_leader_key.md b/docs/feature_leader_key.md
@@ -41,14 +41,20 @@ As you can see, you have a few functions. You can use `SEQ_ONE_KEY` for single-k
 
 Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously.
 
-## Adding Leader Key Support in the `rules.mk`
+## Adding Leader Key Support
 
-To add support for Leader Key you simply need to add a single line to your keymap's `rules.mk`:
+To enable Leader Key, add the following line to your keymap's `rules.mk`:
 
 ```make
 LEADER_ENABLE = yes
 ```
 
+Place the following macro in your `keymap.c` or user space source file, before any functional code. It handles declaration of external variables that will be referenced by Leader Key codes that follows:
+
+```c
+LEADER_EXTERNS();
+```
+
 ## Per Key Timing on Leader keys
 
 Rather than relying on an incredibly high timeout for long leader key strings or those of us without 200wpm typing skills, we can enable per key timing to ensure that each key pressed provides us with more time to finish our stroke. This is incredibly helpful with leader key emulation of tap dance (read: multiple taps of the same key like C, C, C).

diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md
@@ -576,7 +576,7 @@ enum rgb_matrix_effects {
     RGB_MATRIX_PIXEL_FRACTAL,       // Single hue fractal filled keys pulsing horizontally out to edges
     RGB_MATRIX_PIXEL_FLOW,          // Pulsing RGB flow along LED wiring with random hues
     RGB_MATRIX_PIXEL_RAIN,          // Randomly light keys with random hues
-#if define(RGB_MATRIX_FRAMEBUFFER_EFFECTS)
+#if defined(RGB_MATRIX_FRAMEBUFFER_EFFECTS)
     RGB_MATRIX_TYPING_HEATMAP,      // How hot is your WPM!
     RGB_MATRIX_DIGITAL_RAIN,        // That famous computer simulation
 #endif
@@ -1007,7 +1007,7 @@ bool rgb_matrix_indicators_advanced_user(uint8_t led_min, uint8_t led_max) {
 }
 ```
 
-!> RGB indicators on split keyboards will require state information synced to the slave half (e.g. `#define SPLIT_LAYER_STATE_ENABLE`). See [data sync options](feature_split_keyboard.md#data-sync-options) for more details.
+?> RGB indicators on split keyboards will require state information synced to the slave half (e.g. `#define SPLIT_LAYER_STATE_ENABLE`). See [data sync options](feature_split_keyboard.md#data-sync-options) for more details.
 
 #### Indicators without RGB Matrix Effect