master
md 467 lines 29.5 KB
Rendered Raw
1 # Netdata style guide
2
3 The _Netdata style guide_ establishes editorial guidelines for any writing produced by the Netdata team or the Netdata community, including documentation, articles, in-product UX copy, and more.
4
5 > **Note**
6 > This document is meant to be accompanied by the [Documentation Guidelines](/docs/guidelines.md). If you want to contribute to Netdata's documentation, please read it too.
7
8 Both internal Netdata teams and external contributors to any of Netdata's open-source projects should reference and adhere to this style guide as much as possible.
9
10 Netdata's writing should **empower** and **educate**. You want to help people understand Netdata's value, encourage them to learn more, and ultimately use Netdata's products to democratize monitoring in their organizations.
11 To achieve these goals, your writing should be:
12
13 - **Clear**. Use simple words and sentences. Use strong, direct, and active language that encourages readers to action.
14 - **Concise**. Provide solutions and answers as quickly as possible. Give users the information they need right now,
15 along with opportunities to learn more.
16 - **Universal**. Think of yourself as a guide giving a tour of Netdata's products, features, and capabilities to a
17 diverse group of users. Write to reach the widest possible audience.
18
19 You can achieve these goals by reading and adhering to the principles outlined below.
20
21 ## Voice and tone
22
23 One way we write empowering, educational content is by using a consistent voice and an appropriate tone.
24
25 _Voice_ is like your personality, which doesn't really change day to day.
26
27 _Tone_ is how you express your personality. Your expression changes based on your attitude or mood, or based on whom
28 you're around. In writing, you reflect tone in your word choice, punctuation, sentence structure, or emoji.
29
30 The same idea about voice and tone applies to organizations, too. Our voice shouldn't change much between two pieces of
31 content, no matter who wrote each, but the tone might be quite different based on who we think is reading.
32
33 ### Voice
34
35 Netdata's voice is authentic, passionate, playful, and respectful.
36
37 - **Authentic** writing is honest and fact-driven. Focus on Netdata's strength while accurately communicating what
38 Netdata can and can’t do, and emphasize technical accuracy over hard sells and marketing jargon.
39 - **Passionate** writing is strong and direct. Be a champion for the product or feature you're writing about, and let
40 your unique personality and writing style shine.
41 - **Playful** writing is friendly, thoughtful, and engaging. Don't take yourself too seriously, as long as it's not at
42 the expense of Netdata or any of its users.
43 - **Respectful** writing treats people the way you want to be treated. Prioritize giving solutions and answers as
44 quickly as possible.
45
46 ### Tone
47
48 Netdata's tone is fun and playful, but clarity and conciseness come first. We also tend to be informal, and aren't
49 afraid of a playful joke or two.
50
51 While we have general standards for voice and tone, we do want every individual's unique writing style to reflect in
52 published content.
53
54 ## Universal communication
55
56 Netdata is a global company in every sense, with employees, contributors, and users from around the world. We strive to
57 communicate in a way that is clear and easily understood by everyone.
58
59 Here are some guidelines, pointers, and questions to be aware of as you write to ensure your writing is universal. Some
60 of these are expanded into individual sections in
61 the [language, grammar, and mechanics](#language-grammar-and-mechanics) section below.
62
63 - Would this language make sense to someone who doesn't work here?
64 - Could anyone quickly scan this document and understand the material?
65 - Create an information hierarchy with key information presented first and clearly called out to improve clarity and readability.
66 - Avoid directional language like "sidebar on the right of the page" or "header at the top of the page" since
67 presentation elements may adapt for devices.
68 - Use descriptive links rather than "click here" or "learn more".
69 - Include alt text for images and image links.
70 - Ensure any information contained within a graphic element is also available as plain text.
71 - Avoid idioms that may not be familiar to the user, or that may not make sense when translated.
72 - Avoid local, cultural, or historical references that may be unfamiliar to users.
73 - Prioritize active, direct language.
74 - Avoid referring to someone's age unless it is directly relevant; likewise, avoid referring to people with age-related
75 descriptors like "young" or "elderly."
76 - Avoid disability-related idioms like "lame" or "falling on deaf ears." Don't refer to a person's disability unless
77 it’s directly relevant to what you're writing.
78 - Don't call groups of people "guys." Don't call women "girls."
79 - Avoid gendered terms in favor of neutral alternatives, like "server" instead of "waitress" and "businessperson"
80 instead of "businessman."
81 - When writing about a person, use their communicated pronouns. When in doubt, just ask or use their name. It's OK to
82 use "they" as a singular pronoun.
83
84 > Some of these guidelines were adapted from MailChimp under the Creative Commons license.
85
86 ## Language, grammar, and mechanics
87
88 To ensure Netdata's writing is clear, concise, and universal, we’ve established standards for language, grammar, and
89 certain writing mechanics. However, if you're writing about Netdata for an external publication, such as a guest blog
90 post, follow that publication's style guide or standards, while keeping
91 the [preferred spelling of Netdata terms](#netdata-specific-terms) in mind.
92
93 ### Active voice
94
95 Active voice is more concise and easier to understand compared to passive voice. When using active voice, the subject of
96 the sentence is action. In passive voice, the subject is acted upon. A famous example of passive voice is the phrase
97 "mistakes were made."
98
99 | | |
100 |-----------------|-------------------------------------------------------------------------------------------|
101 | Not recommended | When an alert is triggered by a metric, a notification is sent by Netdata. |
102 | **Recommended** | When a metric triggers an alert, Netdata sends a notification to your preferred endpoint. |
103
104 ### Second person
105
106 Use the second person ("you") to give instructions or "talk" directly to users.
107
108 In these situations, avoid "we," "I," "let's," and "us," particularly in documentation. The "you" pronoun can also be
109 implied, depending on your sentence structure.
110
111 One valid exception is when a member of the Netdata team or community wants to write about said team or community.
112
113 | | |
114 |--------------------------------|--------------------------------------------------------------|
115 | Not recommended | To install Netdata, we should try the one-line installer... |
116 | **Recommended** | To install Netdata, you should try the one-line installer... |
117 | **Recommended**, implied "you" | To install Netdata, try the one-line installer... |
118
119 ### "Easy" or "simple"
120
121 Using words that imply the complexity of a task or feature goes against our policy
122 of [universal communication](#universal-communication). If you claim that a task is easy and the reader struggles to
123 complete it, you
124 may inadvertently discourage them.
125
126 However, if you give users two options and want to relay that one option is genuinely less complex than another, be
127 specific about how and why.
128
129 For example, don't write, "Netdata's one-line installer is the easiest way to install Netdata." Instead, you might want
130 to say, "Netdata's one-line installer requires fewer steps than manually installing from source."
131
132 ### Slang, metaphors, and jargon
133
134 A particular word, phrase, or metaphor you're familiar with might not translate well to the other cultures featured
135 among Netdata's global community. We recommended you avoid slang or colloquialisms in your writing.
136
137 In addition, don't use abbreviations that haven’t yet been defined in the content. See our section on
138 [abbreviations](#abbreviations-acronyms-and-initialisms) for additional guidance.
139
140 If you must use industry jargon, such as "mean time to resolution," define the term as clearly and concisely as you can.
141
142 > Netdata helps you reduce your organization's mean time to resolution (MTTR), which is the average time the responsible
143 > team requires to repair a system and resolve an ongoing incident.
144
145 ### Spelling
146
147 While the Netdata team is mostly _not_ American, we still aspire to use American spelling whenever possible, as it is
148 the standard for the monitoring industry.
149
150 See the [word list](#word-list) for spellings of specific words.
151
152 ### Capitalization
153
154 Follow the general [English standards](https://owl.purdue.edu/owl/general_writing/mechanics/help_with_capitals.html) for
155 capitalization. In summary:
156
157 - Capitalize the first word of every new sentence.
158 - Don't use uppercase for emphasis. (Netdata is the BEST!)
159 - Capitalize the names of brands, software, products, and companies according to their official guidelines. (Netdata,
160 Docker, Apache, NGINX)
161 - Avoid camel case (NetData) or all caps (NETDATA).
162
163 Whenever you refer to the company Netdata Inc., or the open-source monitoring Agent the company develops, capitalize both words.
164
165 However, if you’re referring to a process, user, or group on a Linux system, use lowercase and fence the word in an
166 inline code block: `` `netdata` ``.
167
168 | | |
169 |-----------------|------------------------------------------------------------------------------------------------|
170 | Not recommended | The netdata agent, which spawns the netdata process, is actively maintained by Netdata Inc. |
171 | **Recommended** | The Netdata Agent, which spawns the `netdata` process, is actively maintained by Netdata Inc. |
172
173 #### Capitalization of document titles and page headings
174
175 Document titles and page headings should use sentence case. That means you should only capitalize the first word.
176
177 If you need to use the name of a brand, software, product, and company, capitalize it according to their official
178 guidelines.
179
180 Also, don't put a period (`.`) or colon (`:`) at the end of a title or header.
181
182 | | |
183 |-----------------|-----------------------------------------------------------------------------------------------------|
184 | Not recommended | Getting Started Guide <br />Service Discovery and Auto-Detection: <br />Install netdata with docker |
185 | **Recommended** | Getting started guide <br />Service discovery and auto-detection <br />Install Netdata with Docker |
186
187 ### Abbreviations (acronyms and initialisms)
188
189 Use abbreviations (including [acronyms and initialisms](https://www.dictionary.com/e/acronym-vs-abbreviation/)) in
190 documentation when one exists, when it's widely accepted within the monitoring/sysadmin community, and when it improves
191 the readability of a document.
192
193 When introducing an abbreviation to a document for the first time, give the reader both the spelled-out version and the
194 shortened version at the same time. For example:
195
196 > Use Netdata to monitor Extended Berkeley Packet Filter (eBPF) metrics in real-time.
197
198 After you define an abbreviation, don't switch back and forth. Use only the abbreviation for the rest of the document.
199
200 You can also use abbreviations in a document's title to keep the title short and relevant. If you do this, you should
201 still introduce the spelled-out name alongside the abbreviation as soon as possible.
202
203 ### Clause order
204
205 When instructing users to take action, give them the context first. By placing the context in an initial clause at the
206 beginning of the sentence, users can immediately know if they want to read more, follow a link, or skip ahead.
207
208 | | |
209 |-----------------|--------------------------------------------------------------------------------|
210 | Not recommended | Read the reference guide if you'd like to learn more about custom dashboards. |
211 | **Recommended** | If you'd like to learn more about custom dashboards, read the reference guide. |
212
213 ### Oxford comma
214
215 The Oxford comma is the comma used after the second-to-last item in a list of three or more items. It appears just
216 before "and" or "or."
217
218 | | |
219 |-----------------|------------------------------------------------------------------------------|
220 | Not recommended | Netdata can monitor RAM, disk I/O, MySQL queries per second and lm-sensors. |
221 | **Recommended** | Netdata can monitor RAM, disk I/O, MySQL queries per second, and lm-sensors. |
222
223 ### Future releases or features
224
225 Do not mention future releases or upcoming features in writing unless they’ve been previously communicated via a
226 public roadmap.
227
228 In particular, documentation must describe, as accurately as possible, the Netdata Agent _as of the [latest
229 commit](https://github.com/netdata/netdata/commits/master) in the GitHub repository_. For Netdata Cloud, documentation
230 must reflect the _current state of [production](https://app.netdata.cloud).
231
232 ### Informational links
233
234 Every link should clearly state its destination. Don't use words like "here" to describe where a link will take your
235 reader.
236
237 | | |
238 |-----------------|-------------------------------------------------------------------------------------------|
239 | Not recommended | To install Netdata, click [here](/packaging/installer/README.md). |
240 | **Recommended** | To install Netdata, read the [installation instructions](/packaging/installer/README.md). |
241
242 Use links as often as required to provide the necessary context. Blog posts and guides require fewer hyperlinks than
243 documentation.
244
245 ### Contractions
246
247 Contractions like "you'll" or "they're" are acceptable in most Netdata writing. They're both authentic and playful, and
248 reinforce the idea that you, as a writer, are guiding users through a particular idea, process, or feature.
249
250 Contractions are generally not used in press releases or other media engagements.
251
252 ### Emoji
253
254 Emoji can add fun and character to your writing, but should be used sparingly and only if it matches the content's tone
255 and desired audience.
256
257 ## Technical/Linux standards
258
259 Configuration or maintenance of the Netdata Agent requires some system administration skills, such as navigating
260 directories, editing files, or starting/stopping/restarting services. Certain processes
261
262 ### Switching Linux users
263
264 Netdata documentation often suggests that users switch from their normal user to the `netdata` user to run specific
265 commands. Use the following command to instruct users to make the switch:
266
267 ```bash
268 sudo su -s /bin/bash netdata
269 ```
270
271 ### Hostname/IP address of a node
272
273 Use `NODE` instead of an actual or example IP address/hostname when referencing the process of navigating to a dashboard
274 or API endpoint in a browser.
275
276 | | |
277 |-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
278 | 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. |
279 | **Recommended** | Navigate to `http://NODE:19999` in your browser to see Netdata's dashboard. |
280
281 If you worry that `NODE` doesn't provide enough context for the user, particularly in documentation or guides designed
282 for beginners, you can provide an explanation:
283
284 > With the Netdata Agent running, visit `http://NODE:19999/api/v1/info` in your browser, replacing `NODE` with the IP
285 > address or hostname of your Agent.
286
287 ### Paths and running commands
288
289 When instructing users to run a Netdata-specific command, don't assume the path to said command, because not every
290 Netdata Agent installation will have commands under the same paths. When applicable, help them navigate to the correct
291 path, providing a recommendation or instructions on how to view the running configuration, which includes the correct
292 paths.
293
294 For example, the [configuration](/docs/netdata-agent/configuration/README.md) doc first
295 teaches users how to find the Netdata config
296 directory and navigate to it, then runs commands from the `/etc/netdata` path so that the instructions are more
297 universal.
298
299 Don't include full paths, beginning from the system's root (`/`), as these might not work on certain systems.
300
301 | | |
302 |-----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
303 | Not recommended | Use `edit-config` to edit Netdata's configuration: `sudo /etc/netdata/edit-config netdata.conf`. |
304 | **Recommended** | Use `edit-config` to edit Netdata's configuration by first navigating to your [Netdata config directory](/docs/netdata-agent/configuration/README.md#locate-your-config-directory), which is typically at `/etc/netdata`, then running `sudo edit-config netdata.conf`. |
305
306 ### `sudo`
307
308 Include `sudo` before a command if you believe most Netdata users will need to elevate privileges to run it. This makes
309 our writing more universal, and users on `sudo`-less systems are generally already aware that they need to run commands
310 differently.
311
312 For example, most users need to use `sudo` with the `edit-config` script, because the Netdata config directory is owned
313 by the `netdata` user. The same goes for restarting the Netdata Agent with `systemctl`.
314
315 | | |
316 |-----------------|----------------------------------------------------------------------------------------------------------------------------------------------|
317 | Not recommended | Run `edit-config netdata.conf` to configure the Netdata Agent. <br />Run `systemctl restart netdata` to restart the Netdata Agent. |
318 | **Recommended** | Run `sudo edit-config netdata.conf` to configure the Netdata Agent. <br />Run `sudo systemctl restart netdata` to restart the Netdata Agent. |
319
320 ## Markdown syntax
321
322 Netdata's documentation uses Markdown syntax.
323
324 If you're not familiar with Markdown, read the [Mastering
325 Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on creating
326 paragraphs, styled text, lists, tables, and more.
327
328 The following sections describe situations in which a specific syntax is required.
329
330 ### References to UI elements
331
332 When referencing a user interface (UI) element in Netdata, reference the label text of the link/button with Markdown's
333 (`**bold text**`) tag.
334
335 ```markdown
336 Click the **Sign in** button.
337 ```
338
339 Avoid directional language whenever possible. Not every user can use instructions like "look at the top-left corner" to
340 find their way around an interface, and interfaces often change between devices. If you must use directional language,
341 try to supplement the text with an [image](#images).
342
343 ### Images
344
345 Don't rely on images to convey features, ideas, or instructions. Accompany every image with descriptive alt text.
346
347 In Markdown, use the standard image syntax, `![]()`, and place the alt text between the brackets `[]`. Here's an example
348 using our logo:
349
350 ```markdown
351 ![The Netdata logo](https://github.com/netdata/netdata/blob/master/src/web/gui/static/img/netdata-logomark.svg)
352 ```
353
354 Reference in-product text, code samples, and terminal output with actual text content, not screen captures or other
355 images. Place the text in an appropriate element, such as a blockquote or code block, so all users can parse the
356 information.
357
358 ### Syntax highlighting
359
360 Our documentation site at [learn.netdata.cloud](https://learn.netdata.cloud) uses
361 [Prism](https://v2.docusaurus.io/docs/markdown-features#syntax-highlighting) for syntax highlighting. Netdata
362 documentation will use the following for the most part: `c`, `python`, `js`, `shell`, `markdown`, `bash`, `css`, `html`,
363 and `go`. If no language is specified, Prism tries to guess the language based on its content.
364
365 Include the language directly after the three backticks (```` ``` ````) that start the code block. For highlighting C
366 code, for example:
367
368 ````c
369 ```c
370 inline char *health_stock_config_dir(void) {
371 char buffer[FILENAME_MAX + 1];
372 snprintfz(buffer, FILENAME_MAX, "%s/health.d", netdata_configured_stock_config_dir);
373 return config_get(CONFIG_SECTION_DIRECTORIES, "stock health config", buffer);
374 }
375 ```
376 ````
377
378 And the prettified result:
379
380 ```c
381 inline char *health_stock_config_dir(void) {
382 char buffer[FILENAME_MAX + 1];
383 snprintfz(buffer, FILENAME_MAX, "%s/health.d", netdata_configured_stock_config_dir);
384 return config_get(CONFIG_SECTION_DIRECTORIES, "stock health config", buffer);
385 }
386 ```
387
388 Prism also supports titles and line highlighting. See
389 the [Docusaurus documentation](https://v2.docusaurus.io/docs/markdown-features#code-blocks) for more information.
390
391 ### Adding Notes
392
393 Notes inside files should render properly both in GitHub and in Learn, to do that, it is best to use the format listed below:
394
395 ```md
396 > **Note**
397 > This is an info or a note block.
398
399 > **Tip, Best Practice**
400 > This is a tip or a best practice block.
401
402 > **Warning, Caution**
403 > This is a warning or a caution block.
404 ```
405
406 Which renders into:
407
408 > **Note**
409 > This is an info or a note block.
410
411 > **Tip, Best Practice**
412 > This is a tip or a best practice block.
413
414 > **Warning, Caution**
415 > This is a warning or a caution block.
416
417 ### Tabs
418
419 Docusaurus allows for Tabs to be used, but we have to ensure that a user accessing the file from GitHub doesn't notice any weird artifacts while reading. So, we use tabs only when necessary in this format:
420
421 ```
422
423 <Tabs>
424 <TabItem value="tab1" label="tab1">
425
426 <h3> Header for tab1 </h3>
427
428 text for tab1, both visible in GitHub and Docusaurus
429
430
431 </TabItem>
432 <TabItem value="tab2" label="tab2">
433
434 <h3> Header for tab2 </h3>
435
436 text for tab2, both visible in GitHub and Docusaurus
437
438 </TabItem>
439 </Tabs>
440 ```
441
442 ## Word list
443
444 The following tables describe the standard spelling, capitalization, and usage of words found in Netdata's writing.
445
446 ### Netdata-specific terms
447
448 | Term | Definition |
449 |-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
450 | **Connected Node** | A node that you've proved ownership of by completing the [connecting to Cloud process](/src/claim/README.md). The claimed node will then appear in your Space and any Rooms you added it to. |
451 | **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 alert notifications on your preferred platforms_ instead of _Netdata sends alert notifications to your preferred platforms_. |
452 | **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. |
453 | **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. |
454 | **Netdata community forum** | The Discourse-powered forum for feature requests, Netdata Cloud technical support, and conversations about Netdata's monitoring and troubleshooting products. |
455 | **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. |
456 | **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. |
457 | **Unreachable node** | A connected node with a disrupted [Agent-Cloud link](/src/aclk/README.md). Unreachable could mean the node no longer exists or is experiencing network connectivity issues with Cloud. |
458 | **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. |
459 | **Room** | A smaller grouping of nodes where users can view key metrics in real-time and monitor the health of many nodes with their alert status. 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 />_Room_ is always capitalized. |
460
461 ### Other technical terms
462
463 | Term | Definition |
464 |-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
465 | **filesystem** | Use instead of _file system_. |
466 | **pre-configured** | The concept that many of Netdata's features come with sane defaults that users don't need to configure to find immediate value. |
467 | **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. |