|
1 | 1 | <!-- vale off -->
|
| 2 | +<!-- markdownlint-disable MD033 --> |
2 | 3 |
|
3 | 4 | # Contributing to Fluent Bit docs
|
4 | 5 |
|
5 |
| -First of all, thanks for taking the time to read this guide. The fact that you're |
6 |
| -here means you're interested in contributing to Fluent Bit, and we highly appreciate |
7 |
| -your time. |
| 6 | +First of all, thanks for taking the time to read this guide. The fact that you're here means you're interested in contributing to Fluent Bit, and we highly appreciate your time. |
8 | 7 |
|
9 |
| -This repository contains the files for the |
10 |
| -[Fluent Bit documentation library](https://docs.fluentbit.io/). Keeping these docs |
11 |
| -separate from the [main Fluent Bit repository](https://github.com/fluent/fluent-bit) |
12 |
| -helps reduce the number of commits to the Fluent Bit source code and makes it |
13 |
| -easier to maintain both projects. |
| 8 | +This repository contains the files for the [Fluent Bit documentation library](https://docs.fluentbit.io/). Keeping these docs separate from the [main Fluent Bit repository](https://github.com/fluent/fluent-bit) helps reduce the number of commits to the Fluent Bit source code and makes it easier to maintain both projects. |
14 | 9 |
|
15 |
| -Fluent Bit has a group of dedicated maintainers who oversee this repository, |
16 |
| -including several technical writers. These writers will review any pull requests |
17 |
| -you open, so don't be afraid to contribute—even if you're not a writer by trade. |
18 |
| -Your suggestions are valuable, and we'll help you wrangle any stray commas. |
| 10 | +Fluent Bit has a group of dedicated maintainers who oversee this repository, including several technical writers. These writers will review any pull requests you open, so don't be afraid to contribute—even if you're not a writer by trade. Your suggestions are valuable, and we'll help you wrangle any stray commas. |
19 | 11 |
|
20 |
| -## GitBook |
| 12 | +## :star: Quick tips |
21 | 13 |
|
22 |
| -The Fluent Bit docs library is built and hosted through |
23 |
| -[GitBook](https://docs.gitbook.com/). Unfortunately, GitBook doesn't support |
24 |
| -local previews for contributors, but a Fluent Bit maintainer with a dedicated GitBook |
25 |
| -account can verify that things are formatted correctly after you open a new pull |
26 |
| -request. |
| 14 | +- [Sign off](#sign-off-your-git-commits) your Git commits. |
| 15 | +- Use [soft line wraps](#line-wraps) in Markdown files. |
| 16 | +- To link between pages, use [absolute file paths](#links). |
| 17 | +- Review the results of [linters](#linters) for style and formatting guidance. |
27 | 18 |
|
28 |
| -Each `.md` file in this repository is a single page. You can use |
29 |
| -[standard Markdown syntax](https://docs.gitbook.com/content-editor/editing-content/markdown) |
30 |
| -to edit existing pages, or create a new `.md` file to add an additional page to |
31 |
| -the docs library. If you create a new page, you'll also need to update |
32 |
| -[GitBook's `SUMMARY.md` file](https://docs.gitbook.com/integrations/git-sync/content-configuration#structure) |
33 |
| -(or request that a maintainer to update it for you). |
| 19 | +## Review process |
34 | 20 |
|
35 |
| -## Workflow |
| 21 | +After you open a pull request in this repository, a Fluent Bit maintainer will review it, add comments or suggestions as needed, and then merge it. After your changes are successfully merges into `master`, the docs site will update within a few minutes. |
36 | 22 |
|
37 |
| -After you open a pull request in this repository, a Fluent Bit maintainer will review |
38 |
| -it, triage it, add comments or suggestions as needed, and then merge it. After |
39 |
| -your changes are successfully merged into `master`, the docs site will update |
40 |
| -within a few minutes. |
| 23 | +### Request review without merging |
41 | 24 |
|
42 |
| -### Stale pull requests |
43 |
| - |
44 |
| -If you open a pull request that requires ongoing discussion or review, the Fluent Bit |
45 |
| -maintainers will add a `waiting-for-user` to your pull request. This tag means that |
46 |
| -we're blocked from moving forward until you reply. To keep contributions from going |
47 |
| -stale, we'll wait 45 days for your response, but we might close the pull request if we |
48 |
| -don't hear back from you by then. |
| 25 | +If you're contributing documentation for a Fluent Bit feature that's still in development, add the `waiting-on-code-merge` label to a pull request. This lets the maintainers know that your changes are ready for review but not ready to be merged. |
49 | 26 |
|
50 |
| -## Submit a contribution |
| 27 | +### Stale pull requests |
51 | 28 |
|
52 |
| -When you open a pull request, make your changes against `master`, which is the |
53 |
| -active development branch. If your contribution also applies to the latest |
54 |
| -stable version, submit another PR for that versioned branch. However, if |
55 |
| -submitting multiple PRs at the same time adds too much complexity, you can instead |
56 |
| -create a single PR against `master` and specify that your changes need to be |
57 |
| -**backported** to other branches; one of our maintainers will take care of that |
58 |
| -process on your behalf. |
| 29 | +If you open a pull request that requires extended discussion or review, the Fluent Bit maintainers will add a `waiting-for-user` label to your pull request. This label means that we're blocked from moving forward until you reply. To keep contributions from going stale, we'll wait 45 days for your response, but we might close the pull request if we don't hear back from you by then. |
59 | 30 |
|
60 |
| -All contributions must be made **first** against [master branch](https://github.com/fluent/fluent-bit-docs/tree/master) which is the active development branch, and then if the contribution also applies for the current stable branch, submit another PR for that specific branch, if submitting another PR adds some complexity, specify in the first PR as a comment (for master branch) that it needs to be backported. One of the maintainers will take care of that process. |
| 31 | +## Pass DCO checks |
61 | 32 |
|
62 |
| -As a contributor, we'll ask you to follow a few best practices related to Git: |
| 33 | +To pass this repository's [DCO checks](https://github.com/apps/dco), you'll need to adhere to the following Git practices. |
63 | 34 |
|
64 |
| -### One file per commit |
| 35 | +### Set your email in Git |
65 | 36 |
|
66 |
| -Each commit you make should only modify one file or interface, following the same |
67 |
| -practice as commits to the Fluent Bit source code. |
| 37 | +To sign commits properly, you must first set your email address in your local Git environment. This should be the same email address associated with your GitHub account. |
68 | 38 |
|
69 |
| -### Commit subjects |
| 39 | +For more information, refer to GitHub's guide to [setting your commit email address in Git](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#setting-your-commit-email-address-in-git). |
70 | 40 |
|
71 |
| -Use descriptive commit subjects that describe which file or interface you're |
72 |
| -modifying. |
| 41 | +### Sign off your Git commits |
73 | 42 |
|
74 |
| -For example, if you're modifying the Syslog output plugin doc, whose file is |
75 |
| -located at [pipeline/outputs/syslog.md](https://github.com/fluent/fluent-bit-docs/blob/master/pipeline/outputs/syslog.md), this would be a descriptive commit subject: |
| 43 | +You must sign off your commits to certify your identity as the commit author. A commit is "signed off" when its commit message looks like this: |
76 | 44 |
|
77 |
| -`pipeline: outputs: syslog: fix grammar in examples` |
| 45 | +```text |
| 46 | +pipeline: outputs: syslog: fix grammar in examples |
| 47 | +Signed-off-by: Tux <[email protected]> |
| 48 | +``` |
78 | 49 |
|
79 |
| -Because this commit is prefixed with the relevant file's path, it helps the maintainers |
80 |
| -understand and prioritize your contribution. |
| 50 | +For faster signing, you can use the `-s` flag: |
81 | 51 |
|
82 |
| -### Set your email in Git |
| 52 | +`git commit -a -s -m "pipeline: outputs: syslog: fix grammar in examples"` |
83 | 53 |
|
84 |
| -Make sure your email address is configured in your local Git environment. This |
85 |
| -should be the same email address associated with your GitHub account. |
| 54 | +> :bulb: If you're using VSCode, the [**Git: Always Sign Off**](https://github.com/microsoft/vscode/issues/83096#issuecomment-545350047) option automatically appends a `Signed-off-by:` message to all of your commits. |
86 | 55 |
|
87 |
| -For more information, refer to GitHub's guide to |
88 |
| -[setting your commit email address in Git](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#setting-your-commit-email-address-in-git). |
| 56 | +### Fix "DCO is missing" errors |
89 | 57 |
|
90 |
| -### Sign off your commits |
| 58 | +If a DCO error blocks your pull request from merging, refer to this guide about [how to add sign-offs retroactively](https://github.com/src-d/guide/blob/master/developer-community/fix-DCO.md#how-to-add-sign-offs-retroactively). |
91 | 59 |
|
92 |
| -You must sign off your commits to certify your identity as the commit author. If |
93 |
| -you don't sign off your commits, the CI system will flag the pull request with a |
94 |
| -[DCO](https://github.com/src-d/guide/blob/master/developer-community/fix-DCO.md) |
95 |
| -error and prevent your pull request from merging. |
| 60 | +## Style guidelines |
96 | 61 |
|
97 |
| -To prevent DCO errors, refer to the following guide about |
98 |
| -[signing your commits properly](https://github.com/src-d/guide/blob/master/developer-community/fix-DCO.md). |
| 62 | +The Fluent Bit documentation follows the [Google developer documentation style guide](https://developers.google.com/style) for most topics related to grammar and style. We don't expect you |
| 63 | +to memorize these style rules, but the maintainers who review your pull request might suggest changes accordingly. |
99 | 64 |
|
100 |
| -> :bulb: For faster signing, you can use the `-s` flag in Git: |
101 |
| -> |
102 |
| -> `git commit -a -s -m "pipeline: outputs: syslog: fix grammar in examples"` |
103 |
| -> |
104 |
| -> If you're using VSCode, enable the |
105 |
| -> [**Git: Always Sign Off**](https://github.com/microsoft/vscode/issues/83096#issuecomment-545350047) |
106 |
| -> setting, which automatically appends a `Signed-off-by:` message to your commits. |
| 65 | +The active [linters](#linters) in this repository flag certain style errors and, in some cases, explain how to fix them. |
107 | 66 |
|
108 |
| -## Style guidelines |
| 67 | +## Formatting guidelines |
109 | 68 |
|
110 |
| -The Fluent Bit maintainers refer to the |
111 |
| -[Google developer documentation style guide](https://developers.google.com/style) |
112 |
| -for most topics related to grammar, style, and formatting. We don't expect you |
113 |
| -to memorize these style rules, but the technical writer who reviews your pull |
114 |
| -request can suggest changes accordingly. |
| 69 | +The Fluent Bit docs library is built and hosted through [GitBook](https://docs.gitbook.com/). Unfortunately, GitBook doesn't support local previews for contributors, but a Fluent Bit maintainer with a dedicated GitBook account can verify that things are formatted correctly after you open a new pull request. |
115 | 70 |
|
116 |
| -### URLs |
| 71 | +### Links |
117 | 72 |
|
118 |
| -When cross-linking to a page in this repository, use a full absolute path whenever |
| 73 | +When cross-linking between in this repository, use a full absolute path whenever |
119 | 74 | possible. For example:
|
120 | 75 |
|
121 | 76 | ```text
|
122 | 77 | [LTSV](../pipeline/parsers/ltsv.md) and [Logfmt](../pipeline/parsers/logfmt.md)
|
123 | 78 | ```
|
124 | 79 |
|
125 |
| -## Additional testing |
| 80 | +### Line wraps |
| 81 | + |
| 82 | +When GitBook renders pages, it treats all newlines literally, which means hard line wraps in Markdown files create awkward line breaks in the Fluent Bit docs site. Due to this, docs contributions must use soft line wraps. |
| 83 | + |
| 84 | +<details> |
| 85 | +<summary>:white_check_mark: Example: soft line wraps</summary> |
| 86 | + |
| 87 | +```text |
| 88 | +Soft-wrapped text uses newlines only to mark the end of a paragraph. From the perspective of a text editor, this means each paragraph looks like a single, unbroken line of text. |
| 89 | +
|
| 90 | +After two newlines, another paragraph begins. |
| 91 | +``` |
| 92 | + |
| 93 | +</details> |
| 94 | + |
| 95 | +<details> |
| 96 | +<summary>:no_entry_sign: Example: hard line wraps</summary> |
| 97 | + |
| 98 | +```text |
| 99 | +Hard-wrapped text uses newlines |
| 100 | +in the middle of sentences and |
| 101 | +paragraphs. |
| 102 | +
|
| 103 | +This can make text easier for |
| 104 | +humans to read, but GitBook |
| 105 | +renders hard line wraps |
| 106 | +awkwardly. |
| 107 | +``` |
| 108 | + |
| 109 | +</details> |
| 110 | + |
| 111 | +### Quotes |
| 112 | + |
| 113 | +By default, Google Docs and Microsoft Word turn standard straight quotes into "smart" |
| 114 | +curly quotes. If you copy-paste from one of these tools, you must correct the quotes back to straight quotes. You can also turn off smart quotes in [Google Docs](https://support.google.com/docs/thread/217182974/can-i-turn-smart-quotes-off-in-a-google-doc?hl=en) or [Microsoft Word](https://support.microsoft.com/en-us/office/smart-quotes-in-word-and-powerpoint-702fc92e-b723-4e3d-b2cc-71dedaf2f343) to prevent this problem. |
| 115 | + |
| 116 | +### Table of contents |
| 117 | + |
| 118 | +When you create a new `.md` file for a new page, you must add an entry to this repository's [`SUMMARY.md` file](https://github.com/fluent/fluent-bit-docs/blob/master/SUMMARY.md) (or ask a maintainer to add it on your behalf). If you don't update `SUMMARY.md`, the new page won't appear in the table of contents on the Fluent Bit docs site. |
| 119 | + |
| 120 | +## Linters |
126 | 121 |
|
127 |
| -Fluent Bit uses additional tests for style and consistency. Your maintainers |
128 |
| -suggest installing and applying the suggestions from these linters. |
| 122 | +This repository runs linters as GitHub Actions for each pull request. If a linter finds errors or makes suggested changes, you can view these results in the **Files changed** tab. |
| 123 | + |
| 124 | +<details> |
| 125 | +<summary>:white_check_mark: Examples: linter results</summary> |
| 126 | + |
| 127 | + |
| 128 | + |
| 129 | + |
| 130 | + |
| 131 | + |
| 132 | + |
| 133 | +</details> |
129 | 134 |
|
130 | 135 | ### Vale
|
131 | 136 |
|
132 |
| -The Fluent Bit maintainers use the [Vale](https://vale.sh/docs/) plugin, which lints |
133 |
| -the prose of your pull requests and adds suggestions to improve style and clarity. |
134 |
| -There is a [VSCode plugin for Vale](https://marketplace.visualstudio.com/items?itemName=ChrisChinchilla.vale-vscode) |
135 |
| -which outputs suggestions to the problems pane in the IDE. |
136 |
| - |
137 |
| -The Fluent Bit repository runs Vale as a GitHub Action on updated text in new pull |
138 |
| -requests. Vale suggestions, errors, and warnings will display in GitHub on the |
139 |
| -**Files changed** page. |
140 |
| - |
141 |
| -[See the Vale tests for Fluent Bit](https://github.com/fluent/fluent-bit-docs/tree/master/vale-styles). |
142 |
| - |
143 |
| -Most Vale tests are at the `suggestion` level and won't block merging. |
144 |
| - |
145 |
| -The following tests are at `error` level and will cause a test failure: |
146 |
| - |
147 |
| -- [AmSpelling](https://developers.google.com/style/word-list) |
148 |
| -- [Ampersand](https://developers.google.com/style/word-list#ampersand) |
149 |
| -- [Don'tUse](https://github.com/fluent/fluent-bit-docs/blob/master/vale-styles/FluentBit/DontUse.yml) |
150 |
| -- [Emdash](https://github.com/errata-ai/Google/blob/master/Google/EmDash.yml) |
151 |
| -- [Endash](https://github.com/errata-ai/Google/blob/master/Google/EmDash.yml) |
152 |
| -- [Exclamation](https://github.com/errata-ai/Google/blob/master/Google/Exclamation.yml) |
153 |
| -- [Gender](https://developers.google.com/style/pronouns#gender-neutral-pronouns) |
154 |
| -- [GenderBias](https://developers.google.com/style/inclusive-documentation) |
155 |
| -- [Hints](https://github.com/fluent/fluent-bit-docs/blob/master/vale-styles/FluentBit/Hints.yml) using `>`. |
156 |
| -- [HeadingPunctuation](https://developers.google.com/style/capitalization#capitalization-in-titles-and-headings) |
157 |
| -- [Latin](https://developers.google.com/style/abbreviations) |
158 |
| -- [LyHyphens](https://developers.google.com/style/hyphens) |
159 |
| -- [MayMightCan](https://github.com/fluent/fluent-bit-docs/blob/master/vale-styles/FluentBit/MayMightCan.yml) |
160 |
| -- [NonStandardQuotes](https://github.com/fluent/fluent-bit-docs/blob/master/vale-styles/FluentBit/NonStandardQuotes.yml): |
161 |
| - [Use standard quotes](https://developers.google.com/style/quotation-marks#straight-and-curly-quotation-marks). |
162 |
| - By default, Google Docs and Microsoft Word turn standard straight quotes into "smart" |
163 |
| - curly quotes. If you copy-paste from one of these tools, you must correct the quotes |
164 |
| - back to straight quotes. You can also turn off smart quotes |
165 |
| - in [Google Docs](https://support.google.com/docs/thread/217182974/can-i-turn-smart-quotes-off-in-a-google-doc?hl=en) |
166 |
| - or [Microsoft Word](https://support.microsoft.com/en-us/office/smart-quotes-in-word-and-powerpoint-702fc92e-b723-4e3d-b2cc-71dedaf2f343) |
167 |
| - to prevent this problem. |
168 |
| -- [Optional plurals](https://developers.google.com/style/plurals-parentheses) |
169 |
| -- [Ordinal](https://developers.google.com/style/numbers) |
170 |
| -- [Periods](https://developers.google.com/style/abbreviations) |
171 |
| -- [Ranges](https://developers.google.com/style/hyphens) |
172 |
| -- [Repetition](https://github.com/errata-ai/vale/blob/v3/testdata/styles/Markup/Repetition.yml): |
173 |
| - Checks for the same word used twice in succession. |
174 |
| -- [Slang](https://developers.google.com/style/abbreviations) |
175 |
| -- [Spacing](https://developers.google.com/style/sentence-spacing) |
176 |
| - |
177 |
| -The following tests are at a `warning` level and won't prevent merging: |
178 |
| - |
179 |
| -- [Ampersand](https://developers.google.com/style/word-list#ampersand) |
180 |
| -- [First person](https://developers.google.com/style/pronouns#personal-pronouns) |
181 |
| -- [Possessives](https://developers.google.com/style/possessives) |
182 |
| -- [Simplicity](https://developers.google.com/style/word-list#easy) |
| 137 | +[Vale](https://vale.sh/docs/) lints prose for style and clarity. In addition to reviewing the results of each Vale action in GitHub, you can use the [Vale plugin for VSCode](https://marketplace.visualstudio.com/items?itemName=ChrisChinchilla.vale-vscode) to view errors and suggestions locally. |
| 138 | + |
| 139 | +Vale tests for the Fluent Bit docs are stored in the [`/vale-styles`](https://github.com/fluent/fluent-bit-docs/tree/master/vale-styles) folder. Most Vale tests are at the `suggestion` or `warning` level and won't block pull requests from merging. However, tests at the `error` level will block merging until the associated issue is fixed. |
183 | 140 |
|
184 | 141 | ### Markdownlint
|
185 | 142 |
|
186 |
| -[Markdownlint](https://github.com/markdownlint/markdownlint) checks markdown in a |
187 |
| -file and makes suggestions for improvements. Most markdownlint tests are enabled. |
188 |
| -[See the configuration file](https://github.com/fluent/fluent-bit-docs/blob/master/.markdownlint.json). |
| 143 | +[Markdownlint](https://github.com/markdownlint/markdownlint) lints Markdown formatting and makes suggestions for improvements. |
| 144 | + |
| 145 | +Markdownlint tests for the Fluent Bit docs are stored in [`markdownlint.json`](https://github.com/fluent/fluent-bit-docs/blob/master/.markdownlint.json). These tests don't block pull requests from merging. |
| 146 | + |
| 147 | +## Additional resources |
189 | 148 |
|
190 |
| -The Fluent Bit documentation repository is using a GitHub action to check for invalid |
191 |
| -markdown based on the configuration file. This action might provide review |
192 |
| -suggestions, but doesn't block merging. |
| 149 | +For general guidance about writing documentation, consult the following resources: |
193 | 150 |
|
194 |
| -Line wrap tests are off due to a GitBook decision that hard wraps the rendered page |
195 |
| -on line wraps in the markdown. This leads to rendered pages with awkward line wraps. |
| 151 | +- [Open Source Technical Documentation Essentials (LFC111)](https://training.linuxfoundation.org/training/open-source-technical-documentation-essentials-lfc111/) |
| 152 | +- [Creating Effective Documentation for Developers (LFC112)](https://training.linuxfoundation.org/training/creating-effective-documentation-for-developers-lfc112/) |
| 153 | +- [Google Technical Writing Courses for Engineers](https://developers.google.com/tech-writing) |
196 | 154 |
|
197 | 155 | <!-- vale on -->
|
| 156 | +<!-- markdownlint-disable MD033 --> |
0 commit comments