Amélioration des outils de validation

Bonjour,

Étant en train de réfléchir aux différentes interfaces de Zeste de Savoir pour les améliorer, je suis tombé sur ma version de développement sur l’interface de validation, et le fouillis que ça m’a semblé être. @Aabu m’a confirmé qu’en effet, ce n’était pas des plus pratiques.

N’étant pas validateur, j’en viens donc vous demander votre opinion :

1. Êtes-vous satisfait⋅e de l’interface de validation actuelle ? Si non, que lui reprochez-vous ?
2. De quoi avez-vous besoin au quotidien sur cette interface, que ce soit actuellement présent dessus ou non ? (Pensez à tout ce que vous faites manuellement en allant le rechercher ailleurs et qui pourrait être intégré directement, p.ex. l’accès au MP de validation…)
3. Qu’est-ce qui vous semble être le plus important dans le cadre de vos actions de validation ?

Merci d’avance pour vos retours.

D’accord avec @adri1 @Holosmos et @Aabu

Je pense qu’en tant que validateur, une fois corrigée on aura un truc vraiment bien pour notre usage.

Merci pour tous vos retours ! Certaines choses sont assez simples à mettre en place ; d’autres (hum — les commentaires), moins.

Concernant ces derniers, pensez-vous à un système “a la Google Docs” où les commentaires sont persistants au fur et à mesure des modifications, ou un système où un commentaire est simplement attaché à une version du contenu (plus comme ce que ferait, par exemple, GitHub, même si lui les met dans les commits) ?

Pour les commentaires, il existe une version officieuse de markdown pour faire ça… Ça peut être quelque chose d’envisageable ?

Ce serait bizarre d’intégrer ça au code source du contenu.

Dans la même veine de ce que propose @qwerty, mais différemment, pour l’histoire des commentaires, je me demande si l’on ne pourrait pas se servir justement des commentaires de notre markdown.

Le principe

Aujourd’hui, la syntaxe de notre markdown, nous permet d’insérer des commentaires en balisant le contenu de notre texte par <--COMMENTS ceci est une partie commentée. COMMENTS-->. Et si on l’utilise pour gérer la review/commentaire sur notre markdown, on en tire beaucoup d’avantages et forcément des inconvénients.

Dans l’idée donc, on pourrait cliquer sur un mot, une phrase ou un paragraphe, on aurait un bouton "insérer un commentaire". En cliquant dessus on a une modale, dont le seul but est de receuillir le texte qui sera insérer après le curseur de texte. Lors de l’affichage, (à supposer que notre parseur markdown arrive à nous renvoyer les commentaires avec leurs numéros de ligne sous forme de métadonnée) il suffirait d’afficher les commentaire en dehors de la zone de lecture (comme sur Google docs par exemple)

Avantages

• Le commentaire est porté par le markdown, ce qui veut dire que le commentaire est versionné avec le contenu (ça en fait un dépôt git auto portant donc pas besoin d’une base de données a coté pour lire les commentaire)
• L’auteur en modifiant les sources de son contenu, a à portée des yeux le commentaire du relecteur, il peut, dès qu’il traite un commentaire supprimer lui même la balise commentaire pour ne plus avoir le commentaire affiché par la suite.

Inconvénients

• Le contenu de ce qui est dans la balise COMMENTS, dans l’idéal doit être formaté (json ? xml ?) pour pouvoir a minima renseigner l’auteur et la date du commentaire.
• C’est quand même vachement verbeux quand il y a beaucoup de commentaires

Quelques questions

J’imagine que certaines questions peuvent revenir sur le tapis comme :

Je n’ai pas de réponse à donner, mais dans le pire des cas, on pourrait imaginer que les commits généré par les commentaires soient sur une branche dédiée (un contenu étant un dépot git)

Pas forcément, l’interface doit encourager à faire toutes ses reviews "en mémoire" et poster le tout d’un coup dans un seul commit.

Il faudra visiblement séparer chaque étape sur plusieurs branches. Ce qui est visiblement le plus difficile techniquement parlant.

J’avoue, pour avoir déjà réfléchi à la question sur papier, cette façon de faire me semble la plus réalisable techniquement sans trop se planter.

Après il y a peut-être des points bloquant qui m’aurait échappés, mais à première vu ça ne me semble pas déconnant comme approche.

Clairement, annoter le contenu directement avec des commentaires MD serait le plus simple, et de loin. Même si j’y pensais pas exactement de la même façon, j’avais pensé à cet usage aussi.

Ce à quoi j’avais pensé c’était un commentaire de début et de fin de commentaire (pour indiquer ce qu’on commente) avec un identifiant, référençant un fil de discussion en base de données (donc sans tout stocker dans le fichier MD : on n’y garde qu’un pointeur). Dans cet esprit :

Un texte <!--COMMENTS COMMENT:821:START COMMENTS-->qui parle de toasters
électriques<!--COMMENTS COMMENT:821:END COMMENTS--> et nucléaires.

Même si j’admets que ce que tu listes dans les avantages est également intéressant.

Mais dans les faits c’est compliqué. Tu poses trois questions, @firm1, et si je pense que les deux premières sont vite répondues¹, la troisième est bien plus délicate.

Parce qu’il n’est pas aussi simple de passer à un système de branches. Actuellement, certes le contenu est stocké dans un dépôt git, mais on considère que le système de fichier est la référence de ce qu’on affiche à l’utilisateur. Si on passe à un système avec une branche par version (bêta/publiée/brouillon), il faudra passer le dépôt en headless et lire les fichiers depuis .git et non plus depuis le système de fichiers (comme ce que font GitHub/GitLab/etc.). Ou a minima, faire ça pour la branche beta. C’est faisable, mais ça implique pas mal de changements, et j’ignore ce que ça peut donner en terme de performances.

On ne peut pas se contenter de faire des checkout car ça pourrait poser des soucis assez dramatiques en cas de modifications de plusieurs versions par plusieurs personnes en même temps (exemple, une personne qui regarde ou commente la bêta (impliquant un checkout beta) alors qu’une autrice publie une nouvelle version sur la branche brouillon). Ou alors, il faudrait un système de verrou qui met l’un ou l’autre en attente le temps que l’opération soit terminée.

Et si on modifie la branche beta en ajoutant des commentaires, il faudra faire attention aux soucis de conflits de fusion lors de la mise à jour de la bêta. Sauf à faire un pull --force mais alors on perdrait les commentaires (à voir si c’est gênant).

Ou alors il ne faut autoriser l’annotation que de la version brouillon (qu’est toujours la version la plus avancée du contenu au sens de l’historique git mono-branche qu’on a actuellement pour chaque contenu), mais alors on perd la possibilité d’utiliser le système pour la bêta, et ce serait dommage.

J’adorerais pouvoir trouver un système permettant d’identifier un extrait de texte dans un texte brut plus long sans modifier le texte, et qui soit fiable au fil des modifications (peut-être quelque chose à base de diff/blame ?). Mais je n’ai rien trouvé de satisfaisant encore. Ça permettrait de pouvoir annoter un contenu sans modifier le moindre fichier, ce qui serait bien plus propre à mon sens.

Bref. Ma réflexion est encore en cours. Je ne maîtrise pas non plus le code de tutorialv2, donc il est peut-être plus simple que ce que je ne le pense de passer sur un système de branches.

Pour la même raison que je ne modifie jamais le texte des auteurs que je valide, je ne suis pas convaincu par l’intégration des commentaires dans le texte.

C’est peut-être du pinaillage, mais il faut séparer le texte de l’auteur des commentaires, sinon c’est le bordel et on sait plus qui fait quoi. Amha il faut que les commentaires de validation soient créés et validés (= clos) par le validateur, et donc ne pas laisser l’auteur les gérer mais seulement y répondre et modifier son texte.

Comment cela pourrait-il se faire ? Il faut d’une façon ou d’une autre avoir un systèmes d’ancres dans le texte pour pouvoir lier les commentaires à des endroits spécifiques. Ensuite un fichier séparer de commentaires qui recenses les commentaires du validateur. Il faudrait faire attention à comment l’ancre est gérée selon la modification du texte mais on peut très bien imaginer une version de validation où le texte ne peut jamais être supprimé mais seulement barré (et sera supprimé à la fin de la validation).