aboutsummaryrefslogtreecommitdiff
path: root/docs/pr_checklist.md
diff options
context:
space:
mode:
authorRyan <[email protected]>2024-06-02 12:42:24 +1000
committerGitHub <[email protected]>2024-06-02 12:42:24 +1000
commit78a0adfbb4d2c4e12f93f2a62ded0020d406243e (patch)
treee6e123b36569559233025add654580e090dc0154 /docs/pr_checklist.md
parentfa6d23235bf429446250cd5212e209d5fbfdbac2 (diff)
downloadqmk_firmware-78a0adfbb4d2c4e12f93f2a62ded0020d406243e.tar.gz
qmk_firmware-78a0adfbb4d2c4e12f93f2a62ded0020d406243e.zip
[docs] Organize driver & feature docs into subfolders (#23848)
Co-authored-by: Nick Brassel <[email protected]>
Diffstat (limited to 'docs/pr_checklist.md')
-rw-r--r--docs/pr_checklist.md6
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md
index e5ed1d67b6..f7b16e1d85 100644
--- a/docs/pr_checklist.md
+++ b/docs/pr_checklist.md
@@ -126,7 +126,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- commented-out functions removed too
- `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions#keyboard_pre_init_-function-documentation)
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix#lite)
- - prefer LED indicator [Configuration Options](feature_led_indicators#configuration-options) to custom `led_update_*()` implementations where possible
+ - prefer LED indicator [Configuration Options](features/led_indicators#configuration-options) to custom `led_update_*()` implementations where possible
- hardware that's enabled at the keyboard level and requires configuration such as OLED displays or encoders should have basic functionality implemented here
- `<keyboard>.h`
- `#include "quantum.h"` appears at the top
@@ -135,12 +135,12 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- no duplication of `rules.mk` or `config.h` from keyboard
- `keymaps/default/keymap.c`
- `QMKBEST`/`QMKURL` example macros removed
- - if using `MO(1)` and `MO(2)` keycodes together to access a third layer, the [Tri Layer](feature_tri_layer) feature should be used, rather than manually implementing this using `layer_on/off()` and `update_tri_layer()` functions in the keymap's `process_record_user()`.
+ - if using `MO(1)` and `MO(2)` keycodes together to access a third layer, the [Tri Layer](features/tri_layer) feature should be used, rather than manually implementing this using `layer_on/off()` and `update_tri_layer()` functions in the keymap's `process_record_user()`.
- default (and via) keymaps should be "pristine"
- bare minimum to be used as a "clean slate" for another user to develop their own user-specific keymap
- what does pristine mean? no custom keycodes. no advanced features like tap dance or macros. basic mod taps and home row mods would be acceptable where their use is necessary
- standard layouts preferred in these keymaps, if possible
- - should use [encoder map feature](feature_encoders#encoder-map), rather than `encoder_update_user()`
+ - should use [encoder map feature](features/encoders#encoder-map), rather than `encoder_update_user()`
- default keymap should not enable VIA -- the VIA integration documentation requires a keymap called `via`
- submitters can add an example (or bells-and-whistles) keymap showcasing capabilities in the same PR but it shouldn't be embedded in the 'default' keymap
- submitters can also have a "manufacturer-matching" keymap that mirrors existing functionality of the commercial product, if porting an existing board