opensteno_qmk/docs/adding_features_to_qmk.md

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 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 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.