drashna/qmk_firmware
1
0
Fork 0
Code Activity Actions

Vitepress conversion of docs. (#23795)

Browse source
This commit is contained in:
Nick Brassel 2024-05-30 12:00:41 +10:00 • committed by GitHub
parent 395766657f
commit 6ef9717288
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
357 changed files with 3611 additions and 24208 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/contributing.md
View file

@ -56,8 +56,8 @@ Never made an open source contribution before? Wondering how contributions work
Most of our style is pretty easy to pick up on. If you are familiar with either C or Python you should not have too much trouble with our local styles.
* [Coding Conventions - C](coding_conventions_c.md)
* [Coding Conventions - Python](coding_conventions_python.md)
* [Coding Conventions - C](coding_conventions_c)
* [Coding Conventions - Python](coding_conventions_python)
# General Guidelines
@ -101,17 +101,13 @@ enum my_keycodes {
};
```
### Previewing the Documentation :id=previewing-the-documentation
### Previewing the Documentation {#previewing-the-documentation}
Before opening a pull request, you can preview your changes if you have set up the development environment by running this command from the `qmk_firmware/` folder:
qmk docs
or if you only have Python 3 installed:
python3 -m http.server 8936 --directory docs
and navigating to `http://localhost:8936/`.
and navigating to `http://localhost:5173/`.
## Keyboards
@ -119,7 +115,7 @@ Keyboards are the raison d'être for QMK. Some keyboards are community maintaine
We also ask that you follow these guidelines:
* Write a `readme.md` using [the template](documentation_templates.md).
* Write a `readme.md` using [the template](documentation_templates).
* Include a `default` keymap that provides a clean slate for users to start with when creating their own keymaps.
* Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
* Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
@ -128,7 +124,7 @@ We also ask that you follow these guidelines:
## Quantum/TMK Core
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](understanding_qmk.md), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](understanding_qmk), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
* [Chat on Discord](https://discord.gg/Uq7gcHh)
* [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
@ -146,7 +142,7 @@ We also ask that you follow these guidelines:
* Keep the number of commits reasonable or we will squash your PR
* Do not lump keyboards or keymaps in with core changes. Submit your core changes first.
* Write [Unit Tests](unit_testing.md) for your feature
* Write [Unit Tests](unit_testing) for your feature
* Follow the style of the file you are editing. If the style is unclear or there are mixed styles you should conform to the [coding conventions](#coding-conventions) above.
## Refactoring