docs: some typos (#18582)

probably hacktoberism

9 files changed, 11 insertions, 11 deletions

diff --git a/docs/api_docs.md b/docs/api_docs.md
index e2f970f3ab..237b02fed2 100644
--- a/docs/api_docs.md
+++ b/docs/api_docs.md
@@ -21,7 +21,7 @@ This service is an asynchronous API for compiling custom keymaps. You POST some
 }
 ```
 
-As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
+As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports multiple `LAYOUT` macros you can specify which macro to use.
 
 ## Submitting a Compile Job
 
diff --git a/docs/cli_commands.md b/docs/cli_commands.md
index 4608ed85b6..019447075b 100644
--- a/docs/cli_commands.md
+++ b/docs/cli_commands.md
@@ -223,7 +223,7 @@ Check your environment and report problems only:
 
 ## `qmk format-json`
 
-Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if neccesary.
+Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if necessary.
 
 **Usage**:
 
diff --git a/docs/cli_development.md b/docs/cli_development.md
index 17370a732a..d878deff17 100644
--- a/docs/cli_development.md
+++ b/docs/cli_development.md
@@ -162,7 +162,7 @@ del(cli.config.<section>.<key>)
 
 ## Writing The Configuration File
 
-The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberitely using `qmk config`.
+The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberately using `qmk config`.
 
 You can use `cli.save_config()` to write out the configuration.
 
diff --git a/docs/coding_conventions_c.md b/docs/coding_conventions_c.md
index c4bace66cc..3f44da713d 100644
--- a/docs/coding_conventions_c.md
+++ b/docs/coding_conventions_c.md
@@ -24,7 +24,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
   * Readability is more important than consistency.
   * Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
   * When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
-  * You can follow the indention level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
+  * You can follow the indentation level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
 
 Here is an example for easy reference:
 
diff --git a/docs/coding_conventions_python.md b/docs/coding_conventions_python.md
index 960b9cb49e..2b68703448 100644
--- a/docs/coding_conventions_python.md
+++ b/docs/coding_conventions_python.md
@@ -2,7 +2,7 @@
 
 Most of our style follows PEP8 with some local modifications to make things less nit-picky. 
 
-* We target Python 3.7 for compatability with all supported platforms.
+* We target Python 3.7 for compatibility with all supported platforms.
 * We indent using four (4) spaces (soft tabs)
 * We encourage liberal use of comments
   * Think of them as a story describing the feature
@@ -21,7 +21,7 @@ You can use [yapf](https://github.com/google/yapf) to style your code. We provid
 
 We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
 
-Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatability module.
+Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatibility module.
 
 Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
 
diff --git a/docs/config_options.md b/docs/config_options.md
index 02cfe83c69..cc732de7d2 100644
--- a/docs/config_options.md
+++ b/docs/config_options.md
@@ -195,7 +195,7 @@ If you define these options you will enable the associated feature, which may in
 * `#define COMBO_TERM 200`
   * how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
 * `#define COMBO_MUST_HOLD_MODS`
-  * Flag for enabling extending timeout on Combos containing modifers
+  * Flag for enabling extending timeout on Combos containing modifiers
 * `#define COMBO_MOD_TERM 200`
   * Allows for extending COMBO_TERM for mod keys while mid-combo.
 * `#define COMBO_MUST_HOLD_PER_COMBO`
diff --git a/docs/feature_macros.md b/docs/feature_macros.md
index f5bd5be41b..63b7223db9 100644
--- a/docs/feature_macros.md
+++ b/docs/feature_macros.md
@@ -374,7 +374,7 @@ This will clear all keys besides the mods currently pressed.
 This macro will register `KC_LALT` and tap `KC_TAB`, then wait for 1000ms. If the key is tapped again, it will send another `KC_TAB`; if there is no tap, `KC_LALT` will be unregistered, thus allowing you to cycle through windows.
 
 ```c
-bool is_alt_tab_active = false; // ADD this near the begining of keymap.c
+bool is_alt_tab_active = false; // ADD this near the beginning of keymap.c
 uint16_t alt_tab_timer = 0;     // we will be using them soon.
 
 enum custom_keycodes {          // Make sure have the awesome keycode ready
diff --git a/docs/feature_oled_driver.md b/docs/feature_oled_driver.md
index f73909f486..b7451f17df 100644
--- a/docs/feature_oled_driver.md
+++ b/docs/feature_oled_driver.md
@@ -259,12 +259,12 @@ void oled_render(void);
 void oled_set_cursor(uint8_t col, uint8_t line);
 
 // Advances the cursor to the next page, writing ' ' if true
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void oled_advance_page(bool clearPageRemainder);
 
 // Moves the cursor forward 1 character length
 // Advance page if there is not enough room for the next character
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void oled_advance_char(void);
 
 // Writes a single character to the buffer at current cursor position
diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md
index 13c63ac94c..31f0a2cbc5 100644
--- a/docs/feature_rgb_matrix.md
+++ b/docs/feature_rgb_matrix.md
@@ -270,7 +270,7 @@ Configure the hardware via your `config.h`:
 | `ISSI_CONFIGURATION` | (Optional) Configuration for the Configuration Register | |
 | `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF |
 | `ISSI_PULLDOWNUP` | (Optional) Configuration for the Pull Up & Pull Down Register | |
-| `ISSI_TEMP` | (Optional) Configuration for the Tempature Register | |
+| `ISSI_TEMP` | (Optional) Configuration for the Temperature Register | |
 | `ISSI_PWM_ENABLE` | (Optional) Configuration for the PWM Enable Register | |
 | `ISSI_PWM_SET` | (Optional) Configuration for the PWM Setting Register | |
 | `ISSI_SCAL_RED` | (Optional) Configuration for the RED LEDs in Scaling Registers | 0xFF |