qmk

Unnamed repository; edit this file 'description' to name the repository.
git clone git://git.z3bra.org/qmk.git
Log | Files | Refs | Submodules | LICENSE

commit 73ddb764ccbe47662ba4604a18818f003abd8d36
parent 2ec0e014302fbdcd61047e90c131d0e1302f2e17
Author: Alexander Dang-Tran <alex.dangtran@gmail.com>
Date:   Sat, 19 May 2018 16:20:07 -0500

Fix readme and contributing hyperlinks

Diffstat:
docs/README.md | 4++--
docs/contributing.md | 6+++---
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/README.md b/docs/README.md @@ -19,7 +19,7 @@ Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk ## How to Compile -Before you are able to compile, you'll need to [install an environment](01_Getting_Started/01_Install_Build_Tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation: +Before you are able to compile, you'll need to [install an environment](getting_started_build_tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation: make planck/rev4:default @@ -29,4 +29,4 @@ This would build the `rev4` revision of the `planck` with the `default` keymap. ## How to Customize -QMK has lots of [features](05_Features/index.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](07_Reference/Keymap_Overview.md), and changing the [keycodes](06_Keycodes/index.md). +QMK has lots of [features](features.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md). diff --git a/docs/contributing.md b/docs/contributing.md @@ -101,7 +101,7 @@ You'll find all our documentation in the `qmk_firmware/docs` directory, or if yo Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap. -* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#). +* Write a `readme.md` using [the template](documentation_templates.md). * All Keymap PR's are squashed, so if you care about how your commits are squashed you should do it yourself * Do not lump features in with keymap PR's. Submit the feature first and then a second PR for the keymap. * Do not include `Makefile`s in your keymap folder (they're no longer used) @@ -113,7 +113,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](https://docs.qmk.fm/documentation_templates.html#). +* Write a `readme.md` using [the template](documentation_templates.md). * Keep the number of commits reasonable or we will squash your PR * 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]` @@ -140,7 +140,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](http://docs.qmk.fm/unit_testing.html) for your feature +* Write [Unit Tests](unit_testing.md) 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