Update and improve the Netdata style guide (#10433)
* Continue work on style guide * Continuing work * Finish draft of style guide * Add changes to docs contribution guidelines * Copyedits and fix broken links * Add some Linux things to the style guide
Joel Hans committed
Jan 5, 2021 at 09:04 UTC
5e9fe54b38caab506abc7b5f8681e403aef8590b
2 files changed
+398
-362
docs/contributing/contributing-documentation.md
+68
-110
@@ -6,146 +6,104 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/contributin
6
7
# Contributing to documentation
8
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.
9
+We welcome contributions to Netdata's already extensive documentation.
10
12
-Documentation related to Netdata Cloud is stored in a private repository and is not currently open to community
13
-contributions.
11
+We store documentation related to the open-source Netdata Agent inside of the [`netdata/netdata`
12
+repository](https://github.com/netdata/netdata) on GitHub. Documentation related to Netdata Cloud is stored in a private
13
+repository and is not currently open to community contributions.
14
15
-All our documentation is aggregated and published at [learn.netdata.cloud](https://learn.netdata.cloud/).
15
+The Netdata team aggregates and publishes all documentation at [learn.netdata.cloud](https://learn.netdata.cloud/) using
16
+[Docusaurus](https://v2.docusaurus.io/) in a private GitHub repository.
17
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).
18
+## Before you get started
19
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.
20
+Anyone interested in contributing to documentation should first read the [Netdata style
21
+guide](/docs/contributing/style-guide.md) and the [Netdata Community Code of Conduct](/CODE_OF_CONDUCT.md).
22
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.
23
+Netdata's documentation uses Markdown syntax. If you're not familiar with Markdown, read the [Mastering
24
+Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on creating
25
+paragraphs, styled text, lists, tables, and more.
26
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).
27
+### Netdata's documentation structure
28
32
-## How contributing to the documentation works
29
+Netdata's documentation is separated into four sections.
30
34
-There are two ways to contribute to Netdata's documentation:
31
+- **Netdata**: Documents based on the actions users want to take, and solutions to their problems, such both the Netdata
32
+ Agent and Netdata Cloud.
33
+ - Stored in various subfolders of the [`/docs` folder](https://github.com/netdata/netdata/tree/master/docs) within the
34
+ `netdata/netdata` repository: `/docs/collect`, `/docs/configure`, `/docs/export`, `/docs/get`, `/docs/monitor`,
35
+ `/docs/overview`, `/docs/quickstart`, `/docs/store`, and `/docs/visualize`.
36
+ - Published at [`https://learn.netdata.cloud/docs`](https://learn.netdata.cloud/docs).
37
+- **Netdata Agent reference**: Reference documentation for the open-source Netdata Agent.
38
+ - Stored in various `.md` files within the `netdata/netdata` repository alongside the code responsible for that
39
+ feature. For example, the database engine's reference documentation is at `/database/engine/README.md`.
40
+ - Published at [`https://learn.netdata.cloud/docs/agent`](https://learn.netdata.cloud/docs/agent).
41
+- **Netdata Cloud reference**: Reference documentation for the closed-source Netdata Cloud web application.
42
+ - Stored in a private GitHub repository and not editable by the community.
43
+ - Published at [`https://learn.netdata.cloud/docs/cloud`](https://learn.netdata.cloud/docs/cloud).
44
+- **Guides**: Solutions-based articles for users who want instructions on completing a specific complex task using the
45
+ Netdata Agent and/or Netdata Cloud.
46
+ - Stored in the [`/docs/guides` folder](https://github.com/netdata/netdata/tree/master/docs/guides) within the
47
+ `netdata/netdata` repository. Organized into subfolders that roughly correlate with the core Netdata documentation.
48
+ - Published at [`https://learn.netdata.cloud/guides`](https://learn.netdata.cloud/guides).
49
36
-1. Edit documentation [directly in GitHub](#edit-documentation-directly-on-github).
37
-2. Download the repository and [edit documentation locally](#edit-documentation-locally).
50
+Generally speaking, if you want to contribute to the reference documentation for a specific Netdata Agent feature, find
51
+the appropriate `.md` file co-located with that feature. If you want to contribute documentation that spans features or
52
+products, or has no direct correlation with the existing directory structure, place it in the `/docs` folder within
53
+`netdata/netdata`.
54
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.
55
+## How to contribute
56
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.
57
+The easiest way to contribute to Netdata's documentation is to edit a file directly on GitHub. This is perfect for small
58
+fixes to a single document, such as fixing a typo or clarifying a confusing sentence.
59
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,
47
-which might help you catch any lingering issues.
60
+Click on the **Edit this page** button on any published document on [Netdata Learn](https://learn.netdata.cloud). Each
61
+page has two of these buttons: One beneath the table of contents, and another at the end of the document, which take you
62
+to GitHub's code editor. Make your suggested changes, keeping [Netdata style guide](/docs/contributing/style-guide.md)
63
+in mind, and use *Preview changes** button to ensure your Markdown syntax works as expected.
64
49
-To continue, follow one of the paths below:
65
+Under the **Commit changes** header, write descriptive title for your requested change. Click the **Commit changes**
66
+button to initiate your pull request (PR).
67
51
-- [Edit documentation directly in GitHub](#edit-documentation-directly-on-github)
52
-- [Edit documentation locally](#edit-documentation-locally)
68
+Jump down to our instructions on [PRs](#making-a-pull-request) for your next steps.
69
54
-## Edit documentation directly on GitHub
70
+### Edit locally
71
56
-Start editing documentation on GitHub by clicking the small pencil icon on any page on Netdata's [documentation
57
-site](https://learn.netdata.cloud/). You can find them at the top of every page.
72
+Editing documentation locally is the preferred method for complex changes that span multiple documents or change the
73
+documentation's style or structure.
74
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`
61
-repository.
62
-
63
-
65
-
66
-If you know where a file resides in the Netdata repository already, you can skip the step of beginning on the
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
70
-fit. You can use the **Preview changes** button to ensure your Markdown syntax is working correctly.
71
-
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
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
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
86
-the upper-right corner of the window.
75
+Create a fork of the Netdata Agent repository by visit the [Netdata repository](https://github.com/netdata/netdata) and
76
+clicking on the **Fork** button.
77
78
80
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:
81
+GitHub will ask you where you want to clone the repository. When finished, you end up at the index of your forked
82
+Netdata Agent repository. Clone your fork to your local machine:
83
84
```bash
85
git clone https://github.com/YOUR-GITHUB-USERNAME/netdata.git
86
```
87
98
-You can now jump into the directory and explore Netdata's structure for yourself.
99
-
100
-### Understanding the structure of Netdata's documentation
101
-
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
-
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`
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
-
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
-
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
-
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
-
136
-## Pull requests and final steps
88
+Create a new branch using `git checkout -b BRANCH-NAME`. Use your favorite text editor to make your changes, keeping the
89
+[Netdata style guide](/docs/contributing/style-guide.md) in mind. Add, commit, and push changes to your fork. When
90
+you're finished, visit the [Netdata Agent Pull requests](https://github.com/netdata/netdata/pulls) to create a new pull
91
+request based on the changes you made in the new branch of your fork.
92
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).
93
+## Making a pull request
94
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.
95
+Pull requests (PRs) should be concise and informative. See our [PR guidelines](/CONTRIBUTING.md#pr-guidelines) for
96
+specifics.
97
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
98
+- The title must follow the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) and be no more than ~50
99
+ characters.
100
+- The description should explain what was changed and why. Verify that you tested any code or processes that you are
101
+ trying to change.
102
147
-## What's next
103
+The Netdata team will review your PR and assesses it for correctness, conciseness, and overall quality. We may point to
104
+specific sections and ask for additional information or other fixes.
105
149
-- Read up on the Netdata documentation [style guide](style-guide.md).
106
+After merging your PR, the Netdata team rebuilds the [documentation site](https://learn.netdata.cloud) to publish the
107
+changed documentation.
108
109
[](<>)
docs/contributing/style-guide.md
+330
-252
@@ -1,165 +1,162 @@
1
<!--
2
title: "Netdata style guide"
3
-description: "Learn about Netdata's writing and Markdown standards for documentation and educational content."
3
+description: "The _Netdata style guide_ establishes editorial guidelines for all of Netdata's writing, including documentation, blog posts, in-product UX copy, and more."
4
custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/contributing/style-guide.md
5
-->
6
7
# Netdata style guide
8
9
-This in-progress style guide establishes editorial guidelines for anyone who wants to write documentation for Netdata
10
-products.
9
+The _Netdata style guide_ establishes editorial guidelines for any writing produced by the Netdata team or the Netdata
10
+community, including documentation, articles, in-product UX copy, and more. Both internal Netdata teams and external
11
+contributors to any of Netdata's open-source projects should reference and adhere to this style guide as much as
12
+possible.
13
12
-## Table of contents
14
+Netdata's writing should **empower** and **educate**. You want to help people understand Netdata's value, encourage them
15
+to learn more, and ultimately use Netdata's products to democratize monitoring in their organizations. To achieve these
16
+goals, your writing should be:
17
14
-- [Welcome!](#welcome)
15
-- [Goals of the Netdata style guide](#goals-of-the-Netdata-style-guide)
16
-- [General principles](#general-principles)
17
-- [Tone and content](#tone-and-content)
18
-- [Language and grammar](#language-and-grammar)
19
-- [Markdown syntax](#markdown-syntax)
20
-- [Accessibility](#accessibility)
18
+- **Clear**. Use simple words and sentences. Use strong, direct, and active language that encourages readers to action.
19
+- **Concise**. Provide solutions and answers as quickly as possible. Give users the information they need right now,
20
+ along with opportunities to learn more.
21
+- **Universal**. Think of yourself as a guide giving a tour of Netdata's products, features, and capabilities to a
22
+ diverse group of users. Write to reach the widest possible audience.
23
22
-## Welcome
24
+You can achieve these goals by reading and adhering to the principles outlined below.
25
24
-Proper documentation is essential to the success of any open-source project. Netdata is no different. The health of our
25
-monitoring agent and our community depends on this effort.
26
+## Voice and tone
27
27
-We're here to make developers, sysadmins, and DevOps engineers better at their jobs, after all!
28
+One way we write empowering, educational content is by using a consistent voice and an appropriate tone.
29
29
-We welcome contributions to Netdata's documentation. Begin with the [contributing to documentation
30
-guide](contributing-documentation.md), followed by this style guide.
30
+_Voice_ is like your personality, which doesn't really change day to day.
31
32
-## Goals of the Netdata style guide
32
+_Tone_ is how you express your personality. Your expression changes based on your attitude or mood, or based on who
33
+you're around. In writing, your reflect tone in your word choice, punctuation, sentence structure, or even the use of
34
+emoji.
35
34
-An editorial style guide establishes standards for writing and maintaining documentation. At Netdata, we focus on the
35
-following principles:
36
+The same idea about voice and tone applies to organizations, too. Our voice shouldn't change much between two pieces of
37
+content, no matter who wrote each, but the tone might be quite different based on who we think is reading.
38
37
-- Consistency
38
-- High-quality writing
39
-- Conciseness
40
-- Accessibility
39
+For example, a [blog post](https://www.netdata.cloud/blog/) and a [press release](https://www.netdata.cloud/news/)
40
+should have a similar voice, despite most often being written by different people. However, blog posts are relaxed and
41
+witty, while press releases are focused and academic. You won't see any emoji in a press release.
42
42
-These principles will make the documentation better for everyone who wants to use Netdata, whether they're a beginner or
43
-an expert.
43
+### Voice
44
45
-### Breaking the rules
45
+Netdata's voice is authentic, passionate, playful, and respectful.
46
47
-None of the rules described in this style guide are absolute. **We welcome rule-breaking if it creates better, more
48
-accessible documentation.**
47
+- **Authentic** writing is honest and fact-driven. Focus on Netdata's strength while accurately communicating what
48
+ Netdata can and cannot do, and emphasize technical accuracy over hard sells and marketing jargon.
49
+- **Passionate** writing is strong and direct. Be a champion for the product or feature you're writing about, and let
50
+ your unique personality and writing style shine.
51
+- **Playful** writing is friendly, thoughtful, and engaging. Don't take yourself too seriously, as long as it's not at
52
+ the expense of Netdata or any of its users.
53
+- **Respectful** writing treats people the way you want to be treated. Prioritize giving solutions and answers as
54
+ quickly as possible.
55
50
-But be aware that Netdata staff or community members may ask you to justify your rule-breaking during the PR review
51
-process.
56
+### Tone
57
53
-## General principles
58
+Netdata's tone is fun and playful, but clarity and conciseness comes first. We also tend to be informal, and aren't
59
+afraid of a playful joke or two.
60
55
-Yes, this style guide is pretty overwhelming! Establishing standards for a global community is never easy.
61
+While we have general standards for voice and tone, we do want every individual's unique writing style to reflect in
62
+published content.
63
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.
64
+## Universal communication
65
60
-**[Tone and content](#tone-and-content)**:
66
+Netdata is a global company in every sense, with employees, contributors, and users from around the world. We strive to
67
+communicate in a way that is clear and easily understood by everyone.
68
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).
65
-- Don't mention [future releases or features](#mentioning-future-releases-or-features) in the documentation.
69
+Here are some guidelines, pointers, and questions to be aware of as you write to ensure your writing is universal. Some
70
+of these are expanded into individual sections in the [language, grammar, and
71
+mechanics](#language-grammar-and-mechanics) section below.
72
67
-**[Language and grammar](#language-and-grammar)**:
73
+- Would this language make sense to someone who doesn't work here?
74
+- Could someone quickly scan this document and understand the material?
75
+- Create an information hierarchy with key information presented first and clearly called out to improve scannability.
76
+- Avoid directional language like "sidebar on the right of the page" or "header at the top of the page" since
77
+ presentation elements may adapt for devices.
78
+- Use descriptive links rather than "click here" or "learn more".
79
+- Include alt text for images and image links.
80
+- Ensure any information contained within a graphic element is also available as plain text.
81
+- Avoid idioms that may not be familiar to the user or that may not make sense when translated.
82
+- Avoid local, cultural, or historical references that may be unfamiliar to users.
83
+- Prioritize active, direct language.
84
+- Avoid referring to someone's age unless it is directly relevant; likewise, avoid referring to people with age-related
85
+ descriptors like "young" or "elderly."
86
+- Avoid disability-related idioms like "lame" or "falling on deaf ears." Don't refer to a person's disability unless
87
+ it’s directly relevant to what you're writing.
88
+- Don't call groups of people "guys." Don't call women "girls."
89
+- Avoid gendered terms in favor of neutral alternatives, like "server" instead of "waitress" and "businessperson"
90
+ instead of "businessman."
91
+- When writing about a person, use their communicated pronouns. When in doubt, just ask or use their name. It's OK to
92
+ use "they" as a singular pronoun.
93
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.
72
-- Use [active voice](#active-voice) to make clear who or what is acting.
73
-- Always employ an [Oxford comma](#oxford-comma) on lists.
94
+> Some of these guidelines were adapted from MailChimp under the Creative Commons license.
95
75
-**[Markdown syntax](#markdown-syntax)**:
96
+## Language, grammar, and mechanics
97
77
-- [Reference UI elements](#references-to-ui-elements) with bold text.
78
-- Use our [built-in syntax highlighter](#language-specific-syntax-highlighting-in-code-blocks) to improve the
79
- readability and usefulness of code blocks.
98
+**T/K**
99
81
-**[Accessibility](#accessibility)**:
100
+If you're writing about Netdata for an external publication, such as a guest blog post, follow that publication's
101
+style guide or standards, if they have one published.
102
83
-- Include [alt tags on images](#images).
84
-
85
----
86
-
87
-## Tone and content
88
-
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.
93
-
94
-### Conversational and friendly tone
95
-
96
-Netdata's documentation should be conversational and friendly. To borrow from Google's fantastic [developer style
97
-guide](https://developers.google.com/style/tone):
98
-
99
-> Try to sound like a knowledgeable friend who understands what the developer wants to do.
100
-
101
-Feel free to let some of your personality show! Documentation can be highly professional without being dry, formal, or
102
-overly instructive.
103
+### Active voice
104
104
-### Write concisely
105
+Active voice is more concise and easier to understand compared to passive voice. When using active voice, the subject of
106
+the sentence is action. In passive voice, the subject is acted upon. A famous example of passive voice is the phrase
107
+"mistakes were made."
108
106
-You should always try to use as few words as possible to explain a particular feature, configuration, or process.
107
-Conciseness leads to more accurate and understandable writing.
109
+| | |
110
+|-----------------|---------------------------------------------------------------------------------------------|
111
+| Not recommended | When an alarm is triggered by a metric, a notification is sent by Netdata. |
112
+| **Recommended** | When a metric triggers an alarm, Netdata sends a notification to your preferred endpoint. |
113
109
-### Use informational hyperlinks
114
+### Second person
115
111
-Hyperlinks should clearly state its destination. Don't use words like "here" to describe where a link will take your
112
-reader.
116
+Use the second person ("you") to give instructions or "talk" directly to users.
117
114
-```markdown
115
-# Not recommended
116
-To install Netdata, click [here](/packaging/installer/README.md).
118
+In these situations, avoid "we," "I," "let's," and "us," particularly in documentation. The "you" pronoun can also be
119
+implied, depending on your sentence structure.
120
118
-# Recommended
119
-To install Netdata, read our [installation instructions](/packaging/installer/README.md).
120
-```
121
+One valid exception is when a member of the Netdata team or community wants to write about said team or community.
122
122
-In general, guides should include fewer hyperlinks to keep the reader focused on the task at hand. Documentation should
123
-include as many hyperlinks as necessary to provide meaningful context.
123
+| | |
124
+|--------------------------------|-------------------------------------------------------------------------------------------|
125
+| Not recommended | To install Netdata, we should try the one-line installer... |
126
+| **Recommended** | To install Netdata, you should try the one-line installer... |
127
+| **Recommended**, implied "you" | To install Netdata, try the one-line installer... |
128
125
-### Avoid words like "easy" or "simple"
129
+### "Easy" or "simple"
130
127
-Never assume readers of Netdata documentation are experts in Netdata's inner workings or health monitoring/performance
128
-troubleshooting in general.
131
+Using words that imply the complexity of a task or feature goes against our policy of [universal
132
+communication](#universal-communication). If you claim that a task is easy and the reader struggles to complete it, you
133
+may inadvertently discourage them.
134
130
-If you claim that a task is easy and the reader struggles to complete it, you may inadvertently discourage them.
135
+However, if you give users two options and want to relay that one option is genuinely less complex than another, be
136
+specific about how and why.
137
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
134
-one-line installer requires fewer steps than manually installing from source."
138
+For example, don't write, "Netdata's one-line installer is the easiest way to install Netdata." Instead, you might want
139
+to say, "Netdata's one-line installer requires fewer steps than manually installing from source."
140
136
-### Avoid slang, metaphors, and jargon
141
+### Slang, metaphors, and jargon
142
143
A particular word, phrase, or metaphor you're familiar with might not translate well to the other cultures featured
144
among Netdata's global community. We recommended you avoid slang or colloquialisms in your writing.
145
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.
146
+In addition, don't use abbreviations that have not yet been defined in the content. See our section on
147
+[abbreviations](#abbreviations-acronyms-and-initialisms) for additional guidance.
148
149
-Avoid emojis whenever possible for the same reasons—they can be difficult to understand immediately and don't translate
150
-well.
149
+If you must use industry jargon, such as "mean time to resolution," define the term as clearly and concisely as you can.
150
152
-### Mentioning future releases or features
151
+> Netdata helps you reduce your organization's mean time to resolution (MTTR), which is the average time the responsible
152
+> team requires to repair a system and resolve an ongoing incident.
153
154
-Documentation is meant to describe the product as-is, not as it will be or could be in the future. Netdata documentation
155
-generally avoids talking about future features or products, even if we know they are inevitable.
154
+### Spelling
155
157
-An exception can be made for documenting beta features that are subject to change with further development.
158
-
159
-## Language and grammar
156
+While the Netdata team is mostly _not_ American, we still aspire to use American spelling whenever possible, as it is
157
+the standard for the monitoring industry.
158
161
-Netdata's documentation should be consistent in the way it uses certain words, phrases, and grammar. The following
162
-sections will outline the preferred usage for capitalization, point of view, active voice, and more.
159
+See the [word list](#word-list) for spellings of specific words.
160
161
### Capitalization
162
@@ -172,27 +169,16 @@ capitalization. In summary:
169
Docker, Apache, NGINX)
170
- Avoid camel case (NetData) or all caps (NETDATA).
171
175
-#### Capitalization of 'Netdata' and 'netdata'
176
-
172
Whenever you refer to the company Netdata, Inc., or the open-source monitoring agent the company develops, capitalize
173
**Netdata**.
174
180
-However, if you are referring to a process, user, or group on a Linux system, you should not capitalize, as by default
181
-those are typically lowercased. In this case, you should also fence these terms in an inline code block: `` `netdata`
182
-``.
183
-
184
-```markdown
185
-# Not recommended
186
-The netdata agent, which spawns the netdata process, is actively maintained by netdata, inc.
187
-
188
-# Recommended
189
-The Netdata Agent, which spawns the `netdata` process, is actively maintained by Netdata, Inc.
190
-```
175
+However, if you are referring to a process, user, or group on a Linux system, use lowercase and fence the word in an
176
+inline code block: `` `netdata` ``.
177
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.
178
+| | |
179
+|-----------------|------------------------------------------------------------------------------------------------|
180
+| Not recommended | The netdata agent, which spawns the netdata process, is actively maintained by netdata, inc. |
181
+| **Recommended** | The Netdata Agent, which spawns the `netdata` process, is actively maintained by Netdata, Inc. |
182
183
#### Capitalization of document titles and page headings
184
@@ -203,150 +189,246 @@ guidelines.
189
190
Also, don't put a period (`.`) or colon (`:`) at the end of a title or header.
191
206
-```markdown
207
-# Not recommended
208
-Getting Started Guide
209
-Service Discovery and Auto-Detection:
210
-Install netdata with docker
211
-
212
-# Recommended
213
-Getting started guide
214
-Service discovery and auto-detection
215
-Install Netdata with Docker
216
-```
192
+| | |
193
+|-----------------|-----------------------------------------------------------------------------------------------------|
194
+| Not recommended | Getting Started Guide <br />Service Discovery and Auto-Detection: <br />Install netdata with docker |
195
+| **Recommended** | Getting started guide <br />Service discovery and auto-detection <br />Install Netdata with Docker |
196
218
-### Second person
197
+### Abbreviations (acronyms and initialisms)
198
220
-When writing documentation, you should use the second person ("you") to give instructions. When using the second person,
221
-you give the impression that you're personally leading your reader through the steps or tips in question.
199
+Use abbreviations (including [acronyms and initialisms](https://www.dictionary.com/e/acronym-vs-abbreviation/)) in
200
+documentation when one exists, when it's widely accepted within the monitoring/sysadmin community, and when it improves
201
+the readability of a document.
202
223
-See how that works? It's a core part of making Netdata's documentation feel welcoming to all.
203
+When introducing an abbreviation to a document for the first time, give the reader both the spelled-out version and the
204
+shortened version at the same time. For example:
205
225
-Avoid using "we," "I," "let's," and "us" in documentation whenever possible.
206
+> Use Netdata to monitor Extended Berkeley Packet Filter (eBPF) metrics in real-time.
207
227
-The "you" pronoun can also be implied, depending on your sentence structure.
208
+After you define an abbreviation, don't switch back and forth. Use only the abbreviation for the rest of the document.
209
229
-```markdown
230
-# Not recommended
231
-To install Netdata, we should try the one-line installer...
210
+You can also use abbreviations in a document's title to keep the title short and relevant. If you do this, you should
211
+still introduce the spelled-out name alongside the abbreviation as soon as possible.
212
233
-# Recommended
234
-To install Netdata, you should try the one-line installer...
213
+### Clause order
214
236
-# Recommended, implied "you"
237
-To install Netdata, try the one-line installer...
238
-```
215
+When instructing users to take action, give them the context first. By placing the context in an initial clause at the
216
+beginning of the sentence, users can immediately know if they want to read more, follow a link, or skip ahead.
217
240
-### Active voice
218
+| | |
219
+|-----------------|--------------------------------------------------------------------------------|
220
+| Not recommended | Read the reference guide if you'd like to learn more about custom dashboards. |
221
+| **Recommended** | If you'd like to learn more about custom dashboards, read the reference guide. |
222
242
-Use active voice instead of passive voice, because the active voice is more concise and easier to understand.
223
+### Oxford comma
224
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."
225
+The Oxford comma is the comma used after the second-to-last item in a list of three or more items. It appears just
226
+before "and" or "or."
227
247
-```plain
248
-# Not recommended (passive)
249
-When an alarm is triggered by a metric, a notification is sent by Netdata...
228
+| | |
229
+|-----------------|------------------------------------------------------------------------------|
230
+| Not recommended | Netdata can monitor RAM, disk I/O, MySQL queries per second and lm-sensors. |
231
+| **Recommended** | Netdata can monitor RAM, disk I/O, MySQL queries per second, and lm-sensors. |
232
251
-# Recommended (active)
252
-When a metric triggers an alarm, Netdata sends a notification...
253
-```
233
+### Future releases or features
234
255
-### Standard American spelling
235
+Do not mention future releases or upcoming features in writing unless they have been previously communicated via a
236
+public roadmap.
237
257
-While the Netdata team is mostly _not_ American, we still aspire to use American spelling whenever possible, as it is
258
-the standard for the monitoring industry.
238
+In particular, documentation must describe, as accurately as possible, the Netdata Agent _as of the [latest
239
+commit](https://github.com/netdata/netdata/commits/master) in the GitHub repository_. For Netdata Cloud, documentation
240
+must reflect the _current state of [production](https://app.netdata.cloud).
241
260
-### Clause order
242
+### Informational links
243
262
-If you want to instruct your reader to take some action in a particular circumstance, such as optional steps, the
263
-beginning of the sentence should indicate that circumstance.
244
+Every link should clearly state its destination. Don't use words like "here" to describe where a link will take your
245
+reader.
246
265
-```markup
266
-# Not recommended
267
-Read the reference guide if you'd like to learn more about custom dashboards.
247
+| | |
248
+|-----------------|-------------------------------------------------------------------------------------------|
249
+| Not recommended | To install Netdata, click [here](/packaging/installer/README.md). |
250
+| **Recommended** | To install Netdata, read the [installation instructions](/packaging/installer/README.md). |
251
269
-# Recommended
270
-If you'd like to learn more about custom dashboards, read the reference guide.
271
-```
252
+Use links as often as required to provide necessary context. Blog posts and guides require less hyperlinks than
253
+documentation. See the section on [linking between documentation](#linking-between-documentation) for guidance on the
254
+Markdown syntax and path structure of inter-documentation links.
255
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.
256
+### Contractions
257
276
-### Oxford comma
258
+Contractions like "you'll" or "they're" are acceptable in most Netdata writing. They're both authentic and playful, and
259
+reinforce the idea that you, as a writer, are guiding users through a particular idea, process, or feature.
260
278
-The Oxford comma is the comma used after the second-to-last item in a list of three or more items. It appears just
279
-before "and" or "or."
261
+Contractions are generally not used in press releases or other media engagements.
262
281
-```markup
282
-# Not recommended
283
-Netdata can monitor RAM, disk I/O, MySQL queries per second and lm-sensors.
263
+### Emoji
264
285
-# Recommended
286
-Netdata can monitor RAM, disk I/O, MySQL queries per second, and lm-sensors.
287
-```
265
+Emoji can add fun and character to your writing, but should be used sparingly and only if it matches the content's tone
266
+and desired audience.
267
289
-### Abbreviations (acronyms and initialisms)
268
+## Technical/Linux standards
269
291
-Use abbreviations (including [acronyms and initialisms](https://www.dictionary.com/e/acronym-vs-abbreviation/)) in
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.
270
+Configuration or maintenance of the Netdata Agent requires some system administration skills, such as navigating
271
+directories, editing files, or starting/stopping/restarting services. Certain processes
272
295
-When introducing an abbreviation to a document for the first time, give the reader both the spelled-out version and the
296
-shortened version at the same time. For example:
273
+### Switching Linux users
274
+
275
+Netdata documentation often suggests that users switch from their normal user to the `netdata` user to run specific
276
+commands. Use the following command to instruct users to make the switch:
277
298
-```markup
299
-You can use Netdata to monitor Extended Berkeley Packet Filter (eBPF) metrics in real-time.
278
+```bash
279
+sudo su -s /bin/bash netdata
280
```
281
302
-After you define an abbreviation, don't switch back and forth—use only the abbreviation for the rest of the document.
282
+### Hostname/IP address of a node
283
304
-You can also use abbreviations in a document's title to keep the title short and relevant. If you do this, you should
305
-still introduce the spelled-out name alongside the abbreviation as soon as possible.
284
+Use `NODE` instead of an actual or example IP address/hostname when referencing the process of navigating to a dashboard
285
+or API endpoint in a browser.
286
307
-```markup
308
-# Monitoring HDFS with Netdata
287
+| | |
288
+|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
289
+| Not recommended | Navigate to `http://example.com:19999` in your browser to see Netdata's dashboard. <br />Navigate to `http://203.0.113.0:19999` in your browser to see Netdata's dashboard. |
290
+| **Recommended** | Navigate to `http://NODE:19999` in your browser to see Netdata's dashboard. |
291
310
-You can now use Netdata to collect real-time metrics from your Hadoop Distributed File System (HDFS).
311
-```
292
+If you worry that `NODE` doesn't provide enough context for the user, particularly in documentation or guides designed
293
+for beginners, you can provide an explanation:
294
+
295
+> With the Netdata Agent running, visit `http://NODE:19999/api/v1/info` in your browser, replacing `NODE` with the IP
296
+> address or hostname of your Agent.
297
+
298
+### Paths and running commands
299
+
300
+When instructing users to run a Netdata-specific command, don't assume the path to said command, because not every
301
+Netdata Agent installation will have commands under the same paths. When applicable, help them navigate to the correct
302
+path, providing a recommendation or instructions on how to view the running configuration, which includes the correct
303
+paths.
304
+
305
+For example, the [configuration](/docs/configure/nodes.md) doc first teaches users how to find the Netdata config
306
+directory and navigate to it, then runs commands from the `/etc/netdata` path so that the instructions are more
307
+universal.
308
+
309
+Don't include full paths, beginning from the system's root (`/`), as these might not work on certain systems.
310
+
311
+| | |
312
+|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
313
+| Not recommended | Use `edit-config` to edit Netdata's configuration: `sudo /etc/netdata/edit-config netdata.conf`. |
314
+| **Recommended** | Use `edit-config` to edit Netdata's configuration by first navigating to your [Netdata config directory](/docs/configure/nodes.md#the-netdata-config-directory), which is typically at `/etc/netdata`, then running `sudo edit-config netdata.conf`. |
315
+
316
+### `sudo`
317
+
318
+Include `sudo` before a command if you believe most Netdata users will need to elevate privileges to run it. This makes
319
+our writing more universal, and users on `sudo`-less systems are generally already aware that they need to run commands
320
+differently.
321
+
322
+For example, most users need to use `sudo` with the `edit-config` script, because the Netdata config directory is owned
323
+by the `netdata` user. Same goes for restarting the Netdata Agent with `systemctl`.
324
+
325
+| | |
326
+|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------|
327
+| Not recommended | Run `edit-config netdata.conf` to configure the Netdata Agent. <br />Run `systemctl restart netdata` to restart the Netdata Agent. |
328
+| **Recommended** | Run `sudo edit-config netdata.conf` to configure the Netdata Agent. <br />Run `sudo systemctl restart netdata` to restart the Netdata Agent. |
329
330
## Markdown syntax
331
315
-The Netdata documentation uses the Markdown syntax for styling and formatting. If you're not familiar with how it works,
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.
332
+Netdata's documentation uses Markdown syntax.
333
+
334
+If you're not familiar with Markdown, read the [Mastering
335
+Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on creating
336
+paragraphs, styled text, lists, tables, and more.
337
+
338
+The following sections describe situations in which a specific syntax is required.
339
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.
340
+### Syntax standards (`remark-lint`)
341
322
-### Linking between documents
342
+The Netdata team uses [`remark-lint`](https://github.com/remarkjs/remark-lint) for Markdown code styling.
343
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.
344
+- Use a maximum of 120 characters per line.
345
+- Begin headings with hashes, such as `# H1 heading`, `## H2 heading`, and so on.
346
+- Use `_` for italics/emphasis.
347
+- Use `**` for bold.
348
+- Use dashes `-` to begin an unordered list, and put a single space after the dash.
349
+- Tables should be padded so that pipes line up vertically with added whitespace.
350
+
351
+If you want to see all the settings, open the
352
+[`remarkrc.js`](https://github.com/netdata/netdata/blob/master/.remarkrc.js) file in the `netdata/netdata` repository.
353
+
354
+### Frontmatter
355
+
356
+Every document must begin with frontmatter, followed by an H1 (`#`) heading.
357
+
358
+Unlike typical Markdown frontmatter, Netdata uses HTML comments (`<!--`, `-->`) to begin and end the frontmatter block.
359
+These HTML comments are later converted into typical frontmatter syntax when building [Netdata
360
+Learn](https://learn.netdata.cloud).
361
+
362
+Frontmatter _must_ contain the following variables:
363
+
364
+- A `title` that quickly and distinctly describes the document's content.
365
+- A `description` that elaborates on the purpose or goal of the document using no less than 100 characters and no more
366
+ than 155 characters.
367
+- A `custom_edit_url` that links directly to the GitHub URL where another user could suggest additional changes to the
368
+ published document.
369
+
370
+Some documents, like the Ansible guide and others in the `/docs/guides` folder, require an `image` variable as well. In
371
+this case, replace `/docs` with `/img/seo`, and then rebuild the remainder of the path to the document in question. End
372
+the path with `.png`. A member of the Netdata team will assist in creating the image when publishing the content.
373
+
374
+For example, here is the frontmatter for the guide about [deploying the Netdata Agent with
375
+Ansible](https://learn.netdata.cloud/guides/deploy/ansible).
376
+
377
+```markdown
378
+<!--
379
+title: Deploy Netdata with Ansible
380
+description: "Deploy an infrastructure monitoring solution in minutes with the Netdata Agent and Ansible. Use and customize a simple playbook for monitoring as code."
381
+image: /img/seo/guides/deploy/ansible.png
382
+custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/deploy/ansible.md
383
+-->
384
+
385
+# Deploy Netdata with Ansible
386
+
387
+...
388
+```
389
330
-Avoid relative links or traversing up directories using `../`.
390
+Questions about frontmatter in documentation? [Ask on our community
391
+forum](https://community.netdata.cloud/c/blog-posts-and-articles/6).
392
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/guides/longer-metrics-storage.md`.
393
+### Linking between documentation
394
+
395
+Documentation should link to relevant pages whenever it's relevant and provides valuable context to the reader.
396
+
397
+Links should always reference the full path to the document, beginning at the root of the Netdata Agent repository
398
+(`/`), and ending with the `.md` file extension. Avoid relative links or traversing up directories using `../`.
399
+
400
+For example, if you want to link to our node configuration document, link to `/docs/configure/nodes.md`. To reference
401
+the guide for deploying the Netdata Agent with Ansible, link to `/docs/guides/deploy/ansible.md`.
402
403
### References to UI elements
404
337
-If you need to instruct your reader to click a user interface (UI) element inside of a Netdata interface, you should
338
-reference the label text of the link/button with Markdown's (`**bold text**`) tag.
405
+When referencing a user interface (UI) element in Netdata, reference the label text of the link/button with Markdown's
406
+(`**bold text**`) tag.
407
408
```markdown
341
-Click on the **Sign in** button.
409
+Click the **Sign in** button.
410
```
411
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.
412
+Avoid directional language whenever possible. Not every user can use instructions like "look at the top-left corner" to
413
+find their way around an interface, and interfaces often change between devices. If you must use directional language,
414
+try to supplement the text with an [image](#images).
415
+
416
+### Images
417
347
-If you feel that you must use directional language, perhaps use an [image](#images) (with proper alt text) instead.
418
+Don't rely on images to convey features, ideas, or instructions. Accompany every image with descriptive alt text.
419
349
-### Language-specific syntax highlighting in code blocks
420
+In Markdown, use the standard image syntax, `![]()`, and place the alt text between the brackets `[]`. Here's an example
421
+using our logo:
422
+
423
+```markdown
424
+
425
+```
426
+
427
+Reference in-product text, code samples, and terminal output with actual text content, not screen captures or other
428
+images. Place the text in an appropriate element, such as a blockquote or code block, so all users can parse the
429
+information.
430
+
431
+### Syntax highlighting
432
433
Our documentation site at [learn.netdata.cloud](https://learn.netdata.cloud) uses
434
[Prism](https://v2.docusaurus.io/docs/markdown-features#syntax-highlighting) for syntax highlighting. Netdata
@@ -379,36 +461,32 @@ inline char *health_stock_config_dir(void) {
461
Prism also supports titles and line highlighting. See the [Docusaurus
462
documentation](https://v2.docusaurus.io/docs/markdown-features#code-blocks) for more information.
463
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
386
-
387
-Netdata's documentation should be as accessible as possible to as many people as possible. While the rules about [tone
388
-and content](#tone-and-content) and [language and grammar](#language-and-grammar) are helpful to an extent, we also need
389
-some additional rules to improve the reading experience for all readers.
390
-
391
-### Images
392
-
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
-
399
-Provide alt text for every image you include in Netdata's documentation. It should summarize the intent and content of
400
-the image.
401
-
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
-
405
-```markdown
406
-
407
-```
408
-
409
-#### Images of text
410
-
411
-Don't use images of text, code samples, or terminal output. Instead, put that text content in a code block so that all
412
-devices can render it clearly and screen readers can parse it.
464
+## Word list
465
+
466
+The following tables describe the standard spelling, capitalization, and usage of words found in Netdata's writing.
467
+
468
+### Netdata-specific terms
469
+
470
+| Term | Definition |
471
+|-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
472
+| **claimed node** | A node that you've proved ownership of by completing the [claiming process](/claim/README.md). The claimed node will then appear in your Space and any War Rooms you added it to. |
473
+| **Netdata** | The company behind the open-source Netdata Agent and the Netdata Cloud web application. Never use _netdata_ or _NetData_. <br /><br />In general, focus on the user's goals, actions, and solutions rather than what the company provides. For example, write _Learn more about enabling alarm notifications on your preferred platforms_ instead of _Netdata sends alarm notifications to your preferred platforms_. |
474
+| **Netdata Agent** | The free and open source [monitoring agent](https://github.com/netdata/netdata) that you can install on all of your distributed systems, whether they're physical, virtual, containerized, ephemeral, and more. The Agent monitors systems running Linux, Docker, Kubernetes, macOS, FreeBSD, and more, and collects metrics from hundreds of popular services and applications. |
475
+| **Netdata Cloud** | The web application hosted at [https://app.netdata.cloud](https://app.netdata.cloud) that helps you monitor an entire infrastructure of distributed systems in real time. <br /><br />Never use _Cloud_ without the preceding _Netdata_ to avoid ambiguity. |
476
+| **Netdata community** | Contributors to any of Netdata's [open-source projects](https://learn.netdata.cloud/contribute/projects), members of the [community forum](https://community.netdata.cloud/). |
477
+| **Netdata community forum** | The Discourse-powered forum for feature requests, Netdata Cloud technical support, and conversations about Netdata's monitoring and troubleshooting products. |
478
+| **node** | A system on which the Netdata Agent is installed. The system can be physical, virtual, in a Docker container, and more. Depending on your infrastructure, you may have one, dozens, or hundreds of nodes. Some nodes are _ephemeral_, in that they're created/destroyed automatically by an orchestrator service. |
479
+| **Space** | The highest level container within Netdata Cloud for a user to organize their team members and nodes within their infrastructure. A Space likely represents an entire organization or a large team. <br /><br />_Space_ is always capitalized. |
480
+| **unreachable node** | A claimed node with a disrupted [Agent-Cloud link](/aclk/README.md). Unreachable could mean the node no longer exists or is experiencing network connectivity issues with Cloud. |
481
+| **visited node** | A node which has had its Agent dashboard directly visited by a user. A list of these is maintained on a per-user basis. |
482
+| **War Room** | A smaller grouping of nodes where users can view key metrics in real-time and monitor the health of many nodes with their alarm status. War Rooms can be used to organize nodes in any way that makes sense for your infrastructure, such as by a service, purpose, physical location, and more. <br /><br />_War Room_ is always capitalized. |
483
+
484
+### Other technical terms
485
+
486
+| Term | Definition |
487
+|-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
488
+| **filesystem** | Use instead of _file system_. |
489
+| **preconfigured** | The concept that many of Netdata's features come with sane defaults that users don't need to configure to find [immediate value](/docs/overview/why-netdata.md#simple-to-deploy). |
490
+| **real time**/**real-time** | Use _real time_ as a noun phrase, most often with _in_: _Netdata collects metrics in real time_. Use _real-time_ as an adjective: _Netdata collects real-time metrics from hundreds of supported applications and services. |
491
492
[](<>)