From c3337914cd017a93515a95dbc742f5c731797165 Mon Sep 17 00:00:00 2001
From: Karl Fogel <kfogel@red-bean.com>
Date: Thu, 28 Sep 2023 22:08:34 -0500
Subject: [PATCH] Merge material from old OTS public docs repository
https://github.com/OpenTechStrategies/docs/commit/63400bdbf90258e
---
.gitignore | 1 +
CONTRIBUTING.md | 100 ++++++++++++++-
Makefile | 7 +
README.md | 4 +
foss-dev-checklist.md | 202 +++++++++++++++++++++++++++++
pandoc.template | 288 ++++++++++++++++++++++++++++++++++++++++++
6 files changed, 600 insertions(+), 2 deletions(-)
create mode 100644 .gitignore
create mode 100644 Makefile
create mode 100644 foss-dev-checklist.md
create mode 100644 pandoc.template
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..a136337
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+*.pdf
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2916257..72e186d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -7,6 +7,23 @@ given project may extend or override these guidelines as needed.
Please see also the [Code of Conduct](CODE_OF_CONDUCT), which applies
everywhere.
+## Introduction
+
+All code should be developed from the start in a public repository
+under an open source license, except when there is a specific reason
+not to (e.g., a client agreement that stipulates the code only be
+released upon completion). Please have a partner at the firm sign off
+on the outbound license; our default is usually the [GNU Affero
+General Public License](https://www.gnu.org/licenses/agpl-3.0.en.html),
+but we may use other open source licenses depending on circumstances.
+
+We write code in many different programming languages. When you write
+in other languages, please try to use these guidelines to insofar as
+they can be applied to that language, and update this document as
+necessary. If you want to discuss any of the guidelines, please
+[contact](https://opentechstrategies.com/#contact) us or open an
+[issue](https://code.librehq.com/ots/meta/-/issues/new) to discuss.
+
## Standard Pull Request Model
We use the typical "[merge
@@ -59,12 +76,91 @@ commit messages with the corresponding diffs, and use that as a guide.
issue tickets, please mention each ticket number in the commit
message, like this: "issue #123".
-## Indentation and Whitespace
+## Indentation, Whitespace, and Formatting
Please uses spaces not tabs for indentation, and avoid trailing
whitespace. If a language has a standard indentation amount, use that
amount. E.g., indent Javascript code by 2 spaces per level, Python
-code by 4 spaces, etc.
+code by 4 spaces (as per
+[PEP-8](https://www.python.org/dev/peps/pep-0008/)), etc.
+
+Try to keep each line within 76 columns if possible, but it's okay to
+go wider if the alternative is an awkward code wrap or a string being
+broken across lines in a way that makes you feel yucky.
+
+Avoid having symbols that differ only by case.
+
+## Python version
+
+**Prefer Python 3.**
+
+In general, we try to write new code in Python 3, and convert legacy
+code from 2 to 3 (usually using
+[2to3](https://docs.python.org/3/library/2to3.html)) when we can.
+
+_This guideline is sometimes relaxed._ If you're more familiar with
+Python 2 and you just need to get something done quickly, it's okay to
+do it in Python 2 (though be prepared to go to 3 if/when others join
+in maintaining it). There may also still be cases where a certain
+library that you need is not yet available in Python 3.
+
+Think of Python 3 as the eventual destination of all OTS Python code.
+Most of the time, the easiest way to get there is to start out there,
+but there may sometimes be situations where a different path works
+better for you. Use your judgement.
+
+## Code Documentation Recommendations
+
+Not all of our projects follow these code documentation guidelines
+strictly, because these guidelines have only gradually been
+promulgated within OTS. They represent an ideal; if you're starting a
+new project, please try to follow them from the start.
+
+* **Document every class, method, and function.**
+
+ Every class should have a documentation string explaining what it is
+ for -- what it encapsulates. Please don't assume that the
+ conception behind a class is obvious from the class's name: what's
+ obvious to the author may be less obvious to later readers.
+
+ Every method or function should have a documentation string
+ describing the types and meanings of each input parameter, any
+ important side effects performed, and what the return value is (or
+ if there is no return value, say that explicitly).
+
+ Parameters should be specially marked in the doc string (in whatever
+ way is appropriate for the programming language or documentation
+ system in use for that project).
+
+ There is no need to document every possible exception that might be
+ thrown, but it is often good to document at least the custom
+ exceptions that could be raised. Because it can be burdensome to
+ list them all (since callees can raise exceptions too), just use
+ your judgement here.
+
+* **Document non-obvious data structures.**
+
+ Document any variables whose structure and meaning is not obvious.
+ For example, if it's not completely obvious what a dictionary holds,
+ then document the types and meanings of its keys, and the types and
+ meanings of the values those keys map to.
+
+* Python-specific documentation tips:
+
+ * **Put a `__doc__` string at the top of each source file.**
+
+ At the top of each standalone script or module, put a `__doc__`
+ string showing the usage. This string is what should be displayed
+ when the `--usage` or `--help` option is passed, but it's
+ convenient to also have it right at the top of the file, so that
+ people reading the source see it first.
+
+ * **Use underscores\_in\_identifiers, but CamelCase for class names.**
+
+ Use underscores to separate the words in a variable name, method
+ name, function name, or any other identifier, _except_ for class
+ names, which should use CamelCase (with the initial letter
+ capitalized too, e.g., "CamelCase" not "camelCase").
## Keep Unrelated Changes Separate
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..2e7b975
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,7 @@
+all: dev-guidelines.pdf oss-dev-checklist.pdf
+
+%.pdf: %.md pandoc.template Makefile
+ pandoc $< -o $@ --template pandoc.template
+
+clean:
+ rm -f *.aux *.log texput.pdf *.tex *.pdf
diff --git a/README.md b/README.md
index 02a3f5c..2ad78ef 100644
--- a/README.md
+++ b/README.md
@@ -5,6 +5,10 @@ to clients and partners as well.
These guidelines are meant as a starting point. A given project
should extend or override them as needed.
+You can generate a PDF of any Markdown document "FOO" here by running
+
+ $ make FOO.pdf
+
Original materials here are licensed under
a [Creative Commons Attribution-ShareAlike 4.0 license](LICENSE.md);
any 3rd-party materials here are redistributed under their respective
diff --git a/foss-dev-checklist.md b/foss-dev-checklist.md
new file mode 100644
index 0000000..ebf4f4d
--- /dev/null
+++ b/foss-dev-checklist.md
@@ -0,0 +1,202 @@
+# Open Source Development Contracting Checklist
+
+[www.OpenTechStrategies.com](http://www.OpenTechStrategies.com/)
+
+(Published under a [Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/) license.)
+
+**DRAFT** *(started in 2015; continued development TBD)*
+
+Introduction
+------------
+
+Several of our clients at [Open Tech Strategies,
+LLC](http://OpenTechStrategies.com/) have requested a checklist for
+doing open source software development, with special attention paid to
+guiding contractors who may be new to open source processes. We are
+publishing this checklist in the hope that it will be useful to others
+(as well as to our clients), and to have the benefit of others'
+[feedback](https://github.com/OpenTechStrategies/docs/issues).
+
+Please note that the intended audience of the checklist is _not_ the
+typical open source developer, who already knows much of this
+material. It is for executives and managers who either do not have
+much experience with open source development, or who sometimes do not
+have much experience with software development at all, and who
+contract out most or all of their organization's development work.
+
+This checklist is meant to help you draft contracts that procure open
+source results, and to help you work with the development team in an
+open source manner once a contract is under way. It is based on our
+real-world experiences with many different types of organizations
+(for-profit corporations, non-profits, and government agencies) that
+start open source projects or join them, and that engage contractors
+to do open source work. We update this checklist as needed, based on
+our work with our own clients, on our observations of various open
+source projects, and on feedback from others.
+
+The latest version of this document can always be found in
+[https://github.com/OpenTechStrategies/docs/](https://github.com/OpenTechStrategies/docs/).
+
+Version Control
+---------------
+
+* <a href="#use-public-vc" id="use-public-vc">**Public version control from start of development.**</a>
+
+ From the moment the project first starts, keep everything in a
+ public version control repository that can be accessed using an open
+ source version control client. (See ["Be Open From Day
+ One"](http://opentechstrategies.com/resources#be-open-from-day-one)
+ for why it is important to develop in the open from the beginning.)
+
+ "Public" means that anyone with Internet access can check out a copy
+ of the project, without needing to register an account on the
+ version control site, and without being required to inform you or
+ anyone else that they are checking out their own copy. It does
+ _not_ mean that random people can check in changes to your copy,
+ naturally -- you manage that copy, so you control who modifies it
+ and how.
+
+ We recommend [Git](http://git-scm.com/) as the version control
+ system, with repository hosting on [GitHub](https://github.com/) or
+ [Gitorious](https://gitorious.org/), both of which cost nothing for
+ open source projects to use. But if you prefer another version
+ control system or another hosting site (including hosting the
+ repository yourself), that's fine. The important thing is that it
+ be public, and that people can access the code using common
+ open source tools.
+
+* <a href="#public-vc-is-master" id="public-vc-is-master">**Public repository as the development master.**</a>
+
+ For example, see https://tech.dropbox.com/2014/07/open-sourcing-our-go-libraries/ :
+
+ "To make sure that we continue to invest in this open source effort, we are committed to using the public version of this repository internally. We are migrating our internal systems to use the libraries directly from this repository. This ensures all fixes and improvements are applied publicly before they are pulled back internally."
+
+* <a href="#vc-namespace" id="vc-namespace">**Related repositories in one project-related namespace.**</a>
+
+ Host the project's repositories in a single, project-related
+ namespace.
+
+ This does not mean the namespace must be the same as the project
+ name; it just means there should be _one_ namespace, and it should
+ be related to the project in some long-term way.
+
+ For example, development in the OpenHMIS project is being led by
+ Pathways Community Network Institute (PCNI). They have registered
+ an organization account on GitHub,
+ [github.com/PCNI](https://github.com/PCNI/), and all repositories
+ related to the project live in that namespace, e.g.,
+ [github.com/PCNI/OpenHMIS](https://github.com/PCNI/OpenHMIS),
+ [github.com/PCNI/outreach-app](https://github.com/PCNI/outreach-app),
+ etc.
+
+ The purpose of this policy is to avoid having parts of a project
+ spread out across the GitHub accounts of various individuals and
+ contractors. When a project is spread out like that, it's difficult
+ for people to figure out what they need to watch, or where they
+ should obtain source code from. It's fine for developers to have
+ unofficial forks of a project in their own accounts, of course. But
+ the latest official development sources should always be easily
+ identifiable by their location in the official namespace. When a
+ change is checked in to one of the official repositories, that means
+ the change has been accepted by the project.
+
+* <a href="#vc-docs-etc" id="vc-docs-etc" >**Version documentation, design diagrams, etc, like code.**</a>
+
+ If you have design documents, diagrams, and anything else that would
+ help a newcomer understand the project, keep them in the version
+ control repository too.
+
+ Sometimes these documents are written in a real-time collaborative
+ editing environment such as Google Docs. If the docs are still
+ being actively edited there, then
+
+ 1. Make sure the live copies are readable by anyone;
+ 2. Link to them from the documentation in the version control repository;
+ 3. Save checkpointed versions in the repository now and then,
+ but at the top of each checkpointed copy, link to the live online
+ copy, so people know where to get the latest material.
+
+* <a href="#vc-sources-only" id="vc-sources-only" >**Version source files, not generated files.**</a>
+
+ TBD
+
+* <a href="#build-system" id="build-system" >**Use a build system.**</a>
+
+ TBD
+
+* <a href="#commit-often" id="commit-often" >**Commit frequently -- don't wait until perfect.**</a>
+
+ TBD
+
+* <a href="#commit-messages" id="commit-messages" >**Write proper commit messages.**</a>
+
+ TBD. See http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
+
+* <a href="#placeholders-for-sensitive-data" id="placeholders-for-sensitive-data" >**Store placeholder templates for passwords, live server configuration, etc.**</a>
+
+ TBD
+
+* ...
+
+Documentation
+-------------
+
+* <a href="#doc-audience" id="doc-audience" >**Document with target audience in mind.**</a>
+
+ TBD
+
+* <a href="#doc-format" id="doc-format" >**Documentation in Markdown format.**</a>
+
+ TBD. Note the Markdown preview tools that are available.
+
+* <a href="#overview-in-readme" id="overview-in-readme" >**Overview documentation in `README.md`.**</a>
+
+ TBD. Distinguish between README and INSTALL files.
+
+* <a href="#separate-install-doc" id="separate-install-doc" >**Installation documentation in `INSTALL.md`.**</a>
+
+* <a href="#publish-license" id="publish-license" >**LICENSE.md file contains open source license.**</a>
+
+ TBD. Include links to advice on choosing a license.
+
+* <a href="#dev-docs" id="dev-docs" >**Document test servers, etc.**</a>
+
+ TBD. Really this is about developer documentation in general.
+
+* ...
+
+Bug Tracking
+------------
+
+* ...
+
+Communications
+--------------
+
+* <a href="#use-project-forums" id="use-project-forums" >**Use project discussion list, not private email.**</a>
+
+* ...
+
+Special notes for contracting:
+------------------------------
+
+* <a href="#require-apis" id="require-apis" >**Require APIs and import/export capability.**</a>
+
+ TBD. Just being open source isn't enough; the software needs to be
+ programmatically driveable, including the ability to get all data in
+ and out.
+
+* <a href="#require-sample-data" id="require-sample-data" >**Require sample data.**</a>
+
+ TBD. Sample data is necessary for third parties to try out the
+ code. It must be provided in the normal import format, not in some
+ intermediate format that requires domain-specific knowledge to use.
+
+* <a href="#use-right-namespace" id="use-right-namespace" >**Use project namespace consistently.**</a>
+
+ For example, if you're a contractor writing code for a project
+ whose home site is [openhmis.pcni.org](http://openhmis.pcni.org/),
+ then in Java package names use _"org.pcni.openhmis"_, not
+ _"com.yourcompanyname"_.
+
+* ...
diff --git a/pandoc.template b/pandoc.template
new file mode 100644
index 0000000..030ab90
--- /dev/null
+++ b/pandoc.template
@@ -0,0 +1,288 @@
+\documentclass[$if(fontsize)$$fontsize$,$endif$$if(lang)$$babel-lang$,$endif$$if(papersize)$$papersize$paper,$endif$$for(classoption)$$classoption$$sep$,$endfor$]{$documentclass$}
+$if(beamerarticle)$
+\usepackage{beamerarticle} % needs to be loaded first
+$endif$
+$if(fontfamily)$
+\usepackage[$for(fontfamilyoptions)$$fontfamilyoptions$$sep$,$endfor$]{$fontfamily$}
+$else$
+\usepackage{lmodern}
+$endif$
+$if(linestretch)$
+\usepackage{setspace}
+\setstretch{$linestretch$}
+$endif$
+\usepackage{amssymb,amsmath}
+\usepackage{ifxetex,ifluatex}
+\usepackage{fixltx2e} % provides \textsubscript
+\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
+ \usepackage[$if(fontenc)$$fontenc$$else$T1$endif$]{fontenc}
+ \usepackage[utf8]{inputenc}
+$if(euro)$
+ \usepackage{eurosym}
+$endif$
+\else % if luatex or xelatex
+$if(mathspec)$
+ \ifxetex
+ \usepackage{mathspec}
+ \else
+ \usepackage{unicode-math}
+ \fi
+$else$
+ \usepackage{unicode-math}
+$endif$
+ \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
+$for(fontfamilies)$
+ \newfontfamily{$fontfamilies.name$}[$fontfamilies.options$]{$fontfamilies.font$}
+$endfor$
+$if(euro)$
+ \newcommand{\euro}{€}
+$endif$
+$if(mainfont)$
+ \setmainfont[$for(mainfontoptions)$$mainfontoptions$$sep$,$endfor$]{$mainfont$}
+$endif$
+$if(sansfont)$
+ \setsansfont[$for(sansfontoptions)$$sansfontoptions$$sep$,$endfor$]{$sansfont$}
+$endif$
+$if(monofont)$
+ \setmonofont[Mapping=tex-ansi$if(monofontoptions)$,$for(monofontoptions)$$monofontoptions$$sep$,$endfor$$endif$]{$monofont$}
+$endif$
+$if(mathfont)$
+$if(mathspec)$
+ \ifxetex
+ \setmathfont(Digits,Latin,Greek)[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$}
+ \else
+ \setmathfont[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$}
+ \fi
+$else$
+ \setmathfont[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$}
+$endif$
+$endif$
+$if(CJKmainfont)$
+ \usepackage{xeCJK}
+ \setCJKmainfont[$for(CJKoptions)$$CJKoptions$$sep$,$endfor$]{$CJKmainfont$}
+$endif$
+\fi
+% use upquote if available, for straight quotes in verbatim environments
+\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
+% use microtype if available
+\IfFileExists{microtype.sty}{%
+\usepackage[$for(microtypeoptions)$$microtypeoptions$$sep$,$endfor$]{microtype}
+\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
+}{}
+\PassOptionsToPackage{hyphens}{url} % url is loaded by hyperref
+$if(verbatim-in-note)$
+\usepackage{fancyvrb}
+$endif$
+\usepackage[unicode=true]{hyperref}
+$if(colorlinks)$
+\PassOptionsToPackage{usenames,dvipsnames}{color} % color is loaded by hyperref
+$endif$
+\hypersetup{
+$if(title-meta)$
+ pdftitle={$title-meta$},
+$endif$
+$if(author-meta)$
+ pdfauthor={$author-meta$},
+$endif$
+$if(keywords)$
+ pdfkeywords={$for(keywords)$$keywords$$sep$, $endfor$},
+$endif$
+$if(colorlinks)$
+ colorlinks=true,
+ linkcolor=$if(linkcolor)$$linkcolor$$else$Maroon$endif$,
+ citecolor=$if(citecolor)$$citecolor$$else$Blue$endif$,
+ urlcolor=$if(urlcolor)$$urlcolor$$else$Blue$endif$,
+$else$
+ pdfborder={0 0 0},
+$endif$
+ breaklinks=true}
+\urlstyle{same} % don't use monospace font for urls
+$if(verbatim-in-note)$
+\VerbatimFootnotes % allows verbatim text in footnotes
+$endif$
+$if(geometry)$
+\usepackage[$for(geometry)$$geometry$$sep$,$endfor$]{geometry}
+$endif$
+$if(lang)$
+\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
+ \usepackage[shorthands=off,$for(babel-otherlangs)$$babel-otherlangs$,$endfor$main=$babel-lang$]{babel}
+$if(babel-newcommands)$
+ $babel-newcommands$
+$endif$
+\else
+ \usepackage{polyglossia}
+ \setmainlanguage[$polyglossia-lang.options$]{$polyglossia-lang.name$}
+$for(polyglossia-otherlangs)$
+ \setotherlanguage[$polyglossia-otherlangs.options$]{$polyglossia-otherlangs.name$}
+$endfor$
+\fi
+$endif$
+$if(natbib)$
+\usepackage{natbib}
+\bibliographystyle{$if(biblio-style)$$biblio-style$$else$plainnat$endif$}
+$endif$
+$if(biblatex)$
+\usepackage[$if(biblio-style)$style=$biblio-style$,$endif$$for(biblatexoptions)$$biblatexoptions$$sep$,$endfor$]{biblatex}
+$for(bibliography)$
+\addbibresource{$bibliography$}
+$endfor$
+$endif$
+$if(listings)$
+\usepackage{listings}
+$endif$
+$if(lhs)$
+\lstnewenvironment{code}{\lstset{language=Haskell,basicstyle=\small\ttfamily}}{}
+$endif$
+$if(highlighting-macros)$
+$highlighting-macros$
+$endif$
+$if(tables)$
+\usepackage{longtable,booktabs}
+% Fix footnotes in tables (requires footnote package)
+\IfFileExists{footnote.sty}{\usepackage{footnote}\makesavenoteenv{long table}}{}
+$endif$
+$if(graphics)$
+\usepackage{graphicx,grffile}
+\makeatletter
+\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
+\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
+\makeatother
+% Scale images if necessary, so that they will not overflow the page
+% margins by default, and it is still possible to overwrite the defaults
+% using explicit options in \includegraphics[width, height, ...]{}
+\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
+$endif$
+$if(links-as-notes)$
+% Make links footnotes instead of hotlinks:
+\renewcommand{\href}[2]{#2\footnote{\url{#1}}}
+$endif$
+$if(strikeout)$
+\usepackage[normalem]{ulem}
+% avoid problems with \sout in headers with hyperref:
+\pdfstringdefDisableCommands{\renewcommand{\sout}{}}
+$endif$
+$if(indent)$
+$else$
+\IfFileExists{parskip.sty}{%
+\usepackage{parskip}
+}{% else
+\setlength{\parindent}{0pt}
+\setlength{\parskip}{6pt plus 2pt minus 1pt}
+}
+$endif$
+\setlength{\emergencystretch}{3em} % prevent overfull lines
+\providecommand{\tightlist}{%
+ \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
+$if(numbersections)$
+\setcounter{secnumdepth}{$if(secnumdepth)$$secnumdepth$$else$5$endif$}
+$else$
+\setcounter{secnumdepth}{0}
+$endif$
+$if(subparagraph)$
+$else$
+% Redefines (sub)paragraphs to behave more like sections
+\ifx\paragraph\undefined\else
+\let\oldparagraph\paragraph
+\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
+\fi
+\ifx\subparagraph\undefined\else
+\let\oldsubparagraph\subparagraph
+\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
+\fi
+$endif$
+$if(dir)$
+\ifxetex
+ % load bidi as late as possible as it modifies e.g. graphicx
+ $if(latex-dir-rtl)$
+ \usepackage[RTLdocument]{bidi}
+ $else$
+ \usepackage{bidi}
+ $endif$
+\fi
+\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
+ \TeXXeTstate=1
+ \newcommand{\RL}[1]{\beginR #1\endR}
+ \newcommand{\LR}[1]{\beginL #1\endL}
+ \newenvironment{RTL}{\beginR}{\endR}
+ \newenvironment{LTR}{\beginL}{\endL}
+\fi
+$endif$
+
+% set default figure placement to htbp
+\makeatletter
+\def\fps@figure{htbp}
+\makeatother
+
+$for(header-includes)$
+$header-includes$
+$endfor$
+
+$if(title)$
+\title{$title$$if(thanks)$\thanks{$thanks$}$endif$}
+$endif$
+$if(subtitle)$
+\providecommand{\subtitle}[1]{}
+\subtitle{$subtitle$}
+$endif$
+$if(author)$
+\author{$for(author)$$author$$sep$ \and $endfor$}
+$endif$
+$if(institute)$
+\providecommand{\institute}[1]{}
+\institute{$for(institute)$$institute$$sep$ \and $endfor$}
+$endif$
+\date{$date$}
+
+\begin{document}
+$if(title)$
+\maketitle
+$endif$
+$if(abstract)$
+\begin{abstract}
+$abstract$
+\end{abstract}
+$endif$
+
+$for(include-before)$
+$include-before$
+
+$endfor$
+$if(toc)$
+{
+$if(colorlinks)$
+\hypersetup{linkcolor=$if(toccolor)$$toccolor$$else$black$endif$}
+$endif$
+\setcounter{tocdepth}{$toc-depth$}
+\tableofcontents
+}
+$endif$
+$if(lot)$
+\listoftables
+$endif$
+$if(lof)$
+\listoffigures
+$endif$
+$body$
+
+$if(natbib)$
+$if(bibliography)$
+$if(biblio-title)$
+$if(book-class)$
+\renewcommand\bibname{$biblio-title$}
+$else$
+\renewcommand\refname{$biblio-title$}
+$endif$
+$endif$
+\bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$}
+
+$endif$
+$endif$
+$if(biblatex)$
+\printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$
+
+$endif$
+$for(include-after)$
+$include-after$
+
+$endfor$
+\end{document}
--
GitLab