Technical setup of feature structure
A feature contains texts and scripts,
each targeting one of 4 audiences:
- Decision makers
- General README text: file
- Overview text: file
- Getting started text:
- Usage text:
- User-facing scripts
- Bootstrapping text: file
- Maintenance text: file
- Administration scripts
- Project metadata: file
- Bootstrapping script: file
- Site variables: file
- Build variables (generated): file
- Install variables (generated): file
General README text is mandatory.
All other parts are optional.
Generated files should not be tracked with git
(instead created and cleaned with
make as needed).
Files with extension
.md are in CommonMark format.
README must follow the standard-readme specification,
and other CommonMark files should take inspiration from it as well.
Files with extension
.conf are basic settings files
containing only variable settings and comments
CommonMark files should use Diátaxis documentation system,
i.e. each file should aim at serving only one purpose -
A feature may start as a personal draft,
and ideally ends as globally reusable and long-term maintained.
- system-integrated Redpill (packaged unofficially)
- system-integrated Debian (packaged officially)
Personal drafts are kept in
with scripts prefixed "my" symlinked to
Site-specific drafts are kept below
with scripts prefixed "local" symlinked to either
One feature may serve as foundation
for one or more extended features.
- Couchdesign: Musicbox - Jukebox service
- Redpill: Sohobox - Groupware services (email, filesharing, calendar)
- Debian: Box, deploying a system onto hardware using Boxer
A mature feature may need local adaptation
for refinements unsuitable for general reuse.
Feature "account" vary in documentation
(e.g. welcome page for new users)
as well as maintenance routines
(e.g. for account creation, expiry, and backup),
whether an organization offers shell access,
mail, and/or filesharing.
myprint-foo script tailored to unique color proofing
localprint_draftscript tailored inhouse printer
box-print Boxer profile for in-house print queue service
- Redpill: Generic guides to printing
TODO: Rewrite examples to not confusingly reference specific networks.
English is used as main language.
Translations are tracked using gettext
Features are compiled together
to form a coherent documentation bundle.
A gettext template (a.k.a. a pot) file is generated using
extracting all strings from master documents:
The generated gettext template file should be tracked in the git.
For each localized language,
Create/update a corresponding gettext (a.k.a. po) file
using a gettext editor.
TODO: Recommend gettext editors for various operating systems.
The edited gettext file should be tracked in the git.
Localised markdown files are generated using
and a website is generated using
TODO: Actually implement above commands for all features.