Amélioration des outils de validation

Besoin de vos avis de validateurs⋅trices habitué⋅e⋅s

a marqué ce sujet comme résolu.
Auteur du sujet

Équipe technique

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.

Édité par Amaury

#JeSuisArius ⋅ Mon blog scientifiqueLe Pitit Bac

+3 -0

Cette réponse a aidé l’auteur du sujet

Salut,

Je pense que les diff sont le point noir de l’interface actuelle.

Un truc qu’on ne peut pas faire facilement est un diff entre deux versions qui ne sont pas sur la même page de la liste de commits. On est obligé de copier/coller le hash dans l’URL.

L’affichage du diff est perfectible aussi, notamment avoir les fichiers dans l’ordre du tuto plutôt que l’ordre alphanumérique de leur nom, ainsi qu’avoir des liens vers le rendu (notamment pour vérifier les images ou la mise en page par endroits). Typiquement, simplement avoir les noms des sections rendus correctement avec un lien vers le rendu effectif d’une version ou de l’autre à la place des noms de fichiers améliorerait la chose considérablement.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+5 -0

Cette réponse a aidé l’auteur du sujet

D’accord avec @dri1

Globalement je suis plutôt satisfait du système de validation.

Ce qu’il me manquerait ce serait un système de surlignage et commentaires pour plus facilement reporter mes commentaires à l’auteur sur son texte. Actuellement je dois c/c chaque passage, et c’est ce qui prend bêtement le plus de temps dans l’acte de validation.

Cela permettrait aussi un meilleur suivi de si mes commentaires sont bien pris en compte …

+3 -0

Cette réponse a aidé l’auteur du sujet

Ce qu’il me manquerait ce serait un système de surlignage et commentaires pour plus facilement reporter mes commentaires à l’auteur sur son texte. Actuellement je dois c/c chaque passage, et c’est ce qui prend bêtement le plus de temps dans l’acte de validation.

Cela permettrait aussi un meilleur suivi de si mes commentaires sont bien pris en compte …

Holosmos

Je ne suis pas validateur, ceci étant un tel système pour les cours de manière générale serait top. Pour ma part, c’est à cause de ça que je ne fais pas de retours poussés sur les cours en bêta. C’est beaucoup trop long et fastidieux.

Développeur Symfony

+0 -0

Cette réponse a aidé l’auteur du sujet

J’appuie ce qui a été dit à propos du diff et des commentaires.

J’ai aussi des pistes d’améliorations pour la liste des contenus en validation, même si c’est utilisable en l’état.

Dans l’idéal, j’aimerais pouvoir en un coup d’œil (sans clic, sans filtre, sans aucune autre action) et très facilement :

  • distinguer les contenus réservés de ceux qui sont en attente ;
  • pour les contenus en attente, voir l’ancienneté de leur dernière activité (i.e dernière mise à jour ou déreservation si on a l’info) ;
  • de même pour ceux réservés (dernière mise à jour, dernier échange avec l’auteur, …)
  • distinguer rapidement mes réservations de celle des autres ;
  • voir la taille du contenu (article / tuto, mais ça pourrait aussi être autre chose qui mesure la taille).

Actuellement, on a plus ou moins toutes ces infos, mais elle sont fournies brutes et ça ne permet pas de les voir en un coup d’œil.

+3 -0
Auteur du sujet

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) ?

#JeSuisArius ⋅ Mon blog scientifiqueLe Pitit Bac

+0 -0

Cette réponse a aidé l’auteur du sujet

Ce serait bien pendant la validation d’avoir une persistence des commentaires à travers les différentes versions. Un peu à la Google, oui.

La persistence permettrait de suivre ce que fait l’auteur, et de ne pas bêtement devoir chercher tous les commentaires dès qu’une petite modif est faite.

Mais une fois la validation effectuée, il faudrait pouvoir en garder un historique (pour une maj importante qui va suivre par exemple)


C’est vrai qu’en y pensant c’est un peu bordélique, mais c’est parce que ZdS ne détache pas le fond de la forme. Ce qui fait que quand on valide un contenu, celui-ci est modifié dans sa forme et dans son fond simultanément. Si l’on avait un système qui distinguait les deux, ce serait beaucoup plus simple de commenter le contenu qui décrit le fond, et ces commentaires n’apparaitraient pas une fois que la mise en forme est faite

+2 -0

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 :

Si le commentaire fait parti du markdown et qu’une personne extérieure rajoute du texte (certe un commentaire) dans mon contenu, ça ne fait pas de lui un auteur potentiel ? Est-ce que c’est compatible avec toutes les license ?

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)

Si un commentaire = un commit l’historique risque d’être pollué non ?

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.

Aujourd’hui toute les étapes (brouillon, beta, validation, publication) du contenu est géré sur la même branche. Comment on fait des commentaire sur la beta sans impacter la version brouillon.

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.

Édité par firm1

+0 -0
Auteur du sujet

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épondues1, 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.


  1. Pour la première, on ne modifie pas techniquement le contenu, mais on l’annote. En soit, la technique importe peu dans ce cadre là : ok, on modifie le même fichier mais ça n’altère pas le contenu en lui-même. Pour moi c’est donc un faux problème. Pour la seconde question, comme tu dis, il suffit de minimiser le nombre de commits en ayant une interface dans le style des reviews de GitHub, où l’on envoie tout d’un coup à la fin. Et il est également tout à fait possible d’ajouter un marqueur dans le message de commit qui minimiserait ces commits-là dans l’historique.

Édité par Amaury

#JeSuisArius ⋅ Mon blog scientifiqueLe Pitit Bac

+0 -0

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).

Édité par Holosmos

+3 -0

Cette réponse a aidé l’auteur du sujet

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).

Ça, c’est déjà géré par Git. Si tout ce qu’on regarde sont des diff (éventuellement rendus plutôt que sous forme MD brute) avec d’un côté la version avec le commentaire attaché et l’autre la version qui prend le commentaire en compte, on est bon.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+3 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte