summaryrefslogtreecommitdiffstats
path: root/docs/pr_checklist.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/pr_checklist.md')
-rw-r--r--docs/pr_checklist.md3
1 files changed, 2 insertions, 1 deletions
diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md
index ed2b466de3..2f974c3817 100644
--- a/docs/pr_checklist.md
+++ b/docs/pr_checklist.md
@@ -112,6 +112,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- submitters can have a personal (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
- Do not include VIA json files in the PR. These do not belong in the QMK repository as they are not used by QMK firmware -- they belong in the [VIA Keyboard Repo](https://github.com/the-via/keyboards)
+- Do not include KLE json files in the PR. These have no use within QMK.
- Do not include source files from another keyboard or vendors keyboard folder. Including core files is fine.
- For instance, only `wilba_tech` boards shall include `keyboards/wilba_tech/wt_main.c` and `keyboards/wilba_tech/wt_rgb_backlight.c`. But including `drivers/sensors/pmw3360.c` is absolutely fine for any and all boards.
- Code that needs to be used by multiple boards is a candidate for core code changes, and should be separated out.
@@ -135,7 +136,7 @@ Also, specific to ChibiOS:
- for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified
- for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided
- if an existing keymap exists that can leverage this functionality this may not be required (e.g. a new RGB driver chip, supported by the `rgb` keymap) -- consult with the QMK Collaborators on Discord to determine if there is sufficient overlap already
-- any features adding `_kb`/`_user` callbacks must return a `bool`, to allow for user override of keyboard-level callbacks.
+- any features adding `_kb`/`_user` callbacks must return a `bool`, to allow for user override of keyboard-level callbacks.
- other requirements are at the discretion of QMK collaborators
- core is a lot more subjective given the breadth of posted changes