これは、提出された PR を QMK の協力者がレビューする際に何をチェックするのかの非網羅的なチェックリストです。
これらの推奨事項に矛盾がある場合は、このドキュメントに対して issue を開くか、Discord の QMK コラボレータに連絡することをお勧めします。
master ではないブランチを使って提出する必要があります
master ブランチを使っている場合は、マージ後に "git の使い方" ページへのリンクが表示されます - (このドキュメントの最後にはメッセージの内容が含まれます)*.c および *.h ソースファイルの有効なライセンスヘッダ
#ifndef インクルードガードの代わりに #pragma once を使います_delay_ms() のかわりに wait_ms() を。(#include <util/delay.h> も消します)timer_read() と timer_read32() など。 -- タイミング API は timer.h を参照してください#include QMK_KEYBOARD_H を推奨します#define よりも enum が好まれます#define ではなく enum が必要です。最初のエントリには = SAFE_RANGE が必要です\)は不要です終了した PR（インスピレーションを得るために、以前のレビューコメントセットは、自分のレビューのピンポンをなくすのに役立ちます）: https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
info.json
readme.md
:flash で終わっていることrules.mk
MIDI_ENABLE、FAUXCLICKY_ENABLE、HD44780_ENABLE は削除されました# Enable Bluetooth with the Adafruit EZ-Key HID は # Enable Bluetooth に変更されました(-/+サイズ) コメントはなくなりましたconfig.h
PRODUCT 値に MANUFACTURER を繰り返さないでください#define DESCRIPTION は要りません＃define はキーマップ config.h に移動する必要がありますDEBOUNCING_DELAY" の代りに "DEBOUNCE" を使いますdefault ではないキーマップを使って処理する必要がありますkeyboard.c
xxxx_xxxx_kb() または他の weak-define のデフォルト実装関数が削除されていることmatrix_init_board() などが keyboard_pre_init_kb() に移行されました。keyboard_pre_init* を参照してくださいCUSTOM_MATRIX = lite を選択し、標準のデバウンスを許可します。マトリックスコードの部分置き換え を参照してくださいled_update_*() 実装よりも LED インジケータの設定オプションを優先してください。keyboard.h
#include "quantum.h" を置きますLAYOUT マクロは、該当する場合は標準の定義を使用してください
LAYOUT/LAYOUT_allよりも優先されます)config.h
rules.mk や config.h が重複していないことkeymaps/default/keymap.c
QMKBEST/QMKURL が削除されていることMO(_LOWER)および MO(_RAISE)キーコードまたは同等のものを使用していて、キーマップに両方のキーを押したときに adjust レイヤーがある場合 - キーマップに直接 adjust レイヤーに入るキーコードがない場合（MO(_ADJUST)のように）次のように記述します...
layer_state_t layer_state_set_user(layer_state_t state) {
return update_tri_layer_state(state, _LOWER, _RAISE, _ADJUST);
}
process_record_user() 内で layer_on()、 update_tri_layer() を手動で処理する代わりに。via という名前のキーマップが必要です。さらに、ChibiOS に固有で:
BOARD = ST_NUCLEO64_L073RZ を使用できます。board.c には標準の __early_init() (通常の ChibiOS ボードの定義と同じ) と空の boardInit() を実装しなければなりません。
__early_init()は、early_hardware_init_pre() または early_hardware_init_post() で適切に置き換える必要がありますboardInit() は board_init() に移行する必要がありますdevelop ブランチをターゲットにする必要があります。これは、その後、breaking change のタイムラインで master にマージされます。人々が自分の master ブランチを使用する場合、マージ後に以下を投稿します：
For future reference, we recommend against committing to your `master` branch as you've done here, because pull requests from modified `master` branches can make it more difficult to keep your QMK fork updated. It is highly recommended for QMK development – regardless of what is being done or where – to keep your master updated, but **NEVER** commit to it. Instead, do all your changes in a branch (branches are basically free in Git) and issue PRs from your branches when you're developing.
There are instructions on how to keep your fork updated here:
[**Best Practices: Your Fork's Master: Update Often, Commit Never**](https://docs.qmk.fm/#/newbs_git_using_your_master_branch)
[Fixing Your Branch](https://docs.qmk.fm/#/newbs_git_resynchronize_a_branch) will walk you through fixing up your `master` branch moving forward. If you need any help with this just ask.
Thanks for contributing!
一般的に、PR がマージの対象となる前に、意味のある(例えば、コードを検査した)2つ(またはそれ以上)の承認を確認したいと考えています。これらのレビューはコラボレータに限られません -- 時間を割いてくれるコミュニティメンバーは誰でも歓迎(奨励)されます。唯一の違いは、チェックマークが緑にならないことですが、それは問題ありません。
また、PR レビューは自由な時間に行われるものです。それは好意で行われるものなので、私たちはレビューに費やす時間に対して、報酬はうけとっていませんし埋め合わせもありません。そのため、私たちがあなたのプルリクエストに取り掛かるのには時間がかかります。家族や生活のことで PR に手が回らなくなることもあり、そして燃え尽き症候群は深刻な懸念です。QMK ファームウェアリポジトリは、毎月平均200件の PR が開かれ、200件の PR がマージされますので、しばらくお待ちください。