Ce mail (25/11/2005) était destiné à régler un problème de codes intempestifs que met MS-Word dans les fichiers XML qu'il sauvegarde - et a tourné à l'énoncé des différences entre les versions journal et conférence qu'il serait bien, pour des raisons de maintenance, de combler ...
Salut Philippe,
J'ai des soucis avec des reviews (pour la version journal de Myreview que
j'utilise pour le journal dont je suis éditeur): certains relecteurs
utilisent MS-Word pour écrire leur review à partir du patron vide qu'ils
téléchargent, et le résultats est que Word traduit tous les caractères
spéciaux en HTML lorsqu'il sauvegarde dans le type XML (il vire les
balises XML dans TOUS les autres formats, sauf peut-être le .doc mais
celui-ci a bien d'autres problèmes).
Or en comparant la dernière version de myreview avec celle que j'utilise,
je constate que l'upload des fichiers XML n'a plus rien à voir: la version
que j'utilise a son propre XMLReviewParser.php alors qu'il semble que la
dernière version utilise une classe externe Codes.class.php ???
Ceci dit, cela repose de manière évidente le problème de la convergence
éventuelle des 2 versions - conférence et journal ...
qui finalement a envahi tout ce mail, ce qui n'était pas mon intention au départ - mais allons-y!
D'autant plus que la conférence ECCS vient de se terminer : d'une part, il
faudrait que tu intègres les parties de génération de programme, booklet
of abstracts et proceedings que Bertrand a faites. Mais d'autre part,
l'édition 2006 est déjà programmée, et aura elle aussi besoin des 3
niveaux de reviewers : l'éditeur en chef, les éditeurs membres du PC, et
les reviewers (attention, si l'on compte ce qui est maintenant appelé
dans la nouvelle version "external reviewer", c'est-à-dire la possibilité
pour 1 reveiwer de sous-traiter, cela fait 4 niveaux).
Il me semble donc utile de rendre optionnel ce niveau intermédiaire entre
le program chair et les reviewers.
Une autre petite chose qui serait bienvenue dans la version ECCS et la
notion de "type de papier": dans ECCS par exeemple, les gens peuvent
soumettre des papiers longs, courts ou des posters - et le comité de
programme ne s'est pas privé de basculer des papiers d'une catégorie dans
une autre (et de nombreuses conférences ont au moins les notions de
papiers et poster).
Autre chose qui est présent dans la version journal que j'utilise, c'est
la notion de version de papier - et, comme nous en avons discuté un jour,
cela est aussi utile pour certaines conférences (dont ECCS): actuellement,
dans la version conférence, la seule chose qui s'en rapproche est la
notion de camera-ready. Il me semble que la notion de version n'est qu'une
généralisation de la notion de camera-ready. Mais attention, la notion de
"version" devrait être intimement liée à la notion de "state (cf + bas)
car actuellement, ce qu'a fait Jérome est quelque chose qui est incrémenté
à chaque fois que l'auteur uploade un fichier, ce qui arrive quelquefois
plusieurs fois dans les 2-3 jours qui suivent la soumission initiale: il
faudrait que le numéro de version ne soit incrémenté qu'après un round de
reivew et une décision "revise and resubmit"
Enfin, il reste cette idée de "state" (indépendant du "status", qui lui
reflète la décision finale d'acceptation).
Mon idée du state est qu'il doit refléter à quel endroit du processus de
review le papier en est.
Par exemple (à affiner):
Just submitted<br>
sent to editor (s'il y a le niveau "editor")<br>
sent to reviewer<br>
discussion among reviewers opened (s'il y a lieu)<br>
review process completed (il y a eu une décision)<br>
et éventuellement, si doit être révisée<br>
under revision by authors<br>
ou, si est acceptée<br>
waiting for camera-ready<br>
La variable "frozen" serait alors mise à jour en fonction de l'avancement
Dans la version journal, il y a une version "manuelle" du state, mais
inutile de te dire que ce n'est jamais à jour, pusique c'est moi qui suis
censé faire défiler les diverses options ...
VOilà ou j'en suis - sachant qu'il va falloir d'ici début janvier disposer
d'une version opérationnelle pour ECCS.
Serais-tu d'accord pour discuter d'un plan d'action pour tout ça, un de
ces jours (au LRI ou ailleurs, d'ailleurs!)
Amicalement
Marc
Salut Philippe,
J'ai des soucis avec des reviews (pour la version journal de Myreview que
j'utilise pour le journal dont je suis éditeur): certains relecteurs
utilisent MS-Word pour écrire leur review à partir du patron vide qu'ils
téléchargent, et le résultats est que Word traduit tous les caractères
spéciaux en HTML lorsqu'il sauvegarde dans le type XML (il vire les
balises XML dans TOUS les autres formats, sauf peut-être le .doc mais
celui-ci a bien d'autres problèmes).
Or en comparant la dernière version de myreview avec celle que j'utilise,
je constate que l'upload des fichiers XML n'a plus rien à voir: la version
que j'utilise a son propre XMLReviewParser.php alors qu'il semble que la
dernière version utilise une classe externe Codes.class.php ???
Ceci dit, cela repose de manière évidente le problème de la convergence
éventuelle des 2 versions - conférence et journal ...
qui finalement a envahi tout ce mail, ce qui n'était pas mon intention au départ - mais allons-y!
D'autant plus que la conférence ECCS vient de se terminer : d'une part, il
faudrait que tu intègres les parties de génération de programme, booklet
of abstracts et proceedings que Bertrand a faites. Mais d'autre part,
l'édition 2006 est déjà programmée, et aura elle aussi besoin des 3
niveaux de reviewers : l'éditeur en chef, les éditeurs membres du PC, et
les reviewers (attention, si l'on compte ce qui est maintenant appelé
dans la nouvelle version "external reviewer", c'est-à-dire la possibilité
pour 1 reveiwer de sous-traiter, cela fait 4 niveaux).
Il me semble donc utile de rendre optionnel ce niveau intermédiaire entre
le program chair et les reviewers.
Une autre petite chose qui serait bienvenue dans la version ECCS et la
notion de "type de papier": dans ECCS par exeemple, les gens peuvent
soumettre des papiers longs, courts ou des posters - et le comité de
programme ne s'est pas privé de basculer des papiers d'une catégorie dans
une autre (et de nombreuses conférences ont au moins les notions de
papiers et poster).
Autre chose qui est présent dans la version journal que j'utilise, c'est
la notion de version de papier - et, comme nous en avons discuté un jour,
cela est aussi utile pour certaines conférences (dont ECCS): actuellement,
dans la version conférence, la seule chose qui s'en rapproche est la
notion de camera-ready. Il me semble que la notion de version n'est qu'une
généralisation de la notion de camera-ready. Mais attention, la notion de
"version" devrait être intimement liée à la notion de "state (cf + bas)
car actuellement, ce qu'a fait Jérome est quelque chose qui est incrémenté
à chaque fois que l'auteur uploade un fichier, ce qui arrive quelquefois
plusieurs fois dans les 2-3 jours qui suivent la soumission initiale: il
faudrait que le numéro de version ne soit incrémenté qu'après un round de
reivew et une décision "revise and resubmit"
Enfin, il reste cette idée de "state" (indépendant du "status", qui lui
reflète la décision finale d'acceptation).
Mon idée du state est qu'il doit refléter à quel endroit du processus de
review le papier en est.
Par exemple (à affiner):
Just submitted<br>
sent to editor (s'il y a le niveau "editor")<br>
sent to reviewer<br>
discussion among reviewers opened (s'il y a lieu)<br>
review process completed (il y a eu une décision)<br>
et éventuellement, si doit être révisée<br>
under revision by authors<br>
ou, si est acceptée<br>
waiting for camera-ready<br>
La variable "frozen" serait alors mise à jour en fonction de l'avancement
Dans la version journal, il y a une version "manuelle" du state, mais
inutile de te dire que ce n'est jamais à jour, pusique c'est moi qui suis
censé faire défiler les diverses options ...
VOilà ou j'en suis - sachant qu'il va falloir d'ici début janvier disposer
d'une version opérationnelle pour ECCS.
Serais-tu d'accord pour discuter d'un plan d'action pour tout ça, un de
ces jours (au LRI ou ailleurs, d'ailleurs!)
Amicalement
Marc