Artem Titov | a617867 | 2023-01-30 10:51:01 | [diff] [blame] | 1 | <!-- go/cmark --> |
| 2 | <!--* freshness: {owner: 'titovartem' reviewed: '2023-01-16'} *--> |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 3 | |
Artem Titov | a617867 | 2023-01-30 10:51:01 | [diff] [blame] | 4 | # How to write WebRTC documentation |
Artem Titov | 0f2ce5c | 2023-01-26 20:18:46 | [diff] [blame] | 5 | |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 6 | ## Audience |
| 7 | |
| 8 | Engineers and tech writers who wants to contribute to WebRTC documentation |
| 9 | |
| 10 | ## Conceptual documentation |
| 11 | |
| 12 | Conceptual documentation provides overview of APIs or systems. Examples can |
| 13 | be threading model of a particular module or data life cycle. Conceptual |
| 14 | documentation can skip some edge cases in favor of clarity. The main point |
| 15 | is to impart understanding. |
| 16 | |
| 17 | Conceptual documentation often cannot be embedded directly within the source |
Artem Titov | a617867 | 2023-01-30 10:51:01 | [diff] [blame] | 18 | code because it usually describes multiple APIs and entities, so the only |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 19 | logical place to document such complex behavior is through a separate |
| 20 | conceptual document. |
| 21 | |
| 22 | A concept document needs to be useful to both experts and novices. Moreover, |
| 23 | it needs to emphasize clarity, so it often needs to sacrifice completeness |
| 24 | and sometimes strict accuracy. That's not to say a conceptual document should |
| 25 | intentionally be inaccurate. It just means that is should focus more on common |
| 26 | usage and leave rare ones or side effects for class/function level comments. |
| 27 | |
| 28 | In the WebRTC repo, conceptual documentation is located in `g3doc` subfolders |
| 29 | of related components. To add a new document for the component `Foo` find a |
| 30 | `g3doc` subfolder for this component and create a `.md` file there with |
Artem Titov | a617867 | 2023-01-30 10:51:01 | [diff] [blame] | 31 | desired documentation. If there is no `g3doc` subfolder, create a new one. |
| 32 | |
| 33 | Please put the following file header into any created documentation file as the |
| 34 | first line: |
| 35 | |
| 36 | ```markdown |
| 37 | <!-- go/cmark --> |
| 38 | ``` |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 39 | |
| 40 | When you want to specify a link from one page to another - use the absolute |
| 41 | path: |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 42 | |
| 43 | ``` |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 44 | [My document](/module/g3doc/my_document.md) |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 45 | ``` |
| 46 | |
| 47 | If you are a Googler also please specify an owner, who will be responsible for |
| 48 | keeping this documentation updated, by adding the next lines at the beginning |
| 49 | of your `.md` file immediately after page title: |
| 50 | |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 51 | ```markdown |
Artem Titov | a617867 | 2023-01-30 10:51:01 | [diff] [blame] | 52 | <!--* freshness: {owner: '<user name>' reviewed: '<last review date in format yyyy-mm-dd>' *--> |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 53 | ``` |
| 54 | |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 55 | After the document is ready you should add it into `/g3doc/sitemap.md`, so it |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 56 | will be discoverable by others. |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 57 | |
| 58 | ### Documentation format |
| 59 | |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 60 | The documentation is written in GitHub Markdown |
| 61 | ([spec](https://github.github.com/gfm/#:~:text=GitHub%20Flavored%20Markdown%2C%20often%20shortened,a%20strict%20superset%20of%20CommonMark.)). |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 62 | |
| 63 | ## Class/function level comments |
| 64 | |
Xavier Décoret | 967d4cd | 2021-03-30 08:10:04 | [diff] [blame] | 65 | Documentation of specific classes and function APIs and their usage, including |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 66 | their purpose, is embedded in the .h files defining that API. See |
Fanny Linderborg | 0d2dc1f | 2021-07-14 14:02:11 | [diff] [blame] | 67 | [C++ style guide](https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++.md) |
Artem Titov | 8647340 | 2021-03-12 11:42:24 | [diff] [blame] | 68 | for pointers on how to write API documentatin in .h files. |