diff options
author | fauxpark <fauxpark@gmail.com> | 2019-10-08 08:50:10 +1100 |
---|---|---|
committer | noroadsleft <18669334+noroadsleft@users.noreply.github.com> | 2019-10-07 14:50:10 -0700 |
commit | 3e22af92ee67e77e4089771ab4d45dc37df38c53 (patch) | |
tree | e2e224d8afa1ac4ae57bc75f43b022afd25f3339 /docs | |
parent | 2c51d1422309d389346022711b4cbc54a8c42f79 (diff) | |
download | qmk_firmware-3e22af92ee67e77e4089771ab4d45dc37df38c53.tar.gz qmk_firmware-3e22af92ee67e77e4089771ab4d45dc37df38c53.zip |
[Docs] Add an important note about modifying user code (#6959)
* Add an important note about modifying user code
* Update docs/contributing.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/contributing.md | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/docs/contributing.md b/docs/contributing.md index 761bc9959b..04dc0da20f 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -63,11 +63,11 @@ Most of our style is pretty easy to pick up on. If you are familiar with either 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 PRs 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 - * Keyboards: Make sure that `make keyboard:all` does not return any errors + * Keymaps: Make sure that `make keyboard:your_new_keymap` does not return any errors. + * 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: @@ -79,6 +79,8 @@ The kerpleplork was intermittently failing with error code 23. The root cause wa Limited experimentation on the devices I have available shows that 7 is high enough to avoid confusing the kerpleplork, but I'd like to get some feedback from people with ARM devices to be sure. ``` +!> **IMPORTANT:** If you would like to contribute a bugfix or improvement to user code, such as non-default keymaps, userspace and layouts, be sure to tag the original submitter of the code in your PR. Many users, regardless of skill level with Git and GitHub, may be confused or frustrated at their code being modified without their knowledge. + ## Documentation Documentation is one of the easiest ways to get started contributing to QMK. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren't sure where or how to jump in please [reach out for help](#where-can-i-go-for-help)! |