Fix the naming for clueboard files

[qmk_firmware.git] / docs / contributing.md

diff --git a/docs/contributing.md b/docs/contributing.md
index b675f98b3f2e9af3274f85b72197b1272d8de549..58af8ce53b177cc0ea99f354f4eee8c9bc78c6f7 100644 (file)
--- a/docs/contributing.md
+++ b/docs/contributing.md
@@ -78,9 +78,9 @@ We have a few different types of changes in QMK, each requiring a different leve
 * 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-revision-your_new_keymap` does not return an error
-  * Keyboards: Make sure that `make keyboard-all` does not return any errors
-  * Core: Make sure that `make allkb` does not return any errors.
+  * Keymaps: Make sure that `make keyboard:your_new_keymap` does not return an error
+  * 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:
 
 ```
@@ -128,7 +128,7 @@ Here are some things to keep in mind when working on your feature or bug fix.
 
 * **Disabled by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, please talk with us about it.
 * **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
-* **Consider subprojects and different chip-bases** - there are several keyboards that have subprojects 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.
+* **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: