Remove more commented out MCUs

[qmk_firmware.git] / docs / documentation_best_practices.md

diff --git a/docs/documentation_best_practices.md b/docs/documentation_best_practices.md
index 059b25bcd3b536dbe0481e84968811f71927f0f5..77c226117c2d95eb8fcbb27bd8a4cdd355ae2558 100644 (file)
--- a/docs/documentation_best_practices.md
+++ b/docs/documentation_best_practices.md
@@ -4,7 +4,7 @@ This page exists to document best practices when writing documentation for QMK.
 
 # Page Opening
 
-Your documentation page should generally start with an H1 heading, followed by a 1 paragrah description of what the user will find on this page. Keep in mind that this heading and paragraph will sit next to the Table of Contents, so keep the heading short and avoid long strings with no whitespace.
+Your documentation page should generally start with an H1 heading, followed by a 1 paragraph description of what the user will find on this page. Keep in mind that this heading and paragraph will sit next to the Table of Contents, so keep the heading short and avoid long strings with no whitespace.
 
 Example:
 
@@ -22,63 +22,30 @@ Your page should generally have multiple "H1" headings. Only H1 and H2 headings
 
 You can have styled hint blocks drawn around text to draw attention to it.
 
+### Important
+
 ```
-{% hint style='info' %}
-This uses `hint style='info'`
-{% endhint %}
+!> This is important
 ```
 
-### Examples:
-
-{% hint style='info' %}
-This uses `hint style='info'`
-{% endhint %}
-
-{% hint style='tip' %}
-This uses `hint style='tip'`
-{% endhint %}
-
-{% hint style='danger' %}
-This uses `hint style='danger'`
-{% endhint %}
+Renders as:
 
-{% hint style='working' %}
-This uses `hint style='working'`
-{% endhint %}
+!> This is important
 
-# Styled Terminal Blocks
-
-You can present styled terminal blocks by including special tokens inside your text block.
+### General Tips
 
 ```
-\`\`\`
-**[terminal]
-**[prompt foo@joe]**[path ~]**[delimiter  $ ]**[command ./myscript]
-Normal output line. Nothing special here...
-But...
-You can add some colors. What about a warning message?
-**[warning [WARNING] The color depends on the theme. Could look normal too]
-What about an error message?
-**[error [ERROR] This is not the error you are looking for]
-\`\`\`
+?> This is a helpful tip.
 ```
 
-### Example
+Renders as:
+
+?> This is a helpful tip.
 
-```
-**[terminal]
-**[prompt foo@joe]**[path ~]**[delimiter  $ ]**[command ./myscript]
-Normal output line. Nothing special here...
-But...
-You can add some colors. What about a warning message?
-**[warning [WARNING] The color depends on the theme. Could look normal too]
-What about an error message?
-**[error [ERROR] This is not the error you are looking for]
-```
 
 # Documenting Features
 
-If you create a new feature for QMK, create a documentation page for it. It doesn't have to be very long, a few sentances describing your feature and a table listing any relevant keycodes is enough. Here is a basic template:
+If you create a new feature for QMK, create a documentation page for it. It doesn't have to be very long, a few sentences describing your feature and a table listing any relevant keycodes is enough. Here is a basic template:
 
 ```markdown
 # My Cool Feature
@@ -94,4 +61,4 @@ This page describes my cool feature. You can use my cool feature to make coffee
 |KC_SUGAR||Order Sugar|
 ```
 
-Place your documentation into `docs/feature_<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_summary.md`. If you have added any keycodes be sure to add them to `docs/keycodes.md` with a link back to your feature page.
+Place your documentation into `docs/feature_<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_sidebar.md`. If you have added any keycodes be sure to add them to `docs/keycodes.md` with a link back to your feature page.