Docs: Update contributing guidelines (#8781)
* Update docs contributing * Remove other instances of docs.netdata.cloud * Rebase and add a few more updates * Cleanup, descriptions, grammar check * Fix link * Add text about Cloud docs, links, fixes for Zack
Joel Hans committed
May 19, 2020 at 12:56 UTC
000197b770d4eeae10c6841bc6228e07a690c524
7 files changed
+131
-168
docs/README.md
+7
-4
@@ -1,14 +1,17 @@
1
<!--
2
---
3
-title: "Read documentation on <https://docs.netdata.cloud>"
3
+title: "Read documentation on <https://learn.netdata.cloud>"
4
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/README.md
5
---
6
-->
7
8
-# Read documentation on <https://docs.netdata.cloud>
8
+# Read documentation on <https://learn.netdata.cloud>
9
10
-Welcome to the Netdata documentation! While you can read Netdata documentation here, or throughout the Netdata repository, our intention is that these pages are read on [docs.netdata.cloud](https://docs.netdata.cloud).
10
+Welcome to the Netdata documentation! While you can read Netdata documentation here, or throughout the Netdata
11
+repository, our intention is that these pages are read on [learn.netdata.cloud](https://learn.netdata.cloud).
12
12
-Links between documentation pages will work fine here, but the formatting may not be perfect, as our documentation site uses a few extra Markdown features that GitHub doesn't support natively. Other things might be missing or look less than perfect.
13
+Links between documentation pages will work fine here, but the formatting may not be perfect, as our documentation site
14
+uses a few extra Markdown features that GitHub doesn't support natively. Other things might be missing or look less than
15
+perfect.
16
17
Now get out there and build an exceptional infrastructure.
docs/contributing/contributing-documentation.md
+44
-96
@@ -1,25 +1,34 @@
1
<!--
2
title: "Contributing to documentation"
3
+description: "Want to contribute to Netdata's documentation? This guide will set you up with the tools to help others learn about health and performance monitoring."
4
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/contributing/contributing-documentation.md
5
-->
6
7
# Contributing to documentation
8
8
-We welcome contributions to Netdata's already extensive documentation, which we host at
9
-[docs.netdata.cloud](https://docs.netdata.cloud/) and store inside of the [main
10
-repository](https://github.com/netdata/netdata) on GitHub.
9
+We welcome contributions to Netdata's already extensive documentation. We store documentation related to our open source
10
+monitoring Agent inside of the [`netdata/netdata` repository](https://github.com/netdata/netdata) on GitHub.
11
+
12
+Documentation related to Netdata Cloud is stored in a private repository and is not currently open to community
13
+contributions.
14
+
15
+All our documentation is aggregated and published at [learn.netdata.cloud](https://learn.netdata.cloud/).
16
17
Like all contributing to all other aspects of Netdata, we ask that anyone who wants to help with documentation read and
18
abide by the [Contributor Convenant Code of Conduct](/CODE_OF_CONDUCT.md) and follow the
19
instructions outlined in our [Contributing document](/CONTRIBUTING.md).
20
16
-We also ask you to read our [documentation style guide](style-guide.md), which, while not complete, will give you some
17
-guidance on how we write and organize our documentation.
21
+We also ask you to read our [documentation style guide](/docs/contributing/style-guide.md), which, while not complete,
22
+will give you some guidance on how we write and organize our documentation.
23
24
All our documentation uses the Markdown syntax. If you're not familiar with how it works, please read the [Markdown
25
introduction post](https://daringfireball.net/projects/markdown/) by its creator, followed by [Mastering
26
Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub.
27
28
+Our [documentation site](https://learn.netdata.cloud/) is built with [Docusaurus](https://v2.docusaurus.io/). If you
29
+want to contribute to the generated documentation site, and have experience in React and/or Docusaurus itself, send us
30
+an email: [info@netdata.cloud](mailto:info@netdata.cloud).
31
+
32
## How contributing to the documentation works
33
34
There are two ways to contribute to Netdata's documentation:
@@ -27,12 +36,11 @@ There are two ways to contribute to Netdata's documentation:
36
1. Edit documentation [directly in GitHub](#edit-documentation-directly-on-github).
37
2. Download the repository and [edit documentation locally](#edit-documentation-locally).
38
30
-Editing in GitHub is a simpler process and is perfect for quick edits to a single document, such as fixing a typo or
31
-clarifying a confusing sentence.
39
+Editing in GitHub is a more straightforward process and is perfect for quick edits to a single document, such as fixing
40
+a typo or clarifying a confusing sentence.
41
33
-Editing locally is more complex, as you need to download the Netdata repository and build the documentation using
34
-`mkdocs`, but allows you to better organize complex projects. By building documentation locally, you can preview your
35
-work using a local web server before you submit your PR.
42
+Editing locally is more complicated but allows you to organize complex projects. By building documentation locally, you
43
+can preview your work using a local web server before you submit your PR.
44
45
In both cases, you'll finish by submitting a pull request (PR). Once you submit your PR, GitHub will initiate a number
46
of jobs, including a Netlify preview. You can use this preview to view the documentation site with your changes applied,
@@ -46,7 +54,7 @@ To continue, follow one of the paths below:
54
## Edit documentation directly on GitHub
55
56
Start editing documentation on GitHub by clicking the small pencil icon on any page on Netdata's [documentation
49
-site](https://docs.netdata.cloud/). You can find them at the top of every page.
57
+site](https://learn.netdata.cloud/). You can find them at the top of every page.
58
59
Clicking on this icon will take you to the associated page in the `netdata/netdata` repository. Then click the small
60
pencil icon on any documentation file (those ending in the `.md` Markdown extension) in the `netdata/netdata`
@@ -59,23 +67,19 @@ If you know where a file resides in the Netdata repository already, you can skip
67
documentation site and go directly to GitHub.
68
69
Once you've clicked the pencil icon on GitHub, you'll see a full Markdown version of the file. Make changes as you see
62
-fit. You can use the `Preview changes` button to ensure your Markdown syntax is working properly.
70
+fit. You can use the **Preview changes** button to ensure your Markdown syntax is working correctly.
71
64
-Under the `Propose file change` header, write in a descriptive title for your requested change. Beneath that, add a
65
-concise descrition of what you've changed and why you think it's important. Then, click the `Propose file change`
66
-button.
72
+Under the **Propose file change** header, write in a descriptive title for your requested change. Beneath that, add a
73
+concise description of what you've changed and why you think it's essential. Then, click the **Propose file change**
74
+button.
75
76
After you've hit that button, jump down to our instructions on [pull requests and
69
-cleanup](#pull-requests-and-final-steps) for your next steps.
70
-
71
-> This process will create a branch directly on the `netdata/netdata` repository, which then requires manual cleanup. If
72
-> you're going to make significant documentation contributions, or contribute often, we recommend the local editing
73
-> process just below.
77
+cleanup](#pull-requests-and-final-steps) for your next steps.
78
79
## Edit documentation locally
80
81
Editing documentation locally is the preferred method for complex changes, PRs that span across multiple documents, or
78
-those that change the styling or underlying functionality of the documentation.
82
+those that change the documentation's style or underlying functionality.
83
84
Here is the workflow for editing documentation locally. First, create a fork of the Netdata repository, if you don't
85
have one already. Visit the [Netdata repository](https://github.com/netdata/netdata) and click on the `Fork` button in
@@ -84,7 +88,7 @@ the upper-right corner of the window.
88
90
87
-GitHub will ask you where you want to clone the repository, and once finished you'll end up at the index of your forked
91
+GitHub will ask you where you want to clone the repository, and once finished, you end up at the index of your forked
92
Netdata repository. Clone your fork to your local machine:
93
94
```bash
@@ -95,107 +99,51 @@ You can now jump into the directory and explore Netdata's structure for yourself
99
100
### Understanding the structure of Netdata's documentation
101
98
-All of Netdata's documentation is stored within the repository itself, as close as possible to the code it corresponds
99
-to. Many sub-folders contain a `README.md` file, which is then used to populate the documentation about that
102
+All of Netdata's documentation is stored within the `netdata/netdata` repository, as close as possible to the code it
103
+corresponds to. Many sub-folders contain a `README.md` file, which is then used to populate the documentation about that
104
feature/component of Netdata.
105
102
-For example, the file at `packaging/installer/README.md` becomes `https://docs.netdata.cloud/packaging/installer/` and
103
-is our installation documentation. By co-locating it with quick-start installtion code, we ensure documentation is
104
-always tightly-knit with the functions it describes.
106
+For example, the installation documentation at `packaging/installer/README.md` becomes
107
+`https://learn.netdata.cloud/docs/agent/packaging/installer/`. By co-locating it with quick-start installation code, we
108
+ensure documentation is always tightly-knit with the functions it describes.
109
110
You might find other `.md` files within these directories. The `packaging/installer/` folder also contains `UPDATE.md`
107
-and `UNINSTALL.md`, which become `https://docs.netdata.cloud/packaging/installer/update/` and
108
-`https://docs.netdata.cloud/packaging/installer/uninstall/`, respectively.
111
+and `UNINSTALL.md`, which become `https://learn.netdata.cloud/docs/agent/packaging/installer/update/` and
112
+`https://learn.netdata.cloud/docs/agent/packaging/installer/uninstall/`, respectively.
113
114
If the documentation you're working on has a direct correlation to some component of Netdata, place it into the correct
115
folder and either name it `README.md` for generic documentation, or with another name for very specific instructions.
116
117
#### The `docs` folder
118
115
-At the root of the Netdata repository is a `docs/` folder. Inside this folder we place documentation that does not have
119
+At the root of the Netdata repository is a `docs/` folder. Inside this folder, we place documentation that does not have
120
a direct relationship to a specific component of Netdata.
121
118
-If the documentation you're working on doesn't have a direct relaionship to a component of Netdata, it can be placed in
122
+If the documentation you're working on doesn't have a direct relationship to a component of Netdata, you can place it in
123
this `docs/` folder.
124
125
+These documents will end up at the "root" of the Agent documentation at `https://learn.netdata.cloud/docs/agent/`. For
126
+example, the file at `docs/getting-started.md` becomes `https://learn.netdata.cloud/docs/agent/getting-started/`.
127
+
128
### Make your edits
129
130
Now that you're set up and understand where to find or create your `.md` file, you can now begin to make your edits.
131
Just use your favorite editor and keep in mind our [style guide](style-guide.md) as you work.
132
126
-If you add a new file to the documentation, you may need to modify the `buildyaml.sh` file to ensure it's added to the
127
-site's navigation. This is true for any file added to the `docs/` folder.
128
-
133
Be sure to periodically add/commit your edits so that you don't lose your work! We use version control software for a
134
reason.
135
132
-### Build the documentation
133
-
134
-Building the documentation periodically gives you a glimpse into the final product, and is generally required if you're
135
-making changes to the table of contents.
136
-
137
-We have a [netdata/docs Docker Image](https://hub.docker.com/r/netdata/os-test) available on the Docker Hub
138
-that greatly simplifies building the documentation on any [Docker](https://www.docker.com) supported platform.
139
-
140
-To build the docs using this image via Docker simply run the following commands in your shell:
141
-
142
-```bash
143
-cd /path/to/netdata
144
-docker run -i -t -v $PWD:/netdata netdata/docs
145
-```
146
-
147
-----
148
-
149
-if you are using a GNU/Linux based system for developing / contribiting to our documentation, you may build the
150
-docs with the provided Shell scripts in `./docs/generator/buildhtml.sh`. This requires GNU Bash and findutils
151
-as well as Python/pip and some Python packages `mkdocs` and `mkdocs-material` installed in your environment.
152
-
153
-Follow the [Python installation instructions](https://www.python.org/downloads/) for your machine.
154
-
155
-Use `pip`, which was installed alongside Python, to install `mkdocs` and `mkdocs-material`. Your operating system might
156
-force you to use `pip2` or `pip3` instead, depending on which version of Python you have installed.
157
-
158
-```bash
159
-pip install mkdocs mkdocs-material --user
160
-```
161
-
162
-> If you're having trouble with the installation of Python, `mkdocs`, or `mkdocs-material`, try looking into the
163
-> `mkdocs` [installation instructions](https://squidfunk.github.io/mkdocs-material/getting-started/#installation).
164
-
165
-When `pip` is finished installing, navigate to the root directory of the Netdata repository and run the documentation
166
-generator script.
167
-
168
-```bash
169
-sh docs/generator/buildhtml.sh
170
-```
171
-
172
-This process will take some time. Once finished, the built documentation site will be located at
173
-`docs/generator/build/`.
174
-
175
-### Run a local web server to test documentation
176
-
177
-The best way to view the documentation site you just built is to run a simple web server from the
178
-`docs/generator/build/` directory. So, navigate there and run a Python-based web server:
179
-
180
-```sh
181
-cd docs/generator/build/
182
-python3 -m http.server 20000
183
-```
184
-
185
-Feel free to replace the port number you want this web server to listen on (port `20000` in this case (only one higher
186
-than the agent!)).
187
-
188
-Open your web browser and navigate to `http://localhost:20000`. If you replaced the port earlier, change it here as
189
-well. You can now navigate through the documentation as you would on the live site!
190
-
136
## Pull requests and final steps
137
193
-When you're finished with your changes, add and commit them to your fork of the Netdata repository. Head over to GitHub
194
-to create your pull request (PR).
138
+When you finish with your changes, add and commit them to your fork of the Netdata repository. Head over to GitHub to
139
+create your pull request (PR).
140
196
-Once we receive your pull request (PR), we'll take time to read through it and assess it for correctness, conciseness,
141
+Once we receive your pull request (PR), the Netdata team reads through it and assesses it for correctness, conciseness,
142
and overall quality. We may point to specific sections and ask for additional information or other fixes.
143
144
+After merging your PR, we then rebuild the [documentation site](https://learn.netdata.cloud), which is built with
145
+[Docusaurus](https://v2.docusaurus.io/). You can then also delete your branch
146
+
147
## What's next
148
149
- Read up on the Netdata documentation [style guide](style-guide.md).
docs/contributing/style-guide.md
+71
-61
@@ -1,5 +1,6 @@
1
<!--
2
title: "Netdata style guide"
3
+description: "Learn about Netdata's writing and Markdown standards for documentation and educational content."
4
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/contributing/style-guide.md
5
-->
6
@@ -21,9 +22,9 @@ products.
22
## Welcome
23
24
Proper documentation is essential to the success of any open-source project. Netdata is no different. The health of our
24
-monitoring agent, and the community it's created, depends on this effort.
25
+monitoring agent and our community depends on this effort.
26
26
-We’re here to make developers, sysadmins, and DevOps engineers better at their jobs, after all!
27
+We're here to make developers, sysadmins, and DevOps engineers better at their jobs, after all!
28
29
We welcome contributions to Netdata's documentation. Begin with the [contributing to documentation
30
guide](contributing-documentation.md), followed by this style guide.
@@ -38,8 +39,8 @@ following principles:
39
- Conciseness
40
- Accessibility
41
41
-These principles will make documentation better for everyone who wants to use Netdata, whether they're a beginner or an
42
-expert.
42
+These principles will make the documentation better for everyone who wants to use Netdata, whether they're a beginner or
43
+an expert.
44
45
### Breaking the rules
46
@@ -53,21 +54,22 @@ process.
54
55
Yes, this style guide is pretty overwhelming! Establishing standards for a global community is never easy.
56
56
-Here's a few key points to start with. Where relevant, they link to more in-depth information about a given rule.
57
+Let's start with a few key points to start. Where relevant, these points link to more in-depth information about a given
58
+rule.
59
60
**[Tone and content](#tone-and-content)**:
61
62
- Be [conversational and friendly](#conversational-and-friendly-tone).
63
- Write [concisely](#write-concisely).
64
- Don't use words like **here** when [creating hyperlinks](#use-informational-hyperlinks).
63
-- Don't mention [future releases or features](#mentioning-future-releases-or-features) in documentation.
65
+- Don't mention [future releases or features](#mentioning-future-releases-or-features) in the documentation.
66
67
**[Language and grammar](#language-and-grammar)**:
68
69
- [Capitalize words](#capitalization) at the beginning of sentences, for proper nouns, and at the beginning of
70
document titles and section headers.
71
- Use [second person](#second-person)—"you" rather than "we"—when giving instructions.
70
-- Use [active voice](#active-voice) to make clear who or what is performing an action.
72
+- Use [active voice](#active-voice) to make clear who or what is acting.
73
- Always employ an [Oxford comma](#oxford-comma) on lists.
74
75
**[Markdown syntax](#markdown-syntax)**:
@@ -84,8 +86,7 @@ Here's a few key points to start with. Where relevant, they link to more in-dept
86
87
## Tone and content
88
87
-Netdata's documentation should be conversational, concise, and informational, without feeling formal. This isn't a
88
-textbook. It's a repository of information that should (on occasion!) encourage and excite its readers.
89
+Netdata's documentation should be conversational, concise, and informational, without feeling overly formal.
90
91
By following a few principles on tone and content we'll ensure more readers from every background and skill level will
92
learn as much as possible about Netdata's capabilities.
@@ -126,7 +127,7 @@ include as many hyperlinks as necessary to provide meaningful context.
127
Never assume readers of Netdata documentation are experts in Netdata's inner workings or health monitoring/performance
128
troubleshooting in general.
129
129
-If you claim that a task is easy and the reader struggles to complete it, they'll get discouraged.
130
+If you claim that a task is easy and the reader struggles to complete it, you may inadvertently discourage them.
131
132
If you perceive one option to be easier than another, be specific about how and why. For example, don't write,
133
"Netdata's one-line installer is the easiest way to install Netdata." Instead, you might want to say, "Netdata's
@@ -135,10 +136,13 @@ one-line installer requires fewer steps than manually installing from source."
136
### Avoid slang, metaphors, and jargon
137
138
A particular word, phrase, or metaphor you're familiar with might not translate well to the other cultures featured
138
-among Netdata's global community. It's recommended you avoid slang or colloquialisms in your writing.
139
+among Netdata's global community. We recommended you avoid slang or colloquialisms in your writing.
140
140
-If you must use industry jargon, such as "white-box monitoring," in a document, be sure to define the term as clearly
141
-and concisely as you can.
141
+In addition, don't use abbreviations that have not yet been defined in the document. See our section on
142
+[abbreviations](#abbreviations-acronyms-and-initialisms) for more information.
143
+
144
+If you must use industry jargon, such as "white-box monitoring," in a document, define the term as clearly and concisely
145
+as you can.
146
147
> White-box monitoring: Monitoring of a system or application based on the metrics it directly exposes, such as logs.
148
@@ -159,13 +163,13 @@ sections will outline the preferred usage for capitalization, point of view, act
163
164
### Capitalization
165
162
-In text, follow the general [English
163
-standards](https://owl.purdue.edu/owl/general_writing/mechanics/help_with_capitals.html) for capitalization. In summary:
166
+Follow the general [English standards](https://owl.purdue.edu/owl/general_writing/mechanics/help_with_capitals.html) for
167
+capitalization. In summary:
168
169
- Capitalize the first word of every new sentence.
170
- Don't use uppercase for emphasis. (Netdata is the BEST!)
171
- Capitalize the names of brands, software, products, and companies according to their official guidelines. (Netdata,
168
- Docker, Apache, Nginx)
172
+ Docker, Apache, NGINX)
173
- Avoid camel case (NetData) or all caps (NETDATA).
174
175
#### Capitalization of 'Netdata' and 'netdata'
@@ -177,14 +181,19 @@ However, if you are referring to a process, user, or group on a Linux system, yo
181
those are typically lowercased. In this case, you should also fence these terms in an inline code block: `` `netdata`
182
``.
183
180
-```
184
+```markdown
185
# Not recommended
186
The netdata agent, which spawns the netdata process, is actively maintained by netdata, inc.
187
188
# Recommended
185
-The Netdata agent, which spawns the `netdata` process, is actively maintained by Netdata, Inc.
189
+The Netdata Agent, which spawns the `netdata` process, is actively maintained by Netdata, Inc.
190
```
191
192
+#### Capitalization of 'Agent' and 'Cloud'
193
+
194
+Netdata is split into two products: the open source monitoring **Agent**, and the closed source web application
195
+**Cloud**. Because both Agent and Cloud are formal nouns, you should capitalize them.
196
+
197
#### Capitalization of document titles and page headings
198
199
Document titles and page headings should use sentence case. That means you should only capitalize the first word.
@@ -194,13 +203,17 @@ guidelines.
203
204
Also, don't put a period (`.`) or colon (`:`) at the end of a title or header.
205
197
-**Document titles**:
206
+```markdown
207
+# Not recommended
208
+Getting Started Guide
209
+Service Discovery and Auto-Detection:
210
+Install netdata with docker
211
199
-| Capitalization | Not recommended | Recommended
200
-| --- | --- | ---
201
-| Document titles | Getting Started Guide | Getting started guide
202
-| Page headings | Service Discovery and Auto-Detection: | Service discovery and auto-detection
203
-| Proper nouns | Install netdata with docker | Install Netdata with Docker
212
+# Recommended
213
+Getting started guide
214
+Service discovery and auto-detection
215
+Install Netdata with Docker
216
+```
217
218
### Second person
219
@@ -213,7 +226,7 @@ Avoid using "we," "I," "let's," and "us" in documentation whenever possible.
226
227
The "you" pronoun can also be implied, depending on your sentence structure.
228
216
-```
229
+```markdown
230
# Not recommended
231
To install Netdata, we should try the one-line installer...
232
@@ -226,10 +239,10 @@ To install Netdata, try the one-line installer...
239
240
### Active voice
241
229
-Use active voice instead of passive voice, because active voice is more concise and easier to understand.
242
+Use active voice instead of passive voice, because the active voice is more concise and easier to understand.
243
231
-When using voice, the subject of the sentence is performing the action. In passive voice, the subject is being acted
232
-upon. A famous example of passive voice is the phrase "mistakes were made."
244
+When using voice, the subject of the sentence is action. In passive voice, the subject is acted upon. A famous example
245
+of passive voice is the phrase "mistakes were made."
246
247
```plain
248
# Not recommended (passive)
@@ -242,7 +255,7 @@ When a metric triggers an alarm, Netdata sends a notification...
255
### Standard American spelling
256
257
While the Netdata team is mostly _not_ American, we still aspire to use American spelling whenever possible, as it is
245
-more commonly used within the monitoring industry.
258
+the standard for the monitoring industry.
259
260
### Clause order
261
@@ -257,8 +270,8 @@ Read the reference guide if you'd like to learn more about custom dashboards.
270
If you'd like to learn more about custom dashboards, read the reference guide.
271
```
272
260
-By placing the circumstance at the beginning of the sentence, those who don't want to follow can stop reading and move
261
-on. Those who _do_ want to read it are less likely to skip over the sentence.
273
+By placing the circumstance at the beginning of the sentence, readers can immediately know if they want to read more or
274
+follow a link.
275
276
### Oxford comma
277
@@ -276,7 +289,7 @@ Netdata can monitor RAM, disk I/O, MySQL queries per second, and lm-sensors.
289
### Abbreviations (acronyms and initialisms)
290
291
Use abbreviations (including [acronyms and initialisms](https://www.dictionary.com/e/acronym-vs-abbreviation/)) in
279
-documentation when one exists, when it's widely-accepted within the monitoring/sysadmin community, and when it improves
292
+documentation when one exists, when it's widely accepted within the monitoring/sysadmin community, and when it improves
293
the readability of a document.
294
295
When introducing an abbreviation to a document for the first time, give the reader both the spelled-out version and the
@@ -303,13 +316,22 @@ The Netdata documentation uses the Markdown syntax for styling and formatting. I
316
please read the [Markdown introduction post](https://daringfireball.net/projects/markdown/) by its creator, followed by
317
[Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub.
318
306
-We also leverage the power of the [Material theme for MkDocs](https://squidfunk.github.io/mkdocs-material/), which
307
-features several [extensions](https://squidfunk.github.io/mkdocs-material/extensions/admonition/), such as the ability
308
-to create notes, warnings, and collapsible blocks.
309
-
319
You can follow the syntax specified in the above resources for the majority of documents, but the following sections
320
specify a few particular use cases.
321
322
+### Linking between documents
323
+
324
+Documentation should link to relevant pages whenever it's relevant and provides valuable context to the reader. To
325
+ensure links function properly on both GitHub and our generated documentation on [Netdata
326
+Learn](https://learn.netdata.cloud/), links should always reference the full path to the document, beginning at the root
327
+of the Agent repository (`/`). Links should also always end with the filename of the destination document, ending in the
328
+`.md` extension.
329
+
330
+Avoid relative links or traversing up directories using `../`.
331
+
332
+For example, if you want to link to our installation guide, you should link to `/packaging/installer/README.md`. To
333
+reference the guide for increasing metrics storage, use `/docs/tutorials/longer-metrics-storage.md`.
334
+
335
### References to UI elements
336
337
If you need to instruct your reader to click a user interface (UI) element inside of a Netdata interface, you should
@@ -319,23 +341,17 @@ reference the label text of the link/button with Markdown's (`**bold text**`) ta
341
Click on the **Sign in** button.
342
```
343
322
-> Whenever possible, avoid using directional language to orient readers, because not every reader can use instructions
323
-> like "look at the top-left corner" to find their way around an interface.
344
+> ⚠️ Avoid using directional language to orient readers, because not every reader can use instructions like "look at the
345
+> top-left corner" to find their way around an interface.
346
347
If you feel that you must use directional language, perhaps use an [image](#images) (with proper alt text) instead.
348
327
-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.
328
-
349
### Language-specific syntax highlighting in code blocks
350
331
-Our documentation uses the [Highlight
332
-extension](https://facelessuser.github.io/pymdown-extensions/extensions/highlight/) for syntax highlighting. Highlight
333
-is fully compatible with [Pygments](http://pygments.org/), allowing you to highlight the syntax within code blocks in a
334
-number of interesting ways.
335
-
336
-For a full list of languages, see [Pygment's supported languages](http://pygments.org/languages/). Netdata documentation
337
-will use the following for the most part: `c`, `python`, `js`, `shell`, `markdown`, `bash`, `css`, `html`, and `go`. If
338
-no language is specified, the Highlight extension doesn't apply syntax highlighting.
351
+Our documentation site at [learn.netdata.cloud](https://learn.netdata.cloud) uses
352
+[Prism](https://v2.docusaurus.io/docs/markdown-features#syntax-highlighting) for syntax highlighting. Netdata
353
+documentation will use the following for the most part: `c`, `python`, `js`, `shell`, `markdown`, `bash`, `css`, `html`,
354
+and `go`. If no language is specified, Prism tries to guess the language based on its content.
355
356
Include the language directly after the three backticks (```` ``` ````) that start the code block. For highlighting C
357
code, for example:
@@ -360,15 +376,10 @@ inline char *health_stock_config_dir(void) {
376
}
377
```
378
363
-You can also use the Highlight and
364
-[SuperFences](https://facelessuser.github.io/pymdown-extensions/extensions/superfences/) extensions together to show
365
-line numbers or highlight specific lines.
366
-
367
-Display line numbers by appending `linenums="1"` after the language declaration, replacing `1` with the starting line
368
-number of your choice. Highlight lines by appending `hl_lines="2"`, replacing `2` with the line you'd like to highlight.
369
-Or, multiple lines: `hl_lines="1 2 4 12`.
379
+Prism also supports titles and line highlighting. See the [Docusaurus
380
+documentation](https://v2.docusaurus.io/docs/markdown-features#code-blocks) for more information.
381
371
-> Line numbers and highlights are not compatible with GitHub's Markdown parser, and thus will only be viewable on our
382
+> ⚠️ Line numbers and highlights are not compatible with GitHub's Markdown parser, and thus will only be viewable on our
383
> [documentation site](https://learn.netdata.cloud/). They should be used sparingly and only when necessary.
384
385
## Accessibility
@@ -379,10 +390,9 @@ some additional rules to improve the reading experience for all readers.
390
391
### Images
392
382
-Images are an important component to documentation, which is why we have a few rules around their usage.
383
-
384
-Perhaps most importantly, don't use only images to convey instructions. Each image should be accompanied by alt text and
385
-text-based instructions to ensure that every reader can access the information in the best way for them.
393
+We have a few rules around using images. Perhaps most importantly, don't use only images to convey instructions. Each
394
+image should be accompanied by alt text and text-based instructions to ensure that every reader can access the
395
+information in the best way for them.
396
397
#### Alt text
398
@@ -392,7 +402,7 @@ the image.
402
In Markdown, use the standard image syntax, `![]()`, and place the alt text between the brackets `[]`. Here's an example
403
using our logo:
404
395
-```
405
+```markdown
406
407
```
408
docs/step-by-step/step-99.md
+2
-2
@@ -15,8 +15,8 @@ our toolkit for health monitoring and performance troubleshooting.
15
But, perhaps more importantly, also that much closer to being an expert in the _fundamental skills behind health
16
monitoring and performance troubleshooting_, which you can take with you to any job or project.
17
18
-And that is the entire point of this tutorial, and Netdata's [documentation](https://docs.netdata.cloud) as a whole—give
19
-you every resource possible to help you build faster, more resilient systems, services, and applications.
18
+And that is the entire point of this tutorial, and Netdata's [documentation](https://learn.netdata.cloud) as a
19
+whole—give you every resource possible to help you build faster, more resilient systems, services, and applications.
20
21
Along the way, you learned how to:
22
docs/what-is-netdata.md
+2
-2
@@ -357,7 +357,7 @@ write a collector for your custom application using our [plugin API](/collectors
357
358
## Documentation
359
360
-The Netdata documentation is at <https://docs.netdata.cloud>, but you can also find each page inside of Netdata's
360
+The Netdata documentation is at <https://learn.netdata.cloud>, but you can also find each page inside of Netdata's
361
repository itself in Markdown (`.md`) files. You can find all our documentation by navigating the repository.
362
363
Here is a quick list of notable documents:
@@ -394,7 +394,7 @@ You can also find Netdata on:
394
395
## License
396
397
-Netdata is [GPLv3+](/LICENSE).
397
+Netdata is [GPLv3+](https://github.com/netdata/netdata/blob/master/LICENSE).
398
399
Netdata re-distributes other open-source tools and libraries. Please check the [third party licenses](/REDISTRIBUTED.md).
400
packaging/DISTRIBUTIONS.md
+2
-1
@@ -248,7 +248,8 @@ This is Netdata's TLS capability that incorporates encryption on the web server
248
|:---------------:|:------------------:|:----------:|:-------------------:|:----------:|:-----------:|:-----------:|
249
|Auto-detect|Auto-detect|Auto-detect|Auto-detect|NO|NO|NO|
250
251
-- **Flags/instructions to enable**: [Instructions for AWS Kinesis](https://docs.netdata.cloud/backends/aws_kinesis)
251
+- **Flags/instructions to enable**: [Instructions for AWS
252
+ Kinesis](https://learn.netdata.cloud/docs/agent/backends/aws_kinesis)
253
- **Flags to disable from source**: --disable-backend-kinesis
254
- **What packages required for auto-detect?**: `AWS SDK for C++`, `libcurl`, `libssl`, `libcrypto`
255
packaging/docker/README.md
+3
-2
@@ -207,8 +207,9 @@ services:
207
### Pass command line options to Netdata
208
209
Since we use an [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, you can provide
210
-[Netdata daemon command line options](https://docs.netdata.cloud/daemon/#command-line-options) such as the IP address
211
-Netdata will be running on, using the [command instruction](https://docs.docker.com/engine/reference/builder/#cmd).
210
+[Netdata daemon command line options](https://learn.netdata.cloud/docs/agent/daemon/#command-line-options) such as the
211
+IP address Netdata will be running on, using the [command
212
+instruction](https://docs.docker.com/engine/reference/builder/#cmd).
213
214
## Install the Agent using Docker Compose with SSL/TLS enabled HTTP Proxy
215