|
2 | 2 |
|
3 | 3 | Welcome to the repository for the [Replicated documentation site](https://docs.replicated.com/). |
4 | 4 |
|
5 | | -## Contribute to the Replicated Docs |
6 | | - |
7 | | -This repository has been made public so that vendors and the open-source community can contribute to the content using the following methods: |
8 | | - |
9 | | -- **Submit a PR** You can submit a PR directly from a specific topic in the documentation by clicking the **Create pull request or raise issue on GitHub** at the bottom of the page. This method lets you edit the content directly and commit your changes on a new branch. After submitting your proposed changes, the Replicated team will verify the accuracy of the changes and perform an editorial review. If the PR is approved, it will be merged directly into the main branch. |
10 | | - |
11 | | -- **Open a Github Issue** - To open a GitHub issue for this repository, click the Issues tab and click **New Issue**. This method may be more useful when you want to report a bug specifically for the documentation. If you are having an issue with the product itself, we encourage you to report it to us in a support issue submitted in the vendor portal. |
| 5 | +## Contribute to Replicated Docs |
| 6 | + |
| 7 | +This repository has been made public so that the Replicated community can contribute to the content. |
| 8 | + |
| 9 | +### Submit a PR |
| 10 | + |
| 11 | +You can submit a PR directly from a specific topic in the documentation by clicking **Propose Changes** at the bottom of the page. This method lets you edit the content directly and commit your changes on a new branch. After submitting your proposed changes, the Replicated Docs team will verify the accuracy of the changes and perform an editorial review. If the PR is approved, it will be merged directly into the main branch. |
| 12 | + |
| 13 | +### Open a Github Issue |
| 14 | + |
| 15 | +You can open a GitHub issue in this repo to provide feedback or report a bug for the documentation. To open an issue, either go to **Issues > New Issue** in this repo in GitHub, or click **Provide Feedback** at the bottom of any page in the documentation. |
| 16 | + |
| 17 | +If you are having an issue with the product itself, report it to the Replicated team in a support issue submitted in the Vendor Portal. |
| 18 | + |
| 19 | +## Style Guide |
| 20 | + |
| 21 | +The Replicated docs use the Google Developer Docs Style Guide: https://developers.google.com/style/. Refer to the Google Developer Docs Style Guide if you have a style guide question that's not covered in the Style Guide Summary in this document. |
| 22 | + |
| 23 | +The following is a summary of the most important elements of our style guide, plus some house rules that aren't captured or differ from what's in the Google Developer Docs Style Guide: |
| 24 | + |
| 25 | +- Word Choice, Tone, and Voice: |
| 26 | + - Use active voice |
| 27 | + - Use the second person "you" to address the reader. Never use "let's" or "we" to refer to an action that the user is doing |
| 28 | + - Instead of "we", use "Replicated" to talk about recommendations/suggestions. As in "Replicated recommends that you test your releases..." |
| 29 | + - Use present tense (for example, use "returns" and not "will return") |
| 30 | + - Write in a friendly tone without using slang, jargon, or frivolous words |
| 31 | + - Avoid marketing language that is overly promotional |
| 32 | + - Avoid terms like "simple" or "easy" |
| 33 | + - Use common words. Don't use words like "utilize" or "leverage" when you mean "use". This make the docs more suitable for a global audience |
| 34 | + - Try to use fewer than 26 words per sentence |
| 35 | + - Avoid time-bound terminology like "currently", "new", "at this time", and "now". Instead, write timeless documentation that makes no assumptions about a reader's prior knowledge. |
| 36 | + |
| 37 | +- Formatting: |
| 38 | + - Use bold text only to identify UI elements. For example, "Click **Save**." Do not use bold text for emphasis. |
| 39 | + - Use title case for titles and headings |
| 40 | + - Use a bare infinitive verb form for how-to titles/headings. As in, use "Create a Release" instead of "Creating a Release" |
| 41 | + - Procedural/how-to content must use numbered steps. For one-step procedures, use a bullet point. See https://developers.google.com/style/procedures#single-step-procedures for examples |
| 42 | + - Use the following formats for cross references: |
| 43 | + - "For more information about X, see [Topic Title](mdc:url)" |
| 44 | + - "For more information about X, see [Section Heading](mdc:url#section-heading) in _Topic Title_." |
| 45 | + - "For more information about X, see [Section Heading](#section-heading) in this document." |
| 46 | + - We use "Note" and "Important" admonitions. |
| 47 | + - Notes are for informational asides. Only use notes if the info is relevant but not required to succeed in whatever the user is doing right now. Don't use notes to state expected results or to include information that simply describes what precedes. |
| 48 | + ```md |
| 49 | + :::note |
| 50 | + note content |
| 51 | + ::: |
| 52 | + ``` |
| 53 | + - Important admonitions are to provide cautionary/warning messages. |
| 54 | + ```md |
| 55 | + :::impotant |
| 56 | + important content |
| 57 | + ::: |
| 58 | + ``` |
| 59 | + |
| 60 | +### Cheatsheet for Generating Content with LLMs |
| 61 | + |
| 62 | +When generating content for Replicated Docs with LLMs, add the following to the context window: |
| 63 | + |
| 64 | +```md |
| 65 | +- Refer to the style guidelines in this repo at `README.md` |
| 66 | +- Don't add Troubleshooting, Best Practices, Conclusion, Summary, or Next Steps sections unless specifically asked |
| 67 | +- Never use bold text for emphasis or as section/category headings |
| 68 | +- Don't repeat the same information mutiple times. Focus on being concise and using as few words as possible to get the point across |
| 69 | +- Use paragraphs instead of bulleted lists unless specifically asked |
| 70 | +``` |
| 71 | + |
| 72 | +### Use the @doc-reviewer Claude Subagent |
| 73 | + |
| 74 | +The `@docs-reviewer` subagent reviews documentation files against this style guide and identifies issues with suggestions for fixes. You can use it to help you catch common style problems before submitting PRs. |
| 75 | + |
| 76 | +To use it, invoke `@docs-reviewer` in Claude Desktop or Claude Code and specify the file you want reviewed. |
| 77 | + |
| 78 | +For example: |
| 79 | +``` |
| 80 | +@docs-reviewer please review docs/example.md |
| 81 | +``` |
12 | 82 |
|
13 | 83 | ## Folder Structure and Sidebar |
14 | 84 |
|
|
0 commit comments