Documents en LaTeX, sortie en PDF, sources en SVN - besoin d'un composant personnalisable ou d'un logiciel pour révision par les pairs

Question

Nous avons un grand dépôt SVN de documents LaTeX. Chaque document est finalement rendu en PDF.

Les documents doivent être révisés. La révision a deux objectifs principaux: assurer la qualité du texte lui-même et assurer la qualification de la composition.

En ce moment critique pourrait être séparé en deux grands groupes:

1. Ceux qui utilisent SVN à la caisse sources et construire des fichiers PDF pour eux-mêmes, et soumettre les résultats de examen comme SVN engage

2. Ceux qui reçoivent des fichiers PDF préconstruits à partir du serveur ftp et soumettent les résultats sous la forme d'une liste de commentaires par courrier électronique.

auteurs de documents traitent les résultats de l'examen par des blocs de traitement \ todo {} dans le code LaTeX, en annulant les changements inutiles dans SVN ou incorporant des commentaires libres de e-mail dans les sources LaTeX. Le problème est que, à mesure que le nombre de documents augmente, il est très difficile de suivre les réviseurs du deuxième groupe et d'incorporer leurs suggestions de manière opportune et complète.

Par conséquent, une solution de révision post-commit non sophistiquée est nécessaire.

Exigences:

1. examen post-COMMIT

2. Tout dépôt doit être par défaut considéré comme une cible d'examen sans besoin de spécifier des fichiers/ligne gammes pour examen.

3. Soutien aux commentaires anonymes/Examen des résultats

4. Avis/commentaires devraient avoir le statut pour faciliter le traitement

5. Web

6. Intégration avec SVN, afin que les nouveaux commits automatiquement pourraient être incorporé dans la revue

7. Open source/cusomizable

ReviewBoard, CodeStiker, plugins pour trac, Rietveld, JCR - ils échouent tous à satisfaire certaines de ces exigences.

En outre, la plupart d'entre eux sont trop complexes pour le besoin actuel.

Creuset est agréable. C'est complexe, mais cela pourrait être facilité par la personnalisation. Cependant, le prix est un peu lourd.

Qu'est-ce que j'ai manqué?

UPD: nous nous sommes retrouvés sans aucune automatisation après tout. Les utilisateurs expérimentés ont un accès direct au référentiel et effectuent des révisions sous forme de branches/correctifs ou de commentaires dans les sources.D'autres personnes stockent les commentaires en texte brut ou annotent les fichiers PDF résultants.

Après un moment, nous avons cessé de chercher des alternatives.

Answer 1

Il semble que vos exigences soient un peu plus compliquées que vous ne le pensez si vous avez déjà regardé tous ces projets open source, et qu'ils ne répondent pas tous à vos exigences.

Je suis d'accord avec l'utilisation d'un DVCS si vous le pouvez. J'utilise git pour gérer tout mon code latex, et c'est génial.

Avez-vous pensé à utiliser un simple fichier texte pour stocker vos avis? Vous pouvez utiliser quelque chose comme le mode org dans emacs, mettre en place des liens relatifs à vos documents, horodater vos commentaires, utiliser le statut TODO pour garder une trace de ce qui est passé et ce qui ne l'est pas, et garder les commentaires à côté du code latex quelque chose comme: document.tex et document_review.org, .txt ou autre. org-mode publiera sur latex, html et quelques autres formats.

De toute façon, juste une suggestion-- principe KISS au travail!

Answer 2

Cela ressemble à un flux de travail intéressant. Juste combien de documents envisagez-vous, et comment entrent-ils dans le système? Cela ressemble à un client gouvernemental ...

À titre de première recommandation, EasyChair. J'ai eu de bonnes expériences en la matière, en gérant le processus de la soumission des auteurs, en passant en revue, à la sélection des documents acceptés par le comité du programme. C'est écrit en Perl, et j'ai entendu dire qu'il est raisonnable de travailler avec les sources, même si je n'ai pas de contact avec ça. Le traitement de l'anonymat, en particulier, est bien fait. — Pas de source ouverte. Je connais l'un des développeurs, et peut-être que le code peut être partagé sur une base, mais je suppose que cela exclut cela. EasyChair peut être intégré à votre système de contrôle de version. Pour être honnête, je ne vois pas pourquoi cela figure sur votre liste. Vous voulez que les arbitres travaillent avec une version particulière du texte. C'est avec le copy-editor que le document passera par plusieurs versions, et vous pouvez vous attendre à ce que le contact soit moins formel là-bas.

Êtes-vous vraiment marié à Subversion? S'il y a un va-et-vient substantiel entre les auteurs et les éditeurs (contrairement à la relation formalisée entre auteurs et arbitres), avoir un vrai contrôle de version distribuée avec des diffs tridimensionnels de bonne qualité facilite grandement la tâche des auteurs et des éditeurs. apporter des modifications au texte au fur et à mesure. Je connais des éditeurs qui utilisent Git Hub pour gérer les soumissions Latex pour cette raison.