Notes Lane
Les documents de référence sont excellents pour répondre à la question « comment utiliser ça ? » Ils sont bien moins efficaces pour répondre à des questions telles que :
Pourquoi cette fonctionnalité a-t-elle été ajoutée ?
Quel compromis a conduit à cette architecture ?
Quelles expériences sont prometteuses, mais pas encore stables ?
Qu’est-ce que le projet essaie d’apprendre ensuite ?
C’est pourquoi la documentation inclut désormais une ligne Notes séparée.
Ce qui appartient ici
Les notes sont volontairement irrégulières. Un article peut être :
Un Devlog après une semaine de travail sur un compilateur
Un résumé de l’architecture pour une nouvelle caisse
une note de conception sur Musea, le LSP ou l’intégration Vite
une courte mise à jour du projet utile, mais non liée à un tag de version
Pourquoi ne pas tout mettre dans les notes de sortie
Les notes de version sont optimisées pour les modifications de livraison. Ils doivent rester écartés et exploitables.
Les notes laissent place à une narration plus large : le contexte derrière un article, la structure de la feuille de route, et la réflexion qui aide les lecteurs à comprendre le projet au fil du temps.
Direction de l’écriture
En cas de doute :
utilisez les Notes de sortie si le post annonce qu’un article a été publié
utilisez Notes si le post explique la réflexion, les progrès ou les expériences