From 530e0447621c8a23dbd2bf22137b1e90bdc61989 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Mon, 26 Aug 2024 22:28:23 +0100 Subject: [PATCH] Update PR Checklist for 'via' keymaps (#24330) --- docs/pr_checklist.md | 12 +++++++----- 1 file 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