Je ne suis pas pleinement d'accord, j'ai essayé de faire simplement un git+markdown pour gérer ce type de documents et cela ne suffit pas.
Git et Markdown archivent et donnent parfaitement le rendu sous toutes les formes, mais il faut ajouter une couche d'organisation entre les participants et un système de validation et de remise en question. Des variantes aussi.
Bien sûr git et markdown ont toutes les fonctions intrinsèques pour cela, mais pas d'une manière balisée au sens workflow administratif.
En fait, on pourrait probablement utiliser git comme repository au lieu d'une base de donnée, mais le logiciel est un frontend aussi. Il faut gérer qui peut modifier quoi et quel workflow de traitement et de validation cela engendre.
Donc oui, on peut formaliser chaque opération du workflow administratif sous des commandes git (markdown ou autre chose n'a pas d'impact) et faire un front end pour cela, mais ce n'est pas si simple.
Dans le cas d'un traitement de donnée légale, l'utilisateur ne veut pas un word, il veut un traitement fonctionnel par corpus/texte/alinéa.
[^] # Re: GIT et Markdown
Posté par Samuel Ballé . En réponse au journal [UE] Outil législatif collaboratif open source. Évalué à 1.
Je ne suis pas pleinement d'accord, j'ai essayé de faire simplement un git+markdown pour gérer ce type de documents et cela ne suffit pas.
Git et Markdown archivent et donnent parfaitement le rendu sous toutes les formes, mais il faut ajouter une couche d'organisation entre les participants et un système de validation et de remise en question. Des variantes aussi.
Bien sûr git et markdown ont toutes les fonctions intrinsèques pour cela, mais pas d'une manière balisée au sens workflow administratif.
En fait, on pourrait probablement utiliser git comme repository au lieu d'une base de donnée, mais le logiciel est un frontend aussi. Il faut gérer qui peut modifier quoi et quel workflow de traitement et de validation cela engendre.
Donc oui, on peut formaliser chaque opération du workflow administratif sous des commandes git (markdown ou autre chose n'a pas d'impact) et faire un front end pour cela, mais ce n'est pas si simple.
Dans le cas d'un traitement de donnée légale, l'utilisateur ne veut pas un word, il veut un traitement fonctionnel par corpus/texte/alinéa.