aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIskandarMa <epiciskandar@gmail.com>2022-02-09 13:12:39 +0800
committerGitHub <noreply@github.com>2022-02-08 21:12:39 -0800
commit04020da48cef186cd58f7782a090116f90ca2008 (patch)
treebfccacecf201a4b2fabf8bcc56f4a1da52a577c5
parentefdaa7f97205f8964c076677519d1848c5ac4b41 (diff)
downloadqmk_firmware-04020da48cef186cd58f7782a090116f90ca2008.tar.gz
qmk_firmware-04020da48cef186cd58f7782a090116f90ca2008.zip
[Docs] pr checklist: update doc hyperlinks to relative ones and use IDs (#16263)
-rw-r--r--docs/pr_checklist.md14
1 files changed, 7 insertions, 7 deletions
diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md
index 1bd6200b8..e4564746b 100644
--- a/docs/pr_checklist.md
+++ b/docs/pr_checklist.md
@@ -8,7 +8,7 @@ If there are any inconsistencies with these recommendations, you're best off [cr
8 8
9- PR should be submitted using a non-`master` branch on the source repository 9- PR should be submitted using a non-`master` branch on the source repository
10 - this does not mean you target a different branch for your PR, rather that you're not working out of your own master branch 10 - this does not mean you target a different branch for your PR, rather that you're not working out of your own master branch
11 - if submitter _does_ use their own `master` branch, they'll be given a link to the ["how to git"](https://docs.qmk.fm/#/newbs_git_using_your_master_branch) page after merging -- (end of this document will contain the contents of the message) 11 - if submitter _does_ use their own `master` branch, they'll be given a link to the ["how to git"](newbs_git_using_your_master_branch.md) page after merging -- (end of this document will contain the contents of the message)
12- newly-added directories and filenames must be lowercase 12- newly-added directories and filenames must be lowercase
13 - this rule may be relaxed if upstream sources originally had uppercase characters (e.g. LUFA, ChibiOS, or imported files from other repositories etc.) 13 - this rule may be relaxed if upstream sources originally had uppercase characters (e.g. LUFA, ChibiOS, or imported files from other repositories etc.)
14 - if there is valid justification (i.e. consistency with existing core files etc.) this can be relaxed 14 - if there is valid justification (i.e. consistency with existing core files etc.) this can be relaxed
@@ -76,9 +76,9 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
76- `<keyboard>.c` 76- `<keyboard>.c`
77 - empty `xxxx_xxxx_kb()` or other weak-defined default implemented functions removed 77 - empty `xxxx_xxxx_kb()` or other weak-defined default implemented functions removed
78 - commented-out functions removed too 78 - commented-out functions removed too
79 - `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](https://docs.qmk.fm/#/custom_quantum_functions?id=keyboard_pre_init_-function-documentation) 79 - `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions.md?id=keyboard_pre_init_-function-documentation)
80 - prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](https://docs.qmk.fm/#/custom_matrix?id=lite) 80 - prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix.md?id=lite)
81 - prefer LED indicator [Configuration Options](https://docs.qmk.fm/#/feature_led_indicators?id=configuration-options) to custom `led_update_*()` implementations where possible 81 - prefer LED indicator [Configuration Options](feature_led_indicators.md?id=configuration-options) to custom `led_update_*()` implementations where possible
82- `<keyboard>.h` 82- `<keyboard>.h`
83 - `#include "quantum.h"` appears at the top 83 - `#include "quantum.h"` appears at the top
84 - `LAYOUT` macros should use standard definitions if applicable 84 - `LAYOUT` macros should use standard definitions if applicable
@@ -111,13 +111,13 @@ Also, specific to ChibiOS:
111 - example: For an STM32L082KZ, given the similarity to an STM32L073RZ, you can use `BOARD = ST_NUCLEO64_L073RZ` in rules.mk 111 - example: For an STM32L082KZ, given the similarity to an STM32L073RZ, you can use `BOARD = ST_NUCLEO64_L073RZ` in rules.mk
112 - QMK is migrating to not having custom board definitions if at all possible, due to the ongoing maintenance burden when upgrading ChibiOS 112 - QMK is migrating to not having custom board definitions if at all possible, due to the ongoing maintenance burden when upgrading ChibiOS
113- New board definitions must not be embedded in a keyboard PR 113- New board definitions must not be embedded in a keyboard PR
114 - See _Core PRs_ below for the procedure for adding a new board to QMK 114 - See [Core PRs](#core-pr) below for the procedure for adding a new board to QMK
115- if a board definition is unavoidable, `board.c` must have a standard `__early_init()` (as per normal ChibiOS board defs) and an empty `boardInit()`: 115- if a board definition is unavoidable, `board.c` must have a standard `__early_init()` (as per normal ChibiOS board defs) and an empty `boardInit()`:
116 - see Arm/ChibiOS [early initialization](https://docs.qmk.fm/#/platformdev_chibios_earlyinit?id=board-init) 116 - see Arm/ChibiOS [early initialization](platformdev_chibios_earlyinit.md?id=board-init)
117 - `__early_init()` should be replaced by either `early_hardware_init_pre()` or `early_hardware_init_post()` as appropriate 117 - `__early_init()` should be replaced by either `early_hardware_init_pre()` or `early_hardware_init_post()` as appropriate
118 - `boardInit()` should be migrated to `board_init()` 118 - `boardInit()` should be migrated to `board_init()`
119 119
120## Core PRs 120## Core PRs :id=core-pr
121 121
122- must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline 122- must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
123- any new boards adding support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey` 123- any new boards adding support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey`