Vize

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