diff options
Diffstat (limited to 'docs/contributing.md')
-rw-r--r-- | docs/contributing.md | 18 |
1 files changed, 7 insertions, 11 deletions
diff --git a/docs/contributing.md b/docs/contributing.md index 8d993e3389..14025c2c50 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -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 |