Calenco a l'air intéressant dans la mesure où il parle de document autrement qu'en terme bureautique.
Reste qu'il semble oublier un élément essentielle. Une doc, comme un fichier source est / doit être un élément de configuration. Un "truc" (les qualiticiens disent artefact pour faire savant) que l'on doit retrouver dans la livraison et qui doit être en cohérence avec les autres produits (mieux que trucs, non ?) de développement.
A ce titre, il me semble qu'un élément essentiel est l'intégration avec un outil de gestion de configuration / gestion des changement, voire quelque chose de plus ambitieux comme Redmine ou mieux encore une Forge logicielle. Mais quoi qu'il en soit, le point de départ, c'est le client.
Autrement dit, au centre est le système de gestion des changements (c-a-d au départ les besoins des utilisateurs) autour duquel soit s'articuler tout le reste. A commencer par la documentation.
Donc, le système de gestion documentaire doit s'arrêter là où commence la gestion des changements / configuration. Qu'il intègre un workflow, soit. Mais surtout pas une gestion interne des versions. Ou bien cela doit n'être qu'une interface avec le système de gestion de configuration.
Sinon, ça réinvente la roue, ça introduit de la confusion, et ça isole la doc du produit. Ce qui n'est pas souhaitable.
# La doc est un élément de configuration
Posté par 6Ber Yeti . En réponse à la dépêche Calenco : une solution pour la documentation des projets libres ?. Évalué à 5.
Reste qu'il semble oublier un élément essentielle. Une doc, comme un fichier source est / doit être un élément de configuration. Un "truc" (les qualiticiens disent artefact pour faire savant) que l'on doit retrouver dans la livraison et qui doit être en cohérence avec les autres produits (mieux que trucs, non ?) de développement.
A ce titre, il me semble qu'un élément essentiel est l'intégration avec un outil de gestion de configuration / gestion des changement, voire quelque chose de plus ambitieux comme Redmine ou mieux encore une Forge logicielle. Mais quoi qu'il en soit, le point de départ, c'est le client.
Autrement dit, au centre est le système de gestion des changements (c-a-d au départ les besoins des utilisateurs) autour duquel soit s'articuler tout le reste. A commencer par la documentation.
Donc, le système de gestion documentaire doit s'arrêter là où commence la gestion des changements / configuration. Qu'il intègre un workflow, soit. Mais surtout pas une gestion interne des versions. Ou bien cela doit n'être qu'une interface avec le système de gestion de configuration.
Sinon, ça réinvente la roue, ça introduit de la confusion, et ça isole la doc du produit. Ce qui n'est pas souhaitable.