Quelques idées d'une possible organisation de l'écriture collaborative d'articles pour
le web, faisant suite à Publier et braconner et
Publier et braconner (2).
Tout d'abord, l'écriture d'un article (de maths ou d'info, mais en fait l'écriture
de n'importe quoi) doit s'appuyer sur un gestionnaire de versions, même lorsqu'on
écrit tout seul. Garder l'historique de son document, pour pouvoir revenir en arrière
pour reprendre un morceau qu'on avait supprimé, par exemple.
A plusieurs, il est encore plus essentiel de pouvoir écrire chacun à son rythme,
chacun sa partie, et laisser à l'outil la fusion des modifications faites en parallèle.
Cela évite les erreurs de copier-coller en reprenant les modifications de chacun à
droite et à gauche, les modification perdues, ...
Ainsi, par exemple, Mathrice propose depuis un certain temps la possibilité d'avoir des dépôts
Subversion pour le
travail collaboratif.
Le cadre de publication pour le web tel qu'il est présenté dans les deux précédents billets s'appuie
sur l'écriture de fichiers XML avec du LaTeX dedans. Le XML n'est pas très compliqué et d'une
profondeur limitée, ce qui fait que les sources des documents se prêtent bien à une gestion de versions
basée sur les différences textuelles.
Si le site web final a bien sûr vocation à être public, i.e. visible par tous, on peut
distinguer deux visibilités pour ses sources:
- les sources de ce qui est déjà publié peuvent être publiques, afin de permettre à ceux qui voudraient contribuer de s'inspirer des précédents documents, de la même façon que l'on prend souvent un code LaTeX déjà existant pour écrire un nouveau document;
- les sources de ce qui n'est pas encore publié devraient plutôt être privées, c'est-à-dire visibles de leurs seuls auteurs.
Il faut donc d'une part gérer l'historique des sources publiques, et d'autre part
permettre aux auteurs d'utiliser les fonctionnalités de la gestion de versions pour
la rédaction de leurs nouveaux documents.
Ce type de contraintes est un cas d'école pour le gestionnaire de versions distribué qu'est
Git.
Pour ceux qui ne connaissent que Subversion, Git fonctionne un peu de la même façon,
sauf qu'il est possible, pour faire simple, de synchroniser des dépôts entre eux. Là où
dans Subversion il existe un dépôt central dans lequel chacun "commite", dans Git
chacun a son propre dépôt, dans lequel il travaille (il est possible de "commiter"
même en étant déconnecté), et qu'il synchronise avec d'autres dépôts, et notamment
souvent un dépôt central servant de référence.
Cela signifie qu'il est possible d'avoir, dans notre cas, un dépôt public pour les sources
des documents déjà publiés, et un dépôt privé par document non encore publié, et dont l'accès
est réservé à ses auteurs.
La
Figure 1
montre une telle organisation. La rédaction d'un article
peut alors suivre les étapes suivantes, repérées par leur numéro sur la figure:
- clonage du dépôt public pour créer un dépôt privé,
- travail de rédaction dans ce dépôt de façon collaborative entre les auteurs,
- lorsque la version définitive à soumettre est atteinte, on peut la "pousser" dans le dépôt public. (On peut également préalablement déposer auparavant une version PDF dans HAL ou ArXiv)
Ces trois opérations (clonage, modifications collaboratives et envoi vers un dépôt public) sont prises
en charge par Git, pour lequel il existe des interfaces graphiques, ce qui devrait faciliter l'appropriation
de ce type d'organisation par les auteurs. De plus, il existe d'ores et déjà plusieurs offres
publiques permettant d'héberger des dépôts Git privés
(comme la forge INRIA ou
la PLM).