Zulip has three major documentation systems:
Developer and sysadmin documentation: Documentation for people actually interacting with the Zulip codebase (either by developing it or installing it), and written in Markdown.
User-facing documentation: Our scalable system for documenting Zulip’s huge collection of specific features without a lot of overhead or duplicated code/syntax, written in Markdown. We have several hundred pages written using this system. There are 3 branches of this documentation:
User documentation (with a target audience of individual Zulip users),
Integrations documentation (with a target audience of IT folks setting up integrations), and
API documentation (with a target audience of developers writing code to extend Zulip).
These three systems are documented in detail.
Developer and sysadmin documentation¶
What you are reading right now is part of the collection of
documentation targeted at developers and people running their own
Zulip servers. These docs are written in
Commonmark Markdown with a small bit of rST.
We’ve chosen Markdown because it is
easy to write. The source for Zulip’s
developer documentation is at
docs/ in the Zulip git repository, and
they are served in production at
If you want to build the developer documentation locally (e.g. to test your changes), the dependencies are automatically installed as part of Zulip development environment provisioning, and you can build the documentation using:
and then opening
http://127.0.0.1:9991/docs/index.html in your
browser. The raw files are available at
file:///path/to/zulip/docs/_build/html/index.html in your browser
(so you can also use e.g.
firefox docs/_build/html/index.html from
the root of your Zulip checkout).
If you are adding a new page to the table of contents, you will want
docs/index.rst and run
make clean before
make html, so
that other docs besides your new one also get the new entry in the
table of contents.
You can also usually test your changes by pushing a branch to GitHub
and looking at the content on the GitHub web UI, since GitHub renders
Markdown, though that won’t be as faithful as the
When editing dependencies for the Zulip documentation, you should edit
requirements/docs.in and then run
which updates docs.txt file (which is used by ReadTheDocs to build the
Zulip developer documentation, without installing all of Zulip’s
Core website documentation¶
Zulip has around 10 HTML documentation pages under
for specific major topics, like the features list, client apps,
integrations, hotkeys, API bindings, etc. These documents often have
pattern between them other than inheriting from the
template. We generally avoid adding new pages to this collection
unless there’s a good reason, but we don’t intend to migrate them,
either, since this system gives us the flexibility to express these
important elements of the product clearly.
User facing documentation¶
All of these systems use a common Markdown-based framework with
various extensions for macros and variable interpolation,
render_markdown_path in the code), designed to make it convenient
to do the things one does a lot in each type of documentation.
General user documentation¶
Zulip has several automated test suites that we run in CI and recommend running locally when making significant edits:
The ReadTheDocs docs are built and the links tested by
tools/test-documentation, which runs
build-docsand then checks all the links.
There’s an exclude list for the link testing at this horrible path:
which is relevant for flaky links.
The API docs are tested by
tools/test-api, which does some basic payload verification. Note that this test does not check for broken links (those are checked by
/integrations/, and the Core website (“portico”) documentation for broken links. Note that the “portico” documentation check has a manually maintained whitelist of pages, so if you add a new page to this site, you will need to edit
PorticoDocumentationSpiderto add it.
tools/test-backend test_docs.pytests various internal details of the variable substitution logic, as well as rendering. It’s essential when editing the documentation framework, but not something you’ll usually need to interact with when editing documentation.