78b41f375d
This keeps the examples in line with our actual codebase. Also while I'm here revise it to explain the actual motivation for our use of `env`, and to correct some subtle details -- it's actually the kernel that interprets the shebang (as visible in e.g. a `strace` log), not the shell, and when the program is executed as `./my_program.py` the exact name including `./` is passed to the interpreter. |
||
---|---|---|
.. | ||
_static | ||
images | ||
.gitignore | ||
Makefile | ||
README.md | ||
THIRDPARTY | ||
accessibility.md | ||
analytics.md | ||
api-release-checklist.md | ||
architecture-overview.md | ||
bots-guide.md | ||
brief-install-vagrant-dev.md | ||
bug-reports.md | ||
changelog.md | ||
chat-zulip-org.md | ||
chinese.md | ||
client.md | ||
code-of-conduct.md | ||
code-reviewing.md | ||
code-style.md | ||
conf.py | ||
conversion.md | ||
custom-apps.md | ||
dev-env-first-time-contributors.md | ||
dev-overview.md | ||
dev-remote.md | ||
dev-setup-non-vagrant.md | ||
directory-structure.md | ||
email.md | ||
emoji.md | ||
events-system.md | ||
expensive-migrations.md | ||
fixing-commits.md | ||
front-end-build-process.md | ||
full-text-search.md | ||
german.md | ||
git-cheat-sheet-detailed.md | ||
git-cheat-sheet.md | ||
git-guide.md | ||
hashchange-system.md | ||
hotspots.md | ||
html_css.md | ||
html_unescape.py | ||
index.rst | ||
install-docker-dev.md | ||
install-generic-unix-dev.md | ||
install-ubuntu-without-vagrant-dev.md | ||
integration-docs-guide.md | ||
integration-guide.md | ||
life-of-a-request.md | ||
linters.md | ||
logging.md | ||
management-commands.md | ||
manual-testing.md | ||
markdown.md | ||
migration-renumbering.md | ||
mypy.md | ||
new-feature-tutorial.md | ||
pointer.md | ||
polish.md | ||
prod-authentication-methods.md | ||
prod-customize.md | ||
prod-email.md | ||
prod-install.md | ||
prod-maintain-secure-upgrade.md | ||
prod-mobile-push-notifications.md | ||
prod-postgres.md | ||
prod-requirements.md | ||
prod-troubleshooting.md | ||
prod.md | ||
queuing.md | ||
reading-list.md | ||
readme-symlink.md | ||
realms.md | ||
release-checklist.md | ||
requirements.readthedocs.txt | ||
roadmap.md | ||
russian.md | ||
schema-migrations.md | ||
screenshot-and-gif-software.md | ||
security-model.md | ||
settings.md | ||
shell-tips.md | ||
spanish.md | ||
ssl-certificates.md | ||
swagger-api-docs.md | ||
testing-with-casper.md | ||
testing-with-django.md | ||
testing-with-node.md | ||
testing.md | ||
translating.md | ||
travis.md | ||
unread_messages.md | ||
user-docs.md | ||
users.md | ||
using-dev-environment.md | ||
version-control.md | ||
webhook-walkthrough.md | ||
working-copies.md | ||
writing-views.md | ||
zulipbot-usage.md |
README.md
Documentation
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.
-
Core website documentation: Complete webpages for complex topics, written in HTML, JavaScript, and CSS (using the Django templating system). These roughly correspond to the documentation someone might look at when deciding whether to use Zulip. We don't expect to ever have more than about 10 pages written using this system.
-
General user 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 expect to eventually have around 100 pages written using this system. The target audience for this system is individual Zulip users.
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
zulip.readthedocs.io.
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:
./tools/build-docs
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
to modify 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 make html
approach.
When editing dependencies for the Zulip documentation, you should edit
requirements/docs.txt
(which is used by ReadTheDocs to build the
Zulip developer documentation, without installing all of Zulip's
dependencies).
Core website documentation
Zulip has around 10 HTML documentation pages under templates/zerver
for specific major topics, like the features list, client apps,
integrations, hotkeys, API bindings, etc. These documents often have
somewhat complex HTML and JavaScript, without a great deal of common
pattern between them other than inheriting from the portico.html
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.
General user documentation
To learn more about Zulip's general user documentation, visit our guide on writing user documentation here.