several improvements for mitosis:datagrok (#1960)

[qmk_firmware.git] / docs / contributing.md

diff --git a/docs/contributing.md b/docs/contributing.md
index b675f98b3f2e9af3274f85b72197b1272d8de549..6a3f34e4cce583da2d62fd407d389b36bb39055c 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:
 
 ```
@@ -104,6 +104,8 @@ Most first-time QMK contributors start with their personal keymaps. We try to ke
 * Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
 * 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.
+* Do not include `Makefile`s in your keymap folder (they're no longer used)
+* Update copyrights in file headers (look for `REPLACE_WITH_YOUR_NAME `)
 
 ## Keyboards
 
@@ -114,6 +116,9 @@ 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
 * Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
+* Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
+* Do not include `Makefile`s in your keyboard folder (they're no longer used)
+* Update copyrights in file headers (look for `REPLACE_WITH_YOUR_NAME `)
 
 ## Quantum/TMK Core
 
@@ -128,7 +133,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: 
@@ -144,4 +149,4 @@ To maintain a clear vision of how things are laid out in QMK we try to plan out
 
 # What does the Code of Conduct mean for me?
 
-Our Code of Conduct means that you are responsible for treating everyone on the project with respect and courtesy regardless of their identity. If you are the victim of any inappropriate behavior or comments as described in our Code of Conduct, we are here for you and will do the best to ensure that the abuser is reprimanded appropriately, per our code.
+Our [Code of Conduct](https://github.com/qmk/qmk_firmware/blob/master/CODE_OF_CONDUCT.md) means that you are responsible for treating everyone on the project with respect and courtesy regardless of their identity. If you are the victim of any inappropriate behavior or comments as described in our Code of Conduct, we are here for you and will do the best to ensure that the abuser is reprimanded appropriately, per our code.