Skip to main content

Section 47.4 Documentation

Careful documentation must accompany new features. You cannot leave this task for somebody else to clean-up after you, and writing the documentation is likely to cause you to revisit your code to introduce small improvements or squash bugs.

New PreTeXt language elements are described briefly in the overview at ChapterĀ 3. This should make new authors aware of what elements are available, and maybe have enough instruction to get them started. Then the topics at ChapterĀ 4 should have full details. These two sections should link back-and-forth to each other. Examples are welcome, but should be short and succinct. Elaborate examples should be contributed to the Showcase Article.

New options for publishers should be detailed very tersely in the reference section, ChapterĀ 43. This section is organized lexicographically with respect to the XPath expressions describing the entries of the publication file. Then a more careful description, with examples if necessary, should appear in one of the chapters of the publisher part (PartĀ IV) according to which aspects of a conversion are affected. These two sections should link back-and-forth to each other.

Here are some conventions to follow, which will help authors and publishers have a better experience wandering through the Guide. Please observe them in your own contributions.

  • The Guide.

    We usually just say ā€œthe Guideā€ or ā€œin this Guideā€, with no additional formatting, and just the capital ā€œGā€ indicative of a formal title.

  • Modularization.

    When an author's source is modularized (SectionĀ 5.3) we refer to the outermost, or main, file as the ā€œtop-levelā€ file. This is the one file that has the overall <pretext> element in it.

  • Git Branches.

    Reference the primary branch of a git repository as main.