From b02306af01179efa8c93b543e732f2275ece4c96 Mon Sep 17 00:00:00 2001 From: Gervase Markham Date: Mon, 27 Jan 2014 15:12:04 +0000 Subject: Bug 960969 - Write documentation style guide. r=LpSolit, a=justdave. --- docs/en/rst/style.rst | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 docs/en/rst/style.rst (limited to 'docs/en') diff --git a/docs/en/rst/style.rst b/docs/en/rst/style.rst new file mode 100644 index 000000000..8fd9dc037 --- /dev/null +++ b/docs/en/rst/style.rst @@ -0,0 +1,101 @@ +:orphan: + +============================== +Writing Bugzilla Documentation +============================== + +The Bugzilla documentation uses +`reStructured Text (reST) `_, +as extended by our documentation compilation tool, +`Sphinx `_. This document is a reST document for +demonstration purposes. When you build the docs, it gets built (at least in +the HTML version) as a standalone file, although it isn't as readable in that +form because some of the directives discussed are invisible or change when +rendered. + +`The Sphinx documentation `_ +gives a good introduction to reST and the Sphinx-specific extensions. Reading +that one immediately-linked page should be enough to get started. Later, the +`inline markup section `_ +is worth a read. + +Bugzilla's particular documentation conventions are as follows. + +Block Directives +################ + +Every heading should be preceded by an anchor, with a globally-unique name +with no spaces. Then we demonstrate the available heading levels we haven't +used yet: + +.. _uniqueanchorname: + +Third Level Heading +=================== + +Fourth Level Heading +-------------------- + +Fifth Level Heading +~~~~~~~~~~~~~~~~~~~ + +(Although try not to use headings as deep as the 5th level.) + +Make links to anchors like this: :ref:`uniqueanchorname`. It'll pick up the +following heading name automatically and use it as the link text. Don't use +standard reST internal links like `uniqueanchorname`_ - they don't work +across files. + +Comments are done like this: + +.. This is a comment. It can go on to multiple lines. Follow-on lines need to + be indented. + +Other block types: + +.. note:: This is just a note, for your information. Like all double-dot + blocks, follow-on lines need to be indented. + +.. warning:: This is a warning of a potential serious problem you should be + aware of. + +Use both of the above block types sparingly. Consider putting the information +in the main text, omitting it, or (if long) placing it in a subsidiary file. + +Code gets highlighted using Pygments. Choose the highlighter at the top of +each file using: + +.. highlight:: console + +You can change the highlighter for a particular block by introducing it like +this: + +.. code-block:: perl + + # This is some Perl code + print "Hello"; + +There is a +`list of all available lexer names `_ +available. We currently use ``console``, ``perl``, and ``sql``. ``none`` is +also a valid value. + +Inline Directives +################# + +.. warning:: Remember that reST does not support nested inline markup. So you + can't have a substitution inside a link, or bold inside italics. + +A filename or a path to a filename is displayed like this: +:file:`/path/to/filename.ext` + +A command to type in the shell is displayed like this: +:command:`command --arguments` + +We place static values for substitution (using |subst-name|) in the file +:file:`$BUGZILLA_HOME/docs/definitions.rst.tmpl`. +This gets built into definitions.rst, with the script adding some definitions +for minimum module versions etc. generated from the source itself. Lines in +that file look like this: + +.. |subst-name| replace:: Some Text Here -- cgit v1.2.3-24-g4f1b