Documentation Style Guide
TL;DR version:
docs is the marketing website. documentation is the docs.dnscontrol.org website. (Yes, the names are backwards!)The two websites
- 1.
- The main website
- Mostly "marketing" for the project.
- Rarely changes. Updated via GitHub "pages" feature.
- 2.
- Project documentation
- Users and developer documentation
The directory structure
Within the git repo, docs are grouped:
- 1.Add the page to the
documentationfolder (possibly a sub folder) - 2.List the page in
SUMMARY.mdso that it will appear in the table of contents, sidebar, etc.
Files in the
documentation/functions/{record,domain,global} subdirectories have a header at the top that is used to populate other systems.---
name: A
provider: NAMEDOTCOM
parameters:
- name
- address
- modifiers...
parameter_types:
name: string
address: string | number
"modifiers...": RecordModifier[]
---
name: The name of the function/constant in the document. This should match the filename (aside from the.mdsuffix).parameters: These are the names of the parameters that the function accepts.modifiers...indicates that a variable number of modifiers can be added.parameter_types: The typescript type for each parameter. This is used when generatingtypes-dnscontrol.d.tsprovider: If a feature is only available for one provider
"Preview links are only accessible by GitBook users. We're working on a feature that will allow preview links to be viewable by anyone who accesses the PR." — GitBook
Break lines every 80 chars.
Include a blank line between paragraphs.
Leave one blank line before and after a heading.
JavaScript code should use double quotes (
") for strings, not single quotes ('). They are equivalent but consistency is good.# Title of the page
## Heading
At least one paragraph.
## Subheadings
At least one paragraph.
* **Step 1: Foo**
Description of the step.
* **Step 2: Bar**
Description of the step.
(further sub sub headings are discouraged encouraged)
See the examples below, for the Markdown syntax click on the 'Source code'.
Long example: (with filename)
dnsconfig.js
var REG_NONE = NewRegistrar("none");
var DNS_BIND = NewDnsProvider("bind");
D("example.com", REG_NONE, DnsProvider(DNS_BIND),
A("@", "1.2.3.4")
);
Long example: (without filename)
var REG_NONE = NewRegistrar("none");
var DNS_BIND = NewDnsProvider("bind");
D("example.com", REG_NONE, DnsProvider(DNS_BIND),
A("@", "1.2.3.4")
);
Hints are a great way to bring the reader's attention to specific elements in your documentation.
There are 4 different types of hints, and both inline content and formatting are supported.
Info hints are great for showing general information, or providing tips and tricks.
Success hints are good for showing positive actions or achievements.
Warning hints are good for showing important information or non-critical warnings.
Danger hints are good for highlighting destructive actions or raising attention to critical information.
Not every mention to A, CNAME, or function needs to be a link to the manual for that record type. However, the first mention on a page should always be a link. Others are at the authors digression.
The [`PTR`](functions/domain/PTR.md) feature is helpful in LANs.
The function `GetRegistrarCorrections()` returns...
Blah blah blah [M365_BUILDER](functions/record/M365_BUILDER.md)
NOTE: The
.md is required.Just list the URL.
Blah blah blah <https://www.google.com> blah blah.
Blah blah blah [a search engine](https://www.google.com) blah blah.
Please spellcheck documents before submitting a PR.
Don't be surprised if Tom rewrites your text. He often does that to keep the documentation consistent and make it more approachable by new users. It's not because he has a big ego. Well, not usually.