poz/qmk_firmware
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Documentation regarding user code removal/acceptance (#22507)

Browse source
This commit is contained in:
jack 2023-12-03 17:57:42 -07:00 committed by GitHub
parent 37c2dd7c65
commit 8895b13583
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
docs/contributing.md
View file

@ -70,6 +70,7 @@ We have a few different types of changes in QMK, each requiring a different leve
* Keymaps: Make sure that `make keyboard:keymap` does not return any errors. * Keymaps: Make sure that `make keyboard:keymap` does not return any errors.
* Keyboards: Make sure that `make keyboard:all` does not return any errors. * Keyboards: Make sure that `make keyboard:all` does not return any errors.
* Core: Make sure that `make all` does not return any errors. * Core: Make sure that `make all` does not return any errors.
* Note that user-keymap and userspace contributions are no longer accepted.
* Make sure commit messages are understandable on their own. You should put a short description (no more than 70 characters) on the first line, the second line should be empty, and on the 3rd and later lines you should describe your commit in detail, if required. Example: * Make sure commit messages are understandable on their own. You should put a short description (no more than 70 characters) on the first line, the second line should be empty, and on the 3rd and later lines you should describe your commit in detail, if required. Example:
``` ```
@ -80,8 +81,6 @@ The kerpleplork was intermittently failing with error code 23. The root cause wa
Limited experimentation on the devices I have available shows that 7 is high enough to avoid confusing the kerpleplork, but I'd like to get some feedback from people with ARM devices to be sure. Limited experimentation on the devices I have available shows that 7 is high enough to avoid confusing the kerpleplork, but I'd like to get some feedback from people with ARM devices to be sure.
``` ```
!> **IMPORTANT:** If you would like to contribute a bugfix or improvement to user code, such as non-default keymaps, userspace and layouts, be sure to tag the original submitter of the code in your PR. Many users, regardless of skill level with Git and GitHub, may be confused or frustrated at their code being modified without their knowledge.
## Documentation ## Documentation
Documentation is one of the easiest ways to get started contributing to QMK. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren't sure where or how to jump in please [reach out for help](#where-can-i-go-for-help)! Documentation is one of the easiest ways to get started contributing to QMK. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren't sure where or how to jump in please [reach out for help](#where-can-i-go-for-help)!

2
docs/feature_userspace.md
View file

@ -1,5 +1,7 @@
# Userspace: Sharing Code Between Keymaps # Userspace: Sharing Code Between Keymaps
!> Please note, userspace submissions to the upstream `qmk/qmk_firmware` repository are no longer being accepted. The userspace feature itself remains functional and can be configured locally.
If you use more than one keyboard with a similar keymap, you might see the benefit in being able to share code between them. Create your own folder in `users/` named the same as your keymap (ideally your GitHub username, `<name>`) with the following structure: If you use more than one keyboard with a similar keymap, you might see the benefit in being able to share code between them. Create your own folder in `users/` named the same as your keymap (ideally your GitHub username, `<name>`) with the following structure:
* `/users/<name>/` (added to the path automatically) * `/users/<name>/` (added to the path automatically)

7
docs/pr_checklist.md
View file

@ -39,7 +39,7 @@ If there are any inconsistencies with these recommendations, you're best off [cr
## Keymap PRs ## Keymap PRs
Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps. !> Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps.
- `#include QMK_KEYBOARD_H` preferred to including specific board files - `#include QMK_KEYBOARD_H` preferred to including specific board files
- prefer layer `enum`s to `#define`s - prefer layer `enum`s to `#define`s
@ -103,7 +103,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- keyboard `config.h` - keyboard `config.h`
- no `#define DESCRIPTION` - no `#define DESCRIPTION`
- no Magic Key Options, MIDI Options or HD44780 configuration - no Magic Key Options, MIDI Options or HD44780 configuration
- user preference configurable `#define`s need to be moved to keymap `config.h` - user preference configurable `#define`s should not be placed at the keyboard level
- default values should not be redefined, such as `DEBOUNCE`, RGB related settings, etc. - default values should not be redefined, such as `DEBOUNCE`, RGB related settings, etc.
- feature specific documentation contains most default values - feature specific documentation contains most default values
- `grep` or alternative tool can be used to search for default values in core directories (e.g. `grep -r "define DEBOUNCE" quantum`) - `grep` or alternative tool can be used to search for default values in core directories (e.g. `grep -r "define DEBOUNCE" quantum`)
@ -117,8 +117,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- mirroring existing functionality of a commercial board (like custom keycodes and special animations etc.) should be handled through non-`default` keymaps - mirroring existing functionality of a commercial board (like custom keycodes and special animations etc.) should be handled through non-`default` keymaps
- 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()`, `xxxx_xxxx_user()`, 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)