1 files changed, 3 insertions, 3 deletions
diff --git a/docs/contributing.md b/docs/contributing.md
index a1534d968..0e8066f00 100644
--- a/docs/contributing.md
+++ b/docs/contributing.md
@@ -75,7 +75,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
 We have a few different types of changes in QMK, each requiring a different level of rigor. We'd like you to keep the following guidelines in mind no matter what type of change you're making.
-* Separate PR's into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature. 
+* Separate PR's 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 an error
@@ -111,7 +111,7 @@ Most first-time QMK contributors start with their personal keymaps. We try to ke
 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: 
+We also ask that you follow these guidelines:
 * Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
 * Keep the number of commits reasonable or we will squash your PR
@@ -136,7 +136,7 @@ Here are some things to keep in mind when working on your feature or bug fix.
 * **Consider revisions and different chip-bases** - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on.
 * **Explain your feature** - Document it in `docs/`, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work.
-We also ask that you follow these guidelines: 
+We also ask that you follow these guidelines:
 * Keep the number of commits reasonable or we will squash your PR
 * Do not lump keyboards or keymaps in with core changes. Submit your core changes first.

diff --git a/docs/contributing.md b/docs/contributing.md index a1534d968..0e8066f00 100644 --- a/docs/contributing.md +++ b/docs/contributing.md
@@ -75,7 +75,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
75		75
76	We have a few different types of changes in QMK, each requiring a different level of rigor. We'd like you to keep the following guidelines in mind no matter what type of change you're making.	76	We have a few different types of changes in QMK, each requiring a different level of rigor. We'd like you to keep the following guidelines in mind no matter what type of change you're making.
77		77
78	* Separate PR's into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature.	78	* Separate PR's into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature.
79	* Check for unnecessary whitespace with `git diff --check` before committing.	79	* Check for unnecessary whitespace with `git diff --check` before committing.
80	* Make sure your code change actually compiles.	80	* Make sure your code change actually compiles.
81	* Keymaps: Make sure that `make keyboard:your_new_keymap` does not return an error	81	* Keymaps: Make sure that `make keyboard:your_new_keymap` does not return an error
@@ -111,7 +111,7 @@ Most first-time QMK contributors start with their personal keymaps. We try to ke
111		111
112	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.	112	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.
113		113
114	We also ask that you follow these guidelines:	114	We also ask that you follow these guidelines:
115		115
116	* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).	116	* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
117	* Keep the number of commits reasonable or we will squash your PR	117	* Keep the number of commits reasonable or we will squash your PR
@@ -136,7 +136,7 @@ Here are some things to keep in mind when working on your feature or bug fix.
136	* Consider revisions and different chip-bases - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on.	136	* Consider revisions and different chip-bases - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on.
137	* Explain your feature - Document it in `docs/`, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work.	137	* Explain your feature - Document it in `docs/`, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work.
138		138
139	We also ask that you follow these guidelines:	139	We also ask that you follow these guidelines:
140		140
141	* Keep the number of commits reasonable or we will squash your PR	141	* Keep the number of commits reasonable or we will squash your PR
142	* Do not lump keyboards or keymaps in with core changes. Submit your core changes first.	142	* Do not lump keyboards or keymaps in with core changes. Submit your core changes first.