@cryptotaxi247 / netdata-1 / commits / aba7e8c06

Improve guideline docs (#14678)

* merge guideline docs and add info to style guide * Update style-guide.md

Fotis Voutsas committed Mar 14, 2023 at 18:41 UTC aba7e8c064b3b993ce837495bb66d1362b1f21df

3 files changed +87 -867

contribution-guidelines.md deleted

-807

@@ -1,807 +0,0 @@

1 -# Docs Development Guidelines

2 -

3 -Welcome to our docs developer guidelines!

4 -

5 -We store documentation related to Netdata inside of

6 -the [`netdata/netdata` repository](https://github.com/netdata/netdata) on GitHub.

7 -

8 -The Netdata team aggregates and publishes all documentation at [learn.netdata.cloud](/) using

9 -[Docusaurus](https://v2.docusaurus.io/) over at the [`netdata/learn` repository](https://github.com/netdata/learn).

10 -

11 -## Before you get started

12 -

13 -Anyone interested in contributing to documentation should first read the [Netdata style guide](#styling-guide) further

14 -down below and the [Netdata Community Code of Conduct](https://github.com/netdata/.github/blob/main/CODE_OF_CONDUCT.md).

15 -

16 -Netdata's documentation uses Markdown syntax. If you're not familiar with Markdown, read

17 -the [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on

18 -creating paragraphs, styled text, lists, tables, and more, and read further down about some special

19 -occasions [while writing in MDX](#mdx-and-markdown).

20 -

21 -### Netdata's Documentation structure

22 -

23 -Netdata's documentation is separated into 5 categories.

24 -

25 -- **Getting Started**: This section’s purpose is to present “What is Netdata” and for whom is it for while also

26 - presenting all the ways Netdata can be deployed. That includes Netdata’s platform support, Standalone deployment,

27 - Parent-child deployments, deploying on Kubernetes and also deploying on IoT nodes.

28 - - Stored in **WIP**

29 - - Published in **WIP**

30 -- **Concepts**: This section’s purpose is to take a pitch on all the aspects of Netdata. We present the functionality of

31 - each component/idea and support it with examples but we don’t go deep into technical details.

32 - - Stored in the `/docs/concepts` directory in the `netdata/netdata` repository.

33 - - Published in **WIP**

34 -- **Tasks**: This section's purpose is to break down any operation into a series of fundamental tasks for the Netdata

35 - solution.

36 - - Stored in the `/docs/tasks` directory in the `netdata/netdata` repository.

37 - - Published in **WIP**

38 -- **References**: This section’s purpose is to explain thoroughly every part of Netdata. That covers settings,

39 - configurations and so on.

40 - - Stored near the component they refer to.

41 - - Published in **WIP**

42 -- **Collectors References**: This section’s purpose is to explain thoroughly every collector that Netdata supports and

43 - it's configuration options.

44 - - Stored in stored near the collector they refer to.

45 - - Published in **WIP**

46 -

47 -## How to contribute

48 -

49 -The easiest way to contribute to Netdata's documentation is to edit a file directly on GitHub. This is perfect for small

50 -fixes to a single document, such as fixing a typo or clarifying a confusing sentence.

51 -

52 -Click on the **Edit this page** button on any published document on [Netdata Learn](https://learn.netdata.cloud). Each

53 -page has two of these buttons: One beneath the table of contents, and another at the end of the document, which take you

54 -to GitHub's code editor. Make your suggested changes, keeping the [Netdata style guide](#styling-guide)

55 -in mind, and use the ***Preview changes*** button to ensure your Markdown syntax works as expected.

56 -

57 -Under the **Commit changes** header, write descriptive title for your requested change. Click the **Commit changes**

58 -button to initiate your pull request (PR).

59 -

60 -Jump down to our instructions on [PRs](#making-a-pull-request) for your next steps.

61 -

62 -### Edit locally

63 -

64 -Editing documentation locally is the preferred method for complex changes that span multiple documents or change the

65 -documentation's style or structure.

66 -

67 -Create a fork of the Netdata Agent repository by visit the [Netdata repository](https://github.com/netdata/netdata) and

68 -clicking on the **Fork** button.

69 -

70 -GitHub will ask you where you want to clone the repository. When finished, you end up at the index of your forked

71 -Netdata Agent repository. Clone your fork to your local machine:

72 -

73 -```bash

74 -git clone https://github.com/YOUR-GITHUB-USERNAME/netdata.git

75 -```

76 -

77 -Create a new branch using `git checkout -b BRANCH-NAME`. Use your favorite text editor to make your changes, keeping

78 -the [Netdata style guide](https://github.com/netdata/netdata/blob/master/docs/contributing/style-guide.md) in mind. Add, commit, and push changes to your fork. When you're

79 -finished, visit the [Netdata Agent Pull requests](https://github.com/netdata/netdata/pulls) to create a new pull request

80 -based on the changes you made in the new branch of your fork.

81 -

82 -### Making a pull request

83 -

84 -Pull requests (PRs) should be concise and informative. See our [PR guidelines](/contribute/handbook#pr-guidelines) for

85 -specifics.

86 -

87 -- The title must follow the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) and be no more than ~50

88 - characters.

89 -- The description should explain what was changed and why. Verify that you tested any code or processes that you are

90 - trying to change.

91 -

92 -The Netdata team will review your PR and assesses it for correctness, conciseness, and overall quality. We may point to

93 -specific sections and ask for additional information or other fixes.

94 -

95 -After merging your PR, the Netdata team rebuilds the [documentation site](https://learn.netdata.cloud) to publish the

96 -changed documentation.

97 -

98 -## Writing Docs

99 -

100 -We have three main types of Docs: **References**, **Concepts** and **Tasks**.

101 -

102 -### Metadata Tags

103 -

104 -All of the Docs however have what we call "metadata" tags. these help to organize the document upon publishing.

105 -

106 -So let's go through the different necessary metadata tags to get a document properly published on Learn:

107 -

108 -- Docusaurus Specific:\

109 - These metadata tags are parsed automatically by Docusaurus and are rendered in the published document. **Note**:

110 - Netdata only uses the Docusaurus metadata tags releveant for our documentation infrastructure.

111 - - `title: "The title of the document"` : Here we specify the title of our document, which is going to be converted

112 - to the heading of the published page.

113 - - `description: "The description of the file"`: Here we give a description of what this file is about.

114 - - `custom_edit_url: https://github.com/netdata/netdata/edit/master/collectors/COLLECTORS.md`: Here is an example of

115 - the link that the user will be redirected to if he clicks the "Edit this page button", as you see it leads

116 - directly to the edit page of the source file.

117 -- Netdata Learn specific:

118 - - `learn_status: "..."`

119 - - The options for this tag are:

120 - - `"published"`

121 - - `"unpublished"`

122 - - `learn_topic_type: "..."`

123 - - The options for this tag are:

124 - - `"Getting Started"`

125 - - `"Concepts"`

126 - - `"Tasks"`

127 - - `"References"`

128 - - `"Collectors References"`

129 - - This is the Topic that the file belongs to, and this is going to resemble the start directory of the file's

130 - path on Learn for example if we write `"Concepts"` in the field, then the file is going to be placed

131 - under `/Concepts/....` inside Learn.

132 - - `learn_rel_path: "/example/"`

133 - - This tag represents the rest of the path, without the filename in the end, so in this case if the file is a

134 - Concept, it would go under `Concepts/example/filename.md`. If you want to place the file under the "root"

135 - topic folder, input `"/"`.

136 - - ⚠️ In case any of these "Learn" tags are missing or falsely inputted the file will remain unpublished. This is by

137 - design to prevent non-properly tagged files from getting published.

138 -

139 -While Docusaurus can make use of more metadata tags than the above, these are the minimum we require to publish the file

140 -on Learn.

141 -

142 -### Doc Templates

143 -

144 -These are the templates we use for our Documentation files:

145 -

146 -<details>

147 -<summary>Reference Docs</summary>

148 -

149 -The template that is used for Reference files is:

150 -

151 -```

152 - <!--

153 - title: "Apache monitoring with Netdata"

154 - description: "Monitor the health and performance of Apache web servers with zero configuration, per-second metric granularity, and interactive visualizations."

155 - custom_edit_url: https://github.com/netdata/go.d.plugin/edit/master/modules/apache/README.md

156 - learn_topic_type: "Collector References"

157 - learn_rel_path: "/sample_category"

158 - learn_status: "published"

159 - -->

160 -```

161 -

162 -## Configuration files

163 -

164 -### Data collection

165 -

166 -```

167 -go.d/apache.conf

168 -```

169 -

170 -To make changes, see `the ./edit-config task <link>`

171 -

172 -### Alerts

173 -

174 -none

175 -

176 -## Requirements to run this module

177 -

178 -- none

179 -

180 -## Requirement on the monitored application

181 -

182 -- `Apache` with enabled [`mod_status`](https://httpd.apache.org/docs/2.4/mod/mod_status.html)

183 -

184 -## Auto detection

185 -

186 -### Single node installation

187 -

188 -. . . we autodetect localhost:port and what configurations are defaults

189 -

190 -### Kubernetes installations

191 -

192 -. . . Service discovery, click here

193 -

194 -## Metrics

195 -

196 -Columns: Context | description (of the context) | units (of the context) | dimensions | alerts

197 -

198 -- Requests in `requests/s`

199 -- Connections in `connections`

200 -- Async Connections in `connections`

201 -- Scoreboard in `connections`

202 -- Bandwidth in `kilobits/s`

203 -- Workers in `workers`

204 -- Lifetime Average Number Of Requests Per Second in `requests/s`

205 -- Lifetime Average Number Of Bytes Served Per Second in `KiB/s`

206 -- Lifetime Average Response Size in `KiB`

207 -

208 -### Labels

209 -

210 -just like <https://github.com/netdata/go.d.plugin/tree/master/modules/k8s_state#labels>

211 -

212 -## Alerts

213 -

214 -collapsible content for every alert, just like the alert guides

215 -

216 -## Configuration options

217 -

218 -Table with all the configuration options available.

219 -

220 -Columns: name | description | default

221 -

222 -## Configuration example

223 -

224 -Needs only `url` to server's `server-status?auto`. Here is an example for 2 servers:

225 -

226 -```yaml

227 -jobs:

228 - - name: local

229 - url: http://127.0.0.1/server-status?auto

230 - - name: remote

231 - url: http://203.0.113.10/server-status?auto

232 -```

233 -

234 -For all available options please see

235 -module [configuration file](https://github.com/netdata/go.d.plugin/blob/master/config/go.d/apache.conf).

236 -

237 -## Troubleshoot

238 -

239 -backlink to the task to run this module in debug mode

240 -

241 -</details>

242 -

243 -<details>

244 -<summary>Task Docs</summary>

245 -

246 -The template that is used for Task files is:

247 -

248 -```

249 - <!--

250 - title: "Task title"

251 - description: "Task description"

252 - custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/Tasks/sampletask.md

253 - learn_topic_type: "Tasks"

254 - learn_rel_path: "/sample_category"

255 - learn_status: "published"

256 - -->

257 -```

258 -

259 -## Description

260 -

261 -A small description of the Task.

262 -

263 -## Prerequisites

264 -

265 -Describe all the information that the user needs to know before proceeding with the task.

266 -

267 -## Context

268 -

269 -Describe the background information of the Task, the purpose of the Task, and what will the user achieve by completing

270 -it.

271 -

272 -## Steps

273 -

274 -A task consists of steps, here provide the actions needed from the user, so he can complete the task correctly.

275 -

276 -## Result

277 -

278 -Describe the expected output/ outcome of the result.

279 -

280 -## Example

281 -

282 -Provide any examples needed for the Task

283 -

284 -</details>

285 -

286 -<details>

287 -<summary>Concept Docs</summary>

288 -

289 -The template of the Concept files is:

290 -

291 -```

292 - <!--

293 - title: "Concept title"

294 - description: "Concept description"

295 - custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/Concepts/sampleconcept.md

296 - learn_topic_type: "Concepts"

297 - learn_rel_path: "/sample_category"

298 - learn_status: "published"

299 - -->

300 -```

301 -

302 -## Description

303 -

304 -In our concepts we have a more loose structure, the goal is to communicate the "concept" to the user, starting with

305 -simple language that even a new user can understand, and building from there.

306 -

307 -</details>

308 -

309 -## Styling Guide

310 -

311 -The *Netdata style guide* establishes editorial guidelines for any writing produced by the Netdata team or the Netdata

312 -community, including documentation, articles, in-product UX copy, and more. Both internal Netdata teams and external

313 -contributors to any of Netdata's open-source projects should reference and adhere to this style guide as much as

314 -possible.

315 -

316 -Netdata's writing should **empower** and **educate**. You want to help people understand Netdata's value, encourage them

317 -to learn more, and ultimately use Netdata's products to democratize monitoring in their organizations. To achieve these

318 -goals, your writing should be:

319 -

320 -- **Clear**. Use simple words and sentences. Use strong, direct, and active language that encourages readers to action.

321 -- **Concise**. Provide solutions and answers as quickly as possible. Give users the information they need right now,

322 - along with opportunities to learn more.

323 -- **Universal**. Think of yourself as a guide giving a tour of Netdata's products, features, and capabilities to a

324 - diverse group of users. Write to reach the widest possible audience.

325 -

326 -You can achieve these goals by reading and adhering to the principles outlined below.

327 -

328 -## Voice and tone

329 -

330 -One way we write empowering, educational content is by using a consistent voice and an appropriate tone.

331 -

332 -*Voice* is like your personality, which doesn't really change day to day.

333 -

334 -*Tone* is how you express your personality. Your expression changes based on your attitude or mood, or based on who

335 -you're around. In writing, your reflect tone in your word choice, punctuation, sentence structure, or even the use of

336 -emoji.

337 -

338 -The same idea about voice and tone applies to organizations, too. Our voice shouldn't change much between two pieces of

339 -content, no matter who wrote each, but the tone might be quite different based on who we think is reading.

340 -

341 -For example, a [blog post](https://www.netdata.cloud/blog/) and a [press release](https://www.netdata.cloud/news/)

342 -should have a similar voice, despite most often being written by different people. However, blog posts are relaxed and

343 -witty, while press releases are focused and academic. You won't see any emoji in a press release.

344 -

345 -### Voice

346 -

347 -Netdata's voice is authentic, passionate, playful, and respectful.

348 -

349 -- **Authentic** writing is honest and fact-driven. Focus on Netdata's strength while accurately communicating what

350 - Netdata can and cannot do, and emphasize technical accuracy over hard sells and marketing jargon.

351 -- **Passionate** writing is strong and direct. Be a champion for the product or feature you're writing about, and let

352 - your unique personality and writing style shine.

353 -- **Playful** writing is friendly, thoughtful, and engaging. Don't take yourself too seriously, as long as it's not at

354 - the expense of Netdata or any of its users.

355 -- **Respectful** writing treats people the way you want to be treated. Prioritize giving solutions and answers as

356 - quickly as possible.

357 -

358 -### Tone

359 -

360 -Netdata's tone is fun and playful, but clarity and conciseness comes first. We also tend to be informal, and aren't

361 -afraid of a playful joke or two.

362 -

363 -While we have general standards for voice and tone, we do want every individual's unique writing style to reflect in

364 -published content.

365 -

366 -## Universal communication

367 -

368 -Netdata is a global company in every sense, with employees, contributors, and users from around the world. We strive to

369 -communicate in a way that is clear and easily understood by everyone.

370 -

371 -Here are some guidelines, pointers, and questions to be aware of as you write to ensure your writing is universal. Some

372 -of these are expanded into individual sections in

373 -the [language, grammar, and mechanics](#language-grammar-and-mechanics) section below.

374 -

375 -- Would this language make sense to someone who doesn't work here?

376 -- Could someone quickly scan this document and understand the material?

377 -- Create an information hierarchy with key information presented first and clearly called out to improve scannability.

378 -- Avoid directional language like "sidebar on the right of the page" or "header at the top of the page" since

379 - presentation elements may adapt for devices.

380 -- Use descriptive links rather than "click here" or "learn more".

381 -- Include alt text for images and image links.

382 -- Ensure any information contained within a graphic element is also available as plain text.

383 -- Avoid idioms that may not be familiar to the user or that may not make sense when translated.

384 -- Avoid local, cultural, or historical references that may be unfamiliar to users.

385 -- Prioritize active, direct language.

386 -- Avoid referring to someone's age unless it is directly relevant; likewise, avoid referring to people with age-related

387 - descriptors like "young" or "elderly."

388 -- Avoid disability-related idioms like "lame" or "falling on deaf ears." Don't refer to a person's disability unless

389 - it’s directly relevant to what you're writing.

390 -- Don't call groups of people "guys." Don't call women "girls."

391 -- Avoid gendered terms in favor of neutral alternatives, like "server" instead of "waitress" and "businessperson"

392 - instead of "businessman."

393 -- When writing about a person, use their communicated pronouns. When in doubt, just ask or use their name. It's OK to

394 - use "they" as a singular pronoun.

395 -

396 -> Some of these guidelines were adapted from MailChimp under the Creative Commons license.

397 -

398 -## Language, grammar, and mechanics

399 -

400 -To ensure Netdata's writing is clear, concise, and universal, we have established standards for language, grammar, and

401 -certain writing mechanics. However, if you're writing about Netdata for an external publication, such as a guest blog

402 -post, follow that publication's style guide or standards, while keeping

403 -the [preferred spelling of Netdata terms](#netdata-specific-terms) in mind.

404 -

405 -### Active voice

406 -

407 -Active voice is more concise and easier to understand compared to passive voice. When using active voice, the subject of

408 -the sentence is action. In passive voice, the subject is acted upon. A famous example of passive voice is the phrase

409 -"mistakes were made."

410 -

411 -| | |

412 -|-----------------|-------------------------------------------------------------------------------------------|

413 -| Not recommended | When an alarm is triggered by a metric, a notification is sent by Netdata. |

414 -| **Recommended** | When a metric triggers an alarm, Netdata sends a notification to your preferred endpoint. |

415 -

416 -### Second person

417 -

418 -Use the second person ("you") to give instructions or "talk" directly to users.

419 -

420 -In these situations, avoid "we," "I," "let's," and "us," particularly in documentation. The "you" pronoun can also be

421 -implied, depending on your sentence structure.

422 -

423 -One valid exception is when a member of the Netdata team or community wants to write about said team or community.

424 -

425 -| | |

426 -|--------------------------------|--------------------------------------------------------------|

427 -| Not recommended | To install Netdata, we should try the one-line installer... |

428 -| **Recommended** | To install Netdata, you should try the one-line installer... |

429 -| **Recommended**, implied "you" | To install Netdata, try the one-line installer... |

430 -

431 -### "Easy" or "simple"

432 -

433 -Using words that imply the complexity of a task or feature goes against our policy

434 -of [universal communication](#universal-communication). If you claim that a task is easy and the reader struggles to

435 -complete it, you may inadvertently discourage them.

436 -

437 -However, if you give users two options and want to relay that one option is genuinely less complex than another, be

438 -specific about how and why.

439 -

440 -For example, don't write, "Netdata's one-line installer is the easiest way to install Netdata." Instead, you might want

441 -to say, "Netdata's one-line installer requires fewer steps than manually installing from source."

442 -

443 -### Slang, metaphors, and jargon

444 -

445 -A particular word, phrase, or metaphor you're familiar with might not translate well to the other cultures featured

446 -among Netdata's global community. We recommended you avoid slang or colloquialisms in your writing.

447 -

448 -In addition, don't use abbreviations that have not yet been defined in the content. See our section on

449 -[abbreviations](#abbreviations-acronyms-and-initialisms) for additional guidance.

450 -

451 -If you must use industry jargon, such as "mean time to resolution," define the term as clearly and concisely as you can.

452 -

453 -> Netdata helps you reduce your organization's mean time to resolution (MTTR), which is the average time the responsible

454 -> team requires to repair a system and resolve an ongoing incident.

455 -

456 -### Spelling

457 -

458 -While the Netdata team is mostly *not* American, we still aspire to use American spelling whenever possible, as it is

459 -the standard for the monitoring industry.

460 -

461 -See the [word list](#word-list) for spellings of specific words.

462 -

463 -### Capitalization

464 -

465 -Follow the general [English standards](https://owl.purdue.edu/owl/general_writing/mechanics/help_with_capitals.html) for

466 -capitalization. In summary:

467 -

468 -- Capitalize the first word of every new sentence.

469 -- Don't use uppercase for emphasis. (Netdata is the BEST!)

470 -- Capitalize the names of brands, software, products, and companies according to their official guidelines. (Netdata,

471 - Docker, Apache, NGINX)

472 -- Avoid camel case (NetData) or all caps (NETDATA).

473 -

474 -Whenever you refer to the company Netdata, Inc., or the open-source monitoring agent the company develops, capitalize

475 -**Netdata**.

476 -

477 -However, if you are referring to a process, user, or group on a Linux system, use lowercase and fence the word in an

478 -inline code block: `` `netdata` ``.

479 -

480 -| | |

481 -|-----------------|------------------------------------------------------------------------------------------------|

482 -| Not recommended | The netdata agent, which spawns the netdata process, is actively maintained by netdata, inc. |

483 -| **Recommended** | The Netdata Agent, which spawns the `netdata` process, is actively maintained by Netdata, Inc. |

484 -

485 -#### Capitalization of document titles and page headings

486 -

487 -Document titles and page headings should use sentence case. That means you should only capitalize the first word.

488 -

489 -If you need to use the name of a brand, software, product, and company, capitalize it according to their official

490 -guidelines.

491 -

492 -Also, don't put a period (`.`) or colon (`:`) at the end of a title or header.

493 -

494 -| | |

495 -|-----------------|-----------------------------------------------------------------------------------------------------|

496 -| Not recommended | Getting Started Guide <br />Service Discovery and Auto-Detection: <br />Install netdata with docker |

497 -| **Recommended** | Getting started guide <br />Service discovery and auto-detection <br />Install Netdata with Docker |

498 -

499 -### Abbreviations (acronyms and initialisms)

500 -

501 -Use abbreviations (including [acronyms and initialisms](https://www.dictionary.com/e/acronym-vs-abbreviation/)) in

502 -documentation when one exists, when it's widely accepted within the monitoring/sysadmin community, and when it improves

503 -the readability of a document.

504 -

505 -When introducing an abbreviation to a document for the first time, give the reader both the spelled-out version and the

506 -shortened version at the same time. For example:

507 -

508 -> Use Netdata to monitor Extended Berkeley Packet Filter (eBPF) metrics in real-time.

509 -> After you define an abbreviation, don't switch back and forth. Use only the abbreviation for the rest of the document.

510 -

511 -You can also use abbreviations in a document's title to keep the title short and relevant. If you do this, you should

512 -still introduce the spelled-out name alongside the abbreviation as soon as possible.

513 -

514 -### Clause order

515 -

516 -When instructing users to take action, give them the context first. By placing the context in an initial clause at the

517 -beginning of the sentence, users can immediately know if they want to read more, follow a link, or skip ahead.

518 -

519 -| | |

520 -|-----------------|--------------------------------------------------------------------------------|

521 -| Not recommended | Read the reference guide if you'd like to learn more about custom dashboards. |

522 -| **Recommended** | If you'd like to learn more about custom dashboards, read the reference guide. |

523 -

524 -### Oxford comma

525 -

526 -The Oxford comma is the comma used after the second-to-last item in a list of three or more items. It appears just

527 -before "and" or "or."

528 -

529 -| | |

530 -|-----------------|------------------------------------------------------------------------------|

531 -| Not recommended | Netdata can monitor RAM, disk I/O, MySQL queries per second and lm-sensors. |

532 -| **Recommended** | Netdata can monitor RAM, disk I/O, MySQL queries per second, and lm-sensors. |

533 -

534 -### Future releases or features

535 -

536 -Do not mention future releases or upcoming features in writing unless they have been previously communicated via a

537 -public roadmap.

538 -

539 -In particular, documentation must describe, as accurately as possible, the Netdata Agent _as of

540 -the [latest commit](https://github.com/netdata/netdata/commits/master) in the GitHub repository_. For Netdata Cloud,

541 -documentation must reflect the *current state* of [production](https://app.netdata.cloud).

542 -

543 -### Informational links

544 -

545 -Every link should clearly state its destination. Don't use words like "here" to describe where a link will take your

546 -reader.

547 -

548 -| | |

549 -|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------|

550 -| Not recommended | To install Netdata, click [here](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md). |

551 -| **Recommended** | To install Netdata, read the [installation instructions](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md). |

552 -

553 -Use links as often as required to provide necessary context. Blog posts and guides require less hyperlinks than

554 -documentation. See the section on [linking between documentation](#linking-between-documentation) for guidance on the

555 -Markdown syntax and path structure of inter-documentation links.

556 -

557 -### Contractions

558 -

559 -Contractions like "you'll" or "they're" are acceptable in most Netdata writing. They're both authentic and playful, and

560 -reinforce the idea that you, as a writer, are guiding users through a particular idea, process, or feature.

561 -

562 -Contractions are generally not used in press releases or other media engagements.

563 -

564 -### Emoji

565 -

566 -Emoji can add fun and character to your writing, but should be used sparingly and only if it matches the content's tone

567 -and desired audience.

568 -

569 -### Switching Linux users

570 -

571 -Netdata documentation often suggests that users switch from their normal user to the `netdata` user to run specific

572 -commands. Use the following command to instruct users to make the switch:

573 -

574 -```bash

575 -sudo su -s /bin/bash netdata

576 -```

577 -

578 -### Hostname/IP address of a node

579 -

580 -Use `NODE` instead of an actual or example IP address/hostname when referencing the process of navigating to a dashboard

581 -or API endpoint in a browser.

582 -

583 -| | |

584 -|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

585 -| 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. |

586 -| **Recommended** | Navigate to `http://NODE:19999` in your browser to see Netdata's dashboard. |

587 -

588 -If you worry that `NODE` doesn't provide enough context for the user, particularly in documentation or guides designed

589 -for beginners, you can provide an explanation:

590 -

591 -> With the Netdata Agent running, visit `http://NODE:19999/api/v1/info` in your browser, replacing `NODE` with the IP

592 -> address or hostname of your Agent.

593 -

594 -### Paths and running commands

595 -

596 -When instructing users to run a Netdata-specific command, don't assume the path to said command, because not every

597 -Netdata Agent installation will have commands under the same paths. When applicable, help them navigate to the correct

598 -path, providing a recommendation or instructions on how to view the running configuration, which includes the correct

599 -paths.

600 -

601 -For example, the [configuration](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md) doc first

602 -teaches users how to find the Netdata config

603 -directory and navigate to it, then runs commands from the `/etc/netdata` path so that the instructions are more

604 -universal.

605 -

606 -Don't include full paths, beginning from the system's root (`/`), as these might not work on certain systems.

607 -

608 -| | |

609 -|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

610 -| Not recommended | Use `edit-config` to edit Netdata's configuration: `sudo /etc/netdata/edit-config netdata.conf`. |

611 -| **Recommended** | Use `edit-config` to edit Netdata's configuration by first navigating to your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory), which is typically at `/etc/netdata`, then running `sudo edit-config netdata.conf`. |

612 -

613 -### `sudo`

614 -

615 -Include `sudo` before a command if you believe most Netdata users will need to elevate privileges to run it. This makes

616 -our writing more universal, and users on `sudo`-less systems are generally already aware that they need to run commands

617 -differently.

618 -

619 -For example, most users need to use `sudo` with the `edit-config` script, because the Netdata config directory is owned

620 -by the `netdata` user. Same goes for restarting the Netdata Agent with `systemctl`.

621 -

622 -| | |

623 -|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------|

624 -| Not recommended | Run `edit-config netdata.conf` to configure the Netdata Agent. <br />Run `systemctl restart netdata` to restart the Netdata Agent. |

625 -| **Recommended** | Run `sudo edit-config netdata.conf` to configure the Netdata Agent. <br />Run `sudo systemctl restart netdata` to restart the Netdata Agent. |

626 -

627 -## Markdown syntax

628 -

629 -Netdata's documentation uses Markdown syntax.

630 -

631 -If you're not familiar with Markdown, read the [Mastering

632 -Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on creating

633 -paragraphs, styled text, lists, tables, and more.

634 -

635 -The following sections describe situations in which a specific syntax is required.

636 -

637 -### Syntax standards (`remark-lint`)

638 -

639 -The Netdata team uses [`remark-lint`](https://github.com/remarkjs/remark-lint) for Markdown code styling.

640 -

641 -- Use a maximum of 120 characters per line.

642 -- Begin headings with hashes, such as `# H1 heading`, `## H2 heading`, and so on.

643 -- Use `_` for italics/emphasis.

644 -- Use `**` for bold.

645 -- Use dashes `-` to begin an unordered list, and put a single space after the dash.

646 -- Tables should be padded so that pipes line up vertically with added whitespace.

647 -

648 -If you want to see all the settings, open the

649 -[`remarkrc.js`](https://github.com/netdata/netdata/blob/master/.remarkrc.js) file in the `netdata/netdata` repository.

650 -

651 -### MDX and markdown

652 -

653 -While writing in Docusaurus, you might want to take leverage of it's features that are supported in MDX formatted files.

654 -One of those that we use is [Tabs](https://docusaurus.io/docs/next/markdown-features/tabs). They use an HTML syntax,

655 -which requires some changes in the way we write markdown inside them.

656 -

657 -In detail:

658 -

659 -Due to a bug with docusaurus, we prefer to use `<h1>heading</h1> instead of # H1` so that docusaurus doesn't render the

660 -contents of all Tabs on the right hand side, while not being able to navigate

661 -them [relative link](https://github.com/facebook/docusaurus/issues/7008).

662 -

663 -You can use markdown syntax for every other styling you want to do except Admonitions:

664 -For admonitions, follow [this](https://docusaurus.io/docs/markdown-features/admonitions#usage-in-jsx) guide to use

665 -admonitions inside JSX. While writing in JSX, all the markdown stylings have to be in HTML format to be rendered

666 -properly.

667 -

668 -### Frontmatter

669 -

670 -Every document must begin with frontmatter, followed by an H1 (`#`) heading.

671 -

672 -Unlike typical Markdown frontmatter, Netdata uses HTML comments (``) to begin and end the frontmatter block.

673 -These HTML comments are later converted into typical frontmatter syntax when building [Netdata

674 -Learn](https://learn.netdata.cloud).

675 -

676 -Frontmatter *must* contain the following variables:

677 -

678 -- A `title` that quickly and distinctly describes the document's content.

679 -- A `description` that elaborates on the purpose or goal of the document using no less than 100 characters and no more

680 - than 155 characters.

681 -- A `custom_edit_url` that links directly to the GitHub URL where another user could suggest additional changes to the

682 - published document.

683 -

684 -Some documents, like the Ansible guide and others in the `/docs/guides` folder, require an `image` variable as well. In

685 -this case, replace `/docs` with `/img/seo`, and then rebuild the remainder of the path to the document in question. End

686 -the path with `.png`. A member of the Netdata team will assist in creating the image when publishing the content.

687 -

688 -For example, here is the frontmatter for the guide

689 -about [deploying the Netdata Agent with Ansible](https://github.com/netdata/netdata/blob/master/packaging/installer/methods/ansible.md).

690 -

691 -<img width="751" alt="image" src="https://user-images.githubusercontent.com/43294513/217607958-ef0f270d-7947-4d91-a9a5-56b17b4255ee.png">

692 -

693 -

694 -Questions about frontmatter in documentation? [Ask on our community

695 -forum](https://community.netdata.cloud/c/blog-posts-and-articles/6).

696 -

697 -### Admonitions

698 -

699 -In addition to basic markdown syntax, we also encourage the use of admonition syntax, which allows for a more

700 -aesthetically seamless presentation of supplemental information. For general instructions on using admonitions, feel

701 -free to read this [feature guide](https://docusaurus.io/docs/markdown-features/admonitions).

702 -

703 -We encourage the use of **Note** admonitions to provide important supplemental information to a user within a task step,

704 -reference item, or concept passage.

705 -

706 -Additionally, you should use a **Caution** admonition to provide necessary information to present any risk to a user's

707 -setup or data.

708 -

709 -**Danger** admonitions should be avoided, as these admonitions are typically applied to reduce physical or bodily harm

710 -to an individual.

711 -

712 -### Linking between documentation

713 -

714 -Documentation should link to relevant pages whenever it's relevant and provides valuable context to the reader.

715 -

716 -We link between markdown documents by using its GitHub absolute link for

717 -instance `[short description of what we reference](https://github.com/netdata/netdata/blob/master/contribution-guidelines.md)`

718 -

719 -### References to UI elements

720 -

721 -When referencing a user interface (UI) element in Netdata, reference the label text of the link/button with Markdown's

722 -(`**bold text**`) tag.

723 -

724 -```markdown

725 -Click the **Sign in** button.

726 -```

727 -

728 -Avoid directional language whenever possible. Not every user can use instructions like "look at the top-left corner" to

729 -find their way around an interface, and interfaces often change between devices. If you must use directional language,

730 -try to supplement the text with an [image](#images).

731 -

732 -### Images

733 -

734 -Don't rely on images to convey features, ideas, or instructions. Accompany every image with descriptive alt text.

735 -

736 -In Markdown, use the standard image syntax, `![](/docs/agent/contributing)`, and place the alt text between the

737 -brackets `[]`. Here's an example

738 -using our logo:

739 -

740 -```markdown

741 -![The Netdata logo](/docs/agent/web/gui/static/img/netdata-logomark.svg)

742 -```

743 -

744 -Reference in-product text, code samples, and terminal output with actual text content, not screen captures or other

745 -images. Place the text in an appropriate element, such as a blockquote or code block, so all users can parse the

746 -information.

747 -

748 -### Syntax highlighting

749 -

750 -Our documentation site at [learn.netdata.cloud](https://learn.netdata.cloud) uses

751 -[Prism](https://v2.docusaurus.io/docs/markdown-features#syntax-highlighting) for syntax highlighting. Netdata

752 -documentation will use the following for the most part: `c`, `python`, `js`, `shell`, `markdown`, `bash`, `css`, `html`,

753 -and `go`. If no language is specified, Prism tries to guess the language based on its content.

754 -

755 -Include the language directly after the three backticks (```` ``` ````) that start the code block. For highlighting C

756 -code, for example:

757 -

758 -````c

759 -```c

760 -inline char *health_stock_config_dir(void) {

761 - char buffer[FILENAME_MAX + 1];

762 - snprintfz(buffer, FILENAME_MAX, "%s/health.d", netdata_configured_stock_config_dir);

763 - return config_get(CONFIG_SECTION_DIRECTORIES, "stock health config", buffer);

764 -}

765 -```

766 -````

767 -

768 -And the prettified result:

769 -

770 -```c

771 -inline char *health_stock_config_dir(void) {

772 - char buffer[FILENAME_MAX + 1];

773 - snprintfz(buffer, FILENAME_MAX, "%s/health.d", netdata_configured_stock_config_dir);

774 - return config_get(CONFIG_SECTION_DIRECTORIES, "stock health config", buffer);

775 -}

776 -```

777 -

778 -Prism also supports titles and line highlighting. See

779 -the [Docusaurus documentation](https://v2.docusaurus.io/docs/markdown-features#code-blocks) for more information.

780 -

781 -## Word list

782 -

783 -The following tables describe the standard spelling, capitalization, and usage of words found in Netdata's writing.

784 -

785 -### Netdata-specific terms

786 -

787 -| Term | Definition |

788 -|----------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

789 -| **claimed node** | A node that you've proved ownership of by completing the [connecting to Cloud process](https://github.com/netdata/netdata/blob/master/claim/README.md). The claimed node will then appear in your Space and any War Rooms you added it to. |

790 -| **Netdata** | The company behind the open-source Netdata Agent and the Netdata Cloud web application. Never use *netdata* or *NetData*. <br /><br />**Note:** You should use "Netdata" when referencing any general element, function, or part of the user experience. 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*. |

791 -| **Netdata Agent** or **Open-source 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. <br /><br /> **Note:** You should avoid referencing the Netdata Agent or Open-source Netdata agent in any scenario that does not specifically require the distinction for clear instructions. |

792 -| **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 />**Notes:** Never use *Cloud* without the preceding *Netdata* to avoid ambiguity. You should avoid referencing Netdata Cloud in any scenario that does not specifically require the distinction for clear instructions. | |

793 -| **Netdata community** | Contributors to any of Netdata's [open-source projects](https://github.com/netdata/learn/blob/master/contribute/projects.md), members of the [community forum](https://community.netdata.cloud/). |

794 -| **Netdata community forum** | The Discourse-powered forum for feature requests, Netdata Cloud technical support, and conversations about Netdata's monitoring and troubleshooting products. |

795 -| **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. |

796 -| **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. |

797 -| **unreachable node** | A connected node with a disrupted [Agent-Cloud link](https://github.com/netdata/netdata/blob/master/aclk/README.md). Unreachable could mean the node no longer exists or is experiencing network connectivity issues with Cloud. |

798 -| **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. |

799 -| **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. |

800 -

801 -### Other technical terms

802 -

803 -| Term | Definition |

804 -|-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

805 -| **filesystem** | Use instead of *file system*. |

806 -| **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#simple-to-deploy). |

807 -| **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. |

docs/contributing/style-guide.md

+60 -20

@@ -1,13 +1,14 @@

1 # Netdata style guide

3 -The _Netdata style guide_ establishes editorial guidelines for any writing produced by the Netdata team or the Netdata

4 -community, including documentation, articles, in-product UX copy, and more. Both internal Netdata teams and external

5 -contributors to any of Netdata's open-source projects should reference and adhere to this style guide as much as

6 -possible.

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.

8 -Netdata's writing should **empower** and **educate**. You want to help people understand Netdata's value, encourage them

9 -to learn more, and ultimately use Netdata's products to democratize monitoring in their organizations. To achieve these

10 -goals, your writing should be:

5 +> ### Note

6 +> This document is meant to be accompanied by the [Documentation Guidelines](https://github.com/netdata/netdata/blob/master/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:

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,

@@ -347,17 +348,6 @@ The Netdata team uses [`remark-lint`](https://github.com/remarkjs/remark-lint) f

348 If you want to see all the settings, open the

349 [`remarkrc.js`](https://github.com/netdata/netdata/blob/master/.remarkrc.js) file in the `netdata/netdata` repository.

350

350 -### Linking between documentation

351 -

352 -Documentation should link to relevant pages whenever it's relevant and provides valuable context to the reader.

353 -

354 -Links should always reference the full path to the document, beginning at the root of the Netdata Agent repository

355 -(`/`), and ending with the `.md` file extension. Avoid relative links or traversing up directories using `../`.

356 -

357 -For example, if you want to link to our node configuration document, link

358 -to `https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md`. To reference

359 -the guide for deploying the Netdata Agent with Ansible, link to `/packaging/installer/methods/ansible.md`.

360 -

351 ### References to UI elements

352

353 When referencing a user interface (UI) element in Netdata, reference the label text of the link/button with Markdown's

@@ -419,6 +409,58 @@ inline char *health_stock_config_dir(void) {

409 Prism also supports titles and line highlighting. See

410 the [Docusaurus documentation](https://v2.docusaurus.io/docs/markdown-features#code-blocks) for more information.

411

412 +### Adding Notes

413 +

414 +Notes inside files should render properly both in GitHub and in Learn, to do that, it is best to use the format listed below:

415 +

416 +```

417 +> ### Note

418 +> This is an info or a note block.

419 +

420 +> ### Tip, Best Practice

421 +> This is a tip or a best practice block.

422 +

423 +> ### Warning, Caution

424 +> This is a warning or a caution block.

425 +```

426 +

427 +Which renders into:

428 +

429 +

430 +> ### Note

431 +> This is an info or a note block.

432 +

433 +> ### Tip, Best Practice

434 +> This is a tip or a best practice block.

435 +

436 +> ### Warning, Caution

437 +> This is a warning or a caution block.

438 +

439 +### Tabs

440 +

441 +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:

442 +

443 +```

444 +

445 +<Tabs>

446 +<TabItem value="tab1" label="tab1">

447 +

448 +<h3> Header for tab1 </h3>

449 +

450 +text for tab1, both visible in GitHub and Docusaurus

451 +

452 +

453 +</TabItem>

454 +<TabItem value="tab2" label="tab2">

455 +

456 +<h3> Header for tab2 </h3>

457 +

458 +text for tab2, both visible in GitHub and Docusaurus

459 +

460 +</TabItem>

461 +</Tabs>

462 +```

463 +

464 ## Word list

465

466 The following tables describe the standard spelling, capitalization, and usage of words found in Netdata's writing.

@@ -445,5 +487,3 @@ The following tables describe the standard spelling, capitalization, and usage o

487 | **filesystem** | Use instead of _file system_. |

488 | **preconfigured** | The concept that many of Netdata's features come with sane defaults that users don't need to configure to find immediate value. |

489 | **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. |

448 -

449 -

docs/guidelines.md

+27 -40

@@ -1,65 +1,54 @@

1 # Contribute to the documentation

3 -import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';

4 -

3 Welcome to our docs developer guidelines!

7 -This document will guide you to the process of contributing to our

8 -docs (**learn.netdata.cloud**)

5 +This document will guide you to the process of contributing to our docs (**learn.netdata.cloud**)

7 ## Documentation architecture

12 -Our documentation in https://learn.netdata.cloud is generated by markdown documents in the public

13 -Github repositories of the "netdata" organization.

9 +Our documentation in <https://learn.netdata.cloud> is generated by markdown documents in the public Github repositories of the "netdata" organization.

10 +

11 +The structure of the documentation is handled by a [map](https://github.com/netdata/learn/blob/master/map.tsv) file, that contains metadata for every markdown files in the repos we ingest from.

12 +

13 +Then the ingest script parses that map and organizes the markdown files accordingly.

15 ### Improve existing documentation

17 -The easiest way to contribute to Netdata's documentation is to edit a file directly on GitHub. This is perfect for small

18 -fixes to a single document, such as fixing a typo or clarifying a confusing sentence.

17 +The easiest way to contribute to Netdata's documentation is to edit a file directly on GitHub. This is perfect for small fixes to a single document, such as fixing a typo or clarifying a confusing sentence.

20 -Each published document on [Netdata Learn](https://learn.netdata.cloud) includes at the bottom a link to

21 -**Edit this page**. Clicking on that link is the recommended way to improve our documentation, as it

22 -leads you directly to GitHub's code editor.

19 +Each published document on [Netdata Learn](https://learn.netdata.cloud) includes at the bottom a link to **Edit this page**.

20 +Clicking on that link is the recommended way to improve our documentation, as it leads you directly to GitHub's code editor.

21 Make your suggested changes, and use the ***Preview changes*** button to ensure your Markdown syntax works as expected.

25 -Under the **Commit changes** header, write descriptive title for your requested change. Click the **Commit changes**

26 -button to initiate your pull request (PR).

23 +Under the **Commit changes** header, write descriptive title for your requested change. Click the **Commit changes** button to initiate your pull request (PR).

25 Jump down to our instructions on [PRs](#making-a-pull-request) for your next steps.

27 ### Create a new document

32 -You can create a pull request to add a completely new markdown document in any of our public repositories.

33 -After the Github pull request is merged, our documentation team will decide where in the documentation hierarchy to publish

34 -that document.

29 +You can create a pull request to add a completely new markdown document in any of our public repositories.

30 +After the Github pull request is merged, our documentation team will decide where in the documentation hierarchy to publish that document.

36 -If you wish to contribute documentation that is tailored to your specific infrastructure

37 -monitoring/troubleshooting experience, please consider submitting a blog post about your experience.

38 -Check out our [blog](https://github.com/netdata/blog#readme) repo! Any blog submissions that have

39 -widespread or universal application will be integrated into our permanent documentation.

32 +If you wish to contribute documentation that is tailored to your specific infrastructure monitoring/troubleshooting experience, please consider submitting a blog post about your experience.

33 +

34 +Check out our [blog](https://github.com/netdata/blog#readme) repo! Any blog submissions that have widespread or universal application will be integrated into our permanent documentation.

36 #### Before you get started

43 -Anyone interested in contributing significantly to documentation should first read the

44 -[Netdata style guide](https://github.com/netdata/netdata/blob/master/docs/contributing/style-guide.md)

45 -and the [Netdata Community Code of Conduct](https://github.com/netdata/.github/blob/main/CODE_OF_CONDUCT.md).

38 +Anyone interested in contributing significantly to documentation should first read the [Netdata style guide](https://github.com/netdata/netdata/blob/master/docs/contributing/style-guide.md) and the [Netdata Community Code of Conduct](https://github.com/netdata/.github/blob/main/CODE_OF_CONDUCT.md).

47 -Netdata's documentation uses Markdown syntax. If you're not familiar with Markdown, read

48 -the [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on

49 -creating paragraphs, styled text, lists, tables, and more.

40 +Netdata's documentation uses Markdown syntax. If you're not familiar with Markdown, read the [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) guide from GitHub for the basics on creating paragraphs, styled text, lists, tables, and more.

42 #### Edit locally

53 -Editing documentation locally is the preferred method for completely new documents, or complex changes that span multiple

54 -documents. Clone the repository where you wish to make your changes, work on a new branch and create a pull request

55 -with that branch.

44 +Editing documentation locally is the preferred method for completely new documents, or complex changes that span multiple documents. Clone the repository where you wish to make your changes, work on a new branch and create a pull request with that branch.

46 ### Links to other documents

59 -Please ensure that any links to a different documentation resource are fully expanded URLs to the relevant markdown document,

60 -not links to learn.netdata.cloud.

48 +Please ensure that any links to a different documentation resource are fully expanded URLs to the relevant markdown document, not links to "learn.netdata.cloud".

50 e.g.

51 +

52 ```

53 [Correct link to this document](https://github.com/netdata/netdata/blob/master/docs/guidelines.md)

54 vs

@@ -68,17 +57,15 @@ vs

58 This permalink ensures that the link will not be broken by any future restructuring in learn.netdata.cloud.

71 -You can see the URL to the source of any published documentation page in the **Edit this page** link at the bottom. If you

72 -just replace `edit` with `blob` in that URL, you have the permalink to the original markdown document.

60 +You can see the URL to the source of any published documentation page in the **Edit this page** link at the bottom.

61 +If you just replace `edit` with `blob` in that URL, you have the permalink to the original markdown document.

63 ### Making a pull request

76 -Pull requests (PRs) should be concise and informative. See our

77 -[PR guidelines](https://github.com/netdata/.github/blob/main/CONTRIBUTING.md#pr-guidelines) for

78 -specifics.

65 +Pull requests (PRs) should be concise and informative.

66 +See our [PR guidelines](https://github.com/netdata/.github/blob/main/CONTRIBUTING.md#pr-guidelines) for specifics.

80 -The Netdata team will review your PR and assesses it for correctness, conciseness, and overall quality. We may point to

81 -specific sections and ask for additional information or other fixes.

68 +The Netdata team will review your PR and assesses it for correctness, conciseness, and overall quality.

69 +We may point to specific sections and ask for additional information or other fixes.

83 -After merging your PR, the Netdata team rebuilds the [documentation site](https://learn.netdata.cloud) to publish the

84 -changed documentation.

71 +After merging your PR, the Netdata team rebuilds the [documentation site](https://learn.netdata.cloud) to publish the changed documentation.