aboutsummaryrefslogtreecommitdiff
path: root/docs/pr_checklist.md
diff options
context:
space:
mode:
authorJoel Challis <[email protected]>2024-08-26 22:28:23 +0100
committerGitHub <[email protected]>2024-08-27 07:28:23 +1000
commit530e0447621c8a23dbd2bf22137b1e90bdc61989 (patch)
tree619de31609b783ce096936c81b5f60d94fa18ce8 /docs/pr_checklist.md
parent8b42e5fb8f74da4de63f3cec941f53ba6b974aba (diff)
downloadqmk_firmware-530e0447621c8a23dbd2bf22137b1e90bdc61989.tar.gz
qmk_firmware-530e0447621c8a23dbd2bf22137b1e90bdc61989.zip
Update PR Checklist for 'via' keymaps (#24330)
Diffstat (limited to 'docs/pr_checklist.md')
-rw-r--r--docs/pr_checklist.md12
1 files changed, 7 insertions, 5 deletions
diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md
index d95d459b06..268e3b1b11 100644
--- a/docs/pr_checklist.md
+++ b/docs/pr_checklist.md
@@ -44,12 +44,14 @@ If there are any inconsistencies with these recommendations, you're best off [cr
Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps. Please see this [issue](https://github.com/qmk/qmk_firmware/issues/22724) for more information.
:::
-- PRs for vendor specific keymaps will be permitted. The naming convention for these should be `default_${vendor}`, `via_${vendor}` i.e. `via_clueboard`.
- - vendor specific keymaps do not necessarily need to be "vanilla" and can be more richly featured than `default` or `via` stock keymaps.
+- PRs for vendor specific keymaps will be permitted. The naming convention for these should be `default_${vendor}` i.e. `default_clueboard`.
+ - vendor specific keymaps do not necessarily need to be "vanilla" and can be more richly featured than `default` stock keymaps.
- `#include QMK_KEYBOARD_H` preferred to including specific board files
- prefer layer enums to #defines
- custom keycode enums must have first entry = `QK_USER`
- some care with spacing (e.g., alignment on commas or first char of keycodes) makes for a much nicer-looking keymap. Spaces are preferred to tabs
+- keymaps should not enable VIA
+ - keymaps targeting VIA support should be submitted to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository
## Keyboard PRs
@@ -136,12 +138,12 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- `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](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"
+- default 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](features/encoders#encoder-map), rather than `encoder_update_user()`
- - default keymap should not enable VIA -- the VIA integration documentation requires a keymap called `via`
+ - default keymap should not enable VIA -- keymaps targeting VIA support should be submitted to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository
- 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
- 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)
@@ -174,7 +176,7 @@ Also, specific to ChibiOS:
- all core PRs must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
- as indicated above, the smallest set of changes to core components should be included in each PR
- PRs containing multiple areas of change will be asked to be split up and raised separately
- - keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `via`, `default_????` keymaps etc.
+ - keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `default_????` keymaps etc.
- keymap modifications for anything other than the default-like keymaps **should not be included in the initial PR** in order to simplify the review process
- the core PR submitter should submit a followup PR affecting other keymaps after initial PR merge
- large-scale refactoring or consolidation PRs that affect other keymaps (such as renaming keycodes) should always be raised separately