Checklist clarification. (#18440)
This commit is contained in:
parent
b0f824755a
commit
b03a3d7047
|
@ -52,6 +52,9 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
|
||||||
- valid maintainer
|
- valid maintainer
|
||||||
- valid USB VID/PID and device version
|
- valid USB VID/PID and device version
|
||||||
- displays correctly in Configurator (press Ctrl+Shift+I to preview local file, turn on fast input to verify ordering)
|
- displays correctly in Configurator (press Ctrl+Shift+I to preview local file, turn on fast input to verify ordering)
|
||||||
|
- `layout` definitions should include matrix positions, so that `LAYOUT` macros can be generated at build time
|
||||||
|
- should use standard definitions if applicable
|
||||||
|
- use the Community Layout macro names where they apply (preferred above `LAYOUT`/`LAYOUT_all`)
|
||||||
- `readme.md`
|
- `readme.md`
|
||||||
- standard template should be present -- [link to template](https://github.com/qmk/qmk_firmware/blob/master/data/templates/keyboard/readme.md)
|
- standard template should be present -- [link to template](https://github.com/qmk/qmk_firmware/blob/master/data/templates/keyboard/readme.md)
|
||||||
- flash command is present, and has `:flash` at end
|
- flash command is present, and has `:flash` at end
|
||||||
|
@ -82,17 +85,15 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
|
||||||
- Vial-related files or changes will not be accepted, as they are not used by QMK firmware (no Vial-specific core code has been submitted or merged)
|
- Vial-related files or changes will not be accepted, as they are not used by QMK firmware (no Vial-specific core code has been submitted or merged)
|
||||||
- `<keyboard>.c`
|
- `<keyboard>.c`
|
||||||
- empty `xxxx_xxxx_kb()` or other weak-defined default implemented functions removed
|
- empty `xxxx_xxxx_kb()` or other weak-defined default implemented functions removed
|
||||||
|
- empty `xxxx_xxxx_user()` or other user-level functions are disallowed at the keyboard level and must be moved to keymaps
|
||||||
- commented-out functions removed too
|
- commented-out functions removed too
|
||||||
- `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions.md?id=keyboard_pre_init_-function-documentation)
|
- `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions.md?id=keyboard_pre_init_-function-documentation)
|
||||||
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix.md?id=lite)
|
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix.md?id=lite)
|
||||||
- prefer LED indicator [Configuration Options](feature_led_indicators.md?id=configuration-options) to custom `led_update_*()` implementations where possible
|
- prefer LED indicator [Configuration Options](feature_led_indicators.md?id=configuration-options) to custom `led_update_*()` implementations where possible
|
||||||
- Encoder support should not be hacked into the keymap here -- no `tap_code(dynamic_keymap_get_keycode())` or `action_exec()` hacks. The [Encoder Map](feature_encoders.md?id=encoder-map) feature already supports the dynamic keymap feature (what power's VIA's "live keymap updates" capability).
|
- Encoder support should not require any keyboard-level code, and associated keymaps should now leverage the [Encoder Map](feature_encoders.md?id=encoder-map) feature instead.
|
||||||
- If support is absolutely necessary, it should be implemented exclusively at the keymap level, with none of the implementation bleeding into the keyboard level (no empty rows/columns, no encoder specific layouts, etc.), as those configurations can be redefined at the keymap level. Keymaps can then choose to use the `action_exec` hack. <!-- because people will complain, give them a way to implement it, in the meanwhile. To be removed. -->
|
|
||||||
- [Request for official proper VIA support](https://github.com/the-via/app/issues/26)
|
|
||||||
- `<keyboard>.h`
|
- `<keyboard>.h`
|
||||||
- `#include "quantum.h"` appears at the top
|
- `#include "quantum.h"` appears at the top
|
||||||
- `LAYOUT` macros should use standard definitions if applicable
|
- `LAYOUT` macros should be moved to `info.json`
|
||||||
- use the Community Layout macro names where they apply (preferred above `LAYOUT`/`LAYOUT_all`)
|
|
||||||
- keymap `config.h`
|
- keymap `config.h`
|
||||||
- no duplication of `rules.mk` or `config.h` from keyboard
|
- no duplication of `rules.mk` or `config.h` from keyboard
|
||||||
- `keymaps/default/keymap.c`
|
- `keymaps/default/keymap.c`
|
||||||
|
@ -111,7 +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 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
|
- 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 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 source files from another keyboard or vendors keyboard folder. Including core files is fine.
|
- Do not include source files from another keyboard or vendors keyboard folder. Including core files is fine.
|
||||||
- For instance, only `wilba_tech` boards using be including `keyboards/wilba_tech/wt_main.c` and `keyboards/wilba_tech/wt_rgb_backlight.c`. But including `drivers/sensors/pmw3360.c` is absolutely fine.
|
- For instance, only `wilba_tech` boards using be including `keyboards/wilba_tech/wt_main.c` and `keyboards/wilba_tech/wt_rgb_backlight.c`. But including `drivers/sensors/pmw3360.c` is absolutely fine.
|
||||||
- Code that needs to be used by multiple boards is a candidate for core code changes, and should be separated out.
|
- Code that needs to be used by multiple boards is a candidate for core code changes, and should be separated out.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue