|
| 1 | +# Sei Docs style guide |
| 2 | + |
| 3 | +This style guide contains general rules and principles to ensure the documentation is cohesive, useful and organized. |
| 4 | + |
| 5 | +## Principles |
| 6 | + |
| 7 | +This documentation strives to be |
| 8 | + |
| 9 | +### Beginner Friendly |
| 10 | +The Sei community welcomes members from all walks of life. As such, the documentation should be understandable by anyone, including those who are new to Web3 or non-technical. |
| 11 | + |
| 12 | +The docs should strive to be Jargon Free |
| 13 | +- Advanced terms and concepts, especially Web3 related terms and ideas, should be properly explained. |
| 14 | +- Where appropriate, we should provide links to resources that can help the reader understand. |
| 15 | +- Acronyms should be spelled out |
| 16 | + |
| 17 | + |
| 18 | +### Simple |
| 19 | + |
| 20 | +Great documentation is simple and to the point. It should aim to convey more meaning with less words. |
| 21 | + |
| 22 | +- To be clear and inclusive, avoid using jargon and obscure words where possible. |
| 23 | +- Limit the number of clauses in a sentence and make sure that your points are structured. |
| 24 | +- Avoid qualifying language, which is ~~quite~~ often ~~completely~~ uneccessary. |
| 25 | +- Information should be simply organized and easy to find. |
| 26 | + |
| 27 | +### Self-explanatory |
| 28 | + |
| 29 | +Great documentation is self-explanatory. Documentation shouldn't need more documentation to explain itself. |
| 30 | +- Aim to provide as much context as possible. Code snippets and diagrams are great ways to illustrate complex concepts and provide examples. |
| 31 | + |
| 32 | +## Organization |
| 33 | + |
| 34 | +The Sei Docs are structured using the [Nextra](https://nextra.site). Are a guideline, we have split the pages by target audience. |
| 35 | + |
| 36 | +### General |
| 37 | +Docs in these section describe Sei and topics that are applicable to all audiences. This is general information that is not specfic to users or developers. Information here is meant to be as layman as possible and should be understandable by everyone. |
| 38 | + |
| 39 | +Information here might include: |
| 40 | +- What is Sei? |
| 41 | +- How does a blockchain work? |
| 42 | +- General information about how things work. |
| 43 | + |
| 44 | +### For Users |
| 45 | +This section includes information specific to enabling people to interact with the Sei blockchain. |
| 46 | + |
| 47 | +Examples include information about standard resources used to interact with the chain (Wallets, Block Explorers), as well as tutorials on how to get started on Sei (Where to find tokens, apps etc.) |
| 48 | + |
| 49 | +### For Devs |
| 50 | +This section includes resources for developers looking to build Dapps on Sei. Examples of what goes in here include: |
| 51 | +- Smart contract tutorials |
| 52 | +- Endpoints and config information that developers should use to interact with Sei (RPC Endpoints, Chain IDs etc) |
| 53 | +- Information about clients and libraries that developers can use to easily develop apps. |
| 54 | + |
| 55 | +### Advanced |
| 56 | +This section covers topics that are more specific to chain infrastructure. These are topics that are typically abstracted away from regular users and developers, but might be relevant to those looking to contribute chain infrastructure. Examples of topics here include: |
| 57 | +- How to run a Sei Node |
| 58 | +- How to run a Sei Validator |
| 59 | + |
| 60 | +### Misc |
| 61 | +This section houses other pages that do not fall under the buckets above. |
| 62 | + |
| 63 | +## Style guidelines |
| 64 | + |
| 65 | +### Acronyms and Abbreviations |
| 66 | + |
| 67 | +To maximize clarity, we should avoid Acronyms and Abbreviations where possible, especially for shorter, more ambiguous acronyms |
| 68 | +- Just use 'CosmWasm' instead of 'CW' |
| 69 | + |
| 70 | +However, there are occasions where acronyms might be more easily understandable (Eg. NFT instead of Non-Fungible Token, RPC instead of Remote Procedure Call), or referred to very frequently. |
| 71 | + |
| 72 | +In these cases, we should first use the use the spelled-out term followed by the shortened form in parentheses. |
| 73 | +- Command Line Interface (CLI) |
| 74 | +- Denomination (Denom) |
| 75 | + |
| 76 | +On subsequent occurrences in the same topic, we can then use the acronym. |
| 77 | + |
| 78 | +### Links |
| 79 | + |
| 80 | +You can add links to text using the followings syntax |
| 81 | +```md |
| 82 | +[text_to_highlight](link) |
| 83 | +``` |
| 84 | + |
| 85 | +Some examples (These examples assume the page is in the `/pages` directory): |
| 86 | +1. Link to section of [same document](#style-guidelines). |
| 87 | +```md |
| 88 | +[same document](#style-guidelines) |
| 89 | +``` |
| 90 | + |
| 91 | +2. Link to [another document](/pages/overview.mdx). |
| 92 | +```md |
| 93 | +# Path is relative |
| 94 | +[another document](/overview) |
| 95 | +``` |
| 96 | + |
| 97 | +3. Link to [section of another document](/pages/overview.mdx#Staking). |
| 98 | +```md |
| 99 | +[section of another document](/overview#Staking) |
| 100 | +``` |
| 101 | + |
| 102 | +4. External [Link](www.app.sei.io). |
| 103 | +```md |
| 104 | +[Link](www.app.sei.io) |
| 105 | +``` |
| 106 | + |
| 107 | +Sentence ending punctuation should always be included outside the link. |
| 108 | + |
| 109 | +Links should be as descriptive as possible to let the reader know where they are going. |
| 110 | + |
| 111 | +- Bad Example: Interested to learn more about staking? Click [here](#links) to find out more |
| 112 | + |
| 113 | +- Better Example: Interested to learn more about staking? Refer to our [staking guide](#links) to find out more! |
| 114 | + |
| 115 | + |
| 116 | +### Code |
| 117 | +Code should either be specified as `inline` |
| 118 | +```md |
| 119 | +Code should either be specified as `inline` |
| 120 | +``` |
| 121 | + |
| 122 | +Or within code blocks. |
| 123 | +```ts |
| 124 | +const codeBlockString = "codeBlock" |
| 125 | +``` |
| 126 | + |
| 127 | +```md |
| 128 | + ```ts |
| 129 | + const codeBlockString = "codeBlock" |
| 130 | + ``` |
| 131 | +``` |
| 132 | +
|
| 133 | +`Inline Code` should be used when referring to |
| 134 | +- File and directory names. (eg. `./pages/overview.mdx`) |
| 135 | +- References to variables in code (eg. `codeBlockString`) |
| 136 | +
|
| 137 | +Code Blocks should be used when |
| 138 | +- Sharing code snippets |
| 139 | +```ts |
| 140 | +const codeBlockString = () => { |
| 141 | + const text = "codeblock" |
| 142 | + let codeBlockSize: Number = 1 |
| 143 | +} |
| 144 | +``` |
| 145 | + |
| 146 | +- Scripts that users should copy and execute directly |
| 147 | +```sh |
| 148 | +git clone https://github.com/sei-protocol/sei-chain |
| 149 | +cd sei-chain |
| 150 | +git checkout v4.1.4-evm-devnet |
| 151 | +make install |
| 152 | +``` |
| 153 | + |
| 154 | +When code blocks are used, they should always be prettified by specifying the language. For example: |
| 155 | +```md |
| 156 | + TypeScript code block labelled with 'ts' |
| 157 | + ```ts |
| 158 | + const variable = value; |
| 159 | + ``` |
| 160 | + |
| 161 | + Bash command line code block labelled with 'sh' |
| 162 | + ```sh |
| 163 | + git clone https://github.com/sei-protocol/sei-chain |
| 164 | + cd sei-chain |
| 165 | + ``` |
| 166 | +``` |
| 167 | +
|
| 168 | +When writing code blocks, avoid |
| 169 | +1. Creating large code blocks. Break your code into smaller, more digestible pieces. |
| 170 | +2. Writing too much documentation in between lines. If neccessary, break the code block up and add text to explain each code block instead. |
| 171 | +
|
| 172 | +For tutorials, the goal should be to write code blocks that can be directly copied and used by the reader. |
| 173 | +
|
| 174 | +Remember, code is used to elaborate or provide an example, make your point clearly first before using code to substantiate it! |
| 175 | +
|
| 176 | +### Headings |
| 177 | +
|
| 178 | +Headings should be use to denote the start of each section. There are 4 levels of headings that correspond to different sizes (avoid using anything more than level 4 headings) |
| 179 | +
|
| 180 | +``` |
| 181 | +# Page Title |
| 182 | +## Main Topic(s) on page |
| 183 | +### Sub Topics |
| 184 | +#### Use only if more required |
| 185 | +``` |
| 186 | +
|
| 187 | +Headings levels should never be skipped. A level 2 heading should follow a level 1 heading, and a level 3 heading should follow a level 2 heading etc. |
| 188 | +
|
| 189 | +### Images |
| 190 | +
|
| 191 | +To use images, first add them to the `./public/assets` folder. |
| 192 | +
|
| 193 | +Afterwards, they can be imported in each page using an import statement. For example: |
| 194 | +```md |
| 195 | +import nameOfImage from "../../public/assets/nameOfImage.png"; |
| 196 | +``` |
| 197 | + |
| 198 | +Lastly, use the `ImageWithCaption` component to add the image to the page, along with a descriptive label: |
| 199 | +```md |
| 200 | +<ImageWithCaption img={nameOfImage} alt="alt text for my image" caption="Your caption here" /> |
| 201 | +``` |
0 commit comments