Skip to content

Documentation Contribution Checklist

Eric Bottard edited this page Jun 13, 2013 · 4 revisions

The reference documentation for this project is generated via a docbook toolchain from the contents of this wiki repository. Because this content needs to be consumed both from the github interface and in pdf/html form, there are some constraints to authoring documents in this repository, summarized below.

TOC / Concatenation

The entry point for the full reference documentation is the FullGuide.adoc document. Apart from a header, it contains many include:<document> asciidoc directives which should build the whole document from parts. When viewed on github.com, pages reference a sidebar which allows quick navigation. If you add a section to the reference documentation, don’t forget to add it to both FullGuide.adoc and _Sidebar.asciidoc.

Section nesting

In asciidoc, the so-called level 0 titles (=My Title) translate to the document name in docbook. Subsequent level 0 sections translate to <part>`s in docbook. Hence each new document page should have level 1 sections as its title (== My Title`). Nevertheless, github.com already displays the file name of a document when viewed online. As such, that title should not be part of your document. It should only be added to the FullGuide.adoc file. As a consequence, the top-level sections in your files should be level 2 titles (=== My title) and they’ll render Ok in both github.com and the concatenated documentation.

To recap, let’s imagine you want to add the Awesome section to the documentation. Here are the impacts on the FullGuide.adoc and Awesome.asciidoc

To allow consumption as both separate documents on github.com and as a concatenated document, all links between documents should have the following form:

link:<document>#<anchor>[<Label>]

where

<document>

is the name of the 'page' (for example 'Streams')

<anchor>

identifies a location on the document that we want to address. This needs to be created in the target page using the [[<anchor>]] notation. When viewed on github.com, that anchor may not exist (because it is declared in the TOC file — FullGuide.adoc). This is not a problem as an inexistent anchor ends up as giving focus to the top of the page.

<label>

gives a readable text to display as the link text

Behind the scenes, such links are rewritten in the docbook/html generation phase by the gradle build to the following form, suitable for a single asciidoc document:

xref:<anchor>[<Label>]

Clone this wiki locally