Skip to content

Commit 43dad41

Browse files
update contributors guide
Signed-off-by: Alexa Kreizinger <[email protected]>
1 parent 47748d9 commit 43dad41

File tree

4 files changed

+105
-146
lines changed

4 files changed

+105
-146
lines changed
46.1 KB
Loading
27.7 KB
Loading
25.2 KB
Loading

CONTRIBUTING.md

Lines changed: 105 additions & 146 deletions
Original file line numberDiff line numberDiff line change
@@ -1,197 +1,156 @@
11
<!-- vale off -->
2+
<!-- markdownlint-disable MD033 -->
23

34
# Contributing to Fluent Bit docs
45

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

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

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

20-
## GitBook
12+
## :star: Quick tips
2113

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

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
3420

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

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
4124

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

50-
## Submit a contribution
27+
### Stale pull requests
5128

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

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
6132

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

64-
### One file per commit
35+
### Set your email in Git
6536

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

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).
7040

71-
Use descriptive commit subjects that describe which file or interface you're
72-
modifying.
41+
### Sign off your Git commits
7342

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:
7644

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+
```
7849

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:
8151

82-
### Set your email in Git
52+
`git commit -a -s -m "pipeline: outputs: syslog: fix grammar in examples"`
8353

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.
8655
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
8957

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).
9159

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
9661

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

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

108-
## Style guidelines
67+
## Formatting guidelines
10968

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

116-
### URLs
71+
### Links
11772

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
11974
possible. For example:
12075

12176
```text
12277
[LTSV](../pipeline/parsers/ltsv.md) and [Logfmt](../pipeline/parsers/logfmt.md)
12378
```
12479

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
126121

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+
![An example of a warning-level Vale result.](/.gitbook/assets/vale-example-warning.png)
128+
129+
![An example of an error-level Vale result.](/.gitbook/assets/vale-example-error.png)
130+
131+
![An example of a Markdownlint result.](/.gitbook/assets/markdownlint-example.png)
132+
133+
</details>
129134

130135
### Vale
131136

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

184141
### Markdownlint
185142

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
189148

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:
193150

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)
196154

197155
<!-- vale on -->
156+
<!-- markdownlint-disable MD033 -->

0 commit comments

Comments
 (0)