4 files changed, 4 insertions, 4 deletions
diff --git a/docs/coding_conventions_c.md b/docs/coding_conventions_c.md
index 08994bfbb..16e28b288 100644
--- a/docs/coding_conventions_c.md
+++ b/docs/coding_conventions_c.md
@@ -14,7 +14,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
  * Think of them as a story describing the feature
  * Use them liberally to explain why particular decisions were made.
  * Do not write obvious comments
-  * If you not sure if a comment is obvious, go ahead and include it.
+  * If you're not sure if a comment is obvious, go ahead and include it.
 * In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
 * We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
 * We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
diff --git a/docs/coding_conventions_python.md b/docs/coding_conventions_python.md
index 694aa38cf..9dd95e4b7 100644
--- a/docs/coding_conventions_python.md
+++ b/docs/coding_conventions_python.md
@@ -8,7 +8,7 @@ Most of our style follows PEP8 with some local modifications to make things less
  * Think of them as a story describing the feature
  * Use them liberally to explain why particular decisions were made.
  * Do not write obvious comments
-  * If you not sure if a comment is obvious, go ahead and include it.
+  * If you're not sure if a comment is obvious, go ahead and include it.
 * We require useful docstrings for all functions.
 * In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
 * Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas.
diff --git a/docs/feature_haptic_feedback.md b/docs/feature_haptic_feedback.md
index 227363322..ff7337a51 100644
--- a/docs/feature_haptic_feedback.md
+++ b/docs/feature_haptic_feedback.md
@@ -2,7 +2,7 @@
 ## Haptic feedback rules.mk options
-The following options are currently available for haptic feedback in `rule.mk`:
+The following options are currently available for haptic feedback in `rules.mk`:
 `HAPTIC_ENABLE += DRV2605L`
diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md
index 5b834a99d..5695acc50 100644
--- a/docs/feature_rgb_matrix.md
+++ b/docs/feature_rgb_matrix.md
@@ -286,7 +286,7 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
 ## Custom RGB Matrix Effects
-By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rule.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.
+By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rules.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.
 To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this:

diff --git a/docs/coding_conventions_c.md b/docs/coding_conventions_c.md index 08994bfbb..16e28b288 100644 --- a/docs/coding_conventions_c.md +++ b/docs/coding_conventions_c.md
@@ -14,7 +14,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
14	* Think of them as a story describing the feature	14	* Think of them as a story describing the feature
15	* Use them liberally to explain why particular decisions were made.	15	* Use them liberally to explain why particular decisions were made.
16	* Do not write obvious comments	16	* Do not write obvious comments
17	* If you not sure if a comment is obvious, go ahead and include it.	17	* If you're not sure if a comment is obvious, go ahead and include it.
18	* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.	18	* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
19	* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)	19	* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
20	* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`	20	* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`


diff --git a/docs/coding_conventions_python.md b/docs/coding_conventions_python.md index 694aa38cf..9dd95e4b7 100644 --- a/docs/coding_conventions_python.md +++ b/docs/coding_conventions_python.md
@@ -8,7 +8,7 @@ Most of our style follows PEP8 with some local modifications to make things less
8	* Think of them as a story describing the feature	8	* Think of them as a story describing the feature
9	* Use them liberally to explain why particular decisions were made.	9	* Use them liberally to explain why particular decisions were made.
10	* Do not write obvious comments	10	* Do not write obvious comments
11	* If you not sure if a comment is obvious, go ahead and include it.	11	* If you're not sure if a comment is obvious, go ahead and include it.
12	* We require useful docstrings for all functions.	12	* We require useful docstrings for all functions.
13	* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.	13	* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
14	* Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas.	14	* Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas.


diff --git a/docs/feature_haptic_feedback.md b/docs/feature_haptic_feedback.md index 227363322..ff7337a51 100644 --- a/docs/feature_haptic_feedback.md +++ b/docs/feature_haptic_feedback.md
@@ -2,7 +2,7 @@
2		2
3	## Haptic feedback rules.mk options	3	## Haptic feedback rules.mk options
4		4
5	The following options are currently available for haptic feedback in `rule.mk`:	5	The following options are currently available for haptic feedback in `rules.mk`:
6		6
7	`HAPTIC_ENABLE += DRV2605L`	7	`HAPTIC_ENABLE += DRV2605L`
8		8


diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md index 5b834a99d..5695acc50 100644 --- a/docs/feature_rgb_matrix.md +++ b/docs/feature_rgb_matrix.md
@@ -286,7 +286,7 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
286		286
287	## Custom RGB Matrix Effects	287	## Custom RGB Matrix Effects
288		288
289	By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rule.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.	289	By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rules.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.
290		290
291	To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this:	291	To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this:
292		292