> La syntaxe [nomLien](/HowtoFoo#name) est aussi valide, on peut mettre le lien dans les parenthèses et le nom dans les crochets (ce qui permet d'avoir l'autocompletion dans vscode notamment).
Si on montre plusieurs commandes dans un seul bloc, et qu'on veut également montrer leur sortie, il convient de sauter une ligne entre chaque commande et la fin de la sortie de la précédente.
Si l'on doit afficher une commande courte dans le paragraphe du texte, par exemple `/etc/init.d/foo restart`, on utilise les backticks « \`/etc/init.d/foo restart\` ». On peut utiliser la même chose pour les noms de fichier, tel `foo.bar`.
Si l'on doit utiliser un terme quelconque, on privilégiera **foo** et **bar** (puis baz, qux, quux, corge, grault, garply, waldo, fred, plugh, xyzzy, thud). Ainsi, pour un chemin quelconque, on utilisera par exemple `cp /foo/FICHIER /bar/`.
Si l'on utilise des adresses IP, on utilisera des IPv4 en **192.0.2.0/24**, **198.51.100.0/24**, ou **203.0.113.0/24** [RFC5737](https://tools.ietf.org/html/rfc5737#section-3) et des IPv6 en **2001:db8::/32** [RFC3849](https://tools.ietf.org/html/rfc3849).
Si l'on utilise un système autonome, on utilisera un AS entre **64496 et 64511** ou entre **65536 et 65551** [RFC5398](https://tools.ietf.org/html/rfc5398).
Si l'on utilise des noms de domaine, on utilisera **example.com** [RFC2606](https://tools.ietf.org/html/rfc2606) notamment pour les emails, URLs ou serveurs à atteindre.
Par défaut on considère que l'on écrit de la documentation pour la version *stable* d'OpenBSD ou de Debian. Des remarques **obligatoires** doivent être faites pour Debian *oldstable*. Des remarques éventuelles peuvent être faites pour les version précédentes (*oldoldstable*, *oldoldoldstable*, etc). Ces remarques devraient être mises sous forme de "notes" du type :
* À la fin de la liste commençant par la documentation officielle, il doit y avoir un point `Statut de cette page : prod/test / version` où "version" est la version de Debian (ou OpenBSD) visée par la documentation (si applicable) et on mettra "prod" si les principales phases de la documentation (installation et configuration au moins) ont été jouées au moins 1 fois sur un serveur de prod tournant sous "version" (sinon on notera "test").
* Un lien vers le site officiel doit être positionné sur la 1<sup>ère</sup> occurence du nom de la techno dans la description.
* Une section installation doit être présente. On considère que l'on utilise la dernière version de Debian et/ou d'OpenBSD par défaut, si besoin on précise les exceptions pour des releases précédentes comme précisé plus haut.
* Dans la section installation, on montrer la commande apt d'installation, mais un moyen d'obtenir la version installée en temps qu'utilisateur non-root et l'état de l'éventuel démon avec sysctemctl status SAUF la ligne "active".
* En général, il doit y avoir au moins les titres : Installation / Configuration / Administration / Optimisation / Plomberie / Monitoring (avec sous-titres Munin et Nagios) / FAQ.
* L'organisation des titres/sous-titres doit être cohérente quand on regarde la table des titres.
* Les conventions de syntaxe doivent être appliquées partout (voir ci-dessous) notamment pour les adresses IP, les "Note :", les fichiers sous la forme `/etc/foo.conf`,etc.
* Les exemples de code ou contenu de fichiers doivent utiliser la syntaxe avec trois tildes.
* Si l'on mentionne d’autres documentations, mettre des liens internes.
* Objectif zéro faute d'orthographe ou de grammaire.
* Tout ce qu'on a mis en production sur des serveurs doit être mentionné.
* Quand on mentionne des commandes avec des arguments, il faut mettre les versions longues (exemple: `--dry-run` au lieu de `-d` si possible).
* Si la doc est longue, on hésitera pas à avoir un titre "Configuration de base" et "Configuration avancée", ou alors un sous-titre "Utilisation de base" avec les commandes de base si l'on doit lire la doc en 1 minute.
* Si la doc est très longue, elle peut être découpée en sous-pages à l'exemple du [HowtoMySQL]().