summaryrefslogtreecommitdiffstats
path: root/docs/Adding-features-to-QMK.md
diff options
context:
space:
mode:
authorJack Humbert <jack.humb@gmail.com>2017-06-10 14:58:24 -0400
committerJack Humbert <jack.humb@gmail.com>2017-06-10 14:58:24 -0400
commitca01d94005f67ec4fa9528353481faa622d949ae (patch)
treedd6d59d065492e3bb8192263a8a7e7cc0709c48f /docs/Adding-features-to-QMK.md
parent558db0e03f0f3993e2b7fb5cc3f285393da0a4c3 (diff)
convert docs to lowercase and underscores
Diffstat (limited to 'docs/Adding-features-to-QMK.md')
-rw-r--r--docs/Adding-features-to-QMK.md7
1 files changed, 0 insertions, 7 deletions
diff --git a/docs/Adding-features-to-QMK.md b/docs/Adding-features-to-QMK.md
deleted file mode 100644
index f6f7cba208..0000000000
--- a/docs/Adding-features-to-QMK.md
+++ /dev/null
@@ -1,7 +0,0 @@
-If you have an idea for a custom feature or extra hardware connection, we'd love to accept it into QMK! These are generally done via [pull request](https://github.com/qmk/qmk_firmware/pulls) after forking, and here are some things to keep in mind when creating one:
-
-* **Disable 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, [open an issue](https://github.com/qmk/qmk_firmware/issues) for everyone to discuss 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 have allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled in one that doesn't work.
-* **Explain your feature** - submitting a markdown write-up of what your feature does with your PR may be needed, and it will allow a collaborator to easily copy it into the wiki for documentation (after proofing and editing).
-* **Don't refactor code** - to maintain a clear vision of how things are laid out in QMK, we try to plan out refactors in-depth, and have a collaborator make the changes. If you have an idea for refactoring, or suggestions, [open an issue](https://github.com/qmk/qmk_firmware/issues). \ No newline at end of file