summaryrefslogtreecommitdiffstats
path: root/docs/contributing
diff options
context:
space:
mode:
authorPromise Akpan <akpanpromise@hotmail.com>2019-08-15 12:06:39 +0100
committerChris Akritidis <43294513+cakrit@users.noreply.github.com>2019-08-15 13:06:39 +0200
commitf5006d51e8caf9148d393eb68d53dc9fcd28b7b6 (patch)
tree03b757236d6b45e46813a4a875c77dc775e5f896 /docs/contributing
parent69172fd57472df75d877f43de2dcc693c48ab5c0 (diff)
Fix Markdown Lint warnings (#6664)
* make remark access all directories * detailed fix after autofix by remark lint * cross check autofix for this set of files * crosscheck more files * crosschecking and small fixes * crosscheck autofixed md files
Diffstat (limited to 'docs/contributing')
-rw-r--r--docs/contributing/contributing-documentation.md23
-rw-r--r--docs/contributing/style-guide.md73
2 files changed, 42 insertions, 54 deletions
diff --git a/docs/contributing/contributing-documentation.md b/docs/contributing/contributing-documentation.md
index 540d0d4ce8..7cf0d820f2 100644
--- a/docs/contributing/contributing-documentation.md
+++ b/docs/contributing/contributing-documentation.md
@@ -8,13 +8,12 @@ We also ask you to read our [documentation style guide](style-guide.md), which,
All our documentation uses the Markdown syntax. If you're not familiar with how it works, please read the [Markdown introduction post](https://daringfireball.net/projects/markdown/) by its creator, followed by [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub.
-
## How contributing to the documentation works
There are two ways to contribute to Netdata's documentation:
-1. Edit documentation [directly in GitHub](#edit-documentation-directly-on-gitHub).
-2. Download the repository and [edit documentation locally](#edit-documentation-locally).
+1. Edit documentation [directly in GitHub](#edit-documentation-directly-on-gitHub).
+2. Download the repository and [edit documentation locally](#edit-documentation-locally).
Editing in GitHub is a simpler process and is perfect for quick edits to a single document, such as fixing a typo or clarifying a confusing sentence.
@@ -24,9 +23,8 @@ In both cases, you'll finish by submitting a pull request (PR). Once you submit
To continue, follow one of the paths below:
-- [Edit documentation directly in GitHub](#edit-documentation-directly-on-github)
-- [Edit documentation locally](#edit-documentation-locally)
-
+- [Edit documentation directly in GitHub](#edit-documentation-directly-on-github)
+- [Edit documentation locally](#edit-documentation-locally)
## Edit documentation directly on GitHub
@@ -47,7 +45,6 @@ After you've hit that button, jump down to our instructions on [pull requests an
!!! note
This process will create a branch directly on the `netdata/netdata` repository, which then requires manual cleanup. If you're going to make significant documentation contributions, or contribute often, we recommend the local editing process just below.
-
## Edit documentation locally
Editing documentation locally is the preferred method for complex changes, PRs that span across multiple documents, or those that change the styling or underlying functionality of the documentation.
@@ -64,7 +61,6 @@ $ git clone https://github.com/YOUR-GITHUB-USERNAME/netdata.git
You can now jump into the directory and explore Netdata's structure for yourself.
-
### Understanding the structure of Netdata's documentation
All of Netdata's documentation is stored within the repository itself, as close as possible to the code it corresponds to. Many sub-folders contain a `README.md` file, which is then used to populate the documentation about that feature/component of Netdata.
@@ -81,7 +77,6 @@ At the root of the Netdata repository is a `docs/` folder. Inside this folder we
If the documentation you're working on doesn't have a direct relaionship to a component of Netdata, it can be placed in this `docs/` folder.
-
### Make your edits
Now that you're set up and understand where to find or create your `.md` file, you can now begin to make your edits. Just use your favorite editor and keep in mind our [style guide](style-guide.md) as you work.
@@ -90,7 +85,6 @@ If you add a new file to the documentation, you may need to modify the `buildyam
Be sure to periodically add/commit your edits so that you don't lose your work! We use version control software for a reason.
-
### Build the documentation
Building the documentation periodically gives you a glimpse into the final product, and is generally required if you're making changes to the table of contents.
@@ -104,7 +98,7 @@ Follow the [Python installation instructions](https://www.python.org/downloads/)
Use `pip`, which was installed alongside Python, to install `mkdocs` and `mkdocs-material`. Your operating system might force you to use `pip2` or `pip3` instead, dependin on which version of Python you have installed.
-``` bash
+```bash
$ pip install mkdocs mkdocs-material
```
@@ -113,13 +107,12 @@ $ pip install mkdocs mkdocs-material
When `pip` is finished installing, navigate to the root directory of the Netdata repository and run the documentation generator script.
-``` bash
+```bash
$ sh docs/generator/buildhtml.sh
```
This process will take some time. Once finished, the built documentation site will be located at `docs/generator/build/`.
-
### Run a local web server to test documentation
The best way to view the documentation site you just built is to run a simple web server from the `docs/generator/build/` directory. So, navigate there and run a Python-based web server:
@@ -133,14 +126,12 @@ Feel free to replace the port number you want this web server to listen on (port
Open your web browser and navigate to `http://localhost:20000`. If you replaced the port earlier, change it here as well. You can now navigate through the documentation as you would on the live site!
-
## Pull requests and final steps
When you're finished with your changes, add and commit them to your fork of the Netdata repository. Head over to GitHub to create your pull request (PR).
Once we receive your pull request (PR), we'll take time to read through it and assess it for correctness, conciseness, and overall quality. We may point to specific sections and ask for additional information or other fixes.
-
## What's next
-- Read up on the Netdata documentation [style guide](style-guide.md). \ No newline at end of file
+- Read up on the Netdata documentation [style guide](style-guide.md).
diff --git a/docs/contributing/style-guide.md b/docs/contributing/style-guide.md
index e7f9740aa6..42c9810172 100644
--- a/docs/contributing/style-guide.md
+++ b/docs/contributing/style-guide.md
@@ -4,14 +4,13 @@ This in-progress style guide establishes editorial guidelines for anyone who wan
## Table of contents
-- [Welcome!](#welcome)
-- [Goals of the Netdata style guide](#goals-of-the-Netdata-style-guide)
-- [General principles](#general-principles)
-- [Tone and content](#tone-and-content)
-- [Language and grammar](#language-and-grammar)
-- [Markdown syntax](#markdown-syntax)
-- [Accessibility](#accessibility)
-
+- [Welcome!](#welcome)
+- [Goals of the Netdata style guide](#goals-of-the-Netdata-style-guide)
+- [General principles](#general-principles)
+- [Tone and content](#tone-and-content)
+- [Language and grammar](#language-and-grammar)
+- [Markdown syntax](#markdown-syntax)
+- [Accessibility](#accessibility)
## Welcome
@@ -21,15 +20,14 @@ We’re here to make developers, sysadmins, and DevOps engineers better at their
We welcome contributions to Netdata's documentation. Begin with the [contributing to documentation guide](contributing-documentation.md), followed by this style guide.
-
## Goals of the Netdata style guide
An editorial style guide establishes standards for writing and maintaining documentation. At Netdata, we focus on the following principles:
-- Consistency
-- High-quality writing
-- Conciseness
-- Accessibility
+- Consistency
+- High-quality writing
+- Conciseness
+- Accessibility
These principles will make documentation better for everyone who wants to use Netdata, whether they're a beginner or an expert.
@@ -47,26 +45,26 @@ Here's a few key points to start with. Where relevant, they link to more in-dept
**[Tone and content](#tone-and-content)**:
-- Be [conversational and friendly](#conversational-and-friendly-tone).
-- Write [concisely](#write-concisely).
-- Don't use words like **here** when [creating hyperlinks](#use-informational-hyperlinks).
-- Don't mention [future releases or features](#mentioning-future-releases-or-features) in documentation.
+- Be [conversational and friendly](#conversational-and-friendly-tone).
+- Write [concisely](#write-concisely).
+- Don't use words like **here** when [creating hyperlinks](#use-informational-hyperlinks).
+- Don't mention [future releases or features](#mentioning-future-releases-or-features) in documentation.
**[Language and grammar](#language-and-grammar)**:
-- [Capitalize words](#capitalization) at the beginning of sentences, for proper nouns, and at the beginning of document titles and section headers.
-- Use [second person](#second-person)—"you" rather than "we"—when giving instructions.
-- Use [active voice](#active-voice) to make clear who or what is performing an action.
-- Always employ an [Oxford comma](#oxford-comma) on lists.
+- [Capitalize words](#capitalization) at the beginning of sentences, for proper nouns, and at the beginning of document titles and section headers.
+- Use [second person](#second-person)—"you" rather than "we"—when giving instructions.
+- Use [active voice](#active-voice) to make clear who or what is performing an action.
+- Always employ an [Oxford comma](#oxford-comma) on lists.
**[Markdown syntax](#markdown-syntax)**:
-- [Reference UI elements](#references-to-ui-elements) with bold text.
-- Use our [built-in syntax highlighter](#language-specific-syntax-highlighting-in-code-blocks) to improve the readability and usefulness of code blocks.
+- [Reference UI elements](#references-to-ui-elements) with bold text.
+- Use our [built-in syntax highlighter](#language-specific-syntax-highlighting-in-code-blocks) to improve the readability and usefulness of code blocks.
**[Accessibility](#accessibility)**:
-- Include [alt tags on images](#images).
+- Include [alt tags on images](#images).
---
@@ -134,10 +132,10 @@ Netdata's documentation should be consistent in the way it uses certain words, p
In text, follow the general [English standards](https://owl.purdue.edu/owl/general_writing/mechanics/help_with_capitals.html) for capitalization. In summary:
-- Capitalize the first word of every new sentence.
-- Don't use uppercase for emphasis. (Netdata is the BEST!)
-- Capitalize the names of brands, software, products, and companies according to their official guidelines. (Netdata, Docker, Apache, Nginx)
-- Avoid camel case (NetData) or all caps (NETDATA).
+- Capitalize the first word of every new sentence.
+- Don't use uppercase for emphasis. (Netdata is the BEST!)
+- Capitalize the names of brands, software, products, and companies according to their official guidelines. (Netdata, Docker, Apache, Nginx)
+- Avoid camel case (NetData) or all caps (NETDATA).
#### Capitalization of 'Netdata' and 'netdata'
@@ -163,11 +161,11 @@ Also, don't put a period (`.`) or colon (`:`) at the end of a title or header.
**Document titles**:
-| Capitalization | Not recommended | Recommended
+| Capitalization | Not recommended | Recommended
| --- | --- | ---
| Document titles | Getting Started Guide | Getting started guide
-| Page headings | Service Discovery and Auto-Detection: | Service discovery and auto-detection
-| Proper nouns | Install netdata with docker | Install Netdata with Docker
+| Page headings | Service Discovery and Auto-Detection: | Service discovery and auto-detection
+| Proper nouns | Install netdata with docker | Install Netdata with Docker
### Second person
@@ -234,7 +232,6 @@ Netdata can monitor RAM, disk I/O, MySQL queries per second and lm-sensors.
Netdata can monitor RAM, disk I/O, MySQL queries per second, and lm-sensors.
```
-
## Markdown syntax
The Netdata documentation uses the Markdown syntax for styling and formatting. If you're not familiar with how it works, please read the [Markdown introduction post](https://daringfireball.net/projects/markdown/) by its creator, followed by [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub.
@@ -254,10 +251,11 @@ Click on the **Sign in** button.
!!! note
Whenever possible, avoid using directional language to orient readers, because not every reader can use instructions like "look at the top-left corner" to find their way around an interface.
- If you feel that you must use directional language, perhaps use an [image](#images) (with proper alt text) instead.
-
- We're also working to establish standards for how we refer to certain elements of the Netdata's web interface. We'll include that in this style guide as soon as it's complete.
+```
+If you feel that you must use directional language, perhaps use an [image](#images) (with proper alt text) instead.
+We're also working to establish standards for how we refer to certain elements of the Netdata's web interface. We'll include that in this style guide as soon as it's complete.
+```
### Language-specific syntax highlighting in code blocks
@@ -265,7 +263,7 @@ Our documentation uses the [Highlight extension](https://facelessuser.github.io/
For a full list of languages, see [Pygment's supported languages](http://pygments.org/languages/). Netdata documentation will use the following for the most part: `c`, `python`, `js`, `shell`, `markdown`, `bash`, `css`, `html`, and `go`. If no language is specified, the Highlight extension doesn't apply syntax highlighting.
-Include the language directly after the three backticks (`` ``` ``) that start the code block. For highlighting C code, for example:
+Include the language directly after the three backticks (```` ``` ````) that start the code block. For highlighting C code, for example:
````
```c
@@ -298,7 +296,6 @@ Display line numbers by appending `linenums="1"` after the language declaration,
Netdata's documentation should be as accessible as possible to as many people as possible. While the rules about [tone and content](#tone-and-content) and [language and grammar](#language-and-grammar) are helpful to an extent, we also need some additional rules to improve the reading experience for all readers.
-
### Images
Images are an important component to documentation, which is why we have a few rules around their usage.
@@ -317,4 +314,4 @@ In Markdown, use the standard image syntax, `![]()`, and place the alt text betw
#### Images of text
-Don't use images of text, code samples, or terminal output. Instead, put that text content in a code block so that all devices can render it clearly and screen readers can parse it. \ No newline at end of file
+Don't use images of text, code samples, or terminal output. Instead, put that text content in a code block so that all devices can render it clearly and screen readers can parse it.